Beruflich Dokumente
Kultur Dokumente
This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License
to my wife, Barbara, who has provided me with endless support and patience, without which this
book would not be possible.
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Who Is the Lean Change Method for? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Focus Is on Practice Not Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
This Book Assumes That the Reader Has Knowledge of Various Lean and Agile Techniques,
Terms, and Buzzwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Brief Thank You to the Giants Who Have Inspired This Method . . . . . . . . . . . . .
A Quick Blurb on Copyright/Legalese . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What Is the Current Status of Lean Change? . . . . . . . . . . . . . . . . . . . . . . . .
Book Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Lean Change Method Is Still a Work in Progress . . . . . . . . . . . . . . . . . . . .
.
.
.
i
i
i
.
.
.
.
.
.
i
ii
ii
iii
iii
v
.
.
.
.
.
.
.
2
2
6
10
11
16
23
26
26
38
53
55
60
75
75
82
86
92
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
CONTENTS
Verifying Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Looking at How the Canvas Evolves through the Lifecycle . . . . . . . . . . . . . . . . . . 103
Communicating Information Coming Out Of the Validated Change Lifecycle . . . . . . . 109
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
114
114
122
131
134
140
144
148
151
155
158
164
170
178
187
. 193
.
.
.
.
.
.
193
195
197
200
201
203
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
207
207
215
227
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
234
234
239
246
CONTENTS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
250
253
256
259
265
270
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Traditional Approaches to Technology Delivery Is No Longer Suited to Todays Market . . 273
Agile Transformation Is Extremely Hard . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Introduction
First of all, thank you for purchasing this book, and electing to take the time to read it. The Lean
Change method is something new, and while it has been tested in the field, it contains a lot of of
ideas and practices that are still being validated as we speak. I am grateful to those of you who elect
to take part in the continued experiment that is the Lean Change method.
Introduction
ii
artifacts and other terminology are mentioned. This book does not attempt to delve deeply in the
background on the large and diverse world of agile concepts. Doing so would probably have tripled
the size of this book!
Introduction
iii
of Change process, taken from John Kotter s book The Heart of Change, which is copyrighted by
Kotter International.
This book also makes frequent use of the Kanban method, and cites concepts and techniques
described by David J. Anderson in his book The Kanban Method: Successful Evolutionary Change
for Your Technology Business which is copyrighted by David J. Anderson.
Book Summary
Each chapter of the book builds on concepts from the previous chapter. Basic concepts are elaborated
on and extended to make them more suitable for change plans that are more complex, and
transformations that scale out across the enterprise.
Chapter 1: Managing Change with a Change Canvas describes a core component of the
Lean Change method, the Change Canvas. The canvas will be illustrated through a story of a
team member trying to encourage his team to adopt agile methods in order to save a failing
project.
Introduction
iv
Chapter 2: Building a Minimum Viable Change The chapter introduces the concept of a
Minimum Viable Change. Providing guidance on how to create changes that are small, and
how to support this change with explicit experimentation, making the change testable, and
enabling a concept known as validated learning.
Chapter 3: Exploring the Change Canvas In Detail Provides change agents with a robust
set of tools and accelerators to support deeper analysis for different sections of the Change
Canvas. Change agents can elect to use these different Canvas plug-ins as appropriate when
more detail is required to support a change model. Techniques range from Five Whys to Value
Network Design, and from Storytelling to Quantifiable Change Funnel Metrics.
Chapter 4: The Validated Change Lifecycle Shows how change agents can realize a Minimum Viable Change through a four-state process based on the Kotter change management
lifecycle. Each state is described in detail, along with the specific actions change agent can
take in order to move a Minimum Viable Change through the lifecycle. Setting up a Validated
Change Kanban is also discussed. A comprehensive example is provided, showing how a
change agent engages with a group of change participants in the cocreative process to both
define and validate a Minimum Viable Change.
Chapter 5: A Pattern Language for Agile Change Shares a set of change patterns that can
be used to build your Minimum Viable Change. These patterns can be used in isolation or
as part of a larger agile transformation. All patterns are illustrated using the Change Canvas.
Each pattern is discussed in terms of trade-offs, prioritization, benefits, and risks.
Chapter 6: Using a Transformation Canvas to Support Enterprise Agile Change provides
insight on how to use the Change Canvas to model and communicate a larger, organizational
transformation. Advice is provided on how to use the Transformation Canvas either by itself,
or in conjunction with a set of Minimum Viable Changes. The chapter provides guidance
on how to examine the Transformation Canvas according to severity of risk, and the actions
recommended to mitigate risk on a larger organizational change.
Chapter 7: A Cadence Model for Managing Enterprise Transformations Using Lean
Change Discusses how the flow of information required to keep an enterprise transformation
can be modeled, and then managed using a series of workshops, meetings, and other sessions.
An example model is provided, along with details behind various workshops used in the
model.
Appendix: Challenges in Getting from Traditional Methods to an Agile World Provides
a general background on agile methods and lean thinking. It provides a brief overview on
where traditional management thinking comes from, why this thinking is no longer suited
to the challenges of a modern economy, and how lean and agile methods provide a new
answer for the technology organizations of today. Challenges with current approaches to agile
change management are discussed, including big-C change, Scrum, and Kanban. Finally a brief
overview of the Lean Change method is presented.
Introduction
control approach, meticulous planning and coordination, and the development of robust standards
and procedures that carefully lay out the most efficient way to complete a particular task.
Traditional management techniques try to leverage economies of scale; specialists are grouped
together into functional departments, highly repetitive activities are typically completed in large
batches, and passed from one specialist group to the next. Customer demand is serviced in large
quantities, again using a big batch approach.
In a market where customer wealth is low, this approach can effectively service customer demand.
Economies of scale are easy to leverage, as a limited selection of products can be introduced to a large
and undifferentiated customer market. Traditional management seems to work well when product
lifecycles are extremely long, i.e., it takes years or sometimes even decades before one product would
be displaced by another due to innovation or technical advancement.
However, in todays fast-moving market, organizations can be incredibly efficient, follow plans to
perfection, and be incredibly effective at coordinating thousands of specialists, but still fail as a
business. Successful enterprises are now required to continually provide differentiated products and
services at an accelerated rate. Product obsolescence can come in months, weeks, and even days.
Organizations using Lean and Agile inject learning and accelerate creation of value using a number
of methods.
So, to summarize, this book is about helping organizations successfully transform from a traditional
mindset to one that can leverage more lean and agile thinking. This transformation can be incredibly
challenging, and requires management methods to enable success.
business domain. Unique requirements, where they are met, are typically specified by the executives
of the organization, and maybe a small focus group of representatives. The change is implemented
Big Bang, using upfront design, and static plans.
At its best: a big C change will always cause a medium-term something for his performance,
but dramatic degradation in organizational performance. New methods need to be learned, new
responsibilities take time to master, and new skills take time to acquire.
If the organization is able to successfully stick with the change, then performance will bottom out
at the new, deteriorated level of performance. Eventually the desired changes will have the effect of
improving performance, allowing the organization to reap the benefits of the target state.
The big issue here is that the less mature an organization is, the deeper the performance drop will
be once the change starts. Paradoxically, the less mature the organization is, the less tolerance that
organization will have for this performance drop. This paradox of change almost guarantees that
any organization that requires a Big Change will not be able to successfully execute on that change.
up with a target state for the future, creating gaps by examining the current state of the organization,
and finally developing a multiyear implementation roadmap. My team and I would typically stick
around for the first couple of phases of the change rollout.
It became immediately obvious to myself and my associates that the words fixed plan, and
organizational change do not belong in the same sentence. We could immediately see how many
of our assumptions behind the target state model, and change tactics used to realize that model, were
incorrect the moment we started rolling things out. But it was difficult for us to communicate our
learnings to our clients, too many of these folks were focused on tunneling their way through the
plan, wanting to get out of the other side. The result was a lot of dissatisfaction from people on the
ground, increased organizational dysfunction, and an overall decrease in delivery performance for
the organization.
The traditional change approach is the antithesis of the way we do things in a lean world.
Its disrespectful to the people being asked to change, creating deep-rooted change resistance.
Organizational change antibodies form, to continually fight the change. Change plans typically
become unsustainable over time, and often results in the wrong change for the organization, making
things worse in terms of moral and business outcomes.
Again to summarize, this book is about managing agile change using lean thinking.
With that discussion underway, lets continue looking at the title of our book, and examine the
portion of the title Through Kanban, Kotter and Lean Startup Thinking.
10
The folks who have worked with me to come up with the Lean Change method think this is a pretty
good change model. There are some problems however. Change agents following this model tend
to follow a fixed planning and an affront design approach. Change tends to flow from the top of
the organization down to the bottom, with every day employees having very little input. Change
also tends to come from outside consultants and brought into the organization. Finally, there doesnt
11
seem to be enough allowance for feedback and learning. This can be catastrophic as sometimes (often
times) a change vision is dead wrong for the organization.
A basic premise of this book, and The Lean Change method, is that we can extend the Kotter change
model with lean thinking. This allows change agents to take advantage of concepts like feedback,
continuous improvement, and validated learning; these concepts can keep an organizational change
on track
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 startups chance of success. The
Lean Startup method applies lean thinking to the unpredictable world of startups. With a little work,
12
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:
13
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, youll see the term Transformation Canvas be used explicitly.
14
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 recipients. 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 the solution is cocreated by both the
change recipients and change agents.
15
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 recipients 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 recipients.
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 recipients, and then provides Learning to change stakeholders. Improvement Experiments
16
are micro, tactical improvement actions that are backed up with a hypothesis that tries to predict
the outcome of the improvement.
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. Specifically, a large portion of this book
describes how to manage agile organizational change using Lean Startup thinking and Lean Startup
techniques.
17
improve work performance through a combination of visualization, just-in-time value creation, and
focus on flow.
Another premise of the Lean Change method, and this book, is that Kanban is used to manage the
flow of change, taking advantage of visual, just-in-time techniques.
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 Life-
18
cycle, 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.
19
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.
20
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? Its 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, Ive 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 Kanbanbased agile adoptions that stalled because of a lack of patience, existing expertise, or direction.
21
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 any 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 support the organizations 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 recipients 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.
22
23
Its also equally true that real, lasting change has to happen bottom up. Regardless of what executives
and management try to do, knowledge workers have to have a say in the way that they work if
performance is going to really improve.
My team and I designed the Lean Change method to help change agents avoid the flaws inherent in
managed change. To do this, the Lean Change method relies on two key principles:
1. Validated Learning
2. Negotiated Change
Validated Learning
when designing the Lean Change method, it was important that change agents could model a
potential change initiative as a set of assumptions. The method then needed to allow us to show
these assumptions to our change stakeholders so that they could validate (or more likely invalidate)
those assumptions. My change management framework needed to help us validate proposed changes
first through discussion, then by testing how people behaved, and finally how they performed as
24
a result of the change. Our method also needed to test whether change was resulting in expected
business outcomes, or only making things worse. I needed a change management method that would
allow me to make organizational change testable, providing insight to the entire organization around
whether a change was succeeding or not!
The Lean Startup method has been a source of inspiration for applying a concept known as Validated
Learning to handle this problem. Validated learning provides an innovative way for knowledge
workers to create value in a highly uncertain world. In the Lean Startup world, product developers
are asked to describe features, plans, and other components of a sustainable business as a set of
unvalidated assumptions. Product developers then validate those assumptions using a scientific
method. Assumptions are described as hypotheses, and then systematically tested to see if those
hypotheses turn out to be true or false.
Lean Change advocates that any change plan also be described as a set of assumptions, and that
change agents and change stakeholders are responsible for validating those assumptions, again using
explicit hypotheses. Validated Learning supports the notion of deliberate change planning without
falling into the trap of a fixed upfront design. Organizational leaders can implement a deliberate
change, without locking them into a particular approach up front.
Negotiated Change
A very hard lesson learned on my part was that validated learning has to come from the people who
are experiencing the change. Earlier versions of the Lean Change method relied on change agents to
evaluate the validity of the change. This was a disaster for a number of reasons. It thus became even
more important to me that any change management method that we designed ensured that the folks
being asked to change had a say in what that change would look like. I wanted my change recipients
to be co-creators of any change initiative that they were a part of. Change recipients also had to be
the ones primarily responsible for evaluating the success of any change program. Validated learning
had to come from the people being affected by the change, not the change agents themselves!
The principle of Negotiated Change states simply that recipients of any change are co-authors and
co-implementers of all aspects of the change. Designated change agents, change stakeholders, and
change recipients act as change co-creators, ensuring that suggested changes get the buy-in necessary
to ensure that they are successful.
25
27
a client improve delivery effectiveness. Maybe you are a program manager or department manager
trying to turn things around for your group. Maybe you are a team member who wants to improve
team performance. In any of these cases, laying out a change plan in a format that is easy to share,
quick to create, and easy to modify will help you cross the chasm of misunderstanding that most
change agents face on a daily basis.
Dan works as part of the team responsible for developing web applications that need to serve
multiple lines of business within his employing organization. Danny feels that most of his peers
within his team have good experience in their fields of expertise, and are passionate about delivering
a good quality product.
Unfortunately, Dan cannot shake the feeling that the project that he is currently working on is
doomed to fail. This team is currently working on a complex application that has multiple business
stakeholders. The project has a short timeline in which to create a production-ready solution.
Despite the fact that his team is working long hours, Danny feels like it is taking an awfully long
time to show working functionality to the various business stakeholders of this engagement. The
team seems to generally agree that there is no end in sight to this project.
28
When working functionality is shown to customers, these customers tend to be dissatisfied with the
results.
There seems to be a lot of confusion both within the project team around what the solution is
supposed to do, and there seems to be even more confusion between the delivery team and business
stakeholders.
Danny is extremely passionate about his craft, and he has been studying up on different ways of
improving his game. In particular, he has been doing a lot of research on agile methods, and how agile
can improve delivery outcomes for businesses trying to deliver working software to their customers.
Danny wants to completely overhaul the way his team is delivering business value through the
adoption of the agile approach.
29
Danny brings this up with his delivery team, and encounters an immediate and stiff resistance.
Most of Dannys team members feel completely overburdened with the amount of work involved
in delivering this project. The last thing that they want to do is spend the time required to learn a
completely new set of practices and new methods. Dannys team members also do not understand
how agile methods will solve their problems, and cant see how adopting agile methods will bring
any immediate benefits to their current project.
In short, Dannys ideas of adopting agile is shut down by his peers without being given a reasonable
chance.
30
Any change initiative should start with the problems being addressed, and establishing a
sense of Urgency amongst each change participant.
Change initiatives will target one or more Change Participants, who connect with the
problems and urgencies identified on the canvas.
Once a set of change participants can agree on a sense of urgency, a guiding Vision for the
change initiative can be established helping to provide a true North for all stakeholders
involved in the change.
This vision helps to guide one or more Target Options, a potential destination that describes
the suggested methods, behaviors, and other aspects of the working environment that the
change participants and change agents are aspiring to. Its important to note that these are
target options, and elements within this section are very likely to change as we learn more
about our context.
Getting to the target options will require that the change agent and change participants
execute a set of change Actions. Examples could include coaching, self-learning and
facilitated workshops.
Participating in these various actions will require Commitments from the various change
stakeholders who may be impacted by the suggested change. This commitment typically
done one on one comes in the form of time required to learn new methods and experiment
with new ways of working, as well as occasionally in the form of budget required to one on
one upgrade workspaces and other work-related infrastructure.
If change participants and other change stakeholders honor their commitments, they should
receive Benefits in the form of improved productivity, more satisfied customers, and better
working morale.
In order to ensure that the change initiative is moving towards the target options and that
change participants are receiving appropriate benefits, measurable Success Criteria are
tracked throughout the change process. This metric is often expressed as the rate of adoption
of specific agile practices, as well as the improved delivery performance.
Finally, any change initiative needs to be supported by good Communication across the
change agent, participants, and other stakeholders.
A change agent can use the change canvas to model, discuss, and iterate on each of the
elements of a potential change by filling in two to three points for each element within
the Change Canvas. While sometimes a little bit more detail may be required for a specific
element, this exercise can largely be left for later. The purpose of the canvas is to provide
a complete model of the potential change, without diving into the details of any one
aspect of the model. This upports communication and eventually, better collaboration.
31
32
33
Danny feels that the big urgency behind the need for change is that his team applies delivery methods
and practices in a very ad hoc and inconsistent way, this is causing delivery to be both slow and
extremely unpredictable when it comes to the quality of what is shown to the client.
Danny feels that an inconsistent and ad hoc approach to meeting with customers, gathering
their needs into requirements, and demoing working software is significantly contributing to an
environment of poor collaboration.
34
Dannys vision for his team is that of a top performing team that can execute using textbook agile,
enabling the kind of environment that he tends to read about in other places.
35
Danny wants to adopt the management practices of Scrum, the technical practices of extreme
programming, the measurement and metrics approaches prescribed by lean, and some of the
modeling practices described in the agile modeling method to enable his team to become best in
class.
Danny wants to hire an external expert to coach the team on a part-time basis in all the methods
and practices necessary to become successful.
36
Danny thinks that learning and adoption as well as usage of the new methods and tools will
take approximately six hours a week for his manager, four hours a week for his customer, and
approximate two hours a day for the rest of the team. Danny feels that that his team can more than
make up for lost time thanks to the extra performance boosting the gain from these methods.
He also sees big benefits in following this approach. He is hoping his team will be able to deliver
approximately 3 user stories per month. He also hopes that hes going to improve his customers
satisfaction using the net promoter score approach, with the aim of getting a score of nine or higher.
37
Danny would consider this change initiative to be successful if it results in both he and one other
team member becoming an agile expert. He is also hoping that the remaining members of his team
have gained proficiency in agile methods and tools. They dont need to be experts, but he wants
them to have some reasonable aptitude.
Danny wants to rely on classic agile style meetings to communicate progress of not only the project
but the change management plan as well. Danny would like to make sure that his team runs daily
standups, that testers and the rest of the team collaborate at least weekly in an attempt to promote
things to the testing environment, and that customers try to replenish a new set of user stories every
two weeks. Hed also like to make sure that customers are working with new code in production once
a month. Finally, the team needs a monthly retrospective to make sure that their change management
plan is on the right track.
38
39
40
Negotiated Change
Negotiated Change is the foundational principle of the Lean Change method. While using a Change
Canvas to communicate your intentions is a powerful way to use the tool, a Change Canvas will
serve you much better if it is used as a mechanism to negotiate the various dimensions of a change
with the people being impacted. Bringing a pre-populated Change Canvas to a set of potential
change participants is a good way to start the process. Various elements can be discussed, and
modified as necessary to meet change stakeholders needs and constraints, such as the time they
can actually commit to improvement, or how aggressive they want to be when it comes to trying
new things out.
This act of negotiation is really the first step along the path of co-creation. We bring a change plan
to a set of change stakeholders, with the intention of enabling them to modify that plan to suit their
needs. Eventually these change stakeholders become true change participants and change owners.
The intention is to help them move past change negotiation and into true change co-creation, where
they start to own the change plan, proactively managing the change canvas and underlying change
plan with minimal or no guidance.
.
The first people Danny talked to were his manager and primary business stakeholder of the project.
He wanted to make sure he had some initial support to go talk to his remaining team members.
Dannys manager immediately noticed that his canvas did not include the project manager. The
current project manager was only a part-time person responsible mainly for managing coordination
and issues related to dependencies between his team and the business and infrastructure-related
teams. Regardless, the manager felt it was important to get him more involved in this project
including providing input on any suggested changes around how the team was delivering.
Both the business stakeholder and project manager thought it was important to have a director level
executive act as a sponsor and champion for any new approaches that the team was going to take.
Both felt strongly that executive support was required if there was going to be any success using
agile or lean methods.
41
42
All four of these change participants felt that the primary urgency for change was that the team
was not going to be able to deliver a product that was of good quality, meeting the customers needs
according to a specific schedule. Any change to delivery approaches or methods had to support a
set of business-critical dates. Peoples jobs were on the line, and any suggested changes to the way
people were working had to be pragmatic and support this outcome.
The biggest impediment to making this date was the fact that it was taking too long for the delivery
and customer teams to resolve issues that impacted the expected functionality of the solution.
43
Danny then decided to hold a meeting with the rest of the delivery team.
When scheduling the meeting, a business analyst approached him and suggested that he add the
project business subject matter expert as another change participant. The analyst worked very
closely with the subject matter expert when defining all business requirements such as business
rules, workflow and overall business process. Any change to the way requirements were gathered
and validated would directly impact this business subject matter expert.
44
When Danny met with the team, he discussed various problems that would resonate with them,
and they quickly landed on the idea that the team fundamentally lacks confidence. They had no
confidence that they would be able to deliver what their customers wanted, and thought that their
customers shared this lack of confidence.
45
Consequently, Danny and his delivery team were able to hammer out a vision that spoke of building
confidence in both the business and delivery teams through working in a much more collaborative
fashion than they were working in now.
When reviewing this vision, the executive sponsor felt that this problem was systemic across the
organization. He suggested adding the notion that any new methods adopted be introduced to other
teams who were facing similar problems.
46
The team felt that the first step in establishing competence was creating a plan based on a reasonable
capability to deliver, but they also agreed that delivering in very small batches would allow the
customer to frequently check quality, making sure that delivery was going in the right direction.
The team also wanted to make sure that the customers were frequently directing what user stories
would be delivered next. The team finally wanted to make sure that any requirements and design
work was done using collaborative techniques borrowed from the agile world such as story mapping,
and specifications by example. JAD style workshops would be used such as those recommended by
the agile modeling method.
47
Different members of the team learned at different paces so they felt the best way to facilitate
adoption of new methods was to compile the practices that they wanted to use from various
textbooks that could be easily purchased. This combination of methods would be supplemented
with samples taken from their current project.
That being said, the team was not at all confident in adopting a new way of working without
significant help from an expert who had already done this before. The team felt strongly that this
change was a nonstarter unless they had some help from an agile expert. They wanted this expert
to act as a dedicated member of the team until such a time the team felt comfortable in working
according to the new model without outside assistance.
48
Danny worked with his team members, as well as the project manager and other stakeholders to
come up with a rough estimate of what would be involved in implementing this change for this
team. He felt that the non-core stakeholders of this change effort would probably need at least three
hours a week to attend an occasional status meeting, help with issue escalation, as well as to get an
overview of what the new approaches entailed.
The project manager, who was now becoming more active on the project would need around an
hour a day to help with facilitation and coordination.
Team members responsible for solution analysis and requirements gathering would be most
impacted. The business analyst and business stakeholder along with the solution designer would
need to spend a minimum of two hours a day working with the new techniques throughout the
duration of the change.
The team felt that developers and testers would be impacted less, with developers and testers needing
to spend around an hour a day in order to be able to make sure that they were working in a format
that supported a more agile approach.
49
While not entirely sure what a net promoter score was, most of the team thought that improving
customer satisfaction was the primary motivator for this change, and so left the net promoter score
benefit as is on the canvas.
The original throughput of three user stories a month was not nearly sufficient for this project to be
completed on schedule. It also did not justify the investment required in learning the new methods
and tools.
After much discussion, the team cautiously agreed to a throughput of six users stories a month, with
the caveat that they would check this number very carefully to see if it was realistic.
The executive, manager and client stakeholder also wanted to make sure that any methods,
techniques and learnings that were gained as a result of this change would be captured in a way that
could be of use to other teams who were suffering from the same challenges. All three of these folks
agreed that many of the problems that this team was suffering from were typical of other projects
being completed within this organization, and felt that this change was successful and that it should
be considered for the rest of the organization.
50
Everyone seemed to agree that success meant that team throughput had risen so that the client would
be able to deliver a solution that was reliable and could support critical business functionality.
The team also felt that this needed to be accomplished while keeping the teams morale high, and
not getting this project done at the expense of burning out everybody involved.
Finally, Danny worked with all of his change stakeholders that they all agreed with the sessions
and meetings specified on the canvas to communicate progress of both the project and the change
initiative.
Danny was then able to conduct a final workshop with all his stakeholders to review the entire
canvas. Danny felt much more confident of his chances of success now that he was armed with an
agile change plan that reflected the needs of his change stakeholders.
51
Chapter Summary
1. The Change Canvas is a visual way to represent a change plan, allowing you to
model all aspects of the change in a compact, concise way
2. This compactness allows you to easily communicate a change plan with a wide
variety of change stakeholders in a short period of time
3. Take advantage of the informal, compact nature of the canvas to engage in Negotiated Change with your change stakeholders, with an eye towards nurturing a
cocreative environment
4. Any Change Canvas you prepare ahead of time will change dramatically upon first
contact with your various change stakeholders
52
The use of a Change Canvas is inspired from the Lean Startup method. This is important because
the second principle, that change take advantage of validated learning, is also inspired from the
Lean Startup approach. Validated learning is based on the premise that learning is enabled through
a hypothesis, experiment, and measure approach.
54
In the Lean Startup world, a core enabler of validated learning is what is known as a Minimum Viable
Product. Folks using 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, a Minimum Viable Product can be thought of as the smallest product increment that can
enable learning necessary to understand the sustainability of a particular business or product.
The Lean Change method borrows the MVP concept, but in our case, this learning enabler is known
as a Minimum Viable Change. We define a Minimum Viable Change as the smallest possible change
that will enable learning necessary to understand the viability of the overall change program.
55
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 on what is learned while executing 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, we need to do two things:
1. Reduce the scope of the change to make it Minimal
2. Implement the change using Improvement Experiments to validate that the change is Viable
56
We dont want to make it so small that we wouldnt consider the change a complete change. For
instance, it should still have a targeted set of change participants, a set of actions, target options,
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 while still resulting
in a complete change. In other words, all sections of the canvas should be considered.
Our previous change model can be reduced in scope simply by paring down elements within the
urgency, change participant, or target options box to one 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 see that there
are a number of ideas that are not necessarily core to the change being suggested. Looking at the
target options, there are really three distinct themes: the notion of achieving continuous flow and
establishing steady throughput, perhaps using a lean oriented technique such as Kanban, the idea
of using collaborative modeling and collaborative management methods, and finally, the idea of
establishing a steady cadence for replenishing work.
57
If we agree with the premise that the majority of problems currently being faced by Dannys 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, etc.
58
This would have the effect of reducing the scope of the change initiative into a more manageable bitesize piece. We can then reduce the vision to reflect this smaller scope, along with the commitments.
If we look at the actions and benefits section, we see mention of reusable and repeatable methods
framework or library. While this is probably useful to the organization, it does not really address
any of the urgencies felt by our core change participants. In fact, for a team that is struggling to
learn new things and 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 should do.
.
Our Change Canvas now represents a minimal change. Our next step is to try and make it viable.
59
60
Its been my experience that there is no right size for a change, even a Minimum Viable Change.
While the change needs to be small to enable learning, it needs to be big enough to validate that
your overall managed agile change is heading in the right direction. This typically means that your
Minimum Viable Change includes a set of interrelated components that can help you evaluate change
direction.
One way to manage Improvement Experiments is to track them using a 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.
61
Kanban in Brief
Pioneered by David J. Anderson, the Kanban Method uses a combination of techniques to improve
agility for knowledge workers. These methods include a visual system that is used to track the state
of all work tickets going through a particular value stream. This visualization system is known as a
Kanban Board. Kanban is typically used by delivery and maintenance teams that work on software
products and software applications. Being visualized on this type of Kanban are typical for those
used by the software delivery profession, i.e., analysis, development, test, deploy, etc.
.
Different columns represent different states within the improvement lifecycle. As Improvement
62
Experiments complete a particular state, they move from left to right across the Improvement
Experiment Kanban.
The left side of the Kanban represents 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.
63
The numbers on top of each column are 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.
64
Below is a real-life example of a MVC Change Canvas along with an Improvement Experiment
Kanban below it.
65
66
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.
1.
2.
3.
4.
67
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
constraintAn 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 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. Its a good practice to write the outcome from the perspective
of the change participants, and 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, i.e. when the emergency defect occurs.
Its 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 dojos isnt as good as developers
will indicate their mastery of TDD after three coding dojos.
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. Its 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.
.
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 three sessions .
68
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 Dannys case he works with a new, external, agile consultant recently brought to the engagement. They work together to prepare workshop materials, book rooms, and coordinate everybodys
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.
69
The Improvement Experiment continues until either the experiment has proven true or false, or the
constraint has elapsed.
In Dannys case, the value stream mapping Improvement Experiment is moved into the Learn
column after three sessions have been completed.
70
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 Dannys 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 its 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.
71
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.
72
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.
73
Chapter Summary
1. The second core principle of the Lean Change method is that change is subjected to
validated learning, enabled through defining and delivering change as one or more
MVCs.
2. A good practice is to reduce the scope of a change to the smallest size that can still
represent a complete change (making them minimal).
3. Validated learning is achieved by subjecting the assumptions in a change plan to
validation by change participants.
4. Changes can be validated through Improvement Experiments that move the change
forward while allowing change participants to validate change effectiveness (making them viable).
5. Improvement Experiments are managed using an Improvement Kanban, and following a Prepare, Introduce, Learn lifecycle.
6. The Change Canvas used to represent a MVC should be examined and updated
periodically to reflect the latest learnings gained from Improvement Experiments.
74
Ive also discussed how a Change Canvas can be refined so that the change is minimal, as well as
subjecting it to explicit experimentation to ensure that it is viable, and thus creating an MVC in the
process. This allows us to incorporate the concept of validated learning.
76
In this chapter, Ill continue to build upon these previous topics, going over the Validated Change
Lifecycle. The Validated Change Lifecycle provides a path for Minimum Viable Changes to be
developed and validated in a way that maximizes feedback and learning.
Using the Validated Change Lifecycle risks and assumptions that tend to impact change initiatives
first can be dealt with earlier. Other risks and assumptions that impact change initiatives later can
be deferred until it makes the most sense.
Change agents who elect to follow the lifecycle are able to learn faster about whether a particular
change is viable. The idea is to provide feedback with less effort, so that a decision around whether
to pivot or pursue or abandon can be made earlier.
As described in previous chapters of this book, validating a MVC requires subjecting the assumptions
behind the content of the associated Change Canvas to experimentation. Each assumption can be
77
expressed as a hypothesis, which is then tested for correctness. The Validated Change Lifecycle
provides guidance to determine which assumptions to validate first, based on the severity of the risk
inherent in the assumption.
Even when there is a genuine desire and willingness to change, theres still a question of sustainability. Many Change initiatives start with a bang, and then fizzle out over time. Change participants
become burned out trying to adapt to the new models and new methods of working, as a result,
change programs are often only partially completed. Many Change plans simply do Not come
to fruition, because we do not adequately manage how much commitment is required from the
organization and its employees to make the change.
78
Finally, even when resistance has been adequately dealt with, and the pace of change is sustainable,
any upfront change plan may simply specify the wrong solution. You may recall from previous
sections of this book that we discussed the pitfalls of upfront planning and upfront design. You
read about how this approach is not suitable for delivering business value in the face of extreme
uncertainty. Any change solution is especially hard to plan as outcomes are very unpredictable.
Change agents expecting any predefined change plan to survive intact throughout the lifecycle of
the change initiative is facing certain disappointment.
The Validated Change Lifecycle is inspired by the Kotter Eight Steps of Change model, and adapted
into a four state lifecycle. This lifecycle is also heavily inspired by Ash Mauryas Meta-Iteration
Lifecycle Pattern described in his book Running Lean. Minimum Viable Changes are both defined
and validated according to a specific sequence by passing through the lifecycle. The Validated
Change Lifecycle provides explicit acceptance criteria to determine when a MVC can move through
four specific states
79
Check out the appendix for the section on The Eight Steps of Change for more details on the eight
step lifecycle.
.
Much of the language contained within the Change Canvas comes from Kotters Eight steps of
change. In fact, most of these steps align closely to one of the Change Canvas sections.
80
What this means is that each section within the canvas contains assumptions which when validated
will mitigate specific risks.
When a Minimum Viable Change is realized using Improvement Experiments, each of these
experiments is designed to validate a specific subset of the canvas. Ordering these experiments
according to the Validated Change Lifecycle allows us to mitigate change risk in the most optimal
order.
81
The first state is focused on Agreeing on the Urgency of why the change needs to take place. Change
agents focus their effort on establishing a sense of urgency and connecting that urgency with a set
of change participants. Change participants who are willing to form a guiding team. This guiding
team acts as a set of champions for the potential change.
In the second state, change agents work with the identified guiding team and change champions
to Negotiate the Change solution, developing a vision for the MVC, as well as defining the target
options. The important part here is that the solution is cocreated by both the change participants
and change agents.
Once the change model behind the MVC has been developed, the change is Validated from an
82
Adoption perspective. The key question we want to answer at this point is can change participants
effectively change their behavior and improve their expertise in specific methods and skills?
As new skills are acquired, change participants will start demonstrating new behaviors and new
methods. Focus can then switch to Verifying Performance improvement are resulting from the
MVC. We want to ensure that the change is resulting in the right business benefits relative to the
commitments required to implement the MVC.
In this state, focus is on connecting a problem/urgency set with a group of change participants who
care enough to actively participate and own a potential change. The process of connecting problems
to a potential guiding team is an iterative one.
Change agents will interview various potential change participants to examine their pain and
problems, and see if they can form a guiding team to act as change champions for the suggested
change.
83
As problems are identified, potential change participants can be evaluated informally based on their
willingness and ability to participate in coming up with solutions and countermeasures.
The change participants section is completed by locating the set of change participants who feel so
passionate nabout a particular problem that they are willing to become adopters of the upcoming
84
change. Filling out the change participants and urgency sections of the canvas is really a process
of discovery. We are trying to find the ideal match between urgency and change participants that
will serve as the an agile or lean related change.
Refer to the Urgency and the Change Participants section of Chapter 4- Exploring the Change
Canvas in Detail for some ideas on how to explore problems, root cause, and countermeasures that
impact various change participants.
.
Ideal change champions will be ones who have demonstrated past experience in fixing problems and
trying to come up with new solutions. Our experience is that many organizations have employees
who have practiced what we call guerrilla agile, adopting one or more methods and practices
without necessarily having organizational authority to do so. Agile change agents should seek these
people out within the organization and target them for the first wave of change champions who can
form a guiding team.
When a Minimum Viable Change is in the Agree on Urgency state, change agents want to focus on
identifying a set of problems that can go into the urgency section, and more importantly connecting
those problems to a set of potential change participants who feel that urgency enough to act as a
guiding team, one that will help co-create and co-execute the potential change.
85
Its perfectly normal for the identifying label of the Minimum Viable Change to be modified as it goes
through the lifecycle. In the beginning of the process, the suggested change may have a very generic
title, such as implement agile methods with a specific team. As more information is understood
about who the potential change stakeholders will be and what the problems are, the title can change
to reflect an agreed-upon vision.
The Minimum Viable Change will be ready to enter the Negotiate Change state once the change
agent has found a set of change participants who are willing to commit to co-defining a change
solution.
86
During this state, change agents typically focus first on defining the vision, target options, and
resulting benefits. A change agent can take a quick stab at the sections and then refine them through
one or more workshops with the potential guiding team, or he can choose to approach a set of change
participants with a blank canvas, and work with them from scratch.
Target options should describe one or more enabling components of a suggested target state.
Examples include using a team model, suite of agile practices, or particular agile method. A set of
targeted countermeasures may also be suggested. Its important to emphasize that target options
are not commitments, rather they are suggested countermeasures based on current information at
this stage of the change lifecycle. Dont fall in the trap of trying to create a detailed design for your
target options. Rather, favor low-fidelity/low-formality artifacts that help you tell a story of what
the future could look like.
87
Benefits are typically described from both a capability improvement perspective as well as an
improvement in performance. We want to articulate how a change will impact change participants
in terms of their ability to work using new methods, develop new habits, and understand new
techniques. This can be done informally, or using a more structured capability model. In either
case, its important to remember that this type of benefit is qualitative.
We also want to articulate how a change will impact performance of change participants.
Performance benefits can often be described using agile or lean metrics, such as improvements
in velocity, throughput, lead time, etc.
Refer to the Vision, Target Options and Benefits section of Chapter 4- Exploring the Change Canvas
in Detail for some ideas on how to come up with a good vision, and target options for your change.
.
Once these sections are reasonably fleshed out, the change agent and the guiding team can work
on taking a stab at coming up with a set of of change actions, as well as start working on the
commitments required to complete those change actions.
As the canvas starts to take shape, attention can then shift to establishing a set of success criteria
that will define what the success of the change looks like.
Filling out Actions, Commitments, and Success Criteria Section of the Canvas
Completing the actions and commitments sections of the change canvas is all about understanding
what level of commitment change participants feel they can make/or are willing to make, and
what are the best actions that both change agents and change participants can engage in to take
full advantage of those commitments. Once this is understood, explicit, measurable success criteria
can be defined that outlines what a successful change could look like.
Change actions chosen can vary depending on a number of factors, including existing capability
of the team, progress of the overall change effort, and whether you want your change to maximize
new learning or scale out previously tested methods. Options for various change actions can
include:
88
One-on-one mentoring
Developing and publishing various training guides
Facilitated workshops
Classroom training
Community/self-serve drop-ins
Each of these options will require a different level of commitment from both change agents and
other change participants. Commitment can be expressed in terms of dollars to procure tools,
facilities, and other infrastructure. The most important form of commitment is expressed in terms
of time required from change participants to benefit from the change program.
Once both actions and level of commitment are understood, success criteria can be entered into the
canvas. Success criteria tracks the impact you want the change to make, both in terms of exact level
and rate of progress. As an example, at the end of a change, we may hope that a certain percentage
of analysts feel that they exhibit a basic capability in agile analysis techniques, and another smaller
percentage indicate comfort at the leadership/mastery level of one or two techniques. We might
also hope that this improved capability will lead to shorter lead times. We can then specify a
reasonable rate of progress depending on the planned duration of our change. This will allow us
to track in real-time whether our change is moving at the speed that we assumed it would at the
beginning.
Refer to the Actions, Commitments and Success Criteria section of Chapter 4- Exploring the Change
Canvas in Detail for more information on how to explore both the Actions and Commitments
section of the change canvas.
Finally, once the major elements of the change canvas are agreed upon, focus can switch to working
out a communication approach.
.
This suggested approach to completing the various sections of the canvas is not set in stone. In
89
reality, the conversation between change agents and change participants will result in the canvas
being traversed in a variety of sequences.
It is important to note that this process is also highly iterative. Discussion in one section of the
canvas will result in refinements in other sections of the canvas and vice versa.
Regardless of the form that the target options will take, it is important to leverage storytelling
90
techniques that are semiformal in nature to help visualize what the potential change will look like.
It is important to note that many Minimum Viable Changes may be abandoned at this point in
the process. While this might seem like a waste, it is better to take this opportunity to abandon a
potential change before expending significant effort in attempting to adopt new methods and tools.
For the most part, the process of trying to agree on urgency, and negotiate change should be
considered a relatively lightweight one that can be completed in a couple of weeks, with only a
couple of days of actual effort required from any individual change agent.
91
In order for a Minimum Viable Change to pass through the Negotiate Change state, target options
and vision must be agreed by the potential guiding team. It is crucial that the solution be
cocreated with this potential guiding team. Critically, change participants need to step up to any
time commitments specified within the canvas, looking at the relationship between commitments,
actions, and benefits as a kind of contract between change participants, the change agent, and other
change stakeholders.
As mentioned previously, the label of the Minimum Viable Change ticket may be modified to reflect
any updates to the canvas.
92
Validate Adoption
During the previous two states of the Validated Change Lifecycle, validation occurred through
discussion. The Change Canvas was validated by measuring how change participants reacted to
different sections of the canvas. Once a Minimum Viable Change enters the Validate Adoption state
of the Validated Change Lifecycle, we are now ready to validate the change by measuring what
people actually do, and how they actually behave.
93
Its important to note that during the Validate Adoption state, measurement and validation is
considered to be qualitative. While we can use numbers to measure how well people are improving
in new methods and techniques, experience and judgment will still play the largest role in evaluating
our ability to help people achieve a specific capability.
The primary purpose of the Validate Adoption state is to determine if change participants are able
to adopt new behaviors, techniques, and working culture related to lean and agile. Its important to
focus on adoption first, and give people a chance to get used to new methods before focusing on
looking at performance or other business outcomes.
One of the first things a change agent should do during this state is to work with change participants
to come up with a backlog of Improvement Experiments. These Improvement Experiments are
designed to validate that specific actions taken by the change agent will result in improved capability
and adoption of lean and agile methods.
Good Improvement Experiments will also be validated against a specific Success Criteria item listed
Success criteria may also have one or more quantitative benefits around improved throughput or
reduced lead time based on this new mastery of agile modeling techniques. Again while these
numbers are just educated guesses when first entered, they are assumptions that can be validated
and then corrected over time. Like qualitative success criteria, quantifiable success criteria also
94
95
serve as the basis for hypotheses of Improvement experiments. For the example above, lets say
that a success criteria could be agile modeling techniques will reduce defect intake to 1/3 of its
current size.
Some Improvement Experiments for the above example could be change participants will indicate
that they can independently run story mapping/analysis workshops with their business customers
after two sessions supported by an agile coach or collaborative/agile JAD sessions will reduce
requirements related defects by at least 50% after 2 months. In both cases, these Improvement
Experiments target specific success criteria, and once they are run, they can provide insight as to
whether your change model is backed by valid assumptions.
Refer to the Success Criteria section of Chapter 4- Exploring the Change Canvassing Detail for
further information on Success Criteria.
.
Our team has had good success using simple agile and lean capability models, tracking a number
of capability dimensions for a particular cohort of change participants. Improvement Experiments
can be designed by creating a hypothesis that outlines how an activity will result in improvement
on some dimension of the capability model.
It is extremely important that change participants take an ownership role in measuring the
96
effectiveness of Improvement Experiments. Change agents should act as facilitators, and almost
never interfere with the teams self-evaluation.
It is also crucial to make sure that teams do not feel like they are being judged or evaluated by any
type of external authority. The use of capability models is especially prone to misuse by management.
Teams need to feel safe to learn at their own pace, and not get into capability competition with
other teams. The point is to make sure that we can validate assumptions behind how much effort
is required to help teams be willing to adopt new techniques, and to collaboratively adjust any of
these expectations if they turn out to be false.
Again our experience tells that estimating the commitment required for change participants to truly
adopt new techniques is extremely hard. This effort is often vastly underestimated, and is usually
the source of the first pivot required to realign an agile change program.
97
Verifying Performance
When a Minimum Viable Change passes into the Verify Performance State of the Validated Change
Lifecycle, the focus shifts to validating that a change is delivering its expected business outcomes. If
we remember our discussion from previous sections in this chapter, MVC is first validated by what
change participants say, then by what they do, and now finally by how they perform.
Like In the Validate Adoption state, an MVC is validated to ensure that change actions can be
successfully executed, balancing commitments and benefits, helping all change stakeholders achieve
the target options. Unlike the previous state, the change agent is not merely focused on testing
whether the changes are resulting in the acquisition of new behaviors, but rather that the change is
actually improving delivery effectiveness.
98
be able to analyze those metrics to look for potential impediments and problems, and have attempted
to implement improvements based on these potential impediments.
Secondly, change participants should be reliably using new techniques, comfortably using new
methods, and have developed new habits. Dependency on consultants or coaches to help change
participants practice specific methods is now minimized. If the team is still struggling to adapt to
new methods, it doesnt make much sense to start trying to evaluate the change canvas from a
performance perspective.
Finally, before any performance-based experiments are executed, it is recommended that team
performance is approaching some kind of stable baseline. What this means is that velocity and/or
throughput exhibits some kind of predictability, and that the system of work has enough stability
to support measurements-based improvement. Typically this means that teams are comfortable
decomposing business requests into the finer grained units of work such as features or user stories,
can limit how much work they have in progress, and are avoiding big batch transfers of work
across knowledge workers. Frequent delivery of customer value is also a common attribute of stable
delivery performance.
It has been our experience that many domains can benefit from a quantifiable experiment and
improve loop. This type of quantifiable improvement is a cornerstone of the Kanban method. The
loop starts by having a set of knowledge workers coming up with a suggested improvement and
articulating it as an experiment using a hypothesis around what benefits the improvement will
bring.
The Improvement Experiment is implemented by knowledge workers who then check to see if
delivery performance has improved, stayed the same or gotten worse. Regardless of the results,
learning takes place, successful experiments become part of the delivery process, and unsuccessful
experiments prime the team to run a different experiment.
99
100
My experience in agile and lean transformation has been to help teams adapt a mixture of classical
agile methods along with more lean inspired methods such as Kanban.
Using lean metrics supports tracking and reporting on performance metrics that can cross the entire
value stream.
Lean metrics that can be used as the basis for a quantifiable experiment include:
Lead time - the overall time it takes to deliver a particular unit of value to an end customer. Lead
time typically takes into account all the wait time that precedes delivery getting started and all the
wait time taking place after delivery is completed. Wait time can be used to measure end-to-end
project delivery, a particular release, or even the delivery of independent user stories or features.
When leadtime goes down agility goes up, quality tends to go up, and overall performance tends to
improve. Lead time is also a good indicator of overall business agility.
Cycle time - is a lot like lead time, but does not focus on the wait times before and after delivery
starts and ends. Cycle time is good for measuring process efficiently, and like leadtime we want it
to go down.
101
Throughput is the number of business valued items that are completed over a particular period of
time. Throughput is often measured as the number of user stories or features that pass through the
delivery process in a given week, month, or other period of time. Throughput is often a number that
managers and executives care about the most.
Failure Load is the portion of work that we are building that represents value that should have
already delivered to the client because of previous work. Customer complaints, defects, and rework
are all examples of failure load. The inverse of failure load is value load which represents the portion
of work we are currently doing that is genuinely considered to be a new business valued request.
Capacity Load is perhaps one of the most important metrics for any team attempting to use leaninspired methods, such as Kanban. Capacity load tracks how much work in process is in the system
compared to the number of workers in the system. Often represented as number of user stories
or features in process per active worker. We want this number to go down. High numbers are a
predictive indicator of long lead times, unpredictable throughput, a high defect density, and a high
failure load. Kanban tracks capacity load as work in process limits.
102
Once this Improvement Experiment has been successfully adopted by the team and they have some
experience in gathering, reporting and gaining insight from metrics, the team can start basing the
hypotheses of future Improvement Experiments on quantifiable, performance-based outcomes.
103
104
When an MVC enters the Agree on Urgency state, the change agent may put a little more
thought into the urgency and change participant sections to prepare for initial conversations with
stakeholders. Remaining portions of the Change Canvas will often only contain cursory notes or
initial guesses as to what the contents would be.
105
As a Minimum Viable Change passes through the Agree on Urgency state, the Urgency and Change
participant sections of the canvas are validated through discussion with one or more change
participants. 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
participants and change agent discuss how the Vision and target options sections could address
the various problems stated in the Urgency section.
106
Work then progresses on agreeing on a set of Benefits. Corresponding Action Items and Commitments required to meet those Benefits are then flushed out. Success Criteria can then be defined for
the Change Canvas. Finally, a communication approach can be agreed upon.
When the Minimum Viable Change passes into the Validate Adoption state, a backlog of Im-
107
provement Experiments are created. Each of these Improvement Experiments are responsible for
validating that change activities listed in the Actions section will help change participants move
towards the Success Criteria defined in the Change Canvas.
As Improvement Experiments are moved through the improvement lifecycle of Prepare, Adopt
and Learn, various portions of the canvas are validated from a behavioral perspective. Can change
participants successfully use the new methods?
108
Once the Minimum Viable Change moves into the Verify Performance state Improvement Experiments are still executed, but this time Improvement Experiments are evaluated from the context
of improved performance. Improvement Experiments are moved through the Prepare, Adopt and
Learn lifecycle. Can change participants operate in a more effective manner because of the suggested
change?
109
The most direct way to reduce this confusion is to make sure that change agents spend the time
necessary to not only educate change participants on agile and lean techniques, but also on the Lean
Change method as well. We want to help folks going through the change process to take ownership
of their MVC and Improvement Experiments. When starting a large organizational transformation,
we recommend that change agents really immerse themselves with the change participant segment
that they are working with, to the point of even considering themselves a core member of the team.
110
While the Lean Change method does have many interlocking parts, the artifacts it produces are
naturally conducive to agile style information radiators. Information radiators are low fidelity,
physical, highly visual charts and dashboards placed in locations that are close to the team and/or
in highly trafficked areas.
Many teams adopting agile practice the habit of using a physical or virtual card wall such as an agile
task board or Kanban system. If using physical artifacts, a good practice is to place all of the Lean
Change related artifacts right beside the physical card wall being used. This includes the Change
Canvas used to communicate your MVC, and the Improvement Experiments Kanban used to track
progress of related Improvement Experiments.
Also include any charts or dashboards that can show the accumulated results of various Improvement Experiments. An example of good dashboards include capability charts that show depth of
adoption in agile skills, as well as one or more performance charts, such as statistical process control
and cumulative flow diagrams. Burn down charts, and burn up charts are also good options.
111
Other change stakeholders such as business customers, executives, and management will also want
to be informed of progress. A typical approach is to prepare status reports and run status meetings
every week or two. This can create an awful lot of overhead, and still not always convey the right
information.
112
A better approach, where possible, is to bring other change stakeholders to where the various
information radiators are already located and hold a review session in front of those various
radiators. In situations where this was not feasible, we have taken photos of the physical charts,
and displayed them as part of our review sessions.
Urgency
The first section of the canvas that I am going to look at is urgency.
115
Completing the urgency section is all about understanding what pain is being felt by different
potential change participants, and articulating that pain in a language that the change participants
understand and appreciate.
Establishing a sense of urgency is one of the first things that need 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.
We dont want to be overly scientific, rather we want to come up with a set of problems that resonate
emotionally, problems that can get the organization charged up enough to engage in the change
initiative.
Five Whys
We have personally had very good success using a tool known as the five whys to help people
analyze problems that they are feeling, get to a particular root cause for a particular problem, and
collaborate with them to come up with a set of countermeasures that can help address the root cause
of the problem.
Five whys is typically executed using a facilitator and a number of change participants. 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 five times. Eventually the answer will come up with what is known as a root
cause for the issue. The group can then try to discuss potential countermeasures for that root cause.
116
While this technique seems deceptively simple, successfully facilitating a five whys session can be
quite complicated. The relationship between problems, other problems root causes and solutions,
is rarely linear.
In reality, problems end up having a many to many relationship with other problems, root causes,
and countermeasures. This means running the session takes some skill in order to keep the group
focused and continually getting them back on track. When running your first five whys session,
dont be discouraged if things go a little offside. You will get much better at running the sessions
after a couple of tries.
117
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.
118
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 and 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 thirty 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.
A Quick Example
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 a set of business customers.
The team is currently complaining that it 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 getting those customers to validate work that has been
implemented.
119
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
who are extremely busy because of other non-project related commitments.
When speaking to these business subject matter experts, their response was 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 for the entire length of the project. The subject matter experts
felt that they needed this information in order to properly balance their workload with many of the
other commitments that they have outside of this project.
A typical solution in the agile 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, the team seemed 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 dealing with the high amount 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 were spending dealing with
quality issues.
When investigating these quality issues, it became clear that the requirements gathering process that
the team was using was 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 build the requested features by enhancing the existing package solution.
120
More often than not, the solution could not be configured to meet the details contained in the
requirements. This meant that almost every requirement needed to be revisited and rewritten to
support the constraints of the package. Even worse, this rewrite was typically implemented only
after a complete solution demo was conducted with business subject matter experts. This meant
that almost every requirement ended up going through the delivery lifecycle twice.
Upon reflection, the team and the facilitator were able to come up with specific countermeasures.
First, the team decided to establish a biweekly story analysis sessions with the business stakeholder/experts, business analysts, and the lead solution designer. This solution designer was an expert
on the technical package that was being used for this project, and had a deep understanding of its
limitations and constraints.
Going forward, the solution designer would not only be available for all analysis sessions, he would
also train the business analysts in the constraints of the technical product, so they could effectively
gather requirements the right way the first time around.
A Value Stream map could also be used to help facilitate discussions. If the facilitator and change
participants had 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.
121
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 who 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.
122
Change Participants
Filling out the change participants box is all about finding effective change participants within the
organization who will emotionally connect with the urgency that you are trying to establish. We
want to articulate problems with the current state in a way that inspires employee members to take
active ownership of the coming change.
When building a Minimum Viable Change, our goal is to find a specific cohort of change participants,
a smaller group of people who are all experiencing similar problems, and who we can organize so
that they all experience a similar set of changes over period of time.
123
A better metaphor is to think of your change participants as stakeholders that you want to engage
in a co-creative manner. Your first change participants are ones that can serve as change champions,
and eventually will become a guiding team for the larger change initiative. A good change recipient
cohort is one that contains people that will help you in defining what the change solution should
look like, and include people that will take an active role in changing behavior of both themselves
as well as the people around them.
Another important attribute when thinking about starting a change is to look for organizational
employees who are already displaying some capability in improving in agile or lean methods. As an
example, suppose we were considering running an agile pilot 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 having to 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.
124
At first glance, it looks like team B needs the change more than team A. But this would be the wrong
team to implement the improvement initiative on, at least early on in the change effort. Team A is
really the ideal choice.
While this team is struggling, they understand that taking time to improve is worth the investment,
and they will be more likely to engage with an agile change agent in a positive manner.
Whenever we start a change initiative, you want to make sure that early efforts avoid resistance to
the maximum extent possible.
This is often best accomplished by simply choosing the area of the organization that is most likely
to deliver us change participants 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 A into the change participants section of the canvas.
He 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 participants who are indirectly impacted by the change at the bottom of the change
participants section. These stakeholders include a business stakeholder, executive sponsor, and
functional manager.
125
Identifying change participants is done in parallel with identifying problems that go into the urgency
section of the canvas.
Using an iterative process, value stream mapping and five whys sessions are facilitated with
varying potential change participants. Each source of waste, problem, root cause and potential
countermeasure can be identified with one or more change participants.
126
127
In this case, change participants 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 example, a group of change
participants could be all executives, managers, or line staff. The change would then be targeted
at all members of a particular level.
Segmenting could also be cataloged by functional group or specialized skill set. As an example, a
specific change could be targeted to all project managers, business analysts, developers or testers
within an organization.
Many segments of change participants will be defined as a particular cross-functional team within
the organization. This is how most agile and lean methods recommend that change participants be
organized. This cross-functional team would include a set of specialized folks from a number of
functional departments. It may also include customers, managers, and executives who interact with
that specific team.
128
Minimum Viable Changes should be targeted to specific needs of the segment. There is a wealth of
agile methods and tools available to serve the needs of particular levels and functions.
Examples of MVCs that could be targeted at these change participants include:
1. Helping managers and executives improve organizational agility through adoption of methods
and tools found in Jurgen Appelos Management 3.0 Framework.
2. Helping developers achieve better agility through adoption of continuous integration and testdriven development.
3. Piloting a particular agile method (e.g. Kanban, Scrum, extreme programming, etc.) or practice
(test driven development, story mapping, etc.) to help a specific team improve their delivery.
129
Finally, here is our previous example with a cross-functional team described as the primary change
participants segment, with management and executives listed as secondary stakeholders of the
change.
130
131
Vision
The Vision portion of the canvas is all about articulating the objectives of your MVC in a single,
compelling statement that resonates with recipients.
A good Vision statement will connect recipients with the benefits achieved through the target
options.
At a minimum, the Vision section 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 and memorable. We dont want to repeat all of the elements found within
our target options.
Engaging visual thinking is important when filling out the Vision section of the canvas. Try to
accompany your Vision with some kind of picture or diagram that can articulate key aspects of the
change. Good art skills are not required, just a little willingness to be creative and imaginative.
132
A good Vision statement for your MVC can often come in the form of
<outcome or objective> for recipient segment> through/with/using <key target options 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.
133
Helping managers within the channels line of business group to enable organizational agility for the
channels department through adoption of Management 3.0 techniques
If we continue to follow the previous example, 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 solution
analysis team that can rely on agile modeling techniques.
134
Target Options
The target options represent what the working environment may look like after your change
initiative has been successfully implemented. Change participants can elect to evaluate multiple
target options against each other.
When developing target options, 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 in the extreme.
We recommend thinking of target options as a preliminary stab at what the target state will look
like. A range of options can be represented. Its best to think of these options as a story, one that
can help guide both the change agent and change participants towards a common path. While some
upfront design is required, the focus should be on helping to communicate one potential option
toward success, not on trying to blueprint an uncertain future.
135
We recommend considering a number of elements to use when trying to tell the story of various
target options. A set of semiformal narratives can be complemented with pictures and photos, video
mockups, semiformal prototypes, and reenactments. We have even seen some folks articulate target
options using lego blocks.
136
who have 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. According to Juergen, the
atomic unit of a value network is typically a cross-functional team.
He then describes how these teams can be combined to form a value network. The value network is
composed of a set of teams that relate to each other, modeled using a collection 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 act as the
integrators between teams, ensuring that work across teams are synchronized.
This value network approach helps organizations to scale the agile cross-functional team concept out
to support an entire enterprise. With this approach, we want to enable cross-functional collaboration
while still considering that we sometimes have the need to coordinate different specialists both
within and across teams. 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.
137
Unlike value stream mapping, modeling value networks makes it easier for us to articulate how
we want work to be processed in an agile and lean environment. When engaging in application
delivery work activities, value very rarely flows along straight lines 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. Each story
then scatters into acceptance criteria that are delivered by the delivery team. Eventually, acceptance
criteria will aggregate back into user stories in order to be tested. These tested stories will aggregate
into a deployable release that can be validated by the customer team to ensure that we meet business
needs.
In an agile world (and in the non-agile one), knowledge work is also rarely handed off from one
team to another to be processed in isolation. Work tends to progress by collaborating both within
and across teams. Again the value network supports this concept.
The value network can also be extended to show the delivery heartbeat used to produce value. As
an example, Scrum teams deliver in iterations that range from one week to one month.
138
The notion of a sprint or an iteration can also be applied separately to different delivery functions,
providing guidelines as to when different teams can integrate work with each other across the value
network.
If organizational agility is the goal, then most knowledge workers should be placed in crossfunctional teams. That being said, specific knowledge workers can also be grouped into specialist
teams in certain situations. This makes sense where delivering value requires part-time support from
highly specialized workers.
In our experience, security experts, legacy system subject matter experts, and software and hardware
administrators are often placed into specialist teams rather than as full-time members of crossfunctional teams. Of course, there are exceptions, and we do want to stress again that most
knowledge workers should be working within cross-functional teams if organizational agility is
truly an objective.
139
Once the target options have been mocked up using a Value Network or some other convention, it
can then be articulated using a couple of bullet points within the target options section of the canvas.
Shown below are the target options for our MVC example, continued from the previous section.
140
Its important to keep the target options component of the canvas short and concise. People wanting
more detail can refer to the more complete picture that has been defined.
Actions
A change initiative requires specific action necessary to achieve the target options.
141
The action section of the canvas should describe the set of activities required for change participants
to achieve the target options and receive benefits outlined within the canvas.
There are a variety of actions that can be used to help change participants achieve the target options.
Often, change agents will act as a full-time or part-time coach helping change participants apply
new methods, tools, and habits into the real working environment. While team coaching requires
a lot of effort on behalf of the change agent, this tactic is often the most effective way to execute
lasting change.
Team coaching is often supplemented by one-on-one mentoring. Managers and executives often
require significant 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 participants.
142
One of the best ways to get change participants to learn new methods and tools is to help them
co-facilitate learning events and workshops along with the change agents. Co-facilitation can help
turn change participants into change champions, and even change agents.
As changes scale out across the organization, setting up a specific curriculum for habits, methods and
techniques relating to agile delivery is an effective option. This type of activity is not recommended
when starting an agile transformation. It is discouraging to create a curriculum, then learn that it
does not suit the context of your environment, and finally have to rewrite the curriculum.
This is a tactic that is best implemented later in the change program. You want to build a curriculum
after spending sufficient effort validating different aspects of your change. Once a good and stable
curriculum is developed, it will allow you to extend the reach of your change program, allowing it
to scale out and reach a far wider audience.
Classroom training is a good starter tactic to help get a larger number of change participants 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. A much more hands-on approach is required if there is a desire to truly change the
way work is being completed.
143
Sometimes some organizations are in such a dysfunctional state that deep structural and process
changes are required to improve the way the organization wants to deliver. This tends to be a tactic
that many traditional change agents attempt to implement first. In my opinion, deep structural and
process change should be reserved for later, after the organization has achieved some success using
agile methods and techniques. Organizational changes are hard to undo, and so should be tested on
a limited scale rather than rolling them out big bang.
144
Success Criteria
Success criteria allows you to evaluate whether your change is proceeding according to your initial
assumptions.
Success criteria provides 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 participants
continually reorient themselves toward the direction of a successful change.
Keeping things simple, success criteria could be filled out by simply mentioning one or two metrics
that you want to track through the duration of the change engagement.
For example, one success criteria entry could be the number of people that are capable of practicing
user story analysis without coaching assistance. We could also add a second success criteria entry
to continually check the the number of defects that have been generated as a result of improperly
captured user stories.
If we remember our previous discussion around Improvement Experiments, every improvement activity is described with a supporting hypothesis. A good hypothesis for an Improvement Experiment
would refer to one of the metrics described in the success criteria section of the canvas. For instance,
145
taking the above example where we defined a success criteria as employees getting better at story
analysis, a good Improvement Experiment hypothesis could be all team business analysts will be
able to independently run story analysis sessions after four co-facilitated workshops.
More ambitious change agents may want to capture what are known as lifecycle metrics. Lifecycle
metrics track a segment of change participants along a predefined change path. Using this approach,
a change lifecycle is defined for a specific MVC, the lifecycle is decomposed into different stages,
and a prediction is made to try to anticipate how many change participants can achieve each stage
in the lifecycle.
Borrowing from the lean startup world, many startups use a form of lifecycle metrics known as
pirate metrics. Made popular by David McClure, pirate metrics involves tracking the lifecycle of
a potential customer from initial awareness, to first real contact, to when the customer actually
purchases something, to how the customer actually is retained, and finally when the customer refers
another customer.
Continuing with our shameless riffing of the lean startup method, we have come up with a similar
lifecycle that describes how change participants pass through a lifecycle for a particular change
initiative.
Using this model, change participants first become informed of a particular MVC. 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.
146
We create lifecycle metrics by defining success criteria that determine the exact action or activity
required for each stage in the lifecycle. We then make an assumption around how many change
participants we think will make it to each stage in the lifecycle as a condition of the MVC being
successful.
If we imagine that we have a change agent who is working with a department of software developers
to adopt techniques found within the code craftsmanship 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, or after each Improvement Experiment
is adopted.
The lifecycle allows change agents to evaluate how successful our change initiative is from the
perspective of our change participants.
147
1. Change participants show interest by accepting and attending a number of initial agile
modeling workshops.
2. Change participants 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 participants are showing true performance changes when they are able to
independently run workshops without any change agents involved, and also when lead time
in defect rates improve as a result of the new way of working.
4. A stretch goal for this change is that change participants boast to the other employees within
the organization how great this new technique is, and that this posting results in other
employees requesting to adopt the new techniques.
Once this lifecycle has been defined, we can put in an assumption around how many change
participants we hope will reach each stage. As we implement specific Improvement items, we can
continue to revisit these metrics to see if we are progressing according to our initial assumptions.
148
Commitments
Use the commitment portion of the canvas to track what is required from all involved to make a
MVC successful.
Change participants and change agents are required to meet the commitments specified within the
canvas in order to realize the benefits that will be achieved from the target options.
Interestingly, the commitment section of the canvas is often the most important one to change
participants. One of the most focal points of resistance to any agile or lean change initiative is that
149
change participants 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 participants
can actually make, and then tweaking the rest of the canvas to take into account the available
capacity.
Commitments can come in the form 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
participants 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 using the new methods.
150
At a minimum, it is critical to capture an estimate of how much time is required for each change
participant of a particular MVC. Change participants are more willing to give some 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 a particular
change will affect peoples schedules. The calendar type view can be used to show when all meetings,
workshops, and other sessions are taking place, how long they will be, and who is required to attend.
While this might seem like overkill, we have found that this type of illustration helps reduce churn
when negotiating a change model with change participants. Take care to note what existing meetings
and sessions that change participants are already attending, and try to piggyback on some of those,
reorienting and repurposing them to accommodate a more agile perspective.
Continuing our previous example, weve illustrated our initial assessment around the time commitment required to help this team gain proficiency in agile modeling and requirements.
151
Benefits
A successfully implemented Minimum Viable Change will result in benefits received by change
participants.
Use the benefits section of the canvas to articulate what benefits change participants will receive as
a result of committing to the actions required to make the team successful.
152
Customer Perception
One type of benefit that could be listed on the change canvas includes improved customer perception.
Listing this benefit takes some courage on behalf of change participants. They are signing up to
explicitly improve the way their customers feel about the way they work. We think this is an
ideal outcome for changes that involve adopting a new working culture. It makes a bold statement
that no success is meaningful unless the customer acknowledges that they have experienced an
improvement.
Borrowing another page from the lean startup method, a metric known as net promoter score could
be used to track both current and expected customer perception.
Improved Capability
Benefits can also be described in terms of improved capability of the change participants. While this
can be expressed in numbers, this is really a qualitative benefit. One way to accomplish this is to
simply express the number of change participants who we want to achieve a level of capability in a
certain skill.
153
Capability could be expressed in terms of a graduated ladder, or if desired, a 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.
Delivery Performance
Team performance is also something we have commonly used on our canvases. Change participants
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 sprint commitments.
Change participants using more lean inspired methods such as Kanban can try to quantify
performance improvements in terms of throughput and lead time, leveraging cumulative flow and
statistical process control charts. Kanban also supports other metrics such as how often a team is
able to meet its service delivery performance promise.
Trying to articulate the exact impact on performance that a change will have can be a subjective
art at best. We have seen teams using Kanban report drastically different throughput performance
improvement, with outcomes ranging from 30% to a whopping 200%!
154
Our team has also seen teams improve their performance up to six times over the lifecycle of a
project, largely 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 its been measured. This is especially true for teams that are
moving from a waterfall approach to a more agile one for the first time. Teams that measure their
performance often start trying to shrink their user stories to a smaller size in an attempt to increase
business agility. This alone has a dramatic impact on how performance is measured.
What this means is that any prediction of performance improvement resulting from a change
will most likely be a guess, especially when you are beginning a change initiative. As the change
progresses, and team performance begins to stabilize, quantifiable performance improvement starts
to become easier, although it never becomes anything close to an exact science.
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, lead time, or throughput/velocity is achievable
for most change participants that we have encountered, and is also large enough of a number to
generate interest in the change itself.
155
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 indirectly impacted.
Poor communication is often cited as one of the biggest reasons why change initiatives fail.
A good way to start is by understanding how you want communication to flow to your immediate
change participants, as well as other affected sponsors and stakeholders. Simply tracing how the
information is passed using a simple notation is typically sufficient.
156
Different communication channels can be bidirectional, meaning that feedback and response is
expected from the receiver of communication.
Some channels will be unidirectional, meaning that the communication will be broadcast out to a
larger audience.
When describing the communication approach within a canvas, we can often use a cadence
model. Using this approach, we can express the time interval that describes how often specific
communications will be sent out during the lifetime of the change initiative.
157
Intranet/web communications that are sent to both the change participants as well as the rest
of the organization. Another alternative is an internal blog and/or wiki, which makes this a
bidirectional channel.
information radiators, such as posters, dashboards, and other highly informative, physical
artifacts that are placed in such a way as to attract maximum attention from both change
participants as well as other members within the organization.
158
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 cant count the number of times
that somebody has walked by a Kanban style visualization system and was suitably impressed
enough to want to become a change participant for the next change within the organization.
Techniques to Consider
Keep the following techniques in mind when using the Change Canvas to help execute an agile or
lean change plan.
159
160
161
162
163
164
The application maintenance team is infamous for its reputation for poor collaboration both within
the team and with its business customers. There is also a perception across the organization that the
delivery is really slow, and leadtimes are incredibly long. Even when things are delivered, customers
165
continue to complain about quality, and the defect rates of this group are amongst the highest within
the organization. Charlie marks these challenges within the Urgency section of the canvas.
Charlie knows that both Business Analysts and developers are assigned to the application maintenance team, so quickly notes them in the Change Participant section.
Charlie feels that a lack of team culture and bad practices are a major source of problems for the
application maintenance group. Charlie feels that restructuring the group according to an agile
model, one that is co-located, and comprised of full-time dedicated members, will help to kickstart
a more collaborative culture. Charlie also feels that the team will improve their capability to deliver
through the adoption of agile style story analysis techniques, along with agile planning methods
such as physical card walls. Charlie places these three concepts into the Target Options section of
the Change Canvas. He likewise writes down a vision of an agile team in the Vision section.
Charlie quickly jots down his initial thoughts around Actions and Commitments, some upfront
training, along with some occasional coaching, and various meetings. The one big commitment
Charlie has placed is the need for a dedicated Product Owner, something that does not exist in this
organization.
Charlie Then Validates His Thinking so Far
Charlie places two Improvement Experiments onto the Improvement Kanban system next to the
Change Canvas for his MVC. He is hoping to be able to validate that his Urgency and Change
Participant sections are correct through a single workshop. Hes also hoping to find somebody within
either the application maintenance team or the business customer group who would be willing
to play the Product Owner role. He doesnt want to spend more than one week searching for a
candidate. He prepares some workshop material, schedules his workshop, and is ready to run the
workshop to go over the Canvas.
Charlie moves his Improvement Experiments through the Prepare column, and then into the
introduce column. In parallel he also prepares a job description for the Product Owner, and starts
scheduling meetings to see if he can find anybody interested in taking on this role. He likewise
moves this ticket through Prepare and then Introduce.
Unfortunately, both of these Improvement Experiments turn out to have assumptions that are
incorrect.
166
When speaking with the application maintenance team, he gets very little agreement that delivery
times are actually slow. He can also only get partial agreement from some team members around
the issues of poor quality and lack of collaboration. Workshop attendees also point out that he has
not included everyone who is involved in the application maintenance effort.
Since Charlie has gotten both the Urgency and Change Participant sections wrong, the rest of the
Change Canvas is basically invalidated. Charlie needs to basically go back to the drawing board.
167
168
He is able to get good agreement on specific challenges relating to each step within the process. The
value stream map shows a number of these problems, ranging from:
A nonexistent prioritization mechanism where diverse stakeholders (known as Line of
Business Representatives) basically shout over each other to get resources, causing conflict
in demand, and a lot of stop/start work.
A perception of ivory tower analysis causing the Business Analysts to be bypassed by Business
LOB Reps.
Developers are really system specialists, and work largely in silos, severely impacting quality
down the road.
A UAT function that was not capturing quality problems, resulting in production bugs being
unusually high.
169
The Business LOB Reps, who are tagged as having business subject matter expertise, have
little real knowledge of the inner workings of the solution. The real knowledge is possessed
by a diverse group of Operational Experts, the real users of the system. The Business LOB
Reps almost always delegate business-related questions to these Operational Experts.
Charlie is also able to get a good handle on which roles are impacted by these problems, taking time
to speak with members from each of these departments to get their input.
Charlie now has a better handle on the makeup of the application
maintenance group.
Charlie lists a core set of Change Participants which include Business Analysts, developers, and
the Operational Experts. He also adds the business representatives but puts them at the bottom of
the section to indicate that they are secondary change stakeholders and not core members.
Rather than listing all the problems from the value stream map on the Change Canvas, he
summarizes two major points in the Urgency section. First of all, the distributed nature of the team
and unclear expectations around responsibilities is contributing to an environment of poor visibility
and no understanding of who gets to make what decisions. Secondly, there is a growing demand of
production-related defects mainly because issues are not getting caught in UAT where they should
be caught in the first place.
Charlie updates the Action section to reflect the teams desire to have more support than he initially
estimated. He also updates the Commitment section to reflect the need for one day of coaching for
the duration of this change.
170
With the Canvas updated, Charlie moved the we Improvement Experiment into the Learn column,
marking it as a success.
171
Charlie suggests a more pragmatic set of changes this time around. Charlie presents the idea
of preserving the majority of the teams existing processes, but enhancing them with a better
prioritization mechanism. He also suggests putting the Operational Experts in charge of UAT. Charlie
would like to place both analysts and developers together into a cross-functional work cell to perform
the analysis function. Charlie still feels strongly that the application maintenance group would
benefit from more full-time team members working in a dedicated cross-functional nature, so he
leaves that in the Target Options.
Charlie then suggests putting Kanban on top of this process in order to empower the team to improve
their agility over time.
172
173
174
Working with his Change Participants, Charlie updates the Action section of the Canvas to include
Kanban setup and coaching. He also tries to secure commitment for the application maintenance
team to take two days of Kanban training, and have all participants show up to all Kanban-related
sessions and meetings. Finally, he decides to update his own Commitment to two days a week as
this group is larger than he had originally anticipated.
Charlie is hoping that all the listed Change Participants will Benefit from gaining deep Kanban
expertise. Hes also hoping that the team will be able to meet the continually growing demand,
which would require a 100% improvement in throughput. While Change Participants are not entirely
convinced that this is possible, they agree to defer to his enthusiasm. Defects also need to go down
by an order of magnitude, given their huge rate, Charlie has put down a 200% reduction required.
Again the team is not convinced but are willing to go with it for now.
Charlie also uses the planning session as an opportunity to discuss different Success Criteria. Given
the teams relative inexperience with lean and agile methods, this is mostly an exercise in education
and socialization. Charlies Change Participant group consists of 53 members. In order for him to
consider the change successful, Charlie feels that a majority of these employees should be able
to exhibit basic Kanban skills such as pulling work without being asked to, as well as follow other
Kanban-related work policies. He feels that a smaller but sizable portion should be able to create and
implement new work policies. In terms of performance, throughput and quality need to eventually
improve to the number listed in the Benefits section. Charlies gut tells him that this will take at
least ten months for these numbers to take effect.
175
176
Charlie and holds a series of workshops with the selected change champions to carefully go through
each section of the Change Canvas sharing supporting information when necessary, ensuring
complete understanding, and gaining agreement that these change champions will be co-owners
of the change.
177
178
Charlie Starts the Adoption Process, but Again Faces Passive Resistance
As Charlie works with the application maintenance team, a common pattern begins to emerge.
While there was reasonable participation in setting up the Kanban system, and there is always some
participation in the various Kanban-related meetings, a majority of change stakeholders either do
not show up or are very disengaged from the process. No one is actively resisting Charlies work, but
neither are they showing very much initiative to do things on their own. Many change participants
are complaining that they have other activities to do, and that this change is taking too much of
their time.
179
Charlie decides to reflect this information on his canvas. Hes clearly not progressing towards
his Success Criteria as fast as he would like, so he marks it yellow. Only a minority of change
stakeholders consistently show up or engage in standups and other kanban-related meetings. An
even smaller minority shows interest in actually modifying work policies or partaking in workshops
necessary to set up and refine the Kanban system. He marks the Success Criteria as yellow, i.e.
partially correct as he is making some progress.
Charlie tries to work with managers to restructure all capability into a single dedicated team with
employees who can provide full-time commitment, but is met with forceful resistance. It seems
that there is too much point knowledge spread out across too many people, people that have other
responsibilities, so he marks this part of the Target Options as red.
Charlie still believes that there needs to be some concept of a fully focused, dedicated team, but
that some restructuring is required to get this concept to work. He indicates this by marking the
application maintenance team concept within the Change Participant section as yellow. Currently,
not all change participants are fully participating, nor are they learning all the skills promised. He
also marks the appropriate Commitment and Wins Benefits section as being only partially correct
as well.
180
181
The solution team will be made up of dedicated, full-time individuals. The remaining Operational
Experts and Developers are placed in a pool, to be dynamically assembled into feature teams on an
as-needed basis. Charlie needs to work with the appropriate managers (Development Managers and
Business LOB Reps) to make sure that enough capacity is set aside and some service-level agreements
are put in place to ensure that these feature teams can be assembled fast enough to meet the needs
of the solution team.
As a part of designing the value network, Charlie and members of the solution team update the
Change Canvas to reflect the latest thinking. They start with the Target Options, adding the concept
of a dedicated team supported by a feature team.
He then updates the Change Participant section of his canvas to show two different classes of
Change Participants, a dedicated solution team, and a just-in-time feature team.
Likewise, the Success Criteria are now much less ambitious, and the dedicated team is the only
group that needs to have deep skills in Kanban. The larger group needs to only be aware of workrelated policies in order to follow them. The Commitment and Benefits section are likewise updated
to reflect this new focus on the dedicated solution team.
Charlie then puts in a new Action to help the team design this new type of Kanban system and
coach the solution team in operating it.
182
The Team Is Now Collaborating Better, Charlie Turns to Other Elements of the
Change Model That Have Not yet Been Tested
With these new adjustments in place, adoption is going much smoother. Charlie places two new
Improvement Experiments into the backlog, one based on fixing the dysfunctional intake and
prioritization mechanism, and another experiment dedicated to helping the team adopt some of
the metric oriented, root cause analysis capability that comes with the Kanban method.
183
The reality is that each Business LOB Rep has performance bonuses tied to getting their own work
completed by the end of the fiscal year. Interestingly, a very clear mandate from top executives have
made it clear that these LOB representatives need to work with each other to make sure that the
highest priority gets done. These two conflicting messages have contributed to a highly politicized
climate, where backdoor dealing is the rule of the day.
Charlie adds this problem to the Urgency section.
Time to Reintroduce the Product Owner Role
Because of the divisive and fractured nature of the LOB group, Charlie suggests to one of the
executive stakeholders that they look again at the Product Owner role, but this time he suggests that
184
the person fulfilling this role be played by two senior executives, and that the selected individuals
possess the skills and personality to have some tough conversations with various business clients
around business priority, and what can and what cannot be done this year. Charlie is surprised by
how quickly he gets agreement. It turns out that this concept was already being circulated within
the executive group as a potential solution.
Charlie updates the Target Options, to include the concept of a Product Owner. He likewise reflects
the concept of a Product Owner in the Action section. Charlie has upped his Commitment now to
three days a week, as he will be spending a good deal of time coaching the two executives on how
to be Product Owners on an agile team.
You may remember that the concept of a Product Owner was part of the original version of this
Change Canvas. The idea was scrapped when the idea of an agile iterative team model went out the
window and we brought in Kanban instead. This is a completely normal part of the change process.
Elements of a change model will be removed and then added back in based on new learnings. What
Charlie has learned is that he needs to remain flexible and take concepts from different methods and
from different areas of expertise to come up with a solution that truly fits the needs of his change
participants.
Charlie runs a new Improvement Experiment for about a month, dedicated to taking two existing
senior Business LOB Reps, and coaching them to become Product Owners for the entire solution.
They take to the new role extremely well, and all early indications show that they are doing a
fantastic job.
One of the Product Owners takes ownership of looking at performance metrics such as throughput
and lead time, and running periodic root cause analysis sessions to understand if performance
is improving enough to keep up with the growing demand necessary to improving customer
185
satisfaction.
The change participants are now showing the ability to successfully adopt new methods, as well as
gather performance oriented metrics for the purpose of quantifiable improvement. Charlie is now
ready to move the Minimum Viable Change into the final, Verify Performance state of the Validated
Change Lifecycle.
186
187
188
There Are Still A Lot Of Production Level Defects, but Code Quality Is High
Charlie and the Product Owner think its a good idea to take a closer look at the source of all of the
failure intake coming into the system. Despite the team having adopted a better UAT, production
level tickets continue to be a major source of demand for the team, consuming a lot of their effort.
Having spent a good deal of time with this team, Charlie knows that their quality is actually quite
good, and no longer believes that this is the source of production problems. Charlie and the Product
Owner agree to mark this item within the Urgency section as yellow, meaning that more research
is required.
189
190
and restructure them into one or more common user stories that can then be estimated, delivered,
and validated.
Charlie is now able to modify the Benefit section of the Change Canvas, suggesting a much more
modest improvement in throughput and defect reduction. Throughput and defect reduction is now
no longer the primary concern. Correctly implementing a forgotten set of requirements is now
much more important. With this in mind, Charlie adds a new Benefit; to reduce the gap between
requirements that are in the backlog and what has been implemented in the system. He wants to
reduce this gap to one-third of its existing size within three months.
Success criteria is likewise changed, and throughput metrics are now much more modest. More
critically, a new success criteria has been added that will measure the teams ability to analyze
requirements, deliver working code, and have features validated by the business at sufficient speed
to reduce the backlog. Initial suggestions are that if the team is able to process six story themes
per month, then they will be at the right velocity.
Charlie also updates the Commitments section to reflect both training as well as continued effort to
perform story analysis. Story analysis will become a major responsibility for the solution analysts,
and a part-time commitment for the Product Owner. Coaching has now grown to a full-time
responsibility for Charlie. Hes now helping on a number of different fronts, but so far is getting
good return on the time he is spending with this team.
Charlie updates the Action section to reflect the new coaching that he will perform related to story
mapping and estimating.
Charlie and the team agree that the Vision section should now be updated to reflect the teams
commitment to evolve both the process and application to meet the needs of the business, both in
terms of growing demand as well as correct functionality.
191
Once the canvas has been updated, Charlie introduces a new Improvement Experiment to validate
these changes. He is careful to associate the hypothesis within this Improvement Experiment to the
quantifiable metrics listed in his success criteria.
192
194
change.
When starting to adopt agile or lean in your organization, it makes the most sense to focus change on
enabling Quick Wins. Rather than trying to validate whether you have the exact right set of target
options for your exact context, focus on helping a small portion of the organization adopt a set of
lightweight agile methods like Kanban or Scrum. This will identify major obstacles to change. Some
examples of these obstacles include an uninvolved executive, inattentive business owners, overly
specialized organizational structure, or extremely poor morale. With quick wins, you are trying to
determine if the organization is ready to adopt any amount of agile. And if not, what are the major
obstacles, and countermeasures that can be put in place?
Once learning increases through a successive of quick wins, you can start experimenting with
introducing a more fulsome representation of your candidate target state. Introducing a Kernel Pilot
involves introducing the set of organizational target state options representing the vision for the
overall enterprise. This can include a number of agile methods, changes to organizational structure,
and modifications to roles and responsibilities. While this change is bigger than the Quick Win, the
focus here is still on learning. Focus has now changed from learning about resistance to learning
195
196
The Quick Win is typically targeted at a small number of eager adopters, an example being a
medium-size team of approximately six-fifteen FTEs. Typically, no more than one-two managers
or executives would be direct stakeholders of the change. Select change participants that are capable
of acting as a true guiding team, and champions for the larger change initiative.
The Quick Win is targeted at solving a few immediate and tactical problems. We are not looking at
a strategic or long-term return. We want to show results after a month or two.
The Quick Win is meant to be small in scope, adopting a single agile method, or a couple of closely
related practices. Examples here include helping teams get started with Kanban or Scrum, or perhaps
Agile Modeling.
Commitment often comes in the form of some part-time coaching following a couple of days of
upfront training. The most important commitment comes in the form of time provided by change
participants to learn new working habits. Ideal duration is no more than six to nine week for a
change modeled after the Quick Win pattern.
Benefits of this kind of change include change participants 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 capability, and measured in terms
of improved velocity, lead time, or quality.
The ideal communication approach for a Quick Win is in person and face-to-face as we want to
support quick feedback. During the early stages of a change program, it is much more likely that
we will need to make one or more dramatic changes in direction. Enabling fast feedback is thus
critical at the beginning of a change program, and is made more challenging when engaging with
distributed teams.
197
Again, Minimum Viable Changes based on the Quick Win pattern are often introduced at the
beginning of an agile transformation. We want to tackle resistance to the overall change program
through delivery of early value.
The Quick Win is a good way to validate an isolated component of a larger 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
commitment to benefit ratio 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.
Kernel Pilot
After a number of Quick Wins have been implemented within an organization, there can be enough
momentum to execute a more ambitious change, one that more broadly reflects the organizations
suggested true north. Previously implemented Quick Wins should have provided some validation
on different aspects of the potential target options, change actions, and required effort, reducing the
risk of attempting something a little larger.
198
A Minimum Viable Change using the Kernel Pilot pattern is often targeted at an entire value stream,
from intake to support, and all the steps in between. Often this can be represented as one line of
business within 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 Kernel Pilot should address a significant portion of the problems that are also drivers for the
overall agile transformation. We want to evaluate the validity of the agile transformation, but on a
smaller scale.
Likewise, the target options 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, a
discrete segment of change participants (i.e. a team or set of teams) will now 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 outside expertise within delivery teams is
often required to successfully help change participants shift to suggested target options. As the choice
of methods and techniques become stable, some effort can go into developing and socializing a
lightweight 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 three to six months to execute, and
may require one or even two 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
199
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 options have been
adopted in an integrated way, there will still be significant learning. Expect to adjust on all elements
of the change. A change pivot may even be required, depending on what is learned.
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 on behalf of both change
agents and change participants. Dont panic if a lot of high touch activities are still required to make
progress at this point in the change. Optimization of learning effort across the organization can take
place later. Remember that the purpose of a change using this pattern is to try to get a first foothold
on the future target options of the organization.
Below is an example taken from our real world experience, where we helped 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 options of the majority of the organization. Implementing this
change on a smaller group allowed us to refine the stack as well as evaluate assumptions behind the
change program.
200
Kernel Adoption
As one or more Kernel Pilots are 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 aspects of the change solution, and switches focus
to trying to optimize the rate of adoption. As a transformation progresses, we want to modify the
kind of change support provided by change agents, graduating from high touch/high support tactics
to ones that can scale out. Examples include self-study, peer-to-peer mentoring, and improvements
driven solely by change participants.
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. The idea is to help knowledge spread the
learning scale to a larger audience. Change agents spend more time training other members of the
organization to be true change champions, agile knowledge experts, and owners of methods and
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 options for an agile transformation is never done, so some aspects of the change solution
will continue to require validation and may require a change in direction.
201
Self-Starter
A Minimum Viable Change modeled on the Self-Starter pattern attempts to provide an opportunity
for change participants to guide their own adoption. Various improvement methods such as training
material, peer working sessions, scheduled times for change participants 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 participants. Sometimes, curriculum
and pull-based tutoring needs to be complemented with organizational incentives to adopt. These
incentives 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 to change participants
may also be required as the Self-Starter kicks off.
Its often recommended to support this effort with at least some kind of part-time tutoring. This
tutoring can be scheduled or serviced 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
202
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 a larger agile transformation. The overall approach and applicability of specific
methods should have largely been evaluated thanks to one or more previous MVCs.
Self-Starters are good at evaluating whether employees within the organization can improve without
dedicated change agent support, and pull help when and if required. Change agents should also
be looking for ways to optimize the benefits gained compared to the effort required on the part of
change agents.
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 provided 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 employees
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 three hour drop-in
where anyone interested could receive coaching and assistance and have their questions answered
relating to any of these techniques.
203
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 participants, 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.
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. These issues are having a visible impact
on business outcomes.
The target options 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 specialist/generalist hybrid, fostering both collaboration and cross functional
204
tasks sharing necessary to meeting demand variation and complexity. Action can also include
rethinking how careers within the role can progress based on expertise.
A clear and graduated 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.
Effort is focused on building a number of capability gurus. These capability gurus act as knowledge
leaders and method owners of the new capability. A combination of hiring externals, and mentoring
existing employees is used to help build this team of capability gurus. These capability gurus act as
senior keepers of the flame, and are responsible for ensuring a continued commitment to excellence,
and pursuing the kind of 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. Gurus 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. Training capability also needs to be developed. 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 many months to execute. Several full-time, and senior change agents are
often required to support a change following the Capability Modernization pattern. 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 peoples 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. These kinds of changes are smaller, require less investment, and
are better at providing feedback on what works and what doesnt. Before starting a Capability
Modernization style change you will want to have already validated most of the assumptions behind
your transformation. Key learnings from this style of 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 deployment.
205
208
Change agents can validate a Minimum Viable Change by moving it through the Validated Change
Lifecycle.
As a change program scales out, multiple change agents may work on multiple Minimum Viable
Changes in parallel, effecting numerous changes on an organization.
209
Different change agents will come up with different solutions to the unique problems of the
change participants they are working with. This can be considered a good thing. Different change
participants segments will 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 doesnt make sense or work very well for the enterprise as a whole.
210
Different lean and agile methods place emphasis on different things, and even may contradict each
other in the advice they give. Without care change, participants and other change stakeholders can
become confused.
Change agents working within the context of an organizational transformation, one where a larger
number of Minimum Viable Changes are being introduced to the organization, should spend some
time on planning and modeling what that transformation could look like from the perspective of
the entire organization.
Just like a Minimum Viable Change, elements that make up the model of a transformation level
change can be thought of as a set of assumptions that can be validated through experimentation.
An organizational transformation model can be used to ground and otherwise constrain the various
Minimum Viable Changes that pass through the organization. When a change agent begins work
on a new Minimum Viable Change, the first point of reference is the organizational transformation
model. Does the Minimum Viable Change fit within the overall objectives of the organizational
transformation? Does the Minimum Viable Change validate key assumptions in the transformation
model?
211
212
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 participants within an organization.
A Transformation Canvas is used to model the concerns of either the entire organization or a very
large subset of an organization undergoing a transformation.
A Transformation Canvas can be used on its own, without other components of the Lean Change
method. In this scenario, you are using the Transformation Canvas to get consensus on the overall
transformation model, and then using some other change management approach to affect the actual
change.
A Transformation Canvas can also be validated through the implementation of one or more
Minimum Viable Changes.
When using the Transformation Canvas this way, youre asking change agents to take part in a
three 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, which are placed in the
backlog of each Minimum Viable Change.
Using this approach feedback trickles from the lowest to the highest level. Learning from Improvements Experiments impact the validity of elements on the MVC Change Canvas, and updates the
various MVC level changes will impact the validity of elements on the Transformation Canvas.
Likewise, feedback trickles from the highest level to the lowest, changes to the Transformation
Canvas may impact other Minimum Viable Changes being planned or that are in progress. This
may in turn impact specific Improvements Experiments.
213
Shown below is an example of the Transformation Canvas. Its very similar to a regular Change
Canvas only larger, and content is also geared towards discussing an entire transformation.
214
215
The risk that the transformation will result in changes that are incorrect, and wrong for the
organization.
The risk that the transformation will be unsustainable, and that the organization reverts back to
previous ways of working.
216
We have suggested one particular order change agents could traverse the Transformation Canvas.
Of course the exact order of traversing a canvas will depend on the actual transformation, risks, and
their severity will vary from transformation of transformation.
217
Resistance to Change
1) Identify which change participant segment will be the least adversely impacted by one of the
changes suggested within the transformation canvas.
218
2) Search for a set of change champions that want to become a guiding team for your change.
4) Communicate both benefits and learnings, both to your Change Participants and to the rest of
the organization.
219
Correctness of Change
1) Connect change participants with one or more urgencies, and work with them to establish a
shared understanding of why the organization needs to change.
220
2) Extract elements from your target options into the smallest possible change that will result in
demonstrable benefits to your change participant.
221
Sustainability of Change
1) Verify that change participants have the time, effort, and funding required to enable the change.
2) Validate you have the correct benefits by testing what your change participants say.
222
3) Then validate benefits by testing how your Change Participants modify methods, habits, and
behavior
223
1.1) Identify which change participant segment will be the least adversely impacted by one of the
changes suggested within the transformation canvas.
1.2) Connect change participants with one or more urgencies, and work with them to establish a
shared understanding of why the organization needs to change.
224
1.3) Verify that change participants have the time, effort, and funding required to enable the change.
2.1) Search for a set of change champions that want to become a guiding team for your change.
2.2) Extract elements from your target options into the smallest possible change that will result in
demonstrable benefits to your change participant.
2.3) Validate you have the correct benefits by testing what your change participant say.
225
3.1) Implement your change, working in collaboration with your guiding team.
3.3) Then validate benefits by testing how you change participants modify methods, habits, and
behavior.
4.1) Communicate both benefits and learnings, both to your change participants and to the rest of
the organization.
226
4.2) Verify that your transformation is sustainable by validating achievement of success criteria
necessary to making sure change sticks.
This canvas risk traversal map serves as a thinking tool to help change agents identify and validate
any assumptions within the transformation that could pose a risk to successful change.
This approach could be used in conjunction with Minimum Viable Changes, or some other change
management methodology. In keeping with the philosophy that individual Lean Change components
can be used on their own, we want to provide a method of traversing the Transformation Canvas
without having to rely on other tools within the Lean Change method.
227
228
Lets look at a number of risks that we could use to prioritize our Minimum Viable Changes. If we
imagine a backlog of MVCs color-coded by risk type, we can annotate the appropriate section of the
Transformation Canvas that would represent that risk. We will then prioritize the backlog based on
the severity of the risks within this section.
Resistance to Change
At the beginning of a transformation, resistance to change can be often best dealt with by prioritizing
the MVC that targets the group of change participants on your Transformation Canvas who are most
able to identify with current pain points.
229
Ease of collaboration is probably one of your next most important factors to consider when it comes
to prioritizing your Minimum Viable Changes.
When starting a transformation, change efforts are better focused in such a way that they allow
change participants and change agents to collaborate with each other and any stakeholders in a
highly interpersonal way. When possible, try to choose an MVC that allows your change participants
to work in high touch sessions, preferably face-to-face, and prioritize this type of MVC over ones
that require distributed and/or dispersed teams.
230
Sustainability of Change
A big risk to the sustainability of any agile/lean change effort is leadership and executive commitment. Real and deep support is required to make sure that change sticks within the organization.
Minimum Viable Changes that have more obvious leadership support are better to tackle earlier
within a transformation verses one that has less.
231
Impact of Change
Impact also needs to be considered when prioritizing MVCs. When evaluating the various participant
segments on your transformation canvas, prioritize MVCs that interact with participants who you
believe will have the most impact on realizing the transformation vision, in relationship to the time
and effort required.
232
Correctness of Change
Finally, prioritize Minimum Viable Changes that are more likely to validate your overall target
options, versus other changes that may only validate a single theme or isolated method within your
target options.
Notice that we have selected this kind of MVC relatively later compared to the ones that mitigate
other types of risks. This is intentional, since particular element of the target options often end up
being incorrect not because they are wrong, but because they are not consumable, or dont provide
the right value relating to the efforts required to adopt. Our experience is that trying to get a complete
target options validated upfront is expensive, and would require a lot of rework.
233
It should be mentioned that the risks stated here, and the means of prioritizing different Minimum
Viable Changes based on these risks is another thinking tool. Its one that needs to be customized
according to the context of your transformation. This is not an exhaustive list of risks, nor is it
the only way to prioritize MVCs based on those risks. The point is to be able to look at your
Transformation Canvas, evaluate assumptions on the canvas from a risk perspective, and use that
risk perspective to prioritize your backlog of MVCs.
235
Change agents will meet to coordinate and learn from each others experiences in the field.
Improvement experiments will causes MVC Canvases to be updated, which may in turn cause the
Transformation Canvas to be likewise modified. This may require running Transformation Canvas
workshops. Changes to the Transformation Canvas will likewise trickle down to other MVCs and
related experiments.
Modifications will need to be validated and socialized with other change agents, stakeholders,
sponsors and the rest of the organization. Feedback will need to be incorporated to affected artifacts.
All feedback will require further communication.
236
237
Change Participant Update- Change agents spend dedicated time validating improvements for a
particular MVC with their change participants.
Change Agent Stand Up - Change agents coordinate with each other, preferably using an agile
standup style meeting
Stakeholder/sponsor update - Stakeholders and sponsors are provided updates based on the information gained through implementing the change
Change agent planning session - change agents perform deep analysis to understand if the change
is progressing on the right track.
In this example, our team elected to run a two-hour planning session with two distinct agenda items.
The first agenda item was to analyze any insight gained since the last planning session. Validating
improvement experiments, running change standups, and getting feedback from sponsors and
stakeholders, all contribute to generating insight. This insight would result in changes in direction,
and likewise modifying change tactics. Changes to various artifacts would be required, such as
modifications to the Transformation Canvas, MVC Canvases, and Improvement Experiments.
The second topic of the planning session was to coordinate changes to impacted Lean Change
artifacts. Changes could include:
Our team elected to hold the change planning session weekly, with the first part of the session
dedicated to generating and analyzing insight. The second part of the session would focus on
238
updating a particular type of Lean Change artifact, rotating the artifact of focus, on a weekly basis.
This meant that each type of artifact was investigated for a potential refresh once a month ( see the
cadence model below)
Transformation Cadence Model Suggested Timing
As stated previously, I recommend that each activity be conducted according to a set cadence. This
makes it easier to coordinate various activities, and helps the change agent team establish a steady
rhythm for the transformation.
Here is a cadence model that accompanies the above example. Again modify it to support your
particular context.
In a large transformation, you will most likely be employing a team of change agents.
239
240
A standup is a good way to keep change agents aware of each others activities and accomplishments.
This standup can take place in front of your Validated Change Kanban. This Kanban shows the state
of all Minimum Viable Changes across the Validated Change Lifecycle.
241
242
You may also elect to use an additional swim lane to track a consolidated view of all Improvement
Experiments that are in progress. You may remember that Improvement Experiments are also placed
close to appropriate Minimum Viable Change Canvas in an Improvement Experiment Kanban.
Placing active Improvement Experiments on the Validated Change Kanban makes it easier for change
agents to discuss them as a team, but requires some synchronization. You now have Improvement
Experiments being tracked in two separate places, the Improvement Experiment Kanban placed
near your Minimum Viable Change, as well as the Validated Change Lifecycle Kanban. Weigh the
need for communication between change agents with the overhead of having to keep Improvement
Experiments synchronized in more than one place.
243
Here is a photograph of how one group of change agents tracked active Improvement Experiments
on the Validated Changing Kanban, associating experiments with each MVC in play. Each Minimum
Viable Change is represented by a green ticket, with improvement experiments represented by
yellow tickets. The Improvement Experiment tickets were clumped close to the MVC tickets, creating
informal, horizontal swim lanes.
244
For our standups we had change agents rotate who ran the meeting, running it as a Kanban style
standup. Using this approach, the standup is a quick 10-15 minute meeting where each Minimum
Viable Change, and potentially each active Improvement Experiment, is quickly traversed and
discussed. In order to move standups along, an effort is made to focus on problems made obvious
by the Kanban system.
Problems typically take the form of:
- Blockers
245
- Bottlenecks
Once an issue is identified, the issue is assigned to one or more change agents, who usually discuss
a resolution after the standup is over. In this way, the standup can be conducted quickly.
246
When running larger transformations, it can often be necessary to have specific update sessions for
other stakeholders of the change such as line managers, executives, as well as key stakeholders from
partner departments within the organization such as marketing, or product development.
You also need to keep your primary sponsor up to date to enlist his or her help in making sure that
the transformation is progressing well. In our experience, a good primary sponsor is a director or
VP level executive who has director responsibility over a set of change participants. It is also a good
idea for the ultimate owner of the transformation to be a senior executive.
Where possible, try to streamline how many meetings you have and see if you can run a consolidated
stakeholder and sponsorship update, in that way all interested members can collaborate on the same
information. The politics and/or structure of many organizations make this difficult to do, and it may
be necessary to have a dedicated review session for the owner and primary sponsor, and a separate
one for other interested stakeholders. This will mean that synchronization of information across
meetings will be required, which can be a challenge.
247
One topic you want to continually revisit as part of these updates is the overall direction of the
transformation being executed, specifically whether minor changes or a major pivot is required to
keep the transformation successful.
The Transformation Canvas can be annotated with colored tags to indicate which portions of the
transformation contains correct, partially correct or completely incorrect assumptions. This can
serve as a very useful source of discussion during a stakeholder and/or sponsor review.
248
Another point of discussion during the interview sessions, is discussing any items that are acting
as blockers or impediments to the transformation. We want to do everything we can to encourage
sponsors and stakeholders to take ownership of removing these impediments.
The Validated Change Kanban is an excellent source of information to go over any blocking items
and other impediments facing the transformation. We have had good success running a standup
style conversation in front of the Kanban to help facilitate this kind of conversation. Weve also
used photos and/or soft copies of the Validated Change Kanban in certain situations.
249
250
I have found it necessary to commit dedicated time for change agents to get together to continually
revise the direction of an agile transformation. This involves planning, planning, and more planning.
New information is always being uncovered which can make old assumptions invalid.
251
These new learnings will encourage change agents to modify both Minimum Viable Change
Canvases as well as the Transformation Canvas, which in itself will result in new insight.
Leaving the Lean Change process aside for a moment, significant information and insight will also
be uncovered simply through the act of being on the ground and talking with change participants,
and other change stakeholders.
252
When we look at these and other sources of information in their entirety, it becomes clear that
confusion can ensue if we do not try to manage it.
253
Insight Analysis
One way to start off a change planning session is with an insight analysis workshop. Using this
approach, all new learnings are converted into specific insight items, and a deliberate process is
used to convert the insight into one or more actions.
The first part of insight analysis is insight collection. To facilitate this, the MVC Canvas as well as
the Transformation Canvas can be extended with an insight collection area. Change agents, change
participants and change stakeholders are encouraged to place insights into these areas as they occur.
Again, this insight could occur for a variety of different reasons.
254
An advantage of this approach is that insight can serve as another information radiator publicizing
the latest thinking about the transformation.
Once insight is collected, then insight analysis can occur. This is typically done by aggregating
separate insight tickets into related common themes. A key insight is created for each common
theme. Each key insight acts as a reason to kickstart one or more activities, including updating
the Transformation Canvas, updating one or more MVC Canvases, or reprioritizing the backlog of
MVCs.
255
256
As new learnings are generated, you will want to refine your backlog of Minimum Viable Changes.
You may want to prioritize the next set of changes you are going to introduce into the organization.
You may also want to add or remove MVCs from your backlog.
Following the insight and analysis process, insights are collected from various sources and grouped
into themes, which then generate Key Insights. One or more Key Insights can then be converted into
a Change Option.
257
This Change Option can be evaluated in terms of value and effort, and prioritized accordingly. The
Change Option is also evaluated in terms of how well it fits into the overall transformation model.
When there is capacity to start the next high-priority Change Option, it is then introduced as a
Minimum Viable Change into the Validated Change Lifecycle.
258
259
As an agile transformation progresses, new learnings will invalidate the content of one or more
Minimum Viable Changes. Change agents should work with change stakeholders to continually
evaluate, and if necessary modify their MVC canvases as appropriate, including modifying any
related Improvement Experiments.
260
One approach is to run monthly sessions with the change participants group. During this session,
the canvas can be annotated with colored tabs to denote whether a particular assumption is correct,
partially correct or completely incorrect.
261
The group can then collaborate together to work out what is exactly wrong with the current thinking,
and what needs to change.
262
Finally, the group can work to update the MVC Canvas to reflect the latest learnings. This may
include updating the backlog of Improvement Experiments.
263
It is very likely that this process will generate further insight, which may modify other aspects of
the transformation outside of the scope of this MVC. This insight can be collected for future insight
analysis sessions.
264
265
I have found it necessary to allocate dedicated time to keep the Transformation Canvas up-to-date.
Again, a monthly update seems to strike the right balance of overhead and communication.
As discussed previously, Minimum Viable Change Canvases will continually be refined as a result
of running through the Validated Change Lifecycle.
266
New insights generated from these changes will often require modification to the transformation
model. A dedicated workshop can be set up, following a similar process as the Minimum Viable
Change refresh workshop. In this instance we will be looking at the Transformation Canvas instead.
Sections of the canvas can be annotated for correctness, and then workshop members can brainstorm
on both root cause and potential modifications that can be made to the canvas.
267
While we would like our sponsors and stakeholders to be directly involved in this process from the
beginning, we have found that it is sometimes necessary to conduct an initial workshop with change
agents and change champions. A second workshop is then used to socialize changes with a wider
sponsor/stakeholder group, who then suggests further modifications.
268
These changes are then communicated out to the rest of the organization, where feedback can be
received and incorporated back into the Transformation Canvas.
An excellent way to facilitate this feedback is to place the Transformation Canvas in a highly visible
269
place. In this way, the Transformation Canvas serves as an information radiator, and provides an
area for all members of the organization to contribute insight and feedback.
270
The Lean Change method can result in a variety of metrics, dashboards and charts which reflect a
summary of how the transformation is progressing from a number of perspectives. We have found
it valuable to spend some time aggregating and analyzing this information to both communicate
progress as well as generate new insight.
271
As change agents can work with change participant groups to complete various Minimum Viable
Changes, data will be generated from both an adoption as well as performance perspective.
Adoption information can be summarized both within and across change participant segments
through the use of simple capability maps represented using spider charts.
Performance information can likewise be collected for particular change group or across multiple
change groups where it makes sense. Performance metrics used will depend on the particular mixture
of agile and lean methods selected.
Change agents work with change champions and other stakeholders to review this information,
generating insight where appropriate, and communicating this out to stakeholders and other
sponsors.
Where possible, we recommend placing this type of information into well trafficked, public areas
of the organization rather than bringing these charts and graphs to specific review sessions within
meetings.
272
Appendix
Traditional Approaches to Technology Delivery Is No
Longer Suited to Todays Market
Traditional IT Management Methods Borrow Much of Their
Thinking from the John Taylor School of Thought
In the 1930s, this philosophy was based on the premise that organizations would be much more
efficient if resources were organized by specialization. This would allow functional oriented
departments to focus on efficiency through highly standardized and repetitive activity.
Activities were planned and coordinated through the use of functional managers who ensured
that individual employees received adequate instruction and feedback on performance targets.
Managers got their orders from executives who were responsible for determining the objectives
of the organization.
In this approach, big ideas came from the executives and owners of the business, who determined
what the organization should be doing and how it should be doing it. Managers were responsible for
ensuring successful execution of plans. Individual tasks and activities were doled out to employees,
and all coordination between functional departments required intervention by the management
layer. The majority of employees were essentially cogs in a well-orchestrated machine; they did the
work and were not required to perform any meaningful thinking.
Appendix
274
Scaling out an organization simply required the addition of another functional layer. Organizations
could successfully increase in size by expanding out horizontally and vertically, creating a more
nested hierarchical structure.
Appendix
275
One reason this approach works well is that managers and leaders were able to optimize the
execution of highly specialized and repetitive tasks. This allowed workers to leverage economies
of scale, lowering total cost of ownership for both in-process and complete inventory of goods.
Success relied on maximizing efficiency and providing goods and services to customers at the lowest
possible cost.
This low cost was achieved through a command and control approach, meticulous planning and
Appendix
276
coordination, and the development of robust standards and procedures that carefully lay out the
most efficient way to complete a particular task.
Work was organized to leverage economies of scale; specialists were grouped together into functional
departments, highly repetitive activities could be completed in large batches, and passed from one
specialist group to the next. Customer demand was serviced in large quantities, again using a big
batch approach.
In a market where customer wealth was low, this approach effectively serviced customer demand.
Economies of scale were easy to leverage, as a small number of products could be introduced to
a large and undifferentiated customer market. Product lifecycles were also extremely long, taking
years or sometimes even decades before one product would be displaced by innovation.
Appendix
277
In this environment, organizations can be incredibly efficient, follow plans to perfection, and be
incredibly effective at coordinating thousands of specialists, but still fail as a business.
In todays challenging business environment, the biggest risk has shifted from building products
cheaply to building a product that nobody wants. To borrow a line term from the lean startup
community, the question becomes not can I build it, but should I build it?
Appendix
278
In situations where organizatmions are still providing more commoditized goods and services with
longer life cycles huge efficiency gains can be leveraged by taking advantage of the latest wave of
technology innovation.
In this environment speed of execution becomes more important than cost of execution, and
processes, organizational design, and management methods need to be designed to support speed.
The most fundamental change between traditional management methods and ones that leverage
lean and agile methods is the shift from plan driven processes to learning driven processes. In an
environment where customer demand as well as the tools used to service the customer demand are
constantly shifting, long-term plans, static processes, and economies of scale will work against you.
Appendix
279
Instead, organizations need to be designed to manage feedback, and be able to adapt to constant
change.
This feedback loop provided by frequent delivery enables the organization to continually learn based
on the success of the last delivery. This feedback allows organizations to delegate the majority of
decisions to the team level without fear of the organization slipping into dysfunctional behavior.
Teams are better able to learn, and better able to deal with complexity when they are made up of a
diverse set of individuals. Most lean and agile methods recommend that teams are cross functional
and contain the majority of skill sets that are required to consume customer demand and create a
finished product.
Appendix
280
This leads to another key principle in both the lean and agile world. In this model workers are
responsible for both doing the work and coming up with the good ideas around how to complete the
work. All team members are encouraged to be thoughtful about what they are doing, and challenge
why things are being done a certain way, or why they are even being done in the first place. In this
paradigm, workers are self-organizing, and the teams are largely self-managed.
Because feedback is critical to enabling this learning system, work is deliberately processed in small
batches. The whole notion of economies of scale is discarded in favor of working with the lowest
possible level of inventory. What this means is that workers are encouraged to work on only a one
or two business value tasks at a time, and work on those to completion rather than trying to stay
busy by working on many things in parallel.
Appendix
281
Frequent client delivery, cross-functional teams, empowered workers, and limited work in process
all contribute to a system of continual self-correction and learning. Knowledge workers not only just
get better insight into what customers want, but also learn how to optimize their internal methods,
tools and processes to improve their own internal efficiency, speed and quality.
Another key difference between a traditional organization and an agile oriented one is the way that
lean and agile teams look at quality, processes, and standards. Workers in this environment need to
be constantly learning, and adapting.
Poor quality interferes with this learning cycle. Both lean and agile methods recommend that quality
be built into the process, rather than inspected for after-the-fact. Whenever a problem in quality is
found, root cause analysis is conducted to get you to the source of the problem, not only to fix
it, but to make sure that it never happens again. Processes and standards are constantly changing
and evolving based on the insight gained through discovering quality problems, performing root
cause analysis on those problems, and implementing countermeasures to ensure that those quality
problems do not happen again.
Many agile and lean methods recommend the use of information radiators to share information
across the team, with management, and the customer. Information radiators often come in the form
of Kanban systems, agile card walls as well as simple low fidelity dashboards and charts.
Appendix
282
Organizations can scale by organizing teams into a value network. This value network typically
employs peer-to-peer communication enabled by specific key members belonging to more than one
team. The notion of teams actually being a set of overlapping concentric circles is a good metaphor.
For the most part, teams within a value network should be cross-functional, having workers who
possess diverse skill sets and perspectives.
Occasionally teams within a value network will be comprised of a single specialization, similar to the
model found in the more traditional management methods. The specialist approach may be chosen
when there is no stable demand for a specific skill set in any of the cross-functional teams. This
approach is also effective when communication requirements between specialists of the same skill
set tends to be higher than those across skill sets. Functions like enterprise architecture, security, and
infrastructure provisioning are frequently organized according to specialized teams.
The current body of agile and lean thinking has found expression in many forms, including a
variety of principles, methods, and specific practices. This thinking provides guidance, inspiration,
Appendix
283
and advice for those wishing to operate successfully in a complex market taking advantage of selforganization, feedback and learning, frequent customer delivery, and excellence.
Organizations using agile and lean methods are a lot more like a speed boat. The cost per passenger
seems to be a lot higher, but this is made up for in speed and maneuverability.
Appendix
284
Metaphors aside, the real point here is that an organization using traditional methods does not look
a lot like an organization using agile or lean methods. Just like a cruise liner and a speed boat may
both be boats, they really have very little in common when it comes to operation, objectives, and
capability. Agile and traditional organizations are really not the same thing. And the change required
to transition from one to the other is substantial.
The Big C-Change Traditionally used by Big-C Consulting firms Fundamentally Wrong for Agile Change
There is a huge industry focused on assisting organizations to make dramatic changes necessary to
helping them survive. Most major consultancies have an army of practitioners and partners who
have dedicated their careers to helping organizations rewrite the way they think and operate.
In the spirit of full disclosure, I have worked, and I continue to work in a Big C Consulting
environment. During my experiences, I have met more than a few very capable change consultants
who have a lot of good advice to offer potential agile change agents. Several of these change
consultants have provided me with valuable assistance in refining the Lean Change method.
That being said, its been my experience that these change consultants achieve success in spite of,
not because of, the methods and tools that they tend to use. While specific consulting methods
vary depending on the firm in question, our experience is that consulting change methods currently
follow a typical execution pattern.
Consultants work with organizational executives, managers, and occasionally key team members to
articulate a desired target organizational state based on a set of key business drivers.
Appendix
285
Consultants then work with the client to examine the current state of the organization, compare it
to the target, and come up with a set of gaps between the two.
A roadmap is then developed based on prioritizing business drivers to come up with an implementation plan around how the organization will effectively transform to the desired state. This roadmap
frequently comes in the form of a detailed plan that outlines key milestones, required activities, and
effort required by both employees and external consultants.
This approach comes with a number of risks, especially when trying to affect dramatic change in
an organization, such as transforming from traditional methods to one leveraging lean and agile
thinking.
This change management approach typically results in the implementation of big C change.
Dramatic changes are rolled out to the organization, sometimes on a department by department
basis, resulting in wholesale shifts in job titles, processes, and technology. When any change
is introduced into an organization, even a change that is good for that organization, a drop in
performance will result. New methods need to be learned, new responsibilities take time to master,
and new skills take time to acquire.
If the organization is able to successfully stick with the change, then performance will bottom out
at the new, deteriorated level of performance. Eventually the desired changes will have the effect of
improving performance, allowing the organization to reap the benefits of the target state.
Appendix
286
This however, is an almost naive prediction of how big change actually occurs. In reality, many big
changes stall well before organizational benefits achieve the promises of the target state.
Organizations naturally resist change, and professionals within an organization will resent any force
that asks them to change the way they are working. Fear is a major cause of change resistance; fear
of losing ones job, fear of no longer being relevant, as well as fear of being asked to work in a way
that one may not be used to.
Organizations are susceptible to abandoning the change project when organizational performance
drops to its lowest. Its at this point that the change agent might find himself fired. Paradoxically,
organizations that tend to operate at lower levels of maturity will drop more in performance when
asked to make a large change, but will also have a lower tolerance for this drop, and be more likely
to abandon the change as panic sets in.
Appendix
287
Even if change agents and change champions can effectively keep the organization on track, and
get the organization to the target state, the promise of improved performance may not materialize.
The reality is that the suggested change may be wrong for the specific context of the organization
in question.
As stated before, the agile and lean body of knowledge contains a diverse set of methods, practices,
and principles, not all of these are equally suitable to every organizations context.
Every organization has a different set of business drivers, level of maturity, willingness to change,
and an endless host of other factors that will ensure that no two agile transformations are alike.
Appendix
288
If we remember our original discussion around plan-driven methods, a key point is that they leave
us open to the risk of building the wrong thing. This is true of products, software, as well as a change
management target state. In an environment of high variation and complexity, faithfully completing
a plan that was built in the beginning of an engagement leaves us open to creating something that
has no value.
Software, (and other business valued work) is completed by a cross-functional, self-organizing, and
Appendix
289
empowered team that is typically co-located. In order to encourage this cross-functional nature,
Scrum specifies a very limited set of roles i.e.: a team member, a Scrum Master, and optionally a
coach. Team members may have specific specializations, but are not constrained to only doing any
one role. (e.g. a developer may test if it is helpful). Scrum Masters are expected to be servant leaders
who help the team by removing impediments, protecting them from organizational politics, and
providing other advice and guidance.
A particularly important part of Scrum is that teams only commit to delivering what they feel they
can possibly accomplish as part of a specific sprint. Commitment is done at the team, rather than
individual level.
Sprint cycles are typically accompanied by a very lightweight set of artifacts and meetings. Scrum
provides advice on how to conduct Sprint planning sessions, daily Scrums, and product demos, as
well as guidance in how to track velocity using burn down charts.
Scrum helps teams and the organizations they work for to become more agile in a number of ways.
First of all, sprint cycles are designed to maximize customer feedback allowing teams to course
correct and maximize customer value. Sprint cycles are also accompanied with what is known as a
retrospective, a regularly recurring meeting where team members focus on continuous improvement
and addressing existing issues and problems.
Appendix
290
The iterative, customer facing nature of Scrum is also designed to make organizational dysfunction
visible, encouraging the organization to make more systemic changes that are required to ensure
that individual teams can be successful. This focus on organizational impediments provides the data
required for change agents to transform to be more agile.
Using Scrum to help organizations transform share some, but not all of the risks found within a
big C change approach. Because Scrum is a minimalistic framework, the performance impact of
change from initial adoption is not as adverse as found in larger structurally-based transformations.
Subsequent waves of change can also be smaller, as the pace of change can be graduated based on
the impediments found by different teams.
That being said, different organizations have faced a number of challenges while trying to adopt
Scrum, and a significant portion of these organizations have failed to successfully adopt the
method.
While Scrum is a lightweight method, it asks executives, managers, and staff to work in a
fundamentally different paradigm. The whole notion of cross-functional teams, self-organization,
and delivering in small iterations can cause major conflict with organizations that have grown up
using traditional methods and traditional thinking. Many people resist the alien terms that come
Appendix
291
What many folks adopting Scrum also fail to realize is that implementing it must be quickly followed
by implementing other practices from the lean and agile world. The hyper agile model of Scrum
breaks down if organizations are not willing to invest in significant, further changes.
Scrum also faces challenges due to the fact that a pure agile model is not always the right recipe for
all organizations. Not all domains lend themselves to permanent, generalist, self-organizing team
members. Not all work neatly fits into the notion of short, time boxed intervals. Some organizations
are simply not ready for the large and sudden shift required to make Scrum successful.
Appendix
292
The Kanban system is then directly connected to business stakeholders responsible for prioritizing
and validating business valued work. Each customer is given a specific queue and allowed to place
work on that queue based on the amount of capacity dedicated to that customer.
Delivery agility is introduced in the system by putting explicit limits on how much work can be
consumed at a time. Very low work-in-process limits will force teams to adopt a much more agile
and lean working style, collaborating frequently, resolving impediments quickly, and keeping quality
high through best in class techniques. High work-in-process limits will allow teams to operate in
a way that is much more similar to traditional and legacy methods. There will be a much higher
tolerance for multitasking and working in silos. As a result, there will be less pressure to collaborate
Appendix
293
Current work in process is then visualized on the Kanban system based on where it is currently in
the process. Work in process is expressed as work tickets, which may represent enhancements, user
stories, or other business valued work.
Simple visual indicators such as color are used to annotate work so that technology knowledge
workers and their customers can immediately recognize important attributes such as risk, priority
and capabilities required to complete a specific unit of work. This allows knowledge workers to
assign unique processes to different work types. For example, emergencies could be completed as
soon as they are received regardless of what other work is in progress.
Hot colored tickets can also be used to annotate business valued work with associated blockers, and
other impediments. This visualization connects both status and risk of work with knowledge workers
and their managers on an emotional level, allowing them to see how much work is in process, as well
as the health of that work. This encourages people to make better decisions and improve maturity.
Knowledge workers will work through the process using a pull-based approach. Using this method,
work is only moved into a particular state when doing so will not violate the inventory limits for that
particular state. This ensures quick turnaround of delivery work, or what is known as delivery flow.
Delivery flow creates a high feedback system similar to that found in Scrum or other approaches
that rely on short iterations.
Appendix
294
Kanban helps organizations adopt a lean mindset, based on collaboration, continuous improvement
and self-organization. Kanban places a heavy emphasis on improvement through experimentation.
Kanban borrows lean analytical techniques such as the use of statistical process control and
cumulative flow diagrams to measure performance, flow, and lead time.
The combination of visualization, empirical-based improvement, and focus on flow allows knowledge workers to design customized process solutions that match their own context. Different Kanban
systems are allowed to evolve at their own pace within the same organization based on the unique
needs of the workers and customers involved in delivering business value. This process and method
diversity is enabled through a common process improvement method.
Kanban has been labeled as a meta-method, not a software delivery method in its own right.
Technology knowledge workers and their managers are encouraged to design the right method for
their own needs, using an incremental evolutionary approach. Kanban has also been described as
a viral improvement method. Kanban can be adopted in a small part of the organization, which
eventually encourages other workers to connect to that system, and adopt their own Kanban
implementation.
When Kanban works as designed, it offers the least disruptive path to organizational change. Because
getting started does not require anybody to change roles, change job titles, or change the way they
are organized, more conservative and traditional organizations can get started with less impact than
adopting Scrum.
Appendix
295
Kanban contains many design elements such as process policies, work in process limits, and work
types that are customizable to the context of the business value being delivered. This means that
Kanban can be matched to the unique constraints of the organization.
By design, a viral and evolutionary method can take a long time to provide desired performance
improvement results. When asking an expert how long a Kanban improvement method will take to
achieve high maturity, the answer is often as long as it needs to. While this approach may arguably
be the one that makes the most sense, it is often an answer that most organizations desiring some
type of transformation are not willing to or able to accept.
Kanban is also not designed to provide specific process answers for particular problems. Knowledge workers are expected to use Kanban to make problems visible, and engage in continuous
improvement to make the system work better. Our experience is that this can actually cause churn
and confusion in organizations with little practical agile experience. The wealth of options and the
customizable nature of Kanban can actually make change harder for some organizations.
Appendix
296
Finally, Kanban adoption can stutter just like Scrum due to the lack of existing maturity within the
organization. Kanban systems that do not process fine grained units of work, similar to user stories
found in Scrum and other agile methods, may exhibit a lack of feedback, slow performance, and
poor poor stability. This can interfere with continuous improvement. As a result, the initial jump to
successfully adopting Kanban can be larger than it is first thought to be.
Appendix
297
Step number one is establishing a sense of urgency. Insightfully, John believes that most people are at
least subconsciously aware of what is wrong with an organization, thus starting with target options
or vision is the wrong way to go. Instead, successful change agents should focus on establishing a
sense of urgency within the organization. The idea here is to try to emotionally connect the rationale
behind the change with the people who are being asked to change. Dont be over analytical at this
stage, but rather focus on tactics that help people in the organization feel the need to change in their
gut.
The guiding team then works on a change vision, a true North that can help guide the activities
of this change.
Appendix
298
Subsequently, the guiding team works on communicating as necessary to establish consensus and
understanding across all change stakeholders of the change.
Executives, sponsors and stakeholders are all responsible for empowering action so that the guiding
The team, and its sponsors and stakeholders have to be careful to approach change in a sustainable
way, and not giveup partway through
After the organization receives tangible benefits, effort switches to making sure that change sticks,
and becomes a cemented part of the organizational culture.