Lean Change Part 2 - The Lean Change Stack

It is my statistically unverified opinion that big bang, plan driven change programs work at odds with the way people actually change. People learn differently, and don't react the same way to suggested change.

I've been attempting to tackle this problem through the Lean Change method. Lean Change takes the methods and principles behind the Lean Startup method and applies them to the organizational change lifecycle.

While applicable to many change program, we are cutting our teeth using Lean Change on multiple agile organizational change initiatives. Agile and Lean change is really challenging, and seem to suffer from a particularly high failure rate.

The Lean Change approach allows change agents to iterate through a Prepare, Introduce, Learn cycle, accelerating learning necessary to maximizing the chances that a change program will be successful.

Introducing the Lean Change Stack

Extended from Ash Maurya's Lean Stack, the Lean Change stack provides a set of methods and tools to allow change agents to execute a organizational change program using validated learning that follows a Change Iteration Lifecycle.I'm calling this approach Validated Change.

David J. Anderson' s Kanban provide the infrastructure for the method. Kanban is used to manage the change method, as well provide learning for the success of the change in terms of actual performance. Kanban is also used to provide feedback on the change, giving additional direction for the change program.

The stack has 4 major components:

a Change Canvas, used to brainstorm a set of potential change plans, and come up with initial change model for your change program. The idea of mapping out model or plan using a canvas comes from the Business Model Generation book, by Alex Osterwalder and co.

a Change Strategy Board for laying out how you will accomplish your plan, along with a dedicated Risk Kanban. The Risk Kanban section is used track the flow of risk mitigation, represented as Risk Tickets. 

a Validated Change Board, this is a Kanban system used to track Minimum Viable Changes (MVCs) through the Change Iteration Lifecycle

a Validated Adoption Board, given to change recipients, this board is scoped to represent the data from one MVC only. The Validated Adoption Board clones details contained in the Change Canvas and a Validated Change Board, with only data for the Minimum Viable Change being introduced to a particular set of change recipients. 

In general, information flows from components going left to right. That being said my initial use of these tools indicates that data tends to go both ways and is often completed in parallel. 

A high degree of (daily) synchronization is required across these 4 Lean Change Stack components.

Change Canvas

I have already described the Change Canvas in detail in my previous post on Lean Change.

Again the purpose of the Change Canvas is to concisely describe all of the required components necessary to any successful change program.

The format supports brainstorming quickly over numerous models, and iterating to a new model as further information is uncovered while executing on the change.

Here is an example of the Change Canvas with the contents of an agile IT organizational change program.

Change Strategy Board

Once the Change Canvas has been filled out, (and even while it's being filled out) the Change Strategy Board can be used to start laying out a change plan.

Again I borrowed from Ash Maurya's Lean Stack, using the concept of analogues and anti-logs to help both change agents, stakeholders, and recipients get agreement on the direction that the organization is trying to move to as a result of the change.

Once the overall strategy is laid out, Risks risks can be listed, and flowed through the Risk Kanban section of the board.

Validated Change Board

Actual activity relating to the risk on the Change Strategy Board is represented on the Validated Change Board. Changes are represented as Minimum Viable Changes that passes through the Change Iteration Lifecycle.

The Change Iteration Lifecycle has four major stages, individual MVCs should typically only be in one stage at a time, but may move forward or backwards depending on learning involved.

MVCs are introduced to change recipients by breaking them up into individual change experiments known as Minimum Viable Improvements (MVIs).

During the Understand Reason stage, MVIs represent the work necessary to explore the reason for change, along activity required to find the most suitable guiding teams to act as first movers. Typically initial MVCs in this stage will have a non-descriptive name such as "Explore Change".

Once a potential guiding team has been found who' is passionate for responding to that particular change driver, the MVC may pass into the Definine the Change stage. 

During this stage multiple MVIs are deployed with the express purpose of brainstorming potential solutions with both stakeholders and the potential guiding team. A key milestone necessary to moving this MVC out of thisstage is securing commitments in terms of both time and effort from all change recipients being impacted by the change

Validated Adoption Board

Changes are introduced and adopted during the Validate Behavior & Verify Performance stage. Before the validate behavior states can begin, a Validated Adoption Board is introduced to the guiding team. 

The canvas portion of the Validated Adoption Board is built during the Defining the Change stage. This section somewhat equivalent to the Risks and Experiment Layer found in earlier versions of Running Lean. Only details relevant to the Minimum Viable Change being introduced are shown. 

The Validated Adoption Board also contains a dedicated Kanban used to track the flow of Minimum Viable Improvements that relate to the specific MVC.  The Validated Adoption Board makes it easier for change recipients have a clear understanding of what changes are being introduced to them, and the potential flow and future changes. 

This board is placed as close as possible to the physical location of the change recipients, and typically synchronized with the Validated Change Board on a daily basis.

During the Validate Behavior stage, learning focuses on evaluating behavior, and the impact of change on that behavior. We are still evaluating different mechanisms , but all of our current approaches are based on a voluntary, self assessment approach.

During theVerify Performance stage, learning focuses on evaluating how change impacts business objectives and organizational performance.

For agile related organizational change, we are using Kanban systems to measure the impact of lead time and throughput based on the introduction of a particular Minimum Viable Change.