Techniques to Keep in Mind When Building a Change Canvas

Keep the following techniques in mind when using the change canvas to help execute an agile or lean change plan.

Plan Change in a Cocreative Way
Perhaps one of the most important considerations when building a change canvas is to make sure that it's done in a cocreative fashion. You want to ensure that change recipients, and other change stakeholders work closely with change agents to come up with a change solution together. The canvas supports a collaborative environment, but it is up to the facilitator and workshop participants to take advantage of this tool. Below is a great example where we worked with our client to brainstorm a potential change.

Expect Your Change Plan to Be Wrong
The change canvas is easy to build, easy to modify, and easy to tear down if it turns out to be completely wrong. It still takes a combination of courage, introspection, and discipline to take the time to modify elements of a change plan when we discover that they are incorrect. Change planning is really hard to do, and most assumptions behind any initial change model will never be right up front. Expect the change canvas to require revision and require it frequently. Shown below is a minimum viable change canvas annotated for correctness. The change team's latest learnings have been incorporated into the canvas, showing red for incorrect assumptions, and yellow for only partially correct assumptions.



Use the Change Canvas As an Information Radiator
Where possible, try to favor representing the change canvas using physical, low fidelity artifacts that can be placed in a highly visible place, frequently trafficked by members of the organization. We want to encourage maximum exposure to our change model and plan, and receive the maximum amount of feedback from as many sources as possible.



Keep the Content of the Canvas Light Weight and Informal
While the change canvas contains all the components of a complete change model, content within the canvas should be succinct. We want to avoid getting lost in the details, providing key information at a glance. Things need to be lightweight if we want to be able to make changes as we incorporate new learnings over time. The canvas shown below may look chaotic and unfinished at first glance, but in reality a wealth of information is conveyed, and can be collaborated on in real time.



Limit How Much Change You Introduce at Any One Time
When decomposing a minimum viable change into a number of improvements experiments, it is important to limit how many of these improvements experiments you introduce to the organization. It is very easy for change recipients to become overwhelmed with change. Negotiate a reasonable work in progress limit that balances the need for improvement with actual capacity for change within the organization. The minimum viable change on the canvas below has an agreed-upon change in process limit to 3 experiments every two weeks.


Place the Change Canvas As Close As Possible to Where Change Recipients Work
As soon as a change canvas is started, place it as close as you can to wear most of the change recipients work. This encourages change recipients to look at the model in their own time. We also want to encourage ownership of the change model by these change recipients.




Think Visually, Use Pictures to Enhance Communication
Because the canvas is compact there isn't room to write a lot of detail. But a simple picture can convey a lot of meaning. Artistic excellence is not required, simply the willingness to put things down in picture form using whatever skills are available! Below is a real-world example where our client used some visual thinking to help articulate the vision for their department.





 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

Modeling an Enterprise Agile Transformation With a Transformation Canvas

In previous posts I've talked about how to complete a change model as expressed by a Change Canvas. The focus of these posts have been on using the canvas to define Minimum Viable Changes, and also how validate those changes using the Validated Change Lifecycle; first through discussion, then by checking behavior, and finally by checking performance.

I've also discussed how to use the Validated Change Lifecycle to order the kind of actions and experiments we want to execute in order to de-risk our change program.

The type of change that we have been talking about so far, has been at the team or department level. However, we can also use the Change Canvas on a very different scale, to support planning for large-scale organizational transformations. When using a Change Canvas this way, we call it a Transformation Canvas. The Transformation Canvas can help senior executives who are looking to rewrite the Cultural DNA be any of their entire organization, and want to execute large-scale change across the enterprise.

Why Do We Need a Transformation Canvas?
as a quick review of how lean change work so far, change agent can work with a group or cohort of change recipients to execute a set of improvements experiments as a Minimum Viable Change.


A Change Canvas is used to reflect all the components of the minimum viable change, and that canvas is then validated first through discussion, then by checking behavior, and finally by checking performance.
 
Change agents can de risk and maximize learning for a change by moving Minimum Viable Changes through the validated change lifecycle.

As a change program scales out, multiple change agents may work on multiple Minimum Viable Changes can in parallel, effecting numerous changes on an organization.

Different change agents will come up with different solutions to the unique problems of the change recipients they are working with. This can be considered a good thing, different groups of change recipients will often require different solutions that match their context.

However, taken to the extreme, executing different changes in different parts of the organization can result in a solution that doesn't make sense or work very well as a whole.

Different lean and agile methods place emphasis on different things, and even may contradict each other in the advice they give. Without care change recipients and other chain stakeholders can become confused.

Change Agents working on an organizational transformation, one where a larger number of Minimum Viable Changes will be introduced to the organization, should spend some time on planning and modeling what a transformation can look like from the perspective of the entire organization. Just like a Minimum Viable Change, elements that make up the model for a transformation level change can be thought of as assumptions that can validated through experimentation.

An organizational transformation model can be used to ground and otherwise constrain the various minimum viable changes that pass through an organization. When a change agent begins work on a new minimum viable change the first point of reference is the organization organizational transformation model. Does the minimum viable change fit within the overall objectives of the organizational transformation?


A Transformation Canvas Models the Elements of an Enterprise/Organizational Transformation
Just like a Change Canvas can be used to model the elements of a Minimum Viable Change, a change canvas can also be used to model the elements of an organizational transformation. We call this type of Change Canvas a Transformation Canvas.

The main difference between a Transformation Canvas and our previously discussed Change Canvas is one of scope, a Change Canvas used to model an MVC is concerned with improving the lives of a particular segment of change recipients within an organization.

A Transformation Canvas is used to model the concerns of either the entire organization or very large subset of an organization undergoing a transformation.

A Transformation Canvas can be validated through the implementation of one or more Minimum Viable Changes.

When using the Transformation Canvas this way, you're asking change agents to take part in a two tier, hierarchical planning process.
At the top layer an organizational Transformation Canvas is designed, and a suggested set of Minimum Viable Changes are prioritized using a Kanban style backlog.
As change agents become ready to work on new Minimum Viable Changes, Change Canvases are defined and validated through improvements experiments.

Using this approach feedback trickles from the lowest level, learning from Improvements Experiments impact the validity of elements on the MVC Change Canvas, and changes to various MVC Change Canvases impact the Transformation Canvas, and thus cause change to the transformation.

Shown below is an example of the transformation canvas. It's very similar to a regular change Canvas only larger, content is also geared towards discussing an entire transformation.
.



Read More Lean Change - Chapter 5: Using a Transformation Canvas for Enterprise Change

1. Understanding Why We Need an Organizational Transformation Canvas
2. Applying the Change Canvas to Transformations
3. Mitigating Change Risk through Traversing the Canvas
4. Prioritizing Different Minimum Viable Changes Based on Risks on the Organizational Transformation Canvas

Realizing the Change Canvas Through the Validated Change Lifecycle

As change agents and change recipients take a Minimum Viable Change through the Validated Change Lifecycle different sections of the Change Canvas become validated through a number of different methods.

In this post I'll provide a summary of how our team has been typically validating the canvas depending on where it is within the lifecycle.

It is common for a change agent to create a draft canvas as soon as he feels that a change would be a benefit to one or more change recipient groups.



Upon entering the  Agree on Urgency  state the change agent may put a little more  thought into the urgency and change recipient sections to prepare for initial conversations with stakeholders. Remaining portions of the Change Canvas will  often only contained cursory notes or initial guesses as to what the contents would be.



As a Minimum viable change passes through the Agree on Urgency state the Urgency and Change Recipient sections of the canvas are validated through discussion with one or more change recipients. It is typical for the Targets, Vision and potentially other sections of the canvas to be given further consideration as a result of these discussions.


When the Minimum Viable Change passes through the Negotiate Change state the change recipients and change agent discuss how the Vision and Target State sections could address the various problems stated in the Urgency section.


Work then progresses on agreeing on a set of Action Items, Commitments and Benefits. After the majority of the canvas is completed, Success Criteria can be defined for the Change Canvas.


When the Minimum Viable Change passes into the Validate Adoption state, a backlog of Improvement Experiments are created. Each of these Improvement Experiments are responsible for validating that the actions listed in the Actions section will help change recipients move towards the Success Criteria defined boundary in the Change Canvas.


As improvement items are moved through the improvement lifecycle of Prepare, Adopt and Learn, various portions of the canvas are validated from a behavioral perspective. Can change recipients successfully use the new methods?


Once the Minimum Viable Change moves into the Verify Performance state Improvement Experiments are now executed, but this time improvement items are evaluated from the context of improved performance. Again as improvement items are moved through the Prepare, Adopt, and Learn lifecycle the Change Canvas is evaluated for correctness, this time from the perspective of performance. Can change recipients operate in a more effective manner because of the suggested change?


Read the Rest of Lean Change - Chapter 4: the Validated Change Lifecycle

1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
2. State 1: Agree on the Urgency of Change
3. State 2: Negotiate the Change
4. State 3: Validate Adoption
5. State 4: Verify Performance
6. Realizing a Change Canvas through the Validated Change Lifecycle
7. Instantiating the Lifecycle Effectively Using Information Radiators

Using the Change Canvas to Illustrate Agile and Lean Change Patterns

Planning and managing changes using a Change Canvas has allowed our team to recognize a reoccurring set of agile change "patterns". Change agents can review these patterns when looking for a source of inspiration on how to structure the different elements of a Minimum Viable Change. We've represented these patterns using the Change Canvas, providing a visual and compact way to articulate and discuss the different aspects of these patterns. This is just an initial list, hopefully others will be able to add to the catalog over time.

The Quick Win

Agile and Lean transformation are at their greatest peril when they first start. Quick and tangible results are a great way to prove the case for larger more ambitious change efforts. Early success helps mitigate resistance from naysayers, and provide the organization with confidence to invest further and deeper.



The Quick Win is typically targeted at a small number of eager adopters such as what could be found in a medium-size team approximately 6-10 FTEs. No more than 1-2 managers and executives should be impacted at direct stakeholders. The idea is to make sure that the Quick Win is targeted at a small number of change recipients, and that those change recipients are capable of acting as a true guiding team and champion for larger change initiative.

The Quick Win should be targeted at solving a few immediate and tactical problems. Obviously, we are not looking at a strategic or long term return on investment, the value here is showing some kind of return within a month or two of effort.

The Quick Win should also be small in scope, adopting agile method, or perhaps a couple of closely related methods. Examples here include helping teams get started with Kanban or Scrum, or some Agile Modeling.

Commitment often comes in the form of some part-time coaching, a couple of days of upfront training, as well as the appropriate amount of time, perhaps no more than 6 to 9 weeks to learn the new techniques. Benefits of this kind of change include change recipients being successful at the new method as well as receiving some reasonable performance benefits in the short term. Success criteria is likewise measured in terms of the number of people who improve in relating capability, and could also be measured in terms of improved velocity, lead time, or quality.

The communication method should largely be in person, we want to support quick feedback, and potentially drastic changes in direction, this is harder to do when engaging with distributed teams.

Again, this type of change is typically considered earlier in the context of a larger agile transformation. We want to tackle resistance to an agile transformation through delivery of early value. This is a good way to validate an isolated component of a larger agile transformation. This type of change is also really good for validating adoption tactics, as well as determining if the relationship between commitments and benefits are remotely correct. Be ready to pivot on this point, as the effort to commitment is extremely hard to determine upfront.

Below is an example, a favorite Quick Win of ours improving business agility through adoption of the Kanban method.







The Kernel Pilot

After a number of Quick Wins have been executed within an organization, there can be enough momentum to execute a more ambitious change, one that more broadly reflects the organization's suggested true North. Previously implemented Quick Wins should have provided some validation on different aspects of the potential target state, adoption actions, and overall effort, reducing risk of attempting something a little larger.







A Minimum Viable Change using the Kernel Adoption pattern is typically targeted at an entire value stream, from intake all the way to support, and all the steps in between. Often this can be represented as one "line of business" of the organization. It is crucial to involve managers and executives, both from the perspective of capability management as well as issue escalation and resolution. The change should be directed against problems that are also drivers for the overall agile transformation, for the change to be truly valid, it should address most of the drivers behind the overall transformation.

The target state for this Minimum Viable Change should serve as a reference point for the desired state of the overall organization. Once this Minimum Viable Change is complete change recipients should be using new methods, possibly in a flatter, more network-based organizational structure, potentially leveraging new, wider role definitions.

Immersive coaching, facilitation, and even embedding experienced experts within delivery teams is often required to successfully help change recipients shift to new methods. As the choice of methods and techniques become stable, some effort can go into developing and socializing a light weight methods library.

The larger scope and scale of this type of Minimum Viable Change means that a bigger commitment is required. Our experience is that it can take anywhere from 3 to 6 months to execute, and may require 1 or even 2 full-time change agents.

Benefits come in the form of improved performance and improved capability, but also in the form of validation; the kernel pilot can be thought of as a beachhead for the larger organizational agile transformation, and is the first cohesive step into this new direction.

Again, it is often safer to implement a Minimum Viable Change based on the kernel pilot after one or more Quick Win style changes have been successfully executed, this will reduce the risk of adopting the wrong kernel.

As this change reflects the first time that different components of the target state have been adopted at the same time there will still be significant learning, expect to adjust on all elements of the canvas, and even pivot on the target state.

The relationship between commitments and benefits may seem off at this point in the transformation. This is because a significant amount of learning is still taking place, don't panic if a lot of handholding is still required at this point, optimizing the learning effort across the organization can take place later. Remember that the purpose of the change using this pattern is to try to get a first foothold on the overall target state of the organization.

Below is an example taken from our real world experience, where we helped the knowledge workers within one product delivery group to adopt a cross functional, co-located agile team model supported by a number of management, planning, and modeling methods. This agile "suite" was our suggested stack for the target state of the majority of the organization, and executing this change on a smaller group allowed us to refine the stack as well as the remaining assumptions within the change model.



Kernel Adoption

As one or more Kernel Pilot is implemented within the context of a single agile transformation, the transformation can evolve out of pilot mode and into adoption mode. An MVC following the kernel adoption pattern is less concerned with validating change solutions or change tactics, and more focused with trying to optimize the rate of adoption, converting a transformation from a high touch/high support approach to one that is more based on self-study, peer-to-peer sharing, and evolutionary improvement.



As an agile change is rolled out across the organization more effort can go into refining, publishing, and socializing training guides, methods, and other tools that can help knowledge and learning scale to a larger audience. Change agents should be spending more time training other members of the organization to be true change champions, agile knowledge experts, and owners of any methods or tools. High touch, in person coaching can now start to be graduated with other learning methods that can scale out to the entire organization including self training, online knowledge repositories, and communities of practice.

The target state for an agile transformation is never "done", so some aspects of the change solution will continue to require validation and potentially change in direction.

Self-Starter



a Minimum Viable Change modeled on the Self-Starter pattern attempts to provide an opportunity for change recipients to guide their own adoption. Various improvement methods such as training material, peer working sessions, scheduled times for change recipients to attend "tutor drop ins", and mentorship programs are used to allow employees and management to self select their learning pace.





Both new employees as well as those targeted for later adoption will require the means to educate themselves on how the organization is trying to deliver, sometimes long after an agile transformation is considered "complete".

A Self-Starter can also be useful in that it provides employees with permission to start moving to new approaches in advance of any "scheduled" adoption plan. The Self-Starter is also considered "safe", adoption takes place at the comfort level and pace of change recipients. Sometimes, curriculum and pull-based tutoring needs to be complemented with some kind of organizational incentives to adopt, this can be as simple as recognition for employees who have achieved a certain level of capability.

Supporting self learning can take more effort to set up initially, especially if new training material and/or capability models are not already available. Some internal marketing and finally a change recipients may also be required as the Self-Starter kicks off.

It's often recommended to support this effort with at least some kind of part-time tutoring which can be either scheduled or on an as needed basis. When supported properly, this kind of change scales well, and more than makes up for the initial effort. Besides providing the organization with the improved performance that comes with better capability, heightened morale can lead to better employee retention. A good Self-Starter program will continue long after the agile transformation is considered "over".

As stated previously a Minimum Viable Change following this pattern is better introduced later within the context of an agile organizational transformation. The overall approach and applicability of any particular methods should have already been validated thanks to one or more previous MVC's. Validation for a Self-Starter comes from testing whether employees within the organization can improve independently and "pull" help when and if required. Change agents should also be looking for ways to optimize the benefits gained compared to the commitments required.

The example below is taken from an agile transformation that I was a part of. Midway through the transformation it became clear that we did not have enough coaches to support the demand to assist various teams in adopting agile methods. We had already conducted a number of pilots across the organization and had enough training courseware and other material to support the notion of a self-starter. This will provide an avenue for employees who wanted to get started with agile but did not want to wait for dedicated coaching assistance.

This self-starter consisted of some guidelines and training exercises that would get them familiar with basic agile methods such as iterations, using user stories, and collaborative planning. We published this material to the corporate intranet, and announced a weekly 3 hour drop-in where anyone interested could receive coaching and assistance and have their questions answered relating to any of these techniques.



Capability Modernization

True improvements for many organizations will mean taking an honest look at current capability, methods, and techniques and revitalizing them to support business agility. A Minimum Viable Change following the Capability Modernization pattern is focused on improving delivery and/or management techniques for a functional capability within an organization. In more traditional organizations this often mean a functional department, in more modern agile organizations this will mean a collection of employees who can fit into a particular role. Examples include retooling all of the developers within an organization, or providing training and coaching on agile management techniques for all managers and executives.



A change following this pattern typically targets a larger set of change recipients, i.e. all employees that fit within a similar role (e.g. all testers). Any managers responsible for building capability for that role will also be similarly impacted.

Effort should be focused on building a number of "capability gurus" who can act as knowledge leaders and method owners of the new approaches.

Organizations tend to consider the Capability Modernization pattern when things are truly "broken", expertise across the function is considered to be legacy at best, and the current level of maturity is causing a noticeable and growing impact in performance and is having a visible impact on business outcomes.

The target state for this pattern is a complete refresh in terms of capability for that role, including career path, required skills, training and other tools and accelerators. This considerable investment may involve restructuring the organization from a more traditional specialist model to a more horizontal one, and rethinking how careers within the role can progress based on expertise.

A clear and graduate curriculum is often developed, and then introduced onto projects using a rolling wave approach. An effective approach can be to require that all training homework be conducted on real project work. A combination of hiring externals, as well as mentoring existing employees is used to help build a team of capability gurus. These capability gurus act as senior keepers of the flame, and are responsible for ensuring continued commitment to excellence and quality found in the best of agile organizations.

This type of Minimum Viable Change requires a lot of investment on behalf of the organization. Staff wishing to become gurus, need to commit the time required to master new skills to the point where they can train others. Girls need to be carefully selected, not everyone is cut out for this kind of dedication.

Methods and tools, and the training curriculum to support them need to be adapted to the context of the organization, and the training capability needs to be developed as well. This is also a significant investment.

Finally, deep and meaningful change in terms of adopting new methods will take time, this type of change will typically take months to execute. Several full-time, and senior change agents are often required to support this type of change pattern, and be change agents must have years of experience in the selected methods and techniques.

When this type of change is done correctly, benefits to this type of organization are significant. Improvements in capability lead to higher quality, which lead to significant and sustainable performance increases over time. There are no real shortcuts to improving delivery outcomes. Equally important, is that this type of change shows a willingness to invest in people's careers and in their capability, which improves morale.

In the context of a larger agile transformation, a change following this pattern should be done later, a number of Quick Wins, Kernel Adoptions, and even Self Starters should have already been introduced to the organization, providing feedback on what works and what doesn't. Large portions of the transformation will already been validated, key learnings from this Minimum Viable Change will come in the form of understanding how we can scale out the change to the rest of the organization.

A good example of this kind of change would be trying to achieve a state of "technical excellence" through adoption of methods that can be found within the software craftsmanship movement. This includes techniques such as test driven development, SOLID development techniques, continuous integration and continuous employment, perhaps even to adoption of some DEVOPS techniques.



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 5 Communication

One of the most overlooked aspects of any change initiative is the need to communicate with all members involved. This includes people directly affected by the change, as well as sponsors and other stakeholders who may be directly impacted.


Poor communication is often cited as one of the biggest reasons that change initiatives fail.
A good way to start is by understanding how you want to vacation to flow to your direct change recipients as well as the other affected sponsors and stakeholders. Simply tracing how the information should be passed using a simple notation should be sufficient.

 
Different communication channels can be bidirectional meaning that feedback and response is expected from the receiver of the condition.
  
 
As well as unidirectional meaning that up to vacation will be broadcast out to a larger audience.

 
when completing our change canvases we have often expressed the various communications that will be processed using a cadence model. Using this approach we can express the time interval that various communications will be sent out during the lifetime of the change initiative.


communication channels that we've used in the past include

• status meetings where we review progress of the change initiative often with stakeholders, sponsors, and folks were not necessarily directly impacted by the change

• intranet/Web communications that are sent out both the change recipients as well as the rest of the organization. Another alternative to this is an internal blog and or wiki which makes this a bidirectional channel.

• as well as the use of information radiators, such as posters, dashboards, and other highly physical artifacts that are placed in such a way as to attract maximum attention from both change recipients as well as other members within the organization.

It should be noted that agile visualization systems such as Kanban and agile card walls are themselves great communication channels for a change initiative. We probably can't count the number of times that somebody has walked by Kanban style visualization system and in suitably impressed enough to want to become a change recipient for the next change within the organization.

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 4 Benefits & Commitments

The main sections of the change canvas are meaningless unless all stakeholders involved in the change can successfully make the commitments required to achieve potential benefits. These two sections can be thought of as being balanced with each other, and supporting the remaining sections within the change canvas.

 

Commitments

Use the commitment portion of the canvas to track what is required from all involved to make a change successful.

 
Change recipients and change agents are required to meet the commitments specified within the canvas in order to realize the benefits that will be achieved from getting to the target state.

 
Interestingly the commitment section of the canvas is often the most important one to change recipients. One of the most focal point of resistance to any agile or Lean Change initiative is that change recipients are too busy to take the time to think about improving the way they work. The best way to tackle this concern is to hit it head-on, defining what commitments change recipients can actually make, and then tweaking the rest of the canvas to take into account the available resources.


Commitments come in the way of locating spaces for agile teams or dedicated meeting rooms at specific times to run workshops and classrooms.

 
commitment  can also come in the form of hardware, software and other tools that change recipients may not currently have access to.

 
Often the most contentious form of commitment comes in the form of time required to learn, practice and accelerate in new methods.
  
 
At a minimum is critical to capture an estimate of how much time is required for each change recipients of a particular change. have noticed the change recipients are more willing to give more of their time if this commitment can be tied to specific benefits that will make their lives easier.
 
On occasion we have found it necessary to provide a more elaborate picture of how particular change will affect people's schedules. The calendar type view can be used to show when all meetings are taking place, how long they will be, and who is required to attend. While this might seem overkill, we have found that this type of illustration helps reduce churn when negotiating a change model with change recipients.
 
 
Continuing our previous example, we've illustrated our initial assessment around the time commitment required to help this team gain proficiency in agile modeling and requirements.

Benefits

A successful change initiative will result in benefits received by change recipients

 
Use the benefits section of the canvas to articulate what benefits change recipients will receive as a result of committing to the actions required to make the team successful.


Benefits listed in the canvas can be both qualitative, as well as quantitative.


Types of benefits that could be listed on the change canvas include improved customer perception. Listing this benefit takes some courage on about half of change recipients, they are signing up to definitively improve the way their customers feel about the way they work. We think this is an ideal outcome for trying to pilot new methods, it makes a bold statement that no success is meaningful unless the customer experience is improvement.
Borrowing another page from the mean startup method and metric known as net promoter score could be used to track both current and expected customer perception.

 
Team performance is also something we have commonly used on our campuses. Change recipients who are using more classic agile methods such as from scrum and extreme programming can try to quantify benefits in terms of velocity using burn down charts, and other metrics such as how often teams are able to meet their commitments.
Change recipients using more lean inspired methods such as Kanban can try to quantify performance improvements in terms of throughput and leadtime, leveraging cumulative flow and fiscal process control charts, as well as other metrics such as how often a team is able to meet its service delivery performance promises.


Trying to articulate the exact impact on performance they change initiative will have is a highly subjective art at best. We have seen teams using Kanban report drastically different throughput performance improvement outcomes ranging from 30% to a whopping 200%!

Our team has also seen teams improve their performance up to six times over the lifecycle of a project in A large part because they had the chance to gel, and collaborate effectively.

our team has also noticed that the unit of measure, whether it be user stories or features, tends to change in size and effort once it's been measured. Teams that measure their performance often start trying to shrink their user stories to a small they can be while still delivering business value, this alone has a dramatic impact on performance.
What this means is that implementing a change on anything but a very stable team any quantifiable perform improved you suggest will be a guess.

 
We still think that specifying performance improvements is a good thing to Do for many change canvases, especially when trying to adopt a method on the team. Without this business valued promise of improvement, it can be hard to get the buy-in necessary to make any type of reasonable change to the way people are working.
We think the best number to specify is on the aggressive side of conservative. Specifying a number close to 80% improvement in either defect density, leadtime, or throughput/velocity is achievable for most change recipients that we have encountered, and is also large enough of a number to generate interest in the change itself.

 
Benefits can also be described in terms of improved capability of the change recipients. While this can be expressed in numbers, this is really a qualitative benefit. One way to do this is to simply express the number of change recipients who have achieved capability in a certain skill.

 
Capability could be expressed in terms of a graduated ladder, or if desired more complex capability model could be designed to support the change. In this case, capability benefits could be described as the number of folks reaching a certain level within the capability model.

 
Looking at our previous example, we can see our assumptions around benefits both from a performance as well as capability perspective as a result of executing this 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