Toronto Agile Tour 2013 Session

I'll be presenting at #att13 this year. Well not so much presenting as running a workshop. I'll be joined with a team of both peers and clients of mine  to help workshop attendees build a change canvas. The idea is to work with anyone coming to the workshop to help map out an agile change using the canvas.

If you are part of an agile change, or want to get one started come to the workshop and will help you put a change model together. Here is a video describing the workshop below.

For more check out the Lean Change Method: ManagingAgile Transformation with Kanban, Kotter, and Lean Startup Thinking
 

Updating Your Canvas Based on Your Improvement Experiments

At some point you will want to take the time to update the Change Canvas to reflect any new learning that resulted from the Improvement Experiment. This could include rebalancing benefits and commitments, desired target options, or any other component on the canvas.
I recommend setting an explicit Kanban style policy concerning when to take the time to update the Change Canvas. Options include whenever an experiment is finished, or on a set cadence, perhaps biweekly or monthly.
I often run a session with change participants to annotate the canvas for correctness, again using green, yellow, and red markers for portions of the change model that are believed to be correct, partially correct, and completely incorrect. Participants may also annotate the canvas with a statement that describes "why" a certain assumption is not turning out to be true.

The Change Canvas can then be updated to reflect the latest understanding and newest learning. This can include looking at the existing Improvement Experiment backlog and re-factoring it to consider the new information added to the Change Canvas.

Performing a Change Pivot

When a large number of experiments do not meet expectations, then it is time to consider a change pivot. A change pivot involves wholesale modifications to the Change Canvas, and underlying change model. When executing a change pivot, one key aspect of the change model is altered, while keeping another aspect intact. Examples of a change pivot include:
1. Choosing a different set of change participants
2. Selecting a different set of methods, tools or techniques to adopt
3. Switching up actions and tactics, perhaps going from light touch to high touch or vice versa
4. Scaling back benefits to better reflect time commitments that your change participants can make

For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking .

Writing Good Improvement Experiments

A good improvement experiment can take many forms, I design my Improvement Experiments so that they contain the following key items:
1. Explicit activity or action
2. The roles and/or people being affected by the change
3. An outcome or effect as perceived by the people be impacted by the change
4. A constraint, such as a number of sessions, or a time. Where the experiment expires

Change agents should feel free to experiment with the exact format of an Improvement Experiment ticket, I tend to work with the following format:
-an action- -with/for- - a specific change participant- -will result in- -an outcome- -within some constraint-
an example could be:
"co-facilitated story mapping sessions with the business analysts and business subject matter experts will result in them feeling that they can effectively determine solution scope and structure after 3 supported sessions"
The activity is an explicit action that the change agent is going to execute in collaboration with change participants.
The specific change participant is simply the one or more of the change participants listed on the canvas that will be participating in the Improvement Experiment.
The outcome is the expected results, this can be in the form of improved capability, improved performance, or some other benefit. It's a good practice to write the outcome from the perspective of the change participants, how they perceive improvement is taking place (or not).
The constraint can be expressed in the form of a time period, i.e. "after two weeks" or a number of instances of a certain activity, i.e. "after three sessions". A constraint can also be specified as the occurrence of a specific event, iwhen the emergency defect occurs".
It's important to phrase validation from the perspective of the change participants, rather than using language that specifies achievement of some goal in a generic way. For example:
"developers will become TDD ninjas after three weeks of coding dojo's" isn't as good as "developers will indicate their mastery of TDD after three coding dojo's".
We want to structure our outcomes like this because it helps to enforce the idea that all validation of an Improvement experiment has to come from the change participant. It's not enough for a change agent to evaluate the impact of an improvement on change participants. Embedding language that hypothesizes how a change participant will indicate his reaction to a change encourages this mindset.

The nature of the experiment will vary depending on where a Minimum Viable Change is within the lifecycle. Here are some examples of improvement experiments that could be part of each of the 4 states within the validated chief lifecycle:

· the online team can identify enough problem statements to provide a clear case for the adoption of agile technical practices after 3 facilitated workshops (agree on urgency)
· the portal technology group can articulate and contextualize a more agile working model after 1 week of brainstorming (negotiate change)
· analysts who are part of the International Teller Program Will tell me that they can  perform agile style story analysis after 2 weeks of coaching (validated adoption)
· including developers in detail story analysis will reduce defects by 50% after one month (verify performance)
Regardless of whether you use the rest of the method in its entirety, running an agile adoption or transformation as a set of improvement experiments helps to reframe a change agent activity is something that can be put under constant scrutiny, helping the change agent examine his tactics, and possibly changing his strategy if necessary.
For more check he Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

Improvement Experiments In Action - Continuing Our Story of Danny the Developer

In order to show how Improvement Experiments can be used, Let's continue following Danny as he works with his team to Improve delivery performance.

Filling the Backlog

After a couple of planning sessions Danny and his team come up with a set of Improvement Experiments That they feel will result in executing on their change model. The group then prioritizes these Improvement Experiments into various two-week blocks.
They take care to put no more than 3 Improvement Experiments in each block, as the team feels that this is the maximum amount of change the team could absorb every two weeks.

Preparing New Improvement Experiment

When December 1rst rolls around, tickets can start moving into the Next column, signifying that new improvement items should be started. Note that only two tickets are moved as this is the current Wip limit being set by the team.
The team then decides to move the value stream mapping session into the Prepare state.

As tickets are moved through the prepare state the first thing we do is rewrite the ticket so that it supports the notion of testability. Each test should validate the assumptions behind the change, represented in one or more sections of the Change Canvas.
In this instance Danny and the team rewrite the value stream mapping Improvement Experiment so that it says "value stream mapping sessions will allow change participants to reveal urgencies after 3 sessions ".

As an Improvement Experiment is moved into the Prepare column, it is rewritten using this experimental format. The change agent then does all the necessary preparation work to get the improvement ready. Examples include preparing for workshops, developing training guides, scheduling sessions, sending out communications, etc.
In Danny's case he works with a new, external, agile consultant recently brought to the engagement. They work together to prepare workshop material, book rooms, and coordinate everybody's schedule to make sure that they are able to run three workshops dedicated to reviewing and suggesting some fixes using the value stream mapping process.
 

Introducing the Experiment

Once this Improvement Experiment has been prepared, it can now be moved to the Introduce column, this is a signal that the team is now actively running sessions, trying out new techniques, etc., and potentially even benefits from the improvement items. This benefit could be in the form of validation of change assumptions, or actual realization of benefits on the change canvas.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
The Improvement Experiment continues until either the experiment has proven true or false, or the constraint has elapsed.
In Danny's case, the value stream mapping Improvement Experiment is moved into the Learn column after three sessions have been completed.

 

Learning from the Experiment

At this point the experiment is moved to the Learn column, and evaluated for success.
It is important for change agents not to fall into the trap of evaluating experiments on their own, ultimately it is the change participant who needs to make the call about whether an Improvement Experiment is successful or not. In our experience Improvement Experiments do not always simply pass or fail, for this reason we have used A three outcome approach. Success, fail, and partial success. (and tagged with, green, red, or orange markers)
As various Improvement Experiments are passed through the Learn column, the canvas can be evaluated for correctness. Failed experiments are to be expected, and will indicate a need to modify certain sections of the canvas.
If we continue to follow Danny's progress, we can see that the value stream mapping experiment was successful in that he was able to come up with a good set of urgencies with his change participants. Unfortunately, Danny was not able to collaborate with his team to come up with a target options model based on a big A-Agile solution. This latter Improvement Experiment is telling Danny that he needs to rethink what the solution is going to look like if it's going to be of value to his change participants.

Typically as one Improvement Experiment is being prepared, introduced, and evaluated, other Improvement Experiments are being pulled through the Improvement Experiment Kanban based on the capacity limits. Here is a snapshot of the entire Improvement Experiment Kanban.

Breaking up a change model represented on the canvas into a set of Improvement Experiments and then managing them using a Kanban system provides the team with real-time insight on how the change effort is progressing, much like a Kanban system can help software delivery teams provide insight on how a software project is progressing.
For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

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

A Change Canvas Action Cheat Sheet

Here is a quick cheat sheet I put together to help people when trying to navigate a Change Canvas. Enjoy!

For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

Using Kanban to Manage the Flow of Agile Change

Kanban, as described by David J. Anderson's book "Kanban: Successful Evolutionary Change for Your Business", is an ideal method to manage both continuous operation and continues improvement for all kinds of knowledge work systems. Kanban is a lean inspired management method that helps knowledge workers continually improve work performance through a combination of visualization, just-in-time value creation, and focus on flow. Kanban is an excellent method to help manage and improve the operations of an agile change initiative.
Kanban is a core concept to the Lean Change method. Kanban is used in the following ways:
1. to track and manage both minimum viable changes and improvement experiments on various kanban boards
2. as a means of providing quantifiable validation of improvement experiments and the underlying change during the verify performance stage of the Validated Change Lifecycle.
3. As an alternative change management method that can take over from the method once the organization achieves sufficient maturity to operate in a continuous improvement mindset

Both Minimum Viable Changes and Improvement Experiments Are Managed Visually Using Kanban Systems

A focal premise of the Lean Change method is that Kanban is used to manage the flow of change, taking advantage of visual, just-in-time techniques. The Lean Change method uses various Kanban boards to define and visualize how change progresses through the organization, helping change agents get into a state of change "flow".
A Validated Change Kanban is used to track individual Minimum Viable Changes as they pass through the Validated Change Lifecycle. This allows teams of change agents to coordinate and collaborate during a change initiative, taking advantage of Kanban features such as visualization, explicit policies, standups, and limiting the amount of change in progress.

An Improvement Experiment Kanban is used to track Improvement Experiments for each Minimum Viable Change. As an MVC passes through each state in the Validated Change Lifecycle, various portions of the change are validated using one or more Improvement Experiments. Each MVC typically has its own dedicated Improvement Experiment Kanban, placed right next to, or right below, the Change Canvas used to describe the Minimum Viable Change.

Changes Eventually Need to Be Measured in Terms of Improved Performance, Kanban Provides an Excellent Set of Techniques to Do so

I've already talked previously around how Improvement Experiments are used to validate different aspects of a Minimum Viable Change. As change participants gain experience in lean and agile methods, they start to evaluate Improvement Experiments against performance metrics. Because of its origins within lean, Kanban provides mousedown 20 a rich set of metrics such as leadtime, throughput, and failure intake that can be analyzed using statistical process control or cumulative flow diagrams.

Making this concept real, when a Minimum Viable Change passes through the Verify Performance state, Improvement Experiments can then be evaluated to see if one or more kanban inspired metrics improve. An example of an improvement experiment implemented during the verify performance page could be conducting developer reviews of unfinished requirements documentation on a weekly basis will reduce UAT defect density by at least 30% after one month.

Once the Organization Achieves Sufficient Maturity, Kanban Can Take over As the Change Management Method

Kanban is described as a change management method in its own right, by David J. Anderson and others in the LeanKanban community. This change management approach borrows many techniques and ideas from lead and other bodies of knowledge to enable a viral, and evolutionary change management approach designed to help organizations gradually become more agile over time.

Kanban is designed to provide a gradual way for technology knowledge workers to improve. Knowledge workers start by mapping out their existing delivery process and visualizing this process using a Kanban system, typically manifested as a Kanban card wall.

A combination of methods are used to enable a grassroots, continuous improvement mindset, that in some conditions can virally spread across the organization. These techniques include explicit and visual policies that govern how work is conducted, limiting work in process to enable flow, connecting value delivery through frequent regularly scheduled cadences, and allocating work across visually colored classes of service.
So why not just use Kanban by itself and forget about the Lean Change entirely? It's been my experience that the Kanban method, used in isolation, is not always sufficient to help organizations transform to a more agile state. In some circumstances, helping clients adopt the Kanban method has resulted in amazing performance improvements. In other cases I've seen people attempting to use the method never quite grokking the continuous improvement mindset. Even more unfortunate were the cases where teams were doing well, but management did not adequately support changes being suggested by people who adopted the Kanban method, causing those people to eventually become disgruntled, and abandon the change effort. I have personally experienced a number of Kanban-based agile adoption that stalled because of a lack of patience, existing expertise, or direction.


The Lean Change method enhances Kanban to provide the aspects of a managed change initiative that can help organizations receive the guidance and support they need to be get started with Kanban, or some other continuous improvement method. Eventually, the goal of any agile or lean change initiative is to reduce the need any for an official "managed" change. We want to move from a transformative change mindset to an incremental, evolutionary change mindset. The sign of a true healthy, agile organization is one where improvement is continuous, and driven from employees doing the work.
In A nutshell, Kanban is an ideal method to supports the organization's efforts to continually adapt and improve. Lean Change is there to help with explicit change planning and change coordination when required, whether that change is larger or smaller. Kanban can take over when and where continuous improvement is more appropriate.
Think of Lean Change as a mechanism to make some of the more overt changes required to prepare an organization for Kanban. As change participants get used to working in a lean and agile context, they can start using Kanban to continually improve at their own pace, independent of any "managed change" effort.
For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking .

Managing Change Like a Startup

A major premise of the Lean Change method is that a startup is a good metaphor for a change initiative, and hence can benefit from techniques similar to those found in the lean Startup method
What inspired me and my team to look to the Lean Startup domain to help with agile organizational change?

Organizational Change Is Unpredictable

First of all, if there is one thing that is true about large-scale change initiatives, it is that outcomes are extremely hard to predict. When running a change management program, we are trying to help an organization get to improved business outcomes. We do this by defining a target state and planning a set of change actions.
If we are being honest, many of the upfront choices we make concerning our change are really just assumptions. As we execute our change plan, we continually uncover new information about business value, existing capability, current culture, workload, and a variety of other facts. This new information requires us to constantly rethink the validity of our assumptions.
Existing change management methods make it really hard to ensure that our change plan keeps up with our continued learning. Major failure has to occur before a change in direction is considered. As a result, organizations end up with a change that does Not provide the intended value.

Much of the Advice Provided from the Lean Startup Method Can Apply to Managed Change

When looked at from this light, a change initiative can be thought of as a kind of startup . The good news is that a lot of advice exists around how to maximize a startup's chance of success. The Lean Startup method applies lean thinking to the unpredictable world of startups. With a little work, techniques and concepts taken from the lean startup method can be adapted to support managed change initiatives as well. The Lean Change method does exactly this, providing a managed change framework that allows change agents to strive toward success in the face of unpredictability.

As stated previously, many of the tools and concepts in the Lean Change method have been adapted from the the Lean Startup Method to suit organizational change management.
Lean startup inspired techniques covered in this book include:

The Change canvas

Using the Lean Change method we generate models of the future using a holistic, visual approach that emphasize co-creation, prototyping, and re-creation. The folks using the Lean Startup method often create these models using a Lean Canvas or Business Model Canvas. Change agents using the Lean Change method use what is known as a Change Canvas to describe and communicate an agile change plan.

The canvas is an informal "plan on a page", laying out many of the "static" elements found in the Kotter Eight Steps of Change lifecycle. The Lean Change method uses the Change Canvas in two ways. A Minimum Viable Change (MVC) Canvas describes a small incremental change, one that impacts a limited number of employees. While a Transformation Canvas describes an organizational transformation initiative. In most cases, when I use the term Change Canvas, I am speaking about using a canvas to represent a smaller change such as an MVC.. Often the two terms Change Canvas and MVC Canvas are used interchangeably. When speaking about a canvas used to model a larger transformation, you'll see the term Transformation Canvas be used explicitly.

Minimum Viable Changes

The Lean Startup method advocates delivering market facing value in the smallest possible increment. These increments enable learning about whether a particular startup has a sustainable business model, and are known as Minimum Viable Products or MVPs for short.
When using the Lean Change method, change agents are encouraged to roll out the smallest possible change that will enable learning to understand the viability of an agile change program. These increments are known as a Minimum Viable Change, or MVC for short. Again, Minimum Viable Changes are typically modeled using a Change Canvas.

The Validated Change Lifecycle

Successful startups understand that predictions of the future as exactly that, predictions. They thus spend the time to explicitly validate those predictions. Using Lean Change we follow the same mindset. 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 validation of a assumptions behind a particular MVC.
The Validated Change Lifecycle integrates Kotter's Eight Steps with the Meta-Iteration Lifecycle Pattern from the Running Lean book. Using this lifecycle, Minimum Viable Changes are both defined and validated according to a specific sequence.

Change agents start by working with potential change stakeholders to Agree on the the Urgency of why a change is required in the first place. Change agents focus their effort on connecting urgency/problems with a cohort of change participants . The intention is to find change stakeholders who are willing to form the guiding team for a particular MVC.

Next, change agents and change stakeholders collaborate to Negotiate the Change solution, refining what the MVC will look like. The important part here is that is that the solution is cocreated by both the change participants and change agents.

Once the change model behind the MVC has been developed, change participants Validate Adoption is taking place. Focus is on validating whether the MVC is helping change participants to effectively change their behavior and improve their expertise in specific methods and skills.

As new skills, new behaviors, and new capability is demonstrated, change participants then Verify Performance improvement are resulting from the MVC. We want to ensure that the change is resulting in measurable delivery performance improvements for our change participants.

Improvement Experiments

Another key aspect of the Lean Startup method is realizing value through experimentation, supporting activity with a hypothesis, validation, and learn lifecycle, and this has carried over to the Lean Change method as well. As Minimum Viable Changes progress through the Validated Change Lifecycle, change is both implemented and validated by a number of Improvement Experiments. Improvement Experiments have their own lifecycle, each experiment is Prepared, Introduced to change participants, and then provides Learning to change stakeholders. Improvement Experiments are micro, tactical improvement actions that are backed up with a hypothesis that tries to predict the outcome of the improvement.

An example of an Improvement Experiment could be approximately half of the developers within the mobile payment team will adopt basic Test Driven Development as a result of participating in 4 facilitated coding dojo's over the course of a month.

Capability and Performance Metrics

Minimum Viable Changes and Improvement Experiments are validated through measurement. Lean Change provides a number of ways to perform these measurements. Changes are measured primarily from two perspectives. The first perspective is the ability of change participants 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.

Hopefully, I have provided a good summary of the specific techniques and tools that the Lean Change method borrows and adapts from the Lean Startup domain. This should provide some insight into how I have been managing agile organizational change using lean startup thinking and techniques.
For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking .