Refining a Change Canvas to Represent a Minimum Viable Change

Alexis HuiAugust 8th, 2013Last Updated: August 8th, 2013

0 307 5 minutes read

Using a change canvas helps change agents deliver on the first promise of the Lean Change method, that change be negotiated. Following the principle of negotiated change, successful change requires that both change agents and change recipients engage in a cocreative process ensures that any suggested change meets the particular needs of the people being asked to change.

The use of a change canvas is inspired from the lean startup method. This is important because the second promise, that change will maximize the use of validated learning is also inspired from the lean startup approach. This second principle is that change undergo validated learning. Validated learning is based on the premise that learning should be based on a hypothesis, experiment, measure approach.

In the lean startup world a core enabler of validated learning is what is known as a minimum viable product. Folks practicing the lean startup method are interested in maximizing their chances at building a sustainable business within uncertain markets, often with entirely new and untested products. In that light and minimum viable product can be thought of as the smallest product increment that can enable learning necessary to understanding the sustainability of a particular business or product.

The Lean Change method borrows this concept calling it a minimum viable change. We define a minimum viable change as the smallest possible change that will maximize both learning and buy-in necessary building a viable change program and executing a viable set of change tactics.

A minimum viable change can be thought of as a change experiment. When building a change model using the MVC approach, components of that model are best thought of as untested assumptions. Depending at what is learned during a change initiative , different aspects of the model can and should be re-created based on the latest information

In order for a change to be considered a minimum viable change, it should contain two properties.

Property 1 Minimal:

First of all, the change should be minimally i.e. small, while still being considered a complete change. For instance it should still have a targeted set of change recipients, a set of actions, target state, urgencies and all the other components represented on the canvas. For a change to be considered minimal these change components should be pared down as much as possible all still resulting in a complete change. In other words all sections of the canvas should be filled out and considered.

Our previous change model can be reduced in scope simply by paring down elements within the urgency, change recipient, or target state box to 1 or two themes. This makes it easy to revisit the rest of the model and likewise reduce the scope.

If you look at the previous change model created by Danny and his team we can say that there are a number of ideas that are not necessarily core to the change being suggested. If we look at the target state there are really three distinct themes ; the notion of achieving continuous flow and establishing steady throughput perhaps using a lean oriented techniques such as Kanban, idea of a collaborative modeling as well as collaborative management methods, and finally a steady cadence for replenishing work.

If we agree with the premise that the majority of problems currently being faced by Danny’s team are due to poor collaboration with customers we could potentially reduce the change model to focus on just adopting more collaborative modeling methods such as story mapping, agile modeling of the etc.

This would have the effect of reducing the scope of the change initiative into a more manageable bite-size piece. We can then reduce division to reflect this smaller scope, along with the commitments. If we look at the actions and benefits section, we see mention of a reusable and repeatable methods framework or library. While this is probably useful to the organization, it does Not really address any of the urgencies stated in the original change model. In fact for a team that is struggling to learn new things as well as get a project done on time, this can seem like a pointless distraction, and at the very least be considered later.

if we look again at our original change model and compare it to the new one, we see that the new one is less complex, and is more focused on one overarching theme, using agile modeling methods to achieve a shared understanding of what the solution do.

Property 2 Viable:

A minimum viable change also has to be viable. What this means is that we need to validate that our change model represents a viable change plan. This is achieved through executing our change as a set of improvement experiments. Each experiment can be evaluated within the context of the change model represented on the canvas.

One way to do this is through a Kanban improvement board. Each work tickets in the improvement can then system can be used to validate a particular aspect of the change model represented by the canvas.

Improvement work tickets are populated into a backlog segmented out to represent the duration of the suggested change. In this instance we see that the change agent will work with change stakeholders on new improvement items every 2 weeks.

As tickets are moved through the prepare stage 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 in one or more sections of the change canvas.

We recommend that change agents feel free to experiment with the exact format of the ticket, we have landed on the following:

will result in

an example could be:

“co-facilitated story mapping sessions with the business analysts and business subject matter experts will result in the ability to independently effectively determine solution scope and structure after 3 supported sessions”

The activity should be some set of actions that the change agent is going to execute in collaboration with change recipients. The specific change recipient is simply the one or more of the change recipients listed on the canvas who is going to be the receiver of this improvement experiment. The outcome is the expected results, this can be in the form of improved capability, improved performance, or some other benefit.

The constraint should be expressed in the form of a time, i.e. “after two weeks” or a number of instances of a certain activity, I.e. “after 3 sessions”. A constraint can also be specified as when a certain event happens, ie. “when the next emergency defect occurs”.

As each ticket is moved into the prepare column, it is rewritten using this experimental format. The “improvement experiment” is then moved to the Adopt column, at which point the improvement experiment starts.

The improvement experiment continues until either the experiment has proven true or false, or the constraint has elapsed.

It is important for change agents not to fall into the trap of evaluating experiments on their own, ultimately it is the change recipient who needs to make the call about whether an improvement experiment was 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.

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 tweak or even completely change certain portions of the canvas. When a large number experiments do not meet expectations That it is time to consider pivoting, changing large portions of the canvas to reflect what has been learned. This can be a painful exercise the first couple of times that happens.

Reference: Refining a Change Canvas to Represent a Minimum Viable Change from our JCG partner Jeff Anderson at the Lean Transformation blog.