Planning and managing changes using a Change Canvas has allowed our team to recognize a reoccurring set of agile change "patterns". Change agents can review these patterns when looking for a source of inspiration on how to structure the different elements of a Minimum Viable Change. We've represented these patterns using the Change Canvas, providing a visual and compact way to articulate and discuss the different aspects of these patterns. This is just an initial list, hopefully others will be able to add to the catalog over time.
The Quick Win
Agile and Lean transformation are at their greatest peril when they first start. 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.
The Quick Win is typically targeted at a small number of eager adopters such as what could be found in a medium-size team approximately 6-10 FTEs. No more than 1-2 managers and executives should be impacted at direct stakeholders. The idea is to make sure that the Quick Win is targeted at a small number of change recipients, and that those change recipients are capable of acting as a true guiding team and champion for larger change initiative.
The Quick Win should be targeted at solving a few immediate and tactical problems. Obviously, we are not looking at a strategic or long term return on investment, the value here is showing some kind of return within a month or two of effort.
The Quick Win should also be small in scope, adopting agile method, or perhaps a couple of closely related methods. Examples here include helping teams get started with Kanban or Scrum, or some Agile Modeling.
Commitment often comes in the form of some part-time coaching, a couple of days of upfront training, as well as the appropriate amount of time, perhaps no more than 6 to 9 weeks to learn the new techniques. Benefits of this kind of change include change recipients being successful at the new method as well as receiving some reasonable performance benefits in the short term. Success criteria is likewise measured in terms of the number of people who improve in relating capability, and could also be measured in terms of improved velocity, lead time, or quality.
The communication method should largely be in person, we want to support quick feedback, and potentially drastic changes in direction, this is harder to do when engaging with distributed teams.
Again, this type of change is typically considered earlier in the context of a larger agile transformation. We want to tackle resistance to an agile transformation through delivery of early value. This is a good way to validate an isolated component of a larger agile transformation. This type of change is also really good for validating adoption tactics, as well as determining if the relationship between commitments and benefits are remotely correct. Be ready to pivot on this point, as the effort to commitment is extremely hard to determine upfront.
Below is an example, a favorite Quick Win of ours improving business agility through adoption of the Kanban method.
The Kernel Pilot
After a number of Quick Wins have been executed within an organization, there can be enough momentum to execute a more ambitious change, one that more broadly reflects the organization's suggested true North. Previously implemented Quick Wins should have provided some validation on different aspects of the potential target state, adoption actions, and overall effort, reducing risk of attempting something a little larger.
A Minimum Viable Change using the Kernel Adoption pattern is typically targeted at an entire value stream, from intake all the way to support, and all the steps in between. Often this can be represented as one "line of business" of the organization. It is crucial to involve managers and executives, both from the perspective of capability management as well as issue escalation and resolution. The change should be directed against problems that are also drivers for the overall agile transformation, for the change to be truly valid, it should address most of the drivers behind the overall transformation.
The target state for this Minimum Viable Change should serve as a reference point for the desired state of the overall organization. Once this Minimum Viable Change is complete change recipients should be using new methods, possibly in a flatter, more network-based organizational structure, potentially leveraging new, wider role definitions.
Immersive coaching, facilitation, and even embedding experienced experts within delivery teams is often required to successfully help change recipients shift to new methods. As the choice of methods and techniques become stable, some effort can go into developing and socializing a light weight methods library.
The larger scope and scale of this type of Minimum Viable Change means that a bigger commitment is required. Our experience is that it can take anywhere from 3 to 6 months to execute, and may require 1 or even 2 full-time change agents.
Benefits come in the form of improved performance and improved capability, but also in the form of validation; the kernel pilot can be thought of as a beachhead for the larger organizational agile transformation, and is the first cohesive step into this new direction.
Again, it is often safer to implement a Minimum Viable Change based on the kernel pilot after one or more Quick Win style changes have been successfully executed, this will reduce the risk of adopting the wrong kernel.
As this change reflects the first time that different components of the target state have been adopted at the same time there will still be significant learning, expect to adjust on all elements of the canvas, and even pivot on the target state.
The relationship between commitments and benefits may seem off at this point in the transformation. This is because a significant amount of learning is still taking place, don't panic if a lot of handholding is still required at this point, optimizing the learning effort across the organization can take place later. Remember that the purpose of the change using this pattern is to try to get a first foothold on the overall target state of the organization.
Below is an example taken from our real world experience, where we helped the knowledge workers within one product delivery group to adopt a cross functional, co-located agile team model supported by a number of management, planning, and modeling methods. This agile "suite" was our suggested stack for the target state of the majority of the organization, and executing this change on a smaller group allowed us to refine the stack as well as the remaining assumptions within the change model.
Kernel Adoption
As one or more Kernel Pilot is implemented within the context of a single agile transformation, the transformation can evolve out of pilot mode and into adoption mode. An MVC following the kernel adoption pattern is less concerned with validating change solutions or change tactics, and more focused with trying to optimize the rate of adoption, converting a transformation from a high touch/high support approach to one that is more based on self-study, peer-to-peer sharing, and evolutionary improvement.
As an agile change is rolled out across the organization more effort can go into refining, publishing, and socializing training guides, methods, and other tools that can help knowledge and learning scale to a larger audience. Change agents should be spending more time training other members of the organization to be true change champions, agile knowledge experts, and owners of any methods or tools. High touch, in person coaching can now start to be graduated with other learning methods that can scale out to the entire organization including self training, online knowledge repositories, and communities of practice.
The target state for an agile transformation is never "done", so some aspects of the change solution will continue to require validation and potentially change in direction.
Self-Starter
a Minimum Viable Change modeled on the Self-Starter pattern attempts to provide an opportunity for change recipients to guide their own adoption. Various improvement methods such as training material, peer working sessions, scheduled times for change recipients to attend "tutor drop ins", and mentorship programs are used to allow employees and management to self select their learning pace.
Both new employees as well as those targeted for later adoption will require the means to educate themselves on how the organization is trying to deliver, sometimes long after an agile transformation is considered "complete".
A Self-Starter can also be useful in that it provides employees with permission to start moving to new approaches in advance of any "scheduled" adoption plan. The Self-Starter is also considered "safe", adoption takes place at the comfort level and pace of change recipients. Sometimes, curriculum and pull-based tutoring needs to be complemented with some kind of organizational incentives to adopt, this can be as simple as recognition for employees who have achieved a certain level of capability.
Supporting self learning can take more effort to set up initially, especially if new training material and/or capability models are not already available. Some internal marketing and finally a change recipients may also be required as the Self-Starter kicks off.
It's often recommended to support this effort with at least some kind of part-time tutoring which can be either scheduled or on an as needed basis. When supported properly, this kind of change scales well, and more than makes up for the initial effort. Besides providing the organization with the improved performance that comes with better capability, heightened morale can lead to better employee retention. A good Self-Starter program will continue long after the agile transformation is considered "over".
As stated previously a Minimum Viable Change following this pattern is better introduced later within the context of an agile organizational transformation. The overall approach and applicability of any particular methods should have already been validated thanks to one or more previous MVC's. Validation for a Self-Starter comes from testing whether employees within the organization can improve independently and "pull" help when and if required. Change agents should also be looking for ways to optimize the benefits gained compared to the commitments required.
The example below is taken from an agile transformation that I was a part of. Midway through the transformation it became clear that we did not have enough coaches to support the demand to assist various teams in adopting agile methods. We had already conducted a number of pilots across the organization and had enough training courseware and other material to support the notion of a self-starter. This will provide an avenue for employees who wanted to get started with agile but did not want to wait for dedicated coaching assistance.
This self-starter consisted of some guidelines and training exercises that would get them familiar with basic agile methods such as iterations, using user stories, and collaborative planning. We published this material to the corporate intranet, and announced a weekly 3 hour drop-in where anyone interested could receive coaching and assistance and have their questions answered relating to any of these techniques.
Capability Modernization
True improvements for many organizations will mean taking an honest look at current capability, methods, and techniques and revitalizing them to support business agility. A Minimum Viable Change following the Capability Modernization pattern is focused on improving delivery and/or management techniques for a functional capability within an organization. In more traditional organizations this often mean a functional department, in more modern agile organizations this will mean a collection of employees who can fit into a particular role. Examples include retooling all of the developers within an organization, or providing training and coaching on agile management techniques for all managers and executives.
A change following this pattern typically targets a larger set of change recipients, i.e. all employees that fit within a similar role (e.g. all testers). Any managers responsible for building capability for that role will also be similarly impacted.
Effort should be focused on building a number of "capability gurus" who can act as knowledge leaders and method owners of the new approaches.
Organizations tend to consider the Capability Modernization pattern when things are truly "broken", expertise across the function is considered to be legacy at best, and the current level of maturity is causing a noticeable and growing impact in performance and is having a visible impact on business outcomes.
The target state for this pattern is a complete refresh in terms of capability for that role, including career path, required skills, training and other tools and accelerators. This considerable investment may involve restructuring the organization from a more traditional specialist model to a more horizontal one, and rethinking how careers within the role can progress based on expertise.
A clear and graduate curriculum is often developed, and then introduced onto projects using a rolling wave approach. An effective approach can be to require that all training homework be conducted on real project work. A combination of hiring externals, as well as mentoring existing employees is used to help build a team of capability gurus. These capability gurus act as senior keepers of the flame, and are responsible for ensuring continued commitment to excellence and quality found in the best of agile organizations.
This type of Minimum Viable Change requires a lot of investment on behalf of the organization. Staff wishing to become gurus, need to commit the time required to master new skills to the point where they can train others. Girls need to be carefully selected, not everyone is cut out for this kind of dedication.
Methods and tools, and the training curriculum to support them need to be adapted to the context of the organization, and the training capability needs to be developed as well. This is also a significant investment.
Finally, deep and meaningful change in terms of adopting new methods will take time, this type of change will typically take months to execute. Several full-time, and senior change agents are often required to support this type of change pattern, and be change agents must have years of experience in the selected methods and techniques.
When this type of change is done correctly, benefits to this type of organization are significant. Improvements in capability lead to higher quality, which lead to significant and sustainable performance increases over time. There are no real shortcuts to improving delivery outcomes. Equally important, is that this type of change shows a willingness to invest in people's careers and in their capability, which improves morale.
In the context of a larger agile transformation, a change following this pattern should be done later, a number of Quick Wins, Kernel Adoptions, and even Self Starters should have already been introduced to the organization, providing feedback on what works and what doesn't. Large portions of the transformation will already been validated, key learnings from this Minimum Viable Change will come in the form of understanding how we can scale out the change to the rest of the organization.
A good example of this kind of change would be trying to achieve a state of "technical excellence" through adoption of methods that can be found within the software craftsmanship movement. This includes techniques such as test driven development, SOLID development techniques, continuous integration and continuous employment, perhaps even to adoption of some DEVOPS techniques.
Read More Lean Change - Chapter 3: Advanced Change Canvas Topics
- Using Plug-Ins to Explore the Urgency and Change Recipient Sections
- Using Plug-Ins to Explore the Vision and Target State Sections
- Using Plug-Ins to Explore the Actions and Success Criteria Sections
- Using Plug-Ins to Explore the Benefits and Commitment Sections
- Using Plug-Ins to Explore the Communications Section
- a Catalog of Reusable Agile Change Patterns
This comment has been removed by the author.
ReplyDelete