Validate Your Agile Change with an Improvement Experiment Kanban

In various recent posts I have talked about how a Minimum Viable Change as small as it can be. An MVC also has to be viable.

For a change to be viable, we need to continually validate the different aspects of that change. This validation can be achieved by implementing our change using a discrete set of Improvement Experiments. As each Improvement Experiment is introduced to change participants, the experiment is evaluated, providing insight into the validity of the change model represented on the canvas.
One way to manage Improvement Experiments is to track them using an Improvement Kanban System. The Improvement Kanban tracks the progress of Improvement Experiments as they are introduced to change participants. Each MVC typically has its own separate Improvement Kanban board. Frequently, the Improvement Kanban is placed directly under the Change Canvas that is used to represent the MVC in question.
 
 

Different columns represent different states within the improvement lifecycle. As Improvement Experiments complete a particular state they move from left to right across the Improvement Experiment Kanban.
The left side of the Kanban represent items that have not yet started, basically an improvement backlog. It is recommended to use a regularly reoccurring cadence to schedule replenishment of Improvement Experiments. In this case each column represents a two-week interval in the future. What this would mean is that every two weeks the change agent and change participants would meet and start on the Improvement Experiments within the appropriate column. Depending on the number of improvement items and a timeline of the change, a later/optional column could also be placed to the very left, signifying improvement items that may be "stretch" goals.

The right side of the Kanban represents items that are currently in progress, and follow a simple prepare, introduce, and learn lifecycle.

The numbers on top of each column is known as a work in process limit, or WIP limit for short. This number represents a recommended limit to how many tickets should be in a particular state at a time. This "inventory leveling" is a feature of Kanban that helps ensure that value flows quickly through a system and an individual work ticket does not spend too much time waiting around in one particular state.
Below is a real-life example of a MVC Change Canvas along with an Improvement Experiment Kanban below it.
.
For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking