The Validated Change Lifecycle State 1: Agree on the Urgency of Change

The first state within the Validated Change Lifecycle that a Minimum Viable Change passes through is the Agree on Urgency state.



In this state focus on connecting a set of problems/urgency with a group of change recipients who care enough to participate in a potential change. The process of connecting problems to a potential guiding theme is an iterative process.



Change agents will interview various potential change recipients to examine their pain and problems, and see if they can come up with a form a guiding team to act as change champions for the suggested change.



As problems are identified, potential change recipients can be evaluated informally based on their ability to participate in coming up with solutions and countermeasures.



Ideal change champions will be ones who demonstrate experience in actually fixing problems and trying to come up with the solutions in the past. Our experience is that many organizations have employees who have practiced what we call "guerrilla agile", adopting one or more methods and practices without necessarily having organizational authority to do so, agile change agents should seek these people lie within the organization and target them for the first wave of change champions who can form a guiding team.



When a minimum viable change is in the Agree on Urgency state, change agents want to focus on identifying a set of problems that can go into the urgency section, and more importantly connecting those problems to a set of potential change recipients who feel that urgency enough to act as a guiding team, one that will help co-create and co-execute the potential change.

It's perfectly normal for the identifying label of the minimum viable change to be modified as it goes through the lifecycle. The beginning of the process the suggested change may have a very generic title, such as "implement agile methods with a specific team". As more information is understood about the potential change stakeholders will be and what the problems are, the title can reflect an agreed-upon vision.



The minimum viable change will be ready to enter the "negotiate change" state once the change agent has found a set of change recipients who are willing to commit to co-defining a change solution.

Read the Rest of Lean Change - Chapter 4: the Validated Change Lifecycle

1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
2. State 1: Agree on the Urgency of Change
3. State 2: Negotiate the Change
4. State 3: Validate Adoption
5. State 4: Verify Performance
6. Realizing a Change Canvas through the Validated Change Lifecycle
7. Instantiating the Lifecycle Effectively Using Information Radiators

Realizing the Change Canvas Through the Validated Change Lifecycle

As change agents and change recipients take a Minimum Viable Change through the Validated Change Lifecycle different sections of the Change Canvas become validated through a number of different methods.

In this post I'll provide a summary of how our team has been typically validating the canvas depending on where it is within the lifecycle.

It is common for a change agent to create a draft canvas as soon as he feels that a change would be a benefit to one or more change recipient groups.



Upon entering the  Agree on Urgency  state the change agent may put a little more  thought into the urgency and change recipient sections to prepare for initial conversations with stakeholders. Remaining portions of the Change Canvas will  often only contained cursory notes or initial guesses as to what the contents would be.



As a Minimum viable change passes through the Agree on Urgency state the Urgency and Change Recipient sections of the canvas are validated through discussion with one or more change recipients. It is typical for the Targets, Vision and potentially other sections of the canvas to be given further consideration as a result of these discussions.


When the Minimum Viable Change passes through the Negotiate Change state the change recipients and change agent discuss how the Vision and Target State sections could address the various problems stated in the Urgency section.


Work then progresses on agreeing on a set of Action Items, Commitments and Benefits. After the majority of the canvas is completed, Success Criteria can be defined for the Change Canvas.


When the Minimum Viable Change passes into the Validate Adoption state, a backlog of Improvement Experiments are created. Each of these Improvement Experiments are responsible for validating that the actions listed in the Actions section will help change recipients move towards the Success Criteria defined boundary in the Change Canvas.


As improvement items are moved through the improvement lifecycle of Prepare, Adopt and Learn, various portions of the canvas are validated from a behavioral perspective. Can change recipients successfully use the new methods?


Once the Minimum Viable Change moves into the Verify Performance state Improvement Experiments are now executed, but this time improvement items are evaluated from the context of improved performance. Again as improvement items are moved through the Prepare, Adopt, and Learn lifecycle the Change Canvas is evaluated for correctness, this time from the perspective of performance. Can change recipients operate in a more effective manner because of the suggested change?


Read the Rest of Lean Change - Chapter 4: the Validated Change Lifecycle

1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
2. State 1: Agree on the Urgency of Change
3. State 2: Negotiate the Change
4. State 3: Validate Adoption
5. State 4: Verify Performance
6. Realizing a Change Canvas through the Validated Change Lifecycle
7. Instantiating the Lifecycle Effectively Using Information Radiators

Accelerate Change Learning through the Validated Change Life Cycle; leveraging Kotter, Kanban, and Lean Startup

During previous posts I've discussed how change agents can collaborate with change recipients to negotiate their way to a successful change solution.



I've also discussed how a change canvas can be refined so that the change is minimal, as well as subjecting it to explicit experimentation to ensure that it is viable. This allows us to incorporate the concept of validated learning .




During this post I'll continue to build upon these previous topics, going over the Validated Change Lifecycle. The validated change lifecycle provides a path for minimum viable changes to be developed and validated in a way that maximizes feedback and learning.


Why Do We Need a Validated Change Lifecycle?

Change initiatives face a multitude of risks all of which can derail any chance of a positive outcome.



Using the Validated Change Lifecycle risks and assumptions that tend to impact change initiatives first can be dealt with earlier. Other risks and assumptions that impact change initiatives later can be deferred until it makes the most sense.

Change agents who elect to follow the lifecycle are able to learn faster about whether a particular change is viable. The idea is to provide feedback with less effort, so that a decision around whether to pivot or pursue or abandon can be made earlier.

As described in previous posts, validating a change requires subjecting the assumptions contained within a Change Canvas to experimentation. Each assumption can be expressed as a hypothesis, which is then tested for correctness. The Validated Change Lifecycle provides guidance to determine which assumptions to validate first, based on the severity of the risk inherent in the assumption.


An Overview of Key Risks Faced by Agile and Lean (or Any) Change Initiatives
Perhaps the most significant risk of any change engagement is one of resistance. Changes that seemingly make the most sense to everybody involved can still face significant and/or passive resistance when change agents try to execute these changes. Organizations and the people that are employed in those organizations possess very robust antibodies that are able to resist any challenge to the status quo regardless of implied benefits.


Even when organizations and people within them have a genuine desire and willingness to try out new methods and techniques such as agile or lean, there's still a question of sustainability. Many Change initiatives start with a bang, and then fizzle out over time. Change recipients become burned out trying to adapt to the new models and new methods of working and change programs become only partially completed. Many Change plan simply did not come to fruition because he not adequately assess how much commitment the organization can actually contribute to the change.


Finally, even when resistance has been adequately dealt with, and the pace of change is sustainable, any upfront change plan may simply specify the wrong solution. If you remember from the beginning of this course we discussed how detailed planning and upfront design is Not suitable for developing products in highly uncertain and variable markets. This is especially true when trying to define a change management solution that changes the way people behave and work within an organization. Change agents expecting any predefined change solution to survive completely intact throughout the lifecycle of the change initiative is facing certain disappointment.


The Validated Change Lifecycle Is Inspired by the Kotter "Eight Steps of Change" Model
John Kotter, in this text "the heart of change" describes an eight step change lifecycle. John describes a number of case studies showing how change agents work within an organization to enact significant change following these steps.

Step number one is establishing a sense of urgency, insightfully, John believes that most people are at least subconsciously aware of what is wrong with an organization and so starting with a target state or vision is the wrong way to go. Instead, successful change agents should focus on establishing a sense of urgency within the organization.


A good outcome from establishing a sense of urgency is finding enough concerned people within the organization who are willing to form a guiding team that is willing to tackle the sense of urgency being felt.


The guiding team then works on a change vision, a "true North" that can help guide the activities of this change.


Subsequently, the guiding team works on communicating as necessary to establish by across all change stakeholders and others impacted by the change


Executives, sponsors and stakeholders are all responsible for empowering action so that the guiding team can make the changes necessary to realize the vision



It is critical that the guiding team structure their change management effort so that they receive wins in the short-term, and not structure their change management activities so that benefits are loaded


The team, and its sponsors and stakeholders have to be careful to approach change in a sustainable way, and not giving up partway through


After the organization receives tangible benefits, effort switches to making sure that change sticks, and becomes a cemented part of the organizational culture


You may have noticed that much of the language and ideas contained within these eight steps are reflected on our change canvas. In fact most of these steps more or less a line to one of the change canvas components

What this means is that each section within the canvas contains assumptions which when validated will mitigate specific risks

When a minimum viable change is broken up into specific experiments each of these experiments can be designed to validate a specific subset of the canvas. Ordering these experiments according to a change management lifecycle allows us to mitigate change risk in the most optimal order.


The validated change lifecycle provides explicit acceptance criteria to determine when a change can move through for specific states
The validated change lifecycle adapts Kotter eight steps of change, into four specific Lifecycle States. This lifecycle was also inspired by Ash Maurya's Lean Startup Product Development Lifecycle described in his book Running Lean.

Minimum viable changes are both defined and validated according to a specific sequence by passing through the lifecycle.


The first state is About Agreeing on the Urgency of why the change needs to take place. Change agents focus their effort on establishing a sense of urgency and connecting that urgency with a set of change recipients who are willing to form a guiding team. This guiding team acts as a set of teams champions for the potential change.

In the second state change agents work with the identified guiding team and change champions to Negotiate the Change solution, develop a vision for the change as well as the target state. The important part here is that is that the solution is cocreated by both the change recipients (s) and change agents

Once the change model has been agreed upon the change is Validated from an Adoption perspective. The key question be answered here is can change recipients effectively change their behavior and improve their expertise in specific methods and skills?

As new skills are acquired, change recipients will start demonstrating new behaviors and new methods. Focus can then switch to whether the change is  verifying performance improvement, we want to ensure that the change is resulting in the right business benefits relative to the commitments required to execute the change.

Instantiating the Lifecycle through a Validated Change Kanban
You may remember that in a previous post we talked about extending a Change Canvas by placing a Kanban system below it to track the lifecycle of specific improvement experiments.

A Kanban system can also be used to visualize the state of Minimum Viable Changes progressing through the validated change lifecycle. As each MVC satisfies the criteria necessary for it to be considered complete within a certain state, it can pass from one column to the next on the validated change Kanban.


Specific acceptance criteria and completion criteria for each state can be marked as a simple work policy under each column within a Kanban system.

This covers my (not so short) overview of the validated change lifecycle, up next I'll provide details on each state within the validated change lifecycle.


Chapter 3: Advanced Change Canvas Topics

1. Using Plug-Ins to Explore the Urgency and Change Recipient Sections
2. Using Plug-Ins to Explore the Vision and Target State Sections
3. Using Plug-Ins to Explore the Actions and Success Criteria Sections
4. Using Plug-Ins to Explore the Benefits and Commitment Sections
5. Using Plug-Ins to Explore the Communications Section
6. a Catalog of Reusable Agile Change Patterns

Using the Change Canvas to Illustrate Agile and Lean Change Patterns

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

1. Using Plug-Ins to Explore the Urgency and Change Recipient Sections
2. Using Plug-Ins to Explore the Vision and Target State Sections
3. Using Plug-Ins to Explore the Actions and Success Criteria Sections
4. Using Plug-Ins to Explore the Benefits and Commitment Sections
5. Using Plug-Ins to Explore the Communications Section
6. a Catalog of Reusable Agile Change Patterns

The Lean Change Method: 1000 Mile View

Why Lean Change?
There are number of key risks to any change initiative faces, the lean change method is an attempt to provide agile change agent with tools and techniques to help manage those risks.
Perhaps the biggest challenge any significant change faces is one of resistance. A combination of fear, resentment, and simple inertia causes groups of people to defend the status quo. This is especially true when) power, politics, and reputation are in question as is so often the case in large organizations.


Even when discounting resistance, many change initiatives install due to a lack of sustainability. Many change efforts start with a bang and ended with a whimper. This is because too much change is introduced to people too quickly, and becomes impossible to balance regular everyday workload with the demands of learning new techniques, methods, and values.


Finally, there is a very real risk that any suggested target state will most likely be wrong. Defining a "correct" target state and implementing it with a "correct" transformation plan often leaves us with a failed change. Running any type of organizational change is often like an act of war, and no plan will survive first contact. Initial assumptions about maturity, commitment, business context, etc. are very likely to be wrong. Following a change plan faithfully could mean that the organization is left with the change that nobody actually wants.

Lean Change Key Themes
The Lean Change method is an agile transformation approach designed to work in the context of these kinds of risks. There are 2 reoccurring themes that are central to all aspects of the method.
1: Negotiated Change
The concept of Negotiated Change is critical to the lean change method. He Negotiated Change approach demands that recipients of any change are co-authors and coal implementers of all aspects of the change or transformation that they are part of. Designated change agents, change stakeholders, and change recipients act as change co-creators, ensuring that suggested changes get the buy-in necessary to ensure that they are successful.
 
 Validated Learning
Because the outcomes of any organizational change initiative is unpredictable, relying exclusively on upfront plans is an exercise in futility. But the caveat here is that any successful initiative requires some sort of planning. The trick here is to balance planning with a feedback rich learning system that can inform all change stakeholders whether a particular change is working or Not. The lean startup method has been a source of inspiration for applying a concept known as Validated Learning.

Validated learning provides an innovative way for knowledge workers to create value in a highly uncertain world. In the lean startup world, product developers are asked to describe features, plans, and other components of a sustainable business as a set of un validated assumptions, they are then scientifically validate those assumptions using a scientific method. Assumptions are described as hypotheses, and then systematically tested to see if those hypotheses, true or false.
Lean Change advocates that any change plan and change target state model also be described as a set of assumptions, and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses. People familiar with the lean startup method will recognize many of the components that we have adapted from this method, making them more suitable for organizational change.
Lean Change Requires Kanban (or Possibly Scrum)
Lean Change provides a method for change agents to execute a planned change initiative, but using a cocreative, collaborative, and learning oriented approach. The Lean Change method does not attempt to replace existing agile improvement techniques, but rather it acts as an overlay to help change stakeholders coordinate and guide suggested improvements.
For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities. This information can be fed from change recipients into the Lean Change method to help navigate the change initiative.

Either scrum or Kanban could be used as this improvement method. Most Lean Change implementations that we are aware of have elected to use Kanban as the improvement method of choice, and then eventually evolved to adopting some elements of scrum that matched their requirements. That being said, it would be very interesting to learn about any case studies that elect to use scrum as the agile improvement method of choice to integrate with Lean Change.

The Lean Change method is a cocreative agile change management and planning approach. Many components of the method had been taken from the lean startup approach, and adapted so that it is suitable for change agents trying to help organizations become more lean and agile.
A Quick Look at the Lean Change Components

Change Canvas
Borrowing a technique made popular by the lean startup community, design and planning is facilitated using a canvas. One of the most foundational pieces of the Lean Change method is the use of a Change Canvas to describe and communicate an agile change plan.

The canvas is an informal "plan on a page", and is a technique that innovators have been using to iteratively design and implement new business models and startups. The lean change method uses the change Canvas in two ways, a MVC canvas describes a small incremental change in data small number of employees, while a transformation canvas describes an organizational transformation initiative. In most cases, when I use the term change canvas, I'm speaking about a smaller change such as an MVC. Often the terms can be used interchangeably, when speaking about canvases used to model larger transformation, you'll see the term transformation canvas being used.

Minimum Viable Changes
The Lean Startup method advocates delivering market facing value in the smallest possible increments that enable learning about whether a particular startup has a sustainable business model. These increments are known as the Minimum Viable Products or MVPs for short.
In the Lean Change method, change agents are encouraged to roll out the smallest possible change that will enable learning whether a particular change will provide sustainable improvement. These increments are known as a Minimum Viable Change, or MVC for short.

Validated Change Lifecycle
Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle. We have defined this lifecycle to maximize the change agents ability to accelerate negotiation and learning necessary to creating a successful change.

Capability and Performance Metrics
Lean Change also provides a number of ways to measure the impact of specific changes. This impact is looked up from a couple of perspectives. The first perspective is the ability of change recipients to adopt, and ultimately excel at new agile and lean methods and techniques. The second perspective is the impact of these techniques on actual delivery performance and value.

Cadence Model of Suggested Meetings and Workshops to Facilitate Large-Scale Agile and Lean Transformations
Managing a large-scale agile transformation can be challenging, so the lean change method provides a model that suggests different meetings and workshops to handle prioritization, communication, status, and overall communication.



The Lean Change Method Is Modular, Components Are Usable In Isolation
The Lean Change method is designed to be modular, change agents can elect to use some of these components and ignore the others, For instance using a canvas to co-create a suggested change with change recipients without using the lifecycle or measurement components is a great way to get started with the Lean Change method. Likewise, we have seen change agents create minimum viable changes and follow the Lean Change lifecycle, without using the canvas or using a modified version of the canvas.


I'm hoping that the Lean Change method can be useful to other change agents whether they be consultants, managers, or staff. I will continue to provide details on each one of these components in future posts.


Check out the Rest of Lean Change - Chapter 1

1. Why Today's Technology Organizations Need to Change
2. Challenges with Current Organizational Change Methods
3. Presenting the Lean Change Method