An alternative approach is to implement the smallest suite of changes that can achieve tangible benefits. A smaller change can be implemented quicker, providing earlier feedback on our overall change approach. In the context of starting a larger transformation, we want to accelerate our learning necessary to understanding what will work for the larger organization.
Quick and tangible results are a great way to prove the case for larger, more ambitious change efforts. Early success helps mitigate resistance from naysayers, and provide the organization with confidence
to invest further and deeper into subsequent change efforts.
This type of change can be modeled after the Quick Win pattern. Here is the pattern illustrated below using our Change Canvas.
The Quick Win is typically targeted at a small number of eager adopters, think of a medium-size team, approximately 6-10 FTEs, with 1-2 managers and executives. This type of change is small in scope, short in duration, and targeted at a few immediate practical problem.
When asking change stakeholders to participate in this kind of change, you're asking them to commit the time required to learn a small number of new techniques, with the promise of improved performance, perhaps after no more than 6 to 9 weeks.
Kanban Is the Ideal Method for Implementing a Quick Win
For obvious reasons, Kanban is an excellent choice for implementing quick results with a minimum of impact to the people being asked to change. When helping an organization start an agile transformation, I frequently look to the organization for one or more maintenance/enhancement groups responsible for supporting one or more production applications. These groups have a steady flow of demand, a well established client base, and a (usually) stable budget to service a set of applications. These groups also have a catalog of different work types that can be easily grouped into different classes of service. These conditions are ideal to implement the Kanban method, and get meaningful results in a relatively short period of time.
Here is our example of a Kanban adoption, again illustrated using our Change Canvas.
Kanban adoption can be initiated by collaborating with potential change stakeholders to conduct root cause analysis, and suggesting some tactical improvements to improve the flow of work. Some analysis may be performed to understand current capability in terms of throughput and lead time.
A Kanban system is designed, reflecting the maintenance group's current process as much as possible. Work is then typically onboarded onto a visualization system, known as a Kanban board. A coach can assist change stakeholders in adopting a variety of techniques necessary to achieving stable performance, and eventually continuous improvement. These techniques include limiting how much work is in process, establishing a set delivery cadence, establishing issue escalation capability, establishing quantifiable improvement capability, continuous adaptation of procedures and policies based on bottlenecks, and crowd swarming.
As performance stabilizes, different queues can be opened up to different customers, with service delivery promises, an agreement that the maintenance team makes with its customers based on how much value it can deliver over time, established using current performance metrics.
Adopting Kanban into one or more maintenance teams is a great prequel to a larger agile transformation effort. You'll quickly find out which if any members of the organization have a predilection for visual style management, good client negotiation skills, and the ability to collaborate across departmental boundaries to solve problems, remove impediments, and improve flow. Mastering these skills provide evidence to the larger organization that agile thinking is something that this organization can do. Achieving measurable improvements in delivery performance shows that are real
Interesting article, Jeff. Doing large implementations of software such as our ALM product - SwiftALM - we have always encouraged the same approach of quick wins through incremental steps. That has not always been easy as large clients want a big effort upfront to design and implement a solution for the full organization. Wherever we have been successful in convincing our customers, we have seen greater - especially faster - success, than where we have not.ReplyDelete
Using Kanban (not just our tool SwiftKanban but the method) as a tool to facilitate this has been our focus since we got into it 2 years ago. I am curious if you and your teams have seen examples where the lead was taken by software development teams rather than maintenance teams, where the focus on fixed-priced projects seems to make them averse to doing anything Agile, especially Kanban.