Exploring Different Method Plug-Ins for Completing A Change Canvas - Part 3 Actions & Success Criteria

In our previous posts we described options around how to articulated your change recipient-urgency assumptions as well as your assumptions around vision and target state. For this post will focus on how to realize an actual plan using the Action and Success Criteria sections of the change canvas.

Actions

A change initiative require specific action necessary to get into the target state.


The action section of the canvas should describe the set activities required for change recipients to achieve target state and receive benefits outlined within the canvas


Action required to help change recipients achieve targets they can come in a number of forms.

Often change agents will act as a full-time or part-time coach helping change recipients apply new methods tools and habits into real working environment. While team coaching requires a lot of effort on behalf of the change agent it can be the most effective way to effect change.


Team coaching is often supplemented by one-on-one mentoring. Managers and executives often require face time to help them operate in an agile world. Agile management can be extremely hard to learn, and  requires managers that are comfortable enabling teams and departments that have high capability, are self organizing, and learn rapidly. One-on-one mentoring is often suitable for these types of change recipients.


One of the best ways to get change recipients to learn new methods and tools is to help them cope facilitate learning events and workshops along with the change agents. This rapidly transformed recipients into agents, and champions.
  

As changes scale out across the organization setting up a specific curriculum for habits, methods and techniques relating to agile anime delivery is an effective option. This is Not recommended when conducting your first changes within an organization, it is highly challenging to create a curriculum, and then learn that it does not suit the context of your environment, and have to change it again. This is a tactic that is just done later in the change program, there's a lot of upfront effort required to build and communicate the curriculum, but once in place will allow the reach of a specific change program to reach a far wider audience.


Classroom training is a good starter tactic to help get a larger number of change recipients introduced to a particular topic. Relying exclusively on classroom training is a recipe for disappointment, our experience is that most knowledge workers are only able to absorb the most basic concepts through classes, and require much more hands-on approach if there is a desire to truly change the way work is being completed.


It is also been our experience that some organizations are in such a dysfunctional state that there needs to be deep structural and process change if the client wishes to improve the way that they deliver. This tends to be a tactic that many traditional change agents tried to consider first. Our opinion is that deep structural and process change should be reserved for later after the organization has achieved success in using agile methods and techniques on a number of teams or departments. Organizational changes are hard to undo, and so should be tested at a limited scale rather than rolling them out big bang.

 

Success Criteria

Success criteria allow you to evaluate whether your change is proceeding according to your initial assumptions.


Success criteria provide insight about whether actions are leading towards benefits and the target state.


success criteria can be thought of as a compass to help change agents and change recipients continually re-orient themselves toward the direction it will be to success.


Keeping things simple, success criteria could be filled out simply by mentioning one or two metrics That you want to track through the duration of the change engagement.

For example we could mark down that after every improvement item we want to track the number of people that feel comfortable practicing agile modeling techniques without coaching assistance. We could also add a second metric around the number of defects that have been generated as a result of improperly captured user stories.

More ambitious change agents may want to capture what are known as lifecycle metrics. Borrowing from the lean startup world, many lean startup's use a form of lifecycle metrics by David McClure known as pirate metrics. This approach involves tracking the lifecycle of a potential customer from initial awareness, to first real contact (activate), to when the customer actually purchases something, to how the customer actually is retained, and finally how the customer will refer another customer to the product.


Continuing with our shameless riffing of the lean startup method, we have come up with a similar lifecycle that describes how change recipients pass through a lifecycle for a particular change initiative.

Using this model change recipients first become informed of a particular change. They then exhibit some behavior that shows they are interested, further activity illustrates that they are now actively involved in changing behavior, eventually this change in behavior will result in better performance, and finally the success will result in a change recipients boasting, or publicizing, about his achievements either informally or formally.


If we imagine that we have a change agent who is currently trying to work with the Department of software developers to use techniques found within the code craft Mission movement, we can imagine the following change lifecycle. As we start this change initiative, we can measure the number of people who pass through each stage of the lifecycle during periodic intervals.


This would allow us to evaluate how successful our change initiatives from the perspective of our change recipients.

Again following the example that we been showing throughout this section of the course we have designed a change recipient lifecycle for a team trying to become successful through usage of agile modeling method and related techniques.

1. Change recipients show interest by accepting and attending a number of initial agile modeling workshops
2. Change recipients then show that their behavior is starting to change by completing specific class homework as well as independently executing on work assignments that are generated as a result of workshops.
3. Finally change recipients are showing true performance changes when they are able to independently run workshops without any change agents involved, and also when leadtime in defect rates improve as a result of the new way of working
4. A stretch goal for this change is that change recipients boast the other employees within the organization and that this results in other employees requesting to adopt the new techniques.

Once this lifecycle has been defined we can put in assumption around how many folks we hope to target to reach each stage, as we implement specific improvement items we can continue to revisit these metrics to see if we are talking according to our initial assumptions.


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

Exploring Different Method Plug-Ins for Completing a Change Canvas - Part 2 Vision & Target State

In my previous post, I wrote about some potential options for completing the Urgency and Change Recipients section of Change Canvas. For this post I'll focus on the vision and Target State sections.

 

Vision

The Vision portion of the canvas is all About articulating what the objectives of the change initiative our in a single, compelling statement that resonates with change recipients.

A good vision statement will connect change recipients with the benefits achieved through the target state.


Filling out the vision section At a minimum requires a single, bold statement. While we want our vision to be achievable, we also want To make sure that we excite action.  A good vision is short, we don't to repeat all of the elements found within our target state


We also recommend that change agents trying to fill out the vision section of the canvas try to engage in thinking visually and coming up with some kind of picture or diagram that can articulate the elements of the target state. Good art skills are not required, just a little willingness to be creative and imaginative.


a good vision statement can often come in the form of
<outcome or objective >for <change recipient segment >through/with/using <key target state enabler >

For example, achieving accelerated delivery for the integration team through best in class technical practices


achieving a highly collaborative and continuous improvement culture for the maintenance department through the adoption of the Kanban method 

helping managers within the channels line of business group to enable organizational agility for the channels department to adoption of management 3.0 techniques


If we continue to follow the example we had been using. Then a good vision statement could be one that discusses how to win the trust of the client through the use of a co located, cross functional business technology solution analysis team that can rely on agile modeling techniques.

Target State

In the target state you want to describe what the working environment will look like for your change recipients once they change initiative has been successfully implemented.


When developing the target state, many change agents fall into the trap of trying to create an overly detailed design. Processes, artifacts, working structure, are all described in great detail.


My experience is that this is an anti-pattern to say the least.
We recommend thinking of the target state as a story that can help guide both the change agent and a change recipients on a common path. While some upfront design is required, the focus should be on helping to communicate a potential option toward success. Not on trying to blueprint an uncertain future.
We recommend considering a number of elements to use when trying to tell a story of the target state.


A set of semiformal narratives can be complemented with pictures and photos, video mockups, semiformal prototypes, reenactments, and even seen some folks articulate the target state using blocks of Lego.


One approach that we have used on several occasions to help articulate and refine a target state is on your network design. There are a number of eminent leaders within the lean and agile community that I've talked about how knowledge workers can be organized as a value network. These include Juergen Appelo, Don Reinersten and David J. Anderson.

Juergens' approach to visualizing value networks is especially compelling. He describes value networks as a set of teams that relate to each other as a set of interconnecting concentric circles. Knowledge workers are almost always located in a cross functional team, and are occasionally part of more than one team. Workers who serve in more than one team serve as the integrators who ensure that the work of more than one team is properly integrated.

This value network approach helps organizations to scale the agile notion of a cross functional team to support an entire organization without sacrificing the need to coordinate different specialists with each other.


Each team in the value network can be tasked with one or more responsibilities, and the interactions between teams can also be specified using a simple notation.


Unlike value stream mapping, modeling value networks allow us to take advantage of how we want work to be processed in an agile and lean environment. When engaging in application delivery work activities and value very rarely flow into straight line from requirements to delivery . Work typically tends to move in both directions back and forth across the lifecycle.

Work also scatters and aggregates. For instance a business case developed by the customer team will scatter into many user stories which will be handled by the solution analysis team which made them scatter into many acceptance criteria that are delivered by the delivery team. Eventually stories acceptance criteria will need to form into a workable solution that meets the needs of the business case.

In agile world work is also rarely handed off from one team to another to be processed in isolation. Work tends to progress through collaboration both within and across teams, and value network support this concept.



The value network can also be extended to show the typical heartbeat that he intended to produce value. Folks familiar with scrum will know that teams tend deliver in iterations that range from one week to month.
The notion of A sprint or an iteration can also be applied to other teams, providing approximate guidelines of how often these teams will start and finish new work.



Using the value network, specific knowledge workers can also be grouped into specialist teams. This makes sense where delivering value requires part-time support is highly specialized. In our experience security experts, legacy system subject matter experts, software and hardware administrators can be effectively placed into specialist teams rather than as full-time members of our functional teams. We feel that most knowledge workers should be working within cross functional teams with organizational agility is an objective.



Once the target state has been mocked up using the value networks, or some other convention it can then be articulated as 3-full bullet points within the target state section of the canvas.


It's important to keep the target state component of the canvas short and concise, people wanting more detail can refer to the more complete picture that has been defined.   

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

Exploring Different Method Plug-Ins for Completing a Change Canvas - Part 1 Urgency & Change Recipients

As mentioned previously, the canvas is a great way to build a change model and supporting change plan. One of its biggest benefits is that it is collaborative, it forces a certain informality and succintness that makes it easy to create a plan quickly, and tear it down when it turns out to be wrong.

The canvas forces change agents and recipients to consider all aspects of a change initiative, but only in brief, there simply isn't enough space on the canvas to get lost exploring a huge amount of detail.
But sometimes exploring things in a bit more detail is warranted, there are times that we need to understand the complexity of the current organization, perform root cause analysis on its problems, and spend a little more time designing the target state in order to come up with an effective change.

Where required, change agents can plug in different methods and tools to help them perform the analysis necessary to completing a certain section of the canvas.

There are a multitude of approaches and methods out there that can help change agents analyze pain points, define a target state, and identify key gaps.

I'd like to share some of the "plug-in options" which I have seen used to perform analysis on different sections of the canvas. This is by no means a definitive list, but I hope that some of these tools will be useful to you as they have been to other change agents, and that it will spark your imagination and creativity in terms of how to think about completing different sections of The change canvas.
For this post I'll focus on the urgency and change recipients

Urgency

The first section of the canvas that I am going to look at is urgency.


Completing the urgency section is all about understanding what pain is being felt by different intentional change recipients, and articulating back pain in a language that the change recipients understand and appreciate.

Establishing a sense of urgency is one of the first things that need needs to be considered when starting any change initiative. Many change groups out there talk about the need to visualize and communicate what is known as the burning platform. The idea here is to connect any change initiative with a powerful metaphor that speaks to the criticality of executing on this change initiative.

The idea here is not to be overly scientific, but to come up with a set of problems that resonate emotionally and get them charged up enough to engage in the change initiative.

We have personally had very good success using a tool known as the 5 whys to help people analyze problems that they are feeling, get to a particular root cause for particular problem, and collaborate with them to come up with a set of countermeasures that can help address the root causes of problems.

5 whys is typically executed using a facilitator and a number of change recipients. The facilitator helps the group list a number of problems that are currently causing pain, and then helping the group come to a root cause for that problem by asking the question  "why is that problem happening" up to 5 times. Eventually the answer will come up with what is known as a would cause for the issue. The group can then try to discuss potential countermeasures for that root cause.

While This technique seems deceptively simple,Successfully facilitating the 5 whys session can actually be quite complicated. The relationship between problems, other problems root causes and solutions,  is rarely linear.
 

In reality,problems end up having a many many relationship to other problems, other root causes, and countermeasures. This means running the session takes some skill in order to keep the group focused and keep getting them continually back on track. When running your first 5 whys session, don't be discouraged if things go off track. You will get much better at running the sessions after the first couple of them.


value Stream mapping is another analysis technique that is very complementary to five wise. a facilitator can work with a group of change recipients either a workshop style or one-on-one to help Map out the artifacts that are created and the activities that are completed for particular process.

As the process is mapped out into what is known as a value stream, specific issues and problems relating to either components of the process or the entire process itself can be discussed. These issues are often catalogued as a specific kind of waste, Mary and Tom Poppendieck authors of many books on a software development have defined a popular classification of waste that include:

• partially done work
• extra features
• e-learning
• DOS
• delays
• switching
• and defects

each activity can be marked with a specific kind of waste, which can serve as a starter for performing five whys style root cause analysis.

one way of identifying waste as a part of value Stream mapping is to evaluate the ratio between the amount of effort it takes to complete an activity to the amount of calendar time elapsed between that activity starting in that activity ending.

For instance imagine that a business case document is typically around five pages long, and usually takes between 3 and 5 sessions with the appropriate stakeholders to get the right kind of information to fill it out. There is also probably some research time and analysis time that needs to be factored in.
If we look at the actual effort to complete this business case, a range of between six and 30 days is probably sufficient if we are being generous. Anybody completing a business case knows that it can take many weeks, months, and sometimes years to get it completed and approved. The disparity between effort and calendar time is a signal that there is waste within this process, meaning that this is a good place to start performing five whys style root cause analysis.



Here is an example of how five whys can work. Imagine a facilitator is working with a cross functional team responsible for developing web application logic to set of business customers.
The team is currently complaining that is extremely challenging working with their customers. A tangible piece of evidence is that it takes a long time to set up meetings with customers to get direction on what to do next, as well as to how those customers validate work has been done so far.


One issue contributing to this problem is that there are no regular reoccurring meetings, all meetings are set on an ad hoc basis. And it is challenging to coordinate schedules with business stakeholders were extremely busy because the other non-project related commitments.

When speaking to these business subject matter experts and customers their response is simply that they would like a fixed plan that spells out when they need to contribute, what effort that contribution will be, and how often they need to contribute to the entire length of the project. Customers feel they need this information in order to properly balance their workload with many of the other commitments they have nothing to do with this project.

a typical solution in the agile world and lean world is to simply establish a set of fixed meetings that occur on a regular reoccurring interval. For example the team and the customer may elect to meet once a week for possibly three hours to prioritize and do some preliminary analysis on the next set of stories to be delivered.

 When this approach was mentioned to the team, they seem to get very nervous and were unwilling to establish any kind of fixed cadence for any customer oriented meetings.


Upon deeper inspection, it became apparent that the team was facing an unpredictable workload thanks to the number of defects that were being raised as a result of customer demos. The team felt swamped with managing this level of defects, and did not have confidence around how much time they had available to work with customers to prioritize the next set of stories.

What first appeared to be a problem with customers refusing to spend necessary time with the delivery team, in actuality was a problem rooted in the fact that the team did not want to commit to spending time with the customer because the amount of time they're spending dealing with quality issues.

When investigating these quality issues it became clear that the requirements gathering process that the team is using with sub optimal. Analysts were working with business clients to gather requirements "clean slate" then delivering those requirements to the solution designer and developers who would then try to add that an existing package solution to meet the needs of those requirements.

Just as often as not, the solution could not be configured to meet the details contained in those requirements. This meant that almost every requirement needed to be revisited and rewritten to support the constraints of the requirements. Even worse this is typically done only after the solution had a demo to the client meaning that almost every requirement was passing through the delivery lifecycle twice.
Upon reflection, the team and the facilitator able to come up with a specific countermeasure. One, was to establish a biweekly story analysis session between the business stakeholder/experts, business analysts and the lead solution designer who was an expert on the technical product that was being used for this project, including its limitations and constraints. 
forward thinking would ensure that the solution subject matter expert would not only be available for all analysis sessions, but that he would train the business analysts in the inner workings of the technical product, so they could effectively gather requirements the right way to first time around.


A Value Stream Map could also be used to help facilitate discussion. If the facilitator and change recipients have elected to use this approach, then they would have drawn up the process using a value stream map, and then identified where waste was occurring. In this case delays were occurring during the story analysis activity, and a lot of rework was occurring during development. This would indicate that five whys style analysis was required at each of these two points.



All of this analysis could be refined and summarized so they can be properly reflected on the urgency section of the canvas. In this instance the team elected to describe this as poor collaboration between the business clients, business analysts, and the solution technology expert which was causing confusion and poor quality.


Anyone asking for detail behind the statement could be pointed to the value stream map and five whys analysis that was completed for this canvas.

Change Recipients

Filling out the change recipients box is all about finding effective change recipients within the organization that will emotionally connect with the urgency that you are trying to establish to start the change. We are typically looking at a cohort of change recipients who are all experiencing similar problems. By cohort we mean a set of change recipients who can all experience the same set of changes over period of time.  


At minimum your change recipients should be thought of as customers of the change. As a change agent is your job to serve their needs and help them do their jobs better.



A better metaphor is the think of your change recipients as stakeholders that you want to engage in a co- creative manner. Your first change recipients are ones that can serve as change champions, and effectively become what is known as a guiding team for the change initiative. A good change recipients is one that will help you in defining what the change solution should look like, and will take an active role in changing behavior of both himself as well as people around him.


Another important attribute when thinking about starting a change is to find a change recipients who is already displayed some capability in improving in agile or lean methods. For example we may be
considering running in agile improvement change on two different teams.

Team A has previously tried to adopt some elements of Kanban on their own. They have had some successes with the visualization techniques provided by the method, but are struggling with getting to any kind of consistent throughput, and they are still how you deal with a large Number of defects. That being said they want to take things to the next level

Team B is in a much different state. There is a culture of "just getting it done". Often through heroics and last-minute scrambling. There is a general consensus that things need to improve, but people just feel like they are too busy right now to bother.

On first glance it looks like team B needs the change more than team A. But this would be the wrong team to implement improvement initiative on, at least right now. Team A is really the ideal choice, while struggling, they have an understanding that taking time to improve is worth the investment, and they will be more likely to engage with in agile change agent in a positive manner.

Whenever creating our first change is going to be introduced in an organization, we want to make sure that we avoid resistance to the maximum extent possible.



This is best done by simply choosing the area of the organization is most likely to deliver us change recipients who will work with us in a collaborative fashion so that we can negotiate our way to an effective change outcome.



Our change agent can thus put team Alpha into the change recipients section of the canvas, he also makes sure to call out every role within this team as each role may require different actions, commitments and benefits as a result of the change. Our change agent has also decided to list change recipients who are indirectly impacted by the change at the bottom of the change recipients section of the canvas, these include a business stakeholder, executive sponsor, and functional manager.


Identifying change recipients is done in parallel with identifying problems that can go into the urgency section of the canvas.

Using an iterative process, value stream mapping and 5Y sessions are facilitated with varying potential change recipients. Each source of waste, problem, root cause and potential countermeasure can be identified with one or more change recipients.


Looking at our previous example, describe any potential change recipients is as simple as annotating our root cause analysis with the appropriate people involved. In this case, the business subject matter expert and business analysts are most impacted by story analysis related issues, and the developers and testers are being most impacted by issues coming out of the development and customer demos.

Root cause analysis indicates that the lead developer who's playing the role of a product subject matter expert needs to be included in analysis sessions.


In many cases change agents will immediately know who the change recipients of a particular change are. This is true when the change agent is a member or manager of a particular team and he wants to improve the performance of that team. Executives, and external change agents may be more unsure around how to determine who the first change recipients should be.
In this case change recipients can be cataloged into a number of different segments by examining the work structure and project structure of the organization in question.
Some segments can come from organizing folks by their level, for instance change recipients could be either executives, managers, or line staff. Any change could be targeted at all members in a particular level.

Segmenting could also be cataloged by a functional categorization. As an example a specific change could be targeted on all project managers, business analysts, developers or testers within an organization.
 

Many segments of change recipients will be defined as a cross functional team dedicated to achieving a particular customer outcome. This is how most agile and lean methods recommend that change recipients be organized. This cross-cultural team would include a set of specialized folks from a number of functional departments as well as customers managers and executives who are acquired to support a cross functional team.
Examples of change initiatives that are targeted at cross functional teams include piloting a particular agile method or suite of agile methods to help the team improve their delivery. Adopting Kanban, scrum or extreme programming for particular project team and supporting specialists are good examples.


Changes should be targeted to specific needs of thy cohort. There is a wealth of agile methods and tools available to serve the needs of particular levels and functions.
Examples of change initiatives that could be targeted at these change recipients include helping managers and executives improve organizational agility through adoption of methods and tools found in urine apple is management 3.oh framework, or helping developers achieve better agility through adoption of tooling and methods such as continuous integration and test driven development.




Finally here is our previous example with a cross functional team described as the primary change recipients, with management and executives listed as secondary stakeholders of the change.
  

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

.

Refining a Change Canvas to Represent a Minimum Viable Change

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:

-an action- -with/for- - a specific change recipient- -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 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. :-)

 Read More of Lean Change - Chapter 2: Getting Started with the Change Canvas 

1. a Short History of the Canvas 
2. the Change Canvas in Action-a Story of Danny the Developer
3. Using a Canvas to Represent a Minimum Viable Change 
4. Guidelines and Practices When Using the Change Canvas