Leanchangemethod PDF

The Lean Change Method
Managing Agile Organizational Transformation Using

Kanban, Kotter, and Lean Startup Thinking
Jeff Anderson
This book is for sale at http://leanpub.com/leanchangemethod
This version was published on 2014-04-30
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
Tweet This Book!

Please help Jeff Anderson by spreading the word about this book on Twitter!
The suggested tweet for this book is:
I just purchased The Lean Change Method by @thomasjeffrey #leanchange
The suggested hashtag for this book is #leanchange.
Find out what other people are saying about the book by clicking on this link to search for this
hashtag on Twitter:
https://twitter.com/search?q=#leanchange
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
The Core Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Explaining the Lean Change Method . . . . . . . . . . . . . . . . .

Managing Agile Change . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Agile Change Using Lean Thinking . . . . . . . . . . . . .
Managing Change through the Kotter Eight Steps of Change Lifecycle
Managing Change Like a Startup . . . . . . . . . . . . . . . . . . . . .
Managing Change Flow through Kanban . . . . . . . . . . . . . . . .
Key Principles behind Lean Change . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
2
2
6
10
11
16
23
2 Managing Change with a Change Canvas . . . . . . . . . . . . . . . . . . . . . . . . . .

Communicate Your Change Plan Using a Change Canvas . . . . . . . . . . . . . . . . . .
Co-Create Your Change Plan through Negotiated Change . . . . . . . . . . . . . . . . . .
26
26
38
3 Building a Minimum Viable Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Reduce the Scope of Your Change to Make It Minimal . . . . . . . . . . . . . . . . . . . .
Introduce Improvement Experiments to Validate That Your Change Is Viable . . . . . . . .
53
55
60
4 The Validated Change Lifecycle . . . . .

Introducing the Validated Change Lifecycle
Agree on the Urgency of Change . . . . . .
Negotiate the Change Solution . . . . . . .
Validate Adoption . . . . . . . . . . . . . .
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
II Advanced Techniques and Topics . . . . . . . . . . . . . . . . . . . . . . . . . 113

5 Exploring The Change Canvas In Detail . .
Urgency . . . . . . . . . . . . . . . . . . . . .
Change Participants . . . . . . . . . . . . . . .
Vision . . . . . . . . . . . . . . . . . . . . . .
Target Options . . . . . . . . . . . . . . . . . .
Actions . . . . . . . . . . . . . . . . . . . . . .
Success Criteria . . . . . . . . . . . . . . . . .
Commitments . . . . . . . . . . . . . . . . . .
Benefits . . . . . . . . . . . . . . . . . . . . .
Communication . . . . . . . . . . . . . . . . .
Techniques to Consider . . . . . . . . . . . . .
Agreeing on the Urgency of Change . . . . . .
Negotiating a Change Solution . . . . . . . . .
Validating That Change Recipients Can Adopt
Verifying That Performance Is Improving . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 A Pattern Language for Agile Change . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Agile Change Patterns Shift the Focus of Learning Depending on Where You Are in
Your Agile Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Quick Win . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel Pilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Self-Starter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capability Modernization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
114
114
122
131
134
140
144
148
151
155
158
164
170
178
187
. 193
.
.
.
.
.
.
193
195
197
200
201
203
III Managing Enterprise Transformations . . . . . . . . . . . . . . . . . . . . . 206

7 The Transformation Canvas . . . . . . .
The Purpose of the Transformation Canvas
Traversing the Canvas Based on Risk . . .
Prioritizing MVCs For a Transformation . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
207
207
215
227
8 Enterprise Transformation Cadence Model

Overall Cadence Model . . . . . . . . . . . .
Change Agent Standup . . . . . . . . . . . .
Sponsor and Stakeholder Update . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
234
234
239
246
CONTENTS
Change Agent Planning . . . . . . . . . . . . .

Insight Analysis . . . . . . . . . . . . . . . . .
Reprioritizing and Changing the MVC Backlog
Validate and Refresh Change Canvas . . . . .
Transformation Canvas Refresh . . . . . . . .
Update and Share Metrics . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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.
Who Is the Lean Change Method for?

The Lean Change method is for agile change agents. If you are interested in promoting the adoption
of lean and/or agile practices in your team, department, or organization, then the Lean Change
method has something to offer you. The Lean Change method is not just for professional consultants.
Executives, managers, and team members can all benefit from managing agile adoption or agile
transformation using Lean Change.
A good thing about the Lean Change method is that it is meant to scale out based on the complexity
of your situation. The method can be tailored to a variety of different scenarios, from a team member
trying to initiate agile adoption with his peers, a program manager instilling a larger change in his
department, to an executive trying to transform his entire organization. Different tools within the
method are also pluggable in nature. You can replace pieces with your own techniques to make the
method fit your context. Use what you need, and discard what you dont.
Focus Is on Practice Not Theory

To borrow a quote from Ash Maurya in his book, Running Lean, Practice Trumps Theory. With
that in mind, this book explains just enough theory to give some context to the practical tools being
provided to the reader. While the book is based on theory, it is deliberately not theory heavy. The
purpose of the book is to provide agile change agents with a practical set of tools that will help them
support organizations as they move through the journey of an agile change.
This Book Assumes That the Reader Has Knowledge of

Various Lean and Agile Techniques, Terms, and
Buzzwords
As part of explaining the various components of the Lean Change method in examples of different
agile changes are presented. In these examples, plenty of different agile methods, practices, roles,
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!
A Brief Thank You to the Giants Who Have Inspired

This Method
Many aspects of the Lean Change are derived from the Lean Startup method. Specifically, components of the lean change method are inspired by techniques described in the book Running Lean
by Ash Maurya. I have been heavily influenced by his thinking when putting this book together,
and owe him a great deal of thanks for being such an influential pioneer.
This book also makes heavy mention of Kanban and the Kanban Method, made famous by David J.
Anderson. Although Lean Change has been designed to be agnostic of what agile and lean methods
are used, every Lean Change implementation that I am aware of also makes heavy use of Kanban,
I see the two techniques as being highly interdependent and interconnected. David has had a
tremendous influence on me. This insight has been provided through his book, in person, and him
through other channels. I owe David a great deal for the influence he has provided.
A Quick Blurb on Copyright/Legalese

First of all, all content in this book is licensed under a Creative Commons license, which you can
find at the front of this book.
The Lean Change method itself is also licensed under a Creative Commons Attribution-ShareAlike
3.0 Unported License to myself (Jeff Anderson) and Alexis Hui, based on the work that can be found
at http://leanchangemethod.com/ using the tag #leanchange.
In plain English, what this means is that you are free to use, replicate, and extend this work for both
personal, or commercial reasons as long as you provide proper attribution to myself and Alexis.
Its in our best interests to see other people use and gain benefits from the method. If you have any
questions about the creative common license, please look them up. You can find more details at their
site.
In this book, I will make frequent mention of something called a Change Canvas. The Change Canvas
is adapted from the Business Model Canvas, which can be found at www.Businessmodelgeneration.com/canvas.
The Business Model Canvas is also licensed under a Creative Commons Attribution-Share Alike 3.0
Un-ported License.
Many of the concepts in this book are adapted from Ash Mauryas book Running Lean, which is
copyrighted by Spark59.
Lean change uses a change lifecycle to track the progress of individual changes within an organization. This lifecycle, and other aspects of the Lean Change Method are drawn from The Eight Steps
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.
What Is the Current Status of Lean Change?

In its current form, the Lean Change method has been used for just a little over 2 years. The method is
really in its infancy. There are probably between 30 and 50 practitioners who have experience using
Lean Change at this point in time. I personally have been involved in eight large-scale lean/agile
transformations that have used the method, and know of a significant number of other cases where
it is being used. We continue to learn after every implementation, and expect the method to continue
to evolve.
The creation of this book represents a major milestone for the method, as all the thinking can now be
found in one accessible place. Alexis Hui, the cocreator of the Lean Change method, and I continue
to refine the method as we use it in the field.
Jason Little, Andrew Annette, Bernadette Dario, and a group of other agile coaches working for one
of our clients played a crucial role on a large-scale agile transformation where we grew the Lean
Change method, and exercised incredible patience as we cut our teeth on it. They have all provided
meaningful contributions to the method. Jason and Co. have even written another book on Lean
Change (titled Lean Change) documenting their experiences. They have taken the Lean Change
concept in a different direction than I have, but are in keeping with the spirit of it, and I believe they
are enriching the Lean Change community with their text.
Im hoping that readers of this book will consider using some aspects of the method, experimenting
with what works, and what doesnt. I look forward to hearing about these experiences. Please dont
hesitate to reach out to me if you have any questions, or want to share your stories.
I can be found on twitter @ThomasJeffrey
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
The Lean Change Method Is Still a Work in Progress

The lean change method is continuing to evolve as we speak. I am planning a new publication that
will expand on some of the key concepts required to manage large-scale transformations numbering
in the thousands and many thousands of employees. This next publication will also elaborate on
various methods and techniques that integrate well with the lean change method. Examples include
value network design , game oriented learning, and different techniques used in measuring the
progress of a large-scale transformation. This new book will showcase some of the latest techniques
that our team has been using to enable agile change, with the deliberate focus on personal anecdotes
and experiences gained while using the method..
My original intent was to include all these concepts in this book, but on reflection I want to avoid
bloating this book with every possible future. I feel like its current incarnation is useful without
being perfect, and think its time to really focus on getting this out to the community. Let me know
if you want to see any of the items mentioned above, or if theres anything else that I can add to the
next book to make it more useful to you.
If you want to keep up with the latest on the Lean Change Method, pay a visit to leanchangemethod.com
Thanks, and good luck on your agile change!
I The Core Method

The first part of this book focuses on the core of the Lean Change method. Concepts are illustrated
using an additive approach, with each concept building upon the last, enabling a deeper and more
complete understanding of the method. This allows change agents who want to get started quickly
to do so. Readers can then scale out their use of the method to handle more complex situations as
they progress through the remaining chapters.
Part one of the book starts by examining the Lean Change method as a whole, its purpose, sources of
inspiration and major components. The book then goes through each component in detail starting
with the Change Canvas. I show you how to use the Canvas to communicate, negotiate, & co-create
a change model. Next, the notion of a Minimum Viable Changes is introduced, providing insight on
how to introduce change that is both small and testable. Finally, we will go through the Validated
Change Lifecycle, allowing us to sequence change activity in a way that optimizes learning, risk
management, and achievement of successful change outcomes.
1 Explaining the Lean Change Method

This book provides advice on how to use the Lean Change method. I thought I would try to
describe the purpose of this book, and its contents, by examining the books title The Lean Change
Method: Managing Agile Organizational Transformation through Kanban, Kotter, and Lean Startup
Thinking. Thats quite a mouthful, chock-full of buzzwords and industry jargon.
Managing Agile Change

First of all, lets start with the phrase Managing Agile Organizational Transformation. This book
is an attempt to provide change agents with a set of useful tools to manage an agile organizational
change. Im hoping that readers will find something useful within this book regardless of whether
they are part of a smaller scale agile adoption, or a larger scale agile transformation. The various
practices and methods described in the book are all aimed at helping change agents and their
change stakeholders collaborate on organizational change is focused on helping improve delivery
performance through the adoption of lean and agile.
But Agile Change is Extremely Hard!

So why do we need a book on this topic? Well, moving an organization from traditional thinking
to agile thinking is harder than it looks. While different agile methods and tools have unique and
sometimes contradictory viewpoints, there are some fundamental differences between how an agile
or lean organization operates and one using more traditional management methods. Lets take a
look at some of the major differences between traditional and agile organizations.
Traditional Organizations Are Focused on Efficiency Through

Specialization and Command and Control
Traditional management emphasizes an approach that maximizes efficiency, and provides goods and
services to customers at the lowest possible cost. This low cost is achieved through a command and
Explaining the Lean Change Method
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.
Check Out The Appendix for More Information

If you want to read more about traditional management methods and their challenges,
check out the chapter on Traditional approaches to technology delivery in the appendix of
this book.
Lean and Agile Organizations Are Focused on Enabling Learning

through Speed and Self-Organization
In this environment, a combination of learning and speed are fundamental to survival, and are more
important than cost and efficiency of execution. Agile and lean methods provide a framework where
organizational design, delivery techniques, processes, and management methods are all focused on
supporting both speed and learning.
Organizations using Lean and Agile inject learning and accelerate creation of value using a number
of methods.
These methods and techniques include:

Delivering business valued worked to customers frequently, creating a customer oriented
feedback loop
Organizing work so that it is delivered by teams that are cross-functional, cohesive, and selforganizing
Focusing on a limited set of business value tasks at a time
Adapting what delivery methods and techniques to use based on a continuous improvement
learning cycle
Oganizing work across teams according to a value network, rather than a hierarchy

If you want to read more about what makes agile organizations different, check Out the
section on how Agile and Lean Provide a Vision for Success in Todays Complex, Customer
Driven World in the appendix of this book.
Switching to Agile Is a Disruptive, Paradigm Shift for Traditional

Organizations
If we contrast and compare an organization that uses traditional techniques like command and
control, detailed planning and hierarchical specialized structures to one that places a bigger emphasis
on learning, cross-functional teams, self-organization, and network structure, we can see that
organizations using traditional methods dont really look a lot like organizations using agile or lean
methods.
Organizations using traditional methods could be thought of as an industrial cargo boat or cruise
ship. The design is efficient, and we can move a lot of passengers across a vast distance for low cost.
Organizations using agile and lean methods are a lot more like a speed boat. The cost per passenger
might seem to be higher, but this is made up for in speed and usability.
Metaphors aside, the real point here is that traditional organizations and agile organizations dont
have a lot in common, and the change required to get from one to the other is substantial.
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.
Managing Agile Change Using Lean Thinking

Now that we have covered the issue that agile change has the potential to be catastrophic to an
organization, and that many existing change methods dont help the situation, lets talk about some
solutions. This is where we can turn to lean. Lean thinking provides many interesting options to
help us improve the outcome of a managed change initiative.
With that in mind, lets go back to looking at the title of the book and examine the portion of the
title called The Lean Change Method. This book discusses how to bring lean thinking to the world
of managed organizational change. Before I get into what I mean by a change approach inspired by
lean thinking, I want to talk about how change is often conducted within organizations, using the
traditional approach to change. This approach often involves a Big C/Big Bang change.
The Big C Approach to Change Is Risky, Disrespectful, and

Almost Guaranteed to Provide Suboptimal Outcomes
If we look at how organizations often run change initiatives, they typically bring in external
consultants to forklift in a pre-existing change solution based on a particular problem set and
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.
My early forays into trying to improve performance of technology organizations followed a

traditional big C consulting approach. This typically meant performing enough analysis to come
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.

For more on my take on big C change, check out the section on how Big C Change Traditionally Used by Big C Consulting Firms Is Fundamentally Wrong for Agile Transformation
in the appendix of this book.
The Lean Change Method Allows Change Agents to Initiate a

Managed Change in a Cocreative and Collaborative Way
With the Lean Change method, we still rely on change agents and change stakeholders to manage
change, but we use a lean approach to do so. Using the Lean Change method, we follow an approach
that is based on learning, co-creation, and experimentation. We maximize the input from the people
on the ground who are being asked to change. The Lean Change Method is based on the proposition
that dramatic change in an organization does require management. But that doesnt mean we cant
remove a lot of the baggage associated with the way that change initiatives have been managed in
the past, and use lean thinking to get to a valuable outcome for all involved.
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
Managing Change through the Kotter Eight Steps of

Change Lifecycle
Lets start with what do we mean by Kotter? The Lean Change method starts with an established
change life cycle known as the Eight Steps of Change. Made famous by John Kotter in his text The
Heart of Change, this eight-step change lifecycle has been used for over a decade to help guide largescale managed change initiatives. Kotter argues that successful change requires emotional resonance,
and people being asked to change have to feel the need to change in their gut. Kotter recommends
that organizational change start with building urgency, and institutionalizing quick wins using a
coalition of eager change adopters.
This coalition of the willing is guided by a clear vision, good communication, and the right level
of empowerment to create short-term victories. Momentum for the change is continued until the
change is successfully incorporated into the new corporate culture.
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
Managing Change Like a Startup

The idea of using lean thinking to manage change serves as a good introduction to our next topic.
Looking again at the title of our book, we can focus on the Lean Startup portion, and discuss how
Lean Startup fits into the picture.
As stated previously, the Lean Change method starts with the Kotter model. The method then lays
out the Kotter model using a number of Lean Startup techniques, techniques made popular by Ash
Mauryas book Running Lean. Readers familiar with the Lean Startup and the Running Lean book
will recognize the source of inspiration for many of the Lean Change methods and techniques.
What inspired me and my team to look to the Lean Startup domain to help with agile organizational
change?
Organizational Change Is Unpredictable

First of all, if there is one thing that is true about large-scale change initiatives, it is that outcomes are
extremely hard to predict. When running a change management program, we are trying to help an
organization get to improved business outcomes. We do this by defining a target state and planning
a set of change actions.
If we are being honest, many of the upfront choices we make concerning our change are really
just assumptions. As we execute our change plan, we continually uncover new information about
business value, existing capability, current culture, workload, and a variety of other facts. This new
information requires us to constantly rethink the validity of our assumptions.
Existing change management methods make it really hard to ensure that our change plan keeps up
with our continued learning. Major failure has to occur before a change in direction is considered.
As a result, organizations end up with a change that does not provide the intended value.
Much of the Advice Provided from the Lean Startup Method Can
Apply to Managed Change
When looked at from this light, a change initiative can be thought of as a kind of startup . The
good news is that a lot of advice exists around how to maximize a 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:
The Change Canvas

Using the Lean Change method, we generate models of the future using a holistic, visual approach
that emphasizes co-creation, prototyping, and re-creation. The folks using the Lean Startup method
often create these models using a Lean Canvas or Business Model Canvas. Change agents using the
Lean Change method use what is known as a Change Canvas to describe and communicate an agile
change plan.
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.
Minimum Viable Changes

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

Successful startups understand that predictions of the future as exactly that, predictions. They
thus spend the time to explicitly validate those predictions. Using Lean Change, we follow the
same mindset. Minimum Viable Changes are introduced to the organization through a Validated
Change Lifecycle. We have defined this lifecycle to maximize the change agents ability to accelerate
validation of a assumptions behind a particular MVC.
The Validated Change Lifecycle integrates Kotters Eight Steps with the Meta-Iteration Lifecycle
Pattern from the Running Lean book. Using this lifecycle, Minimum Viable Changes are both defined
and validated according to a specific sequence.
Change agents start by working with potential change stakeholders to Agree on the the Urgency
of why a change is required in the first place. Change agents focus their effort on connecting
urgency/problems with a cohort of change 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.
An example of an Improvement Experiment could be approximately half of the developers within

the mobile payment team will adopt basic Test Driven Development as a result of participating in
four facilitated coding dojos over the course of a month.
Capability and Performance Metrics

Minimum Viable Changes and Improvement Experiments are validated through measurement.
Lean Change provides a number of ways to perform these measurements. Changes are measured
primarily from two perspectives. The first perspective is the ability of change recipients to adopt,
and ultimately excel at new agile and lean methods and techniques. The second perspective is the
impact of these techniques on actual delivery performance and value.
Hopefully, I have provided a good summary of the specific techniques and tools that the Lean Change
method borrows and adapts from the Lean Startup domain. Specifically, a large portion of this book
describes how to manage agile organizational change using Lean Startup thinking and Lean Startup
techniques.
Managing Change Flow through Kanban

Now that we have discussed how this book is about using Kotter and Lean Startup to manage agile
organizational change, lets talk about Kanban.
Kanban, as described by David J. Andersons book Kanban: Successful Evolutionary Change for Your
Business, is an ideal method to manage both continuous operation and continues improvement for
all kinds of knowledge work systems. This includes managing the operations of an agile change
initiative. Kanban is a lean inspired management method that helps knowledge workers continually
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.
Both Minimum Viable Changes and Improvement Experiments

Are Managed Visually Using Kanban Systems
The Lean Change method uses various Kanban boards to define and visualize how change progresses
through the organization, helping change agents get into a state of change flow.
A Validated Change Kanban is used to track individual Minimum Viable Changes as they pass
through the Validated Change Lifecycle. This allows teams of change agents to coordinate and
collaborate during a change initiative, taking advantage of Kanban features such as visualization,
explicit policies, standups, and limiting the amount of change in progress.
An Improvement Experiment Kanban is used to track Improvement Experiments for each Minimum Viable Change. As an MVC passes through each state in the Validated Change 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.
Changes Eventually Need to Be Measured in Terms of Improved

Performance, and Kanban Provides an Excellent Set of
Techniques to Do so
Ive talked previously around how Improvement Experiments are used to validate different aspects
of a Minimum Viable Change. As change recipients gain experience in lean and agile methods,
they start to evaluate Improvement Experiments against performance metrics. Because of its origins
within lean, Kanban provides a rich set of metrics such as leadtime, throughput, and failure intake
that can be analyzed using statistical process control or cumulative flow diagrams.
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.
Once the Organization Achieves Sufficient Maturity, Kanban Can

Take over As the Change Management Method
Kanban is described as a change management method in its own right, by David J. Anderson
and others in the Lean-Kanban community. This change management approach borrows many
techniques and ideas from Lean and other bodies of knowledge to enable a viral, and evolutionary
change management approach designed to help organizations gradually become more agile over
time.
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.
Check Out the Appendix for More On Kanban

For a slightly more detailed overview of Kanban and how it works, check out the section
on Kanban in the appendix.
22
What about Scrum?

Scrum could also be used as the method that operationalizes the Lean Change method. It could serve
as a source of performance-based metrics, and takeover as the incremental change management
framework of choice to support bottom-up improvement. That being said, most Lean Change
implementations that we are aware of have elected to use Kanban as the improvement method
of choice, and then eventually evolved to adopting some elements of Scrum that matched their
requirements.
As a side note, many of my early agile adoption projects were based on helping clients adopt Scrum.
On occasion, this caused interesting challenges. When working in an IT context, we encountered a
lot of delivery initiatives that did not seem to easily lend themselves to the idea of cross-functional
teams, where the majority of team members were dedicated to the work of that team. Often
technology delivery was based on the use of packaged software, integration of legacy systems, large
data conversion, etc. all which can cause challenges when trying to get value out of a pure Scrum
approach. Its because of this that I tend to start with Kanban, which offers a little bit more flexibility,
and then integrate elements of Scrum that can provide value to the organization.
Scrum does provide value as a whole method in various contexts, and I would love to hear about
any case studie select to use Scrum as the agile improvement method of choice to integrate with
Lean Change.
Check Out the Appendix for More on Scrum

For a slightly more detailed overview of Scrum and some of its benefits and trade-offs,
please check out the section on Scrum in the appendix.
So What Is This Book about Again?

Getting back on topic, The Lean Change Method, and this book, is about:
1. Providing a framework to help organizations make the incredibly risky move from existing,
traditional methods and values, to ones based on lean thinking and agile principles
2. Providing guidance on how to use a method that extends the Kotter change management
lifecycle with concepts made famous by the Lean Startup movement, such as validated
learning and constant innovation
3. Showing how to operationalize the change program using Kanban, allowing change agents to
continually improve how they are managing change over time
4. Advocating using the latest agile and lean methods to manage an agile change program
23
Key Principles behind Lean Change

There seems to be an inherent paradox in managing ambitious change efforts. On the one hand,
a common strategy and vision is required to align everybody towards a common goal post, and
this common goal needs explicit management by executives, managers, and other dedicated change
agents. On the other hand, managed change comes with a number of potential drawbacks, drawbacks
which tend to severely derail the change effort. Managed change is prone to risk-risk of change
resistance, risk of lack of sustainability, and the risk of being incorrect.
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
2 Managing Change with a Change

Canvas
In this chapter, Im going to provide readers with an overview of how the Change Canvas works.
The idea of using a canvas for modeling an unpredictable future is not a new one. The canvas
was originally made famous by Alex Osterwalder and Yves Pigneur in their book Business Model
Generation. The book described how a Business Model Canvas can be used to model, prototype,
communicate, and iterate on how a business can operate. The Business Model Canvas has gained
wide popularity as a tool to inject design thinking into the world of business strategy and business
planning.
More recently, the canvas has been adapted by the startup community. Ash Maurya, in his book
Running Lean, describes what is known as the Lean Canvas. This canvas is adopted from the
business model variant, making it more suitable to the needs of entrepreneurs trying to start brandnew businesses. The Change Canvas borrows much of its inspiration from this Lean Startup variant,
with specific modifications to make it suitable for organizational transformation.
The Change Canvas is a core component of the Lean Change method. This tool provides a medium
for change agents and change participants to collaborate over a potential change plan. It acts as a
kind of plan on a page. The limited space on the canvas forces succinctness, as well as a certain
informality. That being said the Change Canvas is holistic, and all the aspects of a change plan are
included.
Limited canvas space, combined with a comprehensive scope, encourages canvas builders to engage
in a kind of creative, lateral thinking, where deep analysis is avoided, and different solutions can
be suggested, discarded, and combined. The canvas is easily collaborated on by a group of diverse
individuals. It also supports iteration, making rework easier. Using the Change Canvas, a change
model can be quickly developed, discussed, and then modified without incurring too much overhead.
Communicate Your Change Plan Using a Change

Canvas
The Change Canvas is a great way to communicate a potential change plan. In my experience,
anything you can do to help get a diverse set of stakeholders to a common understanding is a good
thing. Even getting to the point where we can understand each others positions and each others
intentions is a better place than where many change initiatives start.
A very simple and effective use of the Change Canvas is to use it to map out your understanding of
a potential change plan. Maybe you are an external consultant or coach who has been hired to help
Managing Change with a Change Canvas
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.
A Little Bit about Danny the Developer

I think the best way to show how a Change Canvas can help you better communicate a change plan
is to tell a story based on real-world use. Id like to share a story about Danny the developer.
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
Your Change Is Not Just The Change Solution

Change agents often prematurely focus on the change solution, which is really just a small
part of the change! People being asked to change tend to focus on the impact to them,
next they might focus on exactly what problem is being solved, and how the change could
benefit them personally. Danny needs to spend time getting to common ground on what
is at stake, and how things could potentially improve before deciding what the answer is.
Better Communication Using the Change Canvas

Danny then takes a step back. He is determined not to abandon the idea of trying to improve the
way his teammates are delivering software, but is now convinced that he needs to take a different
approach. Simply telling his teammates what he thinks a solution should be is not working. Danny
decides to try to map out all the aspects of the change that he wants to attempt using a Change
Canvas. Hes hoping that by communicating his intentions better, hell be able to open up a more
productive dialogue with his team.
The Makeup of the Change Canvas

The Change Canvas is made up of a number of sections, and each section is responsible for
articulating a key aspect of a change plan.
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
Danny Starts by Filling Out the Canvas on His Own

Danny lists all of his teammates as his change participants. This includes the other developers and
testers that are on his team, as well as his manager, the business analyst on the team, and the most
active business stakeholder.
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
Co-Create Your Change Plan through Negotiated

Change
Now that Danny has completed the canvas, he is ready to show it
to his team.
Danny was now prepared to share his canvas. Danny began to socialize this canvas with his various
team members, stakeholders and other interested parties. Danny was careful to communicate that
the purpose of showing the Change Canvas was to modify it to suit the needs of all the various
change participants and stakeholders and not dictate an approach.
As a result, the change model went under drastic modification._
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.
Address Urgency through Tangible, Business Problems

If you take a look at the difference between the urgency section of this canvas, and the
one that Danny put together on his own, youll see that the problems highlighted in the
current version are rooted in tangible business problems. Dannys original canvas listed
various issues with methods, processes, and techniques. These are real problems, but many
times these wont resonate with the people being asked to make a change. Change agents
must be very careful to work closely with potential change stakeholders to list a set of
problems that matter to the people being asked to change.
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.
Worry If Your Change Canvas Doesnt Change Substantially

The fact that Dannys change canvas has changed so drastically so quickly should not be
of alarm. This is a normal part of the process. A change agent will jot down some ideas
on a canvas in order to show it to various change stakeholders, and as a result, completely
rewrite most or all of the canvas.
Its extremely important not to get too attached to your original change plan, since it will
most likely be wrong! The primary reason to create a canvas ahead of time is so that people
can have something to bounce ideas against. In some cases, its okay to show up with
a canvas completely empty. Just make sure to remember that were trying to encourage
change participants to input their ideas onto the canvas.
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
Build Your First Canvas

1. Think about an opportunity where Lean or Agile related methods could be helpful
in your organization. Build a Change Canvas to reflect your thoughts on how
this change would be realized. Try to target a small and cohesive set of change
participants, such as a specific team or smaller functional department.
2. Socialize your canvas with as many impacted change participants as you can. Try
to run a collaborative session where you can rework the canvas to better reflect
the perspective of your change participants. Be ready to tear down most of your
initial canvas ideas in order to come up with something that better resonates with
the people who are actually being asked to change.
52
3 Building a Minimum Viable Change

Using a Change Canvas helps change agents deliver on the first promise of the Lean Change method,
that change be negotiated. Following the principle of negotiated change, successful change requires
that both change agents and change participants engage in a cocreative process. We want to ensure
that any suggested change meets the particular needs of the people being asked to change.
The use of a Change Canvas is inspired from the Lean Startup method. This is important because
the second 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.
Validated Learning Defined

Eric Ries describes validated learning as the progress made when assumptions have been confirmed
or refuted by subjecting each assumption to one or more customer validation tests.
For our purposes, validated learning can be described as the progress made when assumptions
have been confirmed or refuted by subjecting each assumption to change participant tests. Using
the Lean Change method, validated learning comes through frequent interaction and collaboration
between change agents and other change participants. Validated learning cant happen unless
negotiated change is leading to a cocreative change.
Building a Minimum Viable Change
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
Reduce the Scope of Your Change to Make It Minimal

The first thing that we want to do is to pair down the size of our change so that it is minimal, i.e.,
small.
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.
Strategies to reduce the size of your change

There are a number of ways that we can think about reducing the scope of a change to make sure
that it is minimal. These include:
1.
2.
3.
4.
5.
6.
7.
8.
Paring down the target options to one or two interrelated themes

Focusing on the needs of a smaller cohort of highly integrated change participants
Reducing the scale of anticipated benefits to something tangible and pragmatic
Constraining the required commitments to how much time change participants actually
have capacity for (often less than you want or think)
Focusing on countermeasures for one core problem listed in the urgency section
Limiting external change agent actions to one explicit tactic (i.e. coaching only, creating
publicly available guidelines only)
Keeping the duration of the entire change to less than one month
Limiting the amount of improvement experiments for your change to less than eight
.
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.
Pair Down Your Change so That It Is Minimal

1. Take your existing Change Canvas and collaborate with change participants to
reduce the scope of the change being represented.
2. Focus on the needs of your core change participants, and defer requirements from
secondary stakeholders.
3. Try to reduce the target options, scoping it to a couple of highly interrelated concepts.
4. Likewise, look over the the rest of the canvas and reduce scope where appropriate.
Introduce Improvement Experiments to Validate That

Your Change Is Viable
A Minimum Viable Change also has to be viable. For a change to be viable, we need to continually
validate the different aspects of that change. This validation can be achieved by implementing
our change using a discrete set of Improvement Experiments. As each Improvement Experiment
is introduced to change participants, the experiment is evaluated, providing insight into the validity
of the change model represented on the canvas.
One way to manage Improvement Experiments is to track them using 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.
For more on Kanban checkout Kanban
.
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
Continuing Our Story of Danny the Developer

In order to show how Improvement Experiments can be used, lets continue following Danny as he
works with his team to improve delivery performance.
Filling the Backlog
After a couple of planning sessions, Danny and his team come up with a set of Improvement
Experiments that they feel will result in executing on their change model. The group then prioritizes
these Improvement Experiments into various two-week blocks. They take care to put no more than
three Improvement Experiments in each block, as the team feels that this is the maximum amount
of change the team could absorb every two weeks.
66
Preparing New Improvement Experiment

When December first rolls around, tickets can start moving into the Next column, signifying that
new improvement items should be started. Note that only two tickets are moved as this is the current
WIP limit being set by the team.
The team then decides to move the value stream mapping session into the Prepare state.
As tickets are moved through the prepare state, the first thing we do is rewrite the ticket so that
it supports the notion of testability. Each test should validate the assumptions behind the change,
represented in one or more sections of the Change Canvas.
Writing Testable Improvement Experiments

I try to design my Improvement Experiments so that they contain the following key items:
1.
2.
3.
4.
Explicit activity or action

The roles and/or people being affected by the change
An outcome or effect as perceived by the people be impacted by the change
A constraint, such as a number of sessions, or a time where the experiment expires
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.
Introducing the Experiment

Once this Improvement Experiment has been prepared, it can now be moved to the Introduce
column. This is a signal that the team is now actively running sessions, trying out new techniques,
etc., and potentially even benefitting from the improvement items. This benefit could be in the
form of validation of change assumptions, or actual realization of benefits on the change canvas.
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.
Learning from the Experiment

At this point, the experiment is moved to the Learn column, and evaluated for success.
It is important for change agents not to fall into the trap of evaluating experiments on their own.
Ultimately, it is the change participant who needs to make the call about whether an Improvement
Experiment is successful or not. In our experience, Improvement Experiments do not always simply
pass or fail. For this reason, we have used a three-outcome approach: success, fail, and partial success
(tagged with green, red, or orange markers).
As various Improvement Experiments are passed through the Learn column, the canvas can be
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.
Updating Your Canvas Based on Your Improvement Experiments

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

When a large number of experiments do not meet expectations, then it is time to consider a change
pivot. A change pivot involves wholesale modifications to the Change Canvas, and underlying
change model. When executing a change pivot, one key aspect of the change model is altered,
while keeping another aspect intact. Examples of a change pivot include:
1.
2.
3.
4.
Choosing a different set of change participants

Selecting a different set of methods, tools or techniques to adopt
Switching up actions and tactics, perhaps going from light touch to high touch or vice versa
Scaling back benefits to better reflect time commitments that your change participants can
make
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.
Validate Your Change through Improvement Experiments

1. Set up a Improvement Kanban, determine your backlog of Improvement Experiments, and how often you will replenish the backlog.
2. Come up with some inventory limits to the amount of experiments to take on
during each replenishment, and how many can be in progress at each state in the
improvement lifecycle.
3. Prioritize your Improvement Experiments by placing them into the backlog section
of the Kanban.
4. Begin introducing one or more Improvement Experiments to your change participants. Before starting, make sure to rephrase the Improvement Experiment so that
they are in a testable form.
5. Introduce one or more improvement experiments, and move them through the
improvement lifecycle on your Kanban board. Annotate your Improvement Experiment based on what you have learned. x> 5. Once you have evaluated one
or more Improvement Experiments, meet with your change participants to modify
your Change Canvas based on the latest learnings. Consider setting up a policy that
governs when you should be taking a second look at your Change Canvas based on
the results of Improvement Experiments.
74
4 The Validated Change Lifecycle

In this chapter Ill discuss how Minimum Viable Changes can be both developed and validated by
following a Validated Change Lifecycle.
Using this lifecycle, risks and assumptions that are often raised earlier during a change initiative
can be dealt with earlier. Risks and assumptions that are typically addressed once the change is well
underway can be deferred until later.
Change agents who elect to follow the lifecycle will be able to learn faster about whether a particular
MVC is viable. The lifecycle provides a sequence to order the assumptions you want to validate.
The idea here is to accelerate learning, and provide earlier feedback around which MVC should be
pursued, which requires a pivot, and which change should be abandoned.
Introducing the Validated Change Lifecycle

During previous chapters, Ive discussed how change agents can collaborate with change participants
to negotiate their way to a successful change solution using the Change Canvas.
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.
Why Do We Need a Validated Change Lifecycle?

Change initiatives face a multitude of risks all of which can derail any chance of a positive outcome.
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.
An Overview of Key Risks Faced by Agile and Lean (or Any)

Change Initiatives
Perhaps the most significant risk of any change engagement is one of resistance. Changes that
seemingly make complete sense to everybody involved can still face significant and/or passive
resistance when change agents try to implement these changes. Organizations and the people that are
employed in those organizations possess very robust antibodies that are able to resist any challenge
to the status quo regardless of implied benefits.
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
The Eight Steps of Change

John Kotter, in his text The Heart of Change describes an eight step change lifecycle, showing
a number of case studies illustrating change agents working with an organization to enable
significant change following these steps. The eight step change lifecycle has been used for over a
decade to help guide large-scale managed change initiatives. Kotter argues that successful change
requires emotional resonance, and that people being asked to change have to feel the need to
change in their gut. Kotter recommends that organizational change start with building urgency,
and institutionalizing quick wins using a coalition of eager change adopters.
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
Instantiating the Lifecycle through a Validated Change Kanban

You may remember that in Chapter 2 we talked about extending a Change Canvas by placing a
Kanban system below it to track the lifecycle of specific Improvement Experiments.
A Kanban system can also be used to visualize the state of Minimum Viable Changes progressing
through the Validated Change Lifecycle. As each MVC satisfies the criteria specified in each state,
it can pass from one column to the next on the Validated Change Kanban. These acceptance criteria
are marked underneath the column for each state using clearly stated Kanban style work policies.
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.
Agree on the Urgency of Change

The first state within the Validated Change Lifecycle that a Minimum Viable Change passes through
is the Agree on Urgency state.
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.
Filling out the Urgency and Change Participants Section of

the Canvas
These two sections are typically filled out in parallel using an iterative process. Getting to urgency
is really about articulating pain points as they are felt by potential change participants. These pain
points can surface through workshops using a number of diagnostic techniques like value stream
mapping or five whys, using analytical thinking such as that recommended by the A3 process,
retrospectives, impediments raised through Scrum or Kanban, or a variety of other sources.
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
Negotiate the Change Solution

Once you have connected a set of problems/urgencies with a set of change participants who want to
form a guiding team, your Minimum Viable Change is ready to move into State 2: Negotiate Change,
you are ready to start working on the actual change solution.
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.
Filling out the Vision, Target Options and Benefits Sections

of the Canvas
The vision section of the canvas should be brief, containing a single, compelling statement and
perhaps an image. Its important that the vision of the change strive to excite action! A good vision
captures the essence of the change, a tangible outcome through differentiated action, culture, and
techniques.
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:
Dedicated, and highly immersive team coaching
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.
Filling Out the Communications Section of the Canvas

Use the communication box within the Change Canvas to describe how you are going to
communicate between change agents and change participants, as well as other change stakeholders.
Describe frequency, channel, and purpose of each communication.
Refer to the Communications section of Chapter 4- Exploring the Change Canvas in Detail for
more information on how to explore the Communications section of the change canvas.
.
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.
An MVC can result in a change in process, a change in organizational structure, or in a change in

techniques/methods being employed by employees.
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
on the Change Canvas.
Relating Your Improvement Experiments to Success Criteria

Each Improvement Experiments that you run should tie into one or more success criteria. This
makes it much easier to validate the relationship between commitment, benefits, and target state.
As an example, you may have an MVC that makes the assumption that your team can both master
and benefit from introducing a number of agile modeling techniques.
Success criteria are then made defining how many people will reach what level of capability in
agile modeling methods. Are we trying to get folks to have a basic understanding of new methods,
real working knowledge, or mastery? How many folks? Which skills? For the above example, lets
say that a success criteria is ten analysts can add value in various agile modeling workshops, and
two analysts will be able to plan and facilitate these workshops.
When an Improvement Experiment is introduced, build a hypothesis that a certain activity will
result in a number of participants feeling like they have reached a certain level of mastery. These
types of success criteria and Improvement Experiments are qualitative, and are more art than
science, but they help qualified assumptions in our change model.
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.
Some (Suggested) Requirements for Getting to Verify

Performance
When talking about any kind of agile or lean-related change, improved business outcomes are often
expressed in terms of improved performance. In order for a change agent to effectively measure
performance, a number of things must be in place for the change participants.
First of all, the team must have some type of lean or agile metrics gathering and reporting capability
in place. The team must have some experience in looking at metrics such as velocity or throughput,
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.
A Caveat around Performance-Based Improvement

There are many in the agile community who feel that software delivery work is too close to the
edge of chaos to support any kind of quantitative improvement. There is certainly some merit
to this opinion, and for some domains, it may make sense to have a Minimum Viable Change
completely skip the verify performance stage. The change plan can be considered complete after
the Validated Adoption state is finished.
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
Different Options to Verify Performance

Change participants and change agents attempting to adapt more classical agile methods can base
improvement experiment hypotheses on a suggested change in velocity, and sprint commitment
accuracy.
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.
Make Sure Your Team Has the Capability to Gather and

Investigate Metrics before Going into Verify Performance
As mentioned previously, before a Minimum Viable Change can pass into the Verify Performance
stage, a change agent should have successfully helped a set of change participants adopt the tools
and techniques necessary for them to become measurable. This is typically done through running
an Improvement Experiment during the validated adoption state that is dedicated to this outcome.
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
Looking at How the Canvas Evolves through the

Lifecycle
As change agents and change participants take a Minimum Viable Change through the Validated
Change Lifecycle, different sections of the Change Canvas are evaluated using a number of different
means.
In this section, Ill provide a summary of how our team has been typically validating a Change
Canvas used to model an MVC depending on where it is within the lifecycle.
It is common for a change agent to create a draft canvas as soon as he feels that a change would be
of benefit to a change participant segment.
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
Communicating Information Coming Out Of the

Validated Change Lifecycle
The Lean Change method provides a wealth of information relating to the effectiveness and appropriateness of a particular change. However, if change agents are not careful, change participants and
other stakeholders can become a little bit overwhelmed and confused.
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.
II Advanced Techniques and Topics

Part 2 of the Lean Change method book discusses different ways to extend the method based on
various real world situations that change agents will likely face. Chapters in the second part of this
book focus on techniques and methods that are considered largely optional. While the advice of
using parts of the method that make sense to you applies to the entire method, this is especially
true for the chapters in this part of the book. Depending on your context, there is a lot of value to
be found, but not for all situations.
The second part of the book starts by providing readers with a number of tools and techniques that
can be used to explore the Change Canvas in greater detail. Once these techniques are illustrated,
a comprehensive case study is illustrated showing a team of change participants using the Lean
Change method through the lifecycle of a complex change initiative. Finally, various agile change
patterns are presented, which can be used as an accelerator when trying to develop your own
minimum viable changes.
5 Exploring The Change Canvas In

Detail
As mentioned previously, the canvas is a great way to build a change model and supporting
change plan. One of its biggest benefits is that it is collaborative. It forces a certain informality
and succinctness that makes it easy to create a plan quickly, and tear it down when it turns out to
be wrong.
The canvas forces change agents and change participants to consider all aspects of a change initiative,
but only in brief; there simply isnt enough space on the canvas to get lost exploring a huge amount
of detail.
But sometimes exploring things in a bit more detail is warranted. Sometimes we need to understand
the complexity of the current organization, perform root cause analysis on its problems, and spend
a little more time designing the target options in order to come up with an effective change. Where
required, change agents can plug in different methods and tools to help them perform the analysis
necessary to complete a certain section of the canvas. Different techniques can be plugged in to
facilitate this exploration. These plug-ins are useful when using the canvas to model a Minimum
Viable Change or a larger transformation.
There are a multitude of approaches and methods out there that can help change agents analyze pain
points, define target options, and identify key gaps. The purpose of this chapter is to show some of the
methods and tools that weve used to help us perform the analysis necessary to complete different
sections of the canvas. This is by no means a definitive list, but we hope that some of these tools
will be useful to you as they have been to us, and that it will spark your imagination and creativity
when thinking about how to complete different sections of the Change Canvas.
Urgency
The first section of the canvas that I am going to look at is urgency.
Exploring The Change Canvas In Detail
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
Value Stream Mapping

Value Stream mapping is another analysis technique that is very complementary to five whys.
A value stream map can be developed as part of a facilitated workshop with a group of change
participants, or it can be assembled as a result of several one-to-one interviews. A value stream map
literally maps out the flow of value from a customer request to delivered work product. The value
stream map illustrates the artifacts, activities, and participants in a particular value creation process.
It uses a simple notation that focuses on both value and waste within a particular process.
As the process is mapped out into what is known as a value stream, specific issues and problems
relating to specific aspects of the process are highlighted, and can be discussed. These issues are
often catalogued as a specific kind of waste. Mary and Tom Poppendieck, authors of many books on
software development have defined a popular classification of waste that includes:
partially done work

extra features
e-learning
DOS
delays
switching
and defects
Each activity can be marked with a specific kind of waste, which can serve as a starter for performing
five whys style root cause analysis.
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
Articulate Urgency for Your MVC by Performing Root Cause Analysis

1. Try conducting a deep dive on the urgency section of your canvas with a set of
potential change participants. Either run a workshop and invite all interested parties,
or conduct a number of smaller interviews to support the analysis.
2. Use a combination of value stream mapping and/or five whys analysis to articulate
problems as they are being felt by employees on the ground, their customers, and
their suppliers. Keep working until you can get to a couple of good root causes.
3. Summarize your key findings on the urgency section of your Change Canvas.
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
At a minimum, your change participants should be thought of as customers of the change. As a

change agent, it is your job to serve their needs and help them do their jobs better.
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
Our Example Continued

Looking at our previous example, describing potential change participants for the MVC is as simple
as annotating our root cause analysis with the appropriate people involved.
In this case, the business subject matter expert and business analysts are most impacted by story
analysis related issues, and the developers and testers are being most impacted by issues coming out
of the development and customer demos.
Root cause analysis indicates that the lead developer whos playing the role of a product subject
matter expert needs to be included in analysis sessions.
Locating Change Participants within the Organization

In many cases, change agents will immediately know who the potential change participants for a
particular MVC will be. This is true when the change agent is a member or manager of a particular
team and he wants to improve the performance of that team. Executives and external change agents
running a larger transformation may not be quite so sure when determining who are the first change
participants for a particular MVC.
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.
Associate your MVC Canvas with a Set of

Change Participants
1. If you have not already done so, annotate your value stream map and/or 5 Whys
analysis with impacted change participants. Denote role and/or name of the person.
2. Evaluate specific change participants in terms of their willingness and capability to
serve as a change champion and part of a guiding team for your change.
3. Add the appropriate change participants to your Change Canvas, segmenting by
role, and deciding whether they are directly impacted by the change, or are acting
as some other form of change stakeholder.
4. Consider annotating each change participant to associate them with the problem/countermeasure in the urgency section that is most important to them.
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
Formulate a Vision for Your MVC

1. Conduct a workshop with your recipients to come up with a Vision statement that
is concise, bold and encourages action!
2. See if you can encourage one of your recipients to engage in some visual thinking,
and create a drawing that represents the change Vision. Remember good artistic
skills are not required!
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.
Value Network Design

One approach that we have used on several occasions to help articulate and refine target options is a
value network design. There are a number of eminent leaders within the lean and agile community
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.
Design a Value Network for your MVC for one

Target Option and Summarize on the Change
Canvas
1. Try to reimagine how work could be reorganized when its set up as a value
network. Try to place a cross-functional group of knowledge workers in one core
team with a core responsibility.
2. Scale out as necessary by setting up more than one team, illustrate communication
by placing a teams together as a set of overlapping, concentric circles.
3. Define key interactions between teams, and provide some guidance around the
cadence used to synchronize how value will flow from one team to the next,
establishing a heartbeat of delivery.
4. Consider which knowledge workers should be placed in cross-functional teams
and which should be placed in specialist teams? Are there any trade-offs between
efficiency and agility?
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.
Define Some Actions in Your Canvas to Realize

Your MVC
1. Draw up some actions that will describe tactics used to implement your change.
Evaluate different tactics from both the effectiveness perspective as well as overall
effort.
2. Consider which types of tactics are easier to undo, and which will require more
rework if you need to modify some aspect of your change initiative.
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
Our Example Continued

Again, following the example that we been showing throughout this section of the course, we have
designed a change recipient lifecycle for a team trying to become successful through usage of the
agile modeling method and related techniques.
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
Define Measurable Success Criteria for your

MVC and Place Them on Canvas
1. Taking into account the rest of your change model, define some key metrics that you
can use to evaluate the progress of your MVC. Consider both qualitative/behavioralrelated metrics as well as quantitative/performance-based ones.
2. Come up with some real numbers for each metric, a measure of achievement when
this change is over. Remember, everything that you write down is an assumption
at this point, so its okay to get this wrong!
3. Consider creating a change funnel, so that change participants pass through a IIIR
lifecycle.
4. Review any Improvement Experiments for your MVC, if you have any. Will running
these experiments have a measurable impact on your success criteria? If not, refine
your Improvement Experiments so that they relate to your success criteria.
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
Get Agreement on the Commitment Required

to Make Your MVC Successful
1. Work with your change participants to get clear agreement on the amount of time
they can commit to participating in this MVC. Make sure the rest of your change
model reflects their capacity. You may need to consider a less ambitious change.
2. Make sure to review other commitments, such as meetings, and workshops that
your change participants already have to attend. Is there any way to integrate your
change commitments into those activities?
3. Think about other kinds of commitments necessary to make this MVC successful,
and determine how to source those commitments. Options include executive support
and time, facilities, and software and hardware infrastructure and tools.
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
Benefits listed in the canvas can be both qualitative, as well as quantitative.
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
Outline the Benefits of Your MVC on the

Change Canvas
1. Collaborate with your change participants to outline a set of benefits that will matter
to them. Dont be afraid to be a little ambitious. Remember, we want to excite some
action here!
2. Choose some qualitative benefits, such as morale, improved capability, and customer
satisfaction.
3. Also select some quantitative benefits, such as improvement in lead time, throughput, or reduction in defects. Remember that these are just guesses at the beginning
of a change and will very likely need to be refined over time!
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
Communication channels that weve used in the past include:

Status meetings where we review progress of the change initiative with stakeholders, sponsors,
and others not directly impacted by the change.
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.
Determine How You Will Support your MVC

with Communication
1. Figure out your overall flow of communication. How will you reach your immediate
change participants, as well as other interested change stakeholders? How will you
make sure that they are kept up-to-date on a periodic or continual basis?
2. Consider which channels of communication you want to use. Do you want to favor
directional or bidirectional channels? Ones that require a lot of high touch or that
can scale up to a larger audience?
3. Determine an overall cadence/heartbeat for each of your communications. Will they
be sent out daily, weekly or monthly? On an ad hoc basis?
4. Create an initial backlog of communications that you want to send out.
Techniques to Consider
Keep the following techniques in mind when using the Change Canvas to help execute an agile or
lean change plan.
159
Plan Change in a Cocreative Way

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

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

Where possible, try to favor representing the Change Canvas using physical, low fidelity artifacts
that can be placed in a highly visible place, frequently trafficked by members of the organization.
We want to encourage maximum exposure to our change model and plan, and receive the maximum
amount of feedback from as many sources as possible.
161
Keep the Content of the Canvas Light-Weight and Informal

While the Change Canvas contains all the components of a complete Change model, content within
the canvas should be succinct. We want to avoid getting lost in the details, providing key information
at a glance. Things need to be lightweight if we want to be able to make changes as we incorporate
new learnings over time. The canvas shown below may look chaotic and unfinished at first glance,
but in reality a wealth of information is conveyed, and can be collaborated on in real time.
162
Limit How Much Change You Introduce at Any One Time

When decomposing a Minimum Viable Change into a number of Improvement Experiments, it is
important to limit how many of these Improvement Experiments you introduce to the organization.
It is very easy for change participants to become overwhelmed with change. Negotiate a reasonable
work-in-progress limit that balances the need for improvement with actual capacity for change
within the organization. The Minimum Viable Change on the canvas below has an agreed-upon
change in process limits of three experiments every two weeks.
163
Place the Change Canvas As Close As Possible to Where Change

Participants Work
As soon as a Change Canvas is started, place it as close as you can to where most of the change
participants work. This encourages change participants to look at the model in their own time. We
also want to encourage ownership of the change model by these change participants.
Think Visually, Use Pictures to Enhance Communication

Because the canvas is compact, there isnt room to write a lot of detail. But a simple picture can
convey a lot of meaning. Artistic excellence is not required. Simply the willingness to put things
down in picture form using whatever skills are available! Below is a real-world example where our
client used some visual thinking to help articulate the vision for their department.
164
Agreeing on the Urgency of Change

Lets get started presenting a case study showcasing how a Minimum Viable Change is both defined
and then validated, and finally re-factored as a result of going through this lifecycle. To begin, we
will showcase how a Minimum Viable Change passes through the Agree on Urgency state.
Charlie the Change Agent Has a Job to Do
Charlie is an agile coach whose responsibility is to help employees within his organization be more
successful through the use of lean and agile methods and values. Charlie has been asked by the
CIO of the organization to have a look at the application maintenance team. The maintenance
team is responsible for supporting a complex, distributed solution that provides mission-critical
functionality for the business. The team is having numerous challenges and business customers are
starting to complain. Charlie is tasked with helping the application maintenance group improve their
delivery performance.
Charlie Marks down Some of His Thoughts on a Change Canvas
Charlie begins by taking a stab at putting together a Change Canvas to represent his first thoughts
on what a MVC could look like. Charlie has worked for the organization for several years and has
an idea of some of the problems that the application maintenance team is facing.
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
Charlie Conducts Some Deeper Analysis to Understand How the Application

Maintenance Team Functions and What Their Problems Are
Charlie suggests to the application maintenance team that they spend more time understanding the
current context of this team. He suggests running a number of value stream mapping sessions with
the goal of coming up with a more accurate set of change participant and key problems within a
two-week period.
Charlie prepares and schedules the workshop and then moves a new Improvement Experiment
through the Prepare and I will ntroduce states.
168
Charlie Is Now Ready To Take A Second Crack At The Canvas

After several sessions, Charlie is able to come up with a reasonably accurate value stream map,
outlining major activities including who is responsible for specific tasks.
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.
Support the Progression of a Minimum Viable

Change through the Agree on Urgency State
1. Conduct a set of Urgency workshops with different segments of change participants.
Remember, your objective is to find a group of change participants who can
emotionally connect with the problems that could be solved by an agile or leanrelated change.
2. Conduct root cause analysis with different change participants, paying attention
to which participants show passion, capability, and problem-solving experience.
History with agile or lean methods is also a plus.
3. Form a guiding team, a cohort of change participants that will co-create and co-own
the Minimum Viable Change.
4. Update your canvas accordingly.
Negotiating a Change Solution

Having validated the Urgency and Change Participant section of the Change Canvas, Charlie is now
ready to work with his identified Change Participants to co-create a change solution for the MVC.
171
Charlie Conducts a Workshop with the Change Participants to Collaborate on a

Target Options
Charlie prepares, then facilitates a workshop in the aim of working through different sections of the
Canvas. Charlie hopes to come up with a change solution.
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
Charlie Faces Passive Resistance

During the first negotiate change workshop, it becomes clear that many of the developers do
not want to commit to any decisions that will significantly impact the way they work. Most of
the technical folks are reluctant to agree (or disagree) with any of the suggested Target Options
concepts.
Charlie Discovers Another Set of Change Stakeholders

After the workshop, one of the developers approaches Charlie. He lets Charlie know that the
173
developers really belong to a number of different departments, segregated by system. These

departments each have their own development manager. And it is hard for developers to agree to
any changes to working methods without input and agreement from these development managers.
Charlie adds these development managers as another set of secondary change stakeholders to
the Change Participant section of the Canvas. He then holds another workshop inviting these
development managers, and is able to get reasonable consensus on his suggested approach.
Charlie Is Now Ready to Start Planning Adoption of His Suggested Target

Options
Charlie now prepares for, and then facilitates a change planning workshop with the intent of
discussing what is required to realize this change.
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
Charlie Is Having Trouble Getting Everyone to Engage

Despite the fact that the workshops have gone reasonably well, Charlie marks his improvement
experiment as only partially correct. Some participants in his workshop seemed to be disengaged
from the process. Hes becoming increasingly aware that a core group of Change Participants are
working hard to understand concepts, and help co-create the solution. However, a larger portion
seems to be distracted, and even resentful that these numerous workshops are taking place.
176
Charlie Focuses on His Champions

Charlie decides to segregate his Change Participants into two groups, those that are showing
passion for the change, and actively engaging on shaping it, and those who are more disengaged
and more passive to the process.
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.
Support the Progression of A Minimum Viable

Change through the Negotiate the Change
State
1. Working with your Change Participants, help them come up with a change solution.
Describe various options, countermeasures, and solutions that could be used to
address the problems stated in the Urgency section of the Change Canvas.
2. Take the time to educate various Change Participants on agile techniques, thinking
tools, principles, etc. This may be time-consuming, but will save effort downstream!
3. Design a working model that matches the context of your Change Participants,
balancing the need for change with the need to avoid large disruptions. Try to think
of a combination of agile methods that can provide early value, be consumable, and
pragmatic in the eyes of the Change Participants.
4. Work with your Change Participants to come up with a set of qualitative and
quantifiable benefits. Update the target section of your canvas, summarizing key
points.
5. Define some explicit and measurable success criteria based on these benefits.
6. Come up with a set of actions required to realize the potential Target Options.
7. Based on your actions, outline the commitments required from yourself, Change
Participants, and other impacted stakeholders to make this change successful.
8. Finally, refine your communication model and plan, taking into account all interested parties.
177
178
Validating That Change Recipients Can Adopt

Charlie feels that he has performed enough discovery with his change participants to move
his Minimum Viable Change into the Validate Adoption state. He populates his Improvement
Experiment backlog with a set of tickets dedicated to understanding whether the application
maintenance team can successfully adopt some of the process improvements and Kanban-related
practices described by the Target Options.
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
Charlie and His Change Participants Perform a Change Pivot

Charlie starts working with his change champions to get a better understanding of how work actually flows through the application maintenance team. These change champions have been showing
enthusiasm and a genuine desire to improve performance. What is interesting is that these change
champions are made up of a number of roles. There are a select number of Operational Experts,
Business Analysts, and Developers/Specialists who are showing a mostly full-time commitment. A
larger portion of these folks fall into the other, less interested group.
Charlie collaborates with these change champions to design a simple value network. This diagram
is used to try to get an understanding of the different degrees of responsibility across these folks.
It becomes clear that a subset of the application maintenance team are acting as a virtual team. A
subset of Operational Experts and Business Analysts understand the system from an end-to-end
solution perspective, or have domain expertise in multiple lines of business. A subset of Developers
likewise understand how all the various systems work together from a solution and or integration
perspective. Remaining Operational Experts and Developers are either knowledgeable in one line of
business or one specific system. These people are really only needed on a part-time basis, depending
on the particular aspect of the solution that needs to be changed.
From Dedicated Team to Feature Team
Taking some inspiration from Kanban literature, Charlie looks at a concept known as a feature
team. Charlie suggests creating a core team, calling it the solution team. He works with his change
champions to redefine the role of the Business Analysts and the Operational Experts who will be
placed in the solution team, calling them Solution Analysts. They likewise redefine the role of the
Developers who will be placed in the solution team, calling them Solution Developers.
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
Again, Charlie Faces the Evil of Passive Resistance

Charlie runs a number of facilitated prioritization sessions with Business LOB Representatives who
are responsible for establishing priority. He is shocked by how little progress he makes. His attempts
to create queues and allocate them to different lines of business go nowhere. No one is willing to
step up and say exactly how much capacity they need, nor are any of these representatives willing
to contradict anybody else. Charlie knows that many of these representatives are still going directly
to Developers, bypassing the Analysts, and practicing backdoor politics to get their work done first.
Charlie is also unable to find any one person who really wants to own the role of analyzing metrics
and getting the team into a state of quantifiable improvement based on data.
Charlie is unsure which parts of this change model are incorrect, so he places yellow markers in the
Urgency, Target Options and Action section. He knows he needs to do some work here but is not
sure exactly what.
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.
Supporting the Progression of Your Minimum

Viable Change through Validate Adoption
1. Working with your change participants, define the overall change schedule youll
use to introduce various Improving Experiments as a part of this Minimum Viable
Change.
2. Set up an Improvement Experiment Kanban. Suggest inventory limits, indicating
the maximum amount of change that can be introduced to your change participants
at any one time. Define a replenishment cadence indicating how often youll start
new Improvement Experiments.
3. Create a backlog of Improvement Experiments based on the contents of your
Minimum Viable Change. Make sure that your Improvement Experiments will be
testable and verifiable from the perspective of your success criteria.
4. Begin introducing Improvement Experiments through the prepare, adopt, and learn
lifecycle. As you do so, rephrase Improvement Experiments so that they are in a
testable format that can be verified by your success criteria. Focus your experiments
on validating that your actions are helping change participants acquire new skills
and learn new methods. Remember, performance comes later!
5. Annotate your Improvement Experiments and corresponding portions of your
canvas based on what you learn. Discuss with your change participants, and update
portions of the canvas to reflect feedback.
186
187
Verifying That Performance Is Improving
Performance Is Not Improving Close to What Is Expected

Charlie coaches the Product Owner to do some metric-oriented root cause analysis, and shares this
analysis with the rest of the team to get their thoughts. The bottom line is that while throughput and
quality are improving, they are not receiving the magnitude of order performance improvements
necessary to keep the backlog from growing at a rapid rate. Theres simply too much demand coming
into the system.
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
Production Bugs Are Being Used to Capture Requirements

After a couple of facilitated workshop sessions where defects are analyzed, a number of common
causes become clear. Many of the defects are actually uncaptured requirements. There appears to be
a whole category of requirements that were not captured at the beginning of the project, and as a
result, the solution design needs to be re-factored to consider these features. The current approach
to managing these requirements is accidental and ad hoc. Operational Experts capture these missed
requirements as production level defects, and the team then attempts to fix the system to meet
these new requirements, typically by hacking the system. No one is looking at these requirements
from a holistic perspective to determine overall impact on the system, or whether any refactoring
is required. The result is the system constantly breaks, and never quite satisfies these uncaptured
requirements.
Story Mapping to the Rescue
Charlie discusses this with the application maintenance solution team and suggests that they bring
back in another concept that was retired from the Change Canvas as it was progressing through the
beginning of the Validated Change Lifecycle. Charlie suggests that they reconsider story analysis.
If you remember, Charlie had removed this as a concept from the Target Options along with some
of the other aspects of a purer agile model. His change participants have felt at the time that story
analysis was too heavyweight for maintenance type activities.
Charlie now suggests that they bring story analysis back, including incorporating a technique known
as story mapping. He also recommends adopting some other related techniques such as planning
poker, and acceptance criteria definition. This will help the team group defects into similar themes,
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.
Supporting Your Minimum Viable Change

through the Verify Performance State
1. When you feel your change participants are ready, introduce an Improvement Experiment to adopt practices that allow them to measure their delivery performance
in terms of quality, speed, and/or perceived customer value. Borrow from a mixture
of lean and or agile metrics and reports for inspiration.
2. Once these methods have been adopted, move your Minimum Viable Change to the
final state, Verify Performance.
3. Review your backlog of Improvement Experiments. Do they need to be changed
so that they will be measurable from a performance perspective? Are your metrics
telling you that different improvements need to be introduced?
4. As you move new Improvement Experiments through the Prepare, Adopt, and Learn
lifecycle, make sure you rephrase them into a testable format. This time, relate
Improvement Experiments to any success criteria entries that have quantifiable
metrics. When ready, evaluate these Improvement Experiments from a performance
perspective.
5. Discuss all learnings with your team, updating your Change Canvas and backlog of
Improvement Experiments as necessary to reflect any feedback.
192
6 A Pattern Language for Agile

Change
Planning and managing MVCs using a Change Canvas has allowed our team to recognize a
reoccurring set of agile change patterns. Change agents can look to these patterns when looking
for a source of inspiration when building an MVC. These patterns are represented using the Change
Canvas, providing a visual and compact way to articulate and discuss the different aspects of these
patterns. The patterns listed in this chapter represent a first take at creating this kind of catalog. We
are hoping that other agile change agents will be able to come up with other patterns.
If you have some other ideas, please let me know. Id be more than happy to add them to this book,
with attribution of course.
The Agile Change Patterns Shift the Focus of Learning

Depending on Where You Are in Your Agile
Transformation
When looking at the patterns together, they form a pattern language that helps you focus. Where
youre learning should depend on the progress your organization is making in adopting an agile
A Pattern Language for Agile Change
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
about whether assumptions behind the solution are correct.

As one or more kernel pilots are introduced into the organization, the change initiative switches from
piloting to adopting. A change based on the Kernel Adoption pattern is focused on introducing the
future state using successive, rolling waves. As we uncover more and more understanding of how
the organization accepts change, and what approach is ideal for the organizational context, we can
gradually switch learning from what is the target state, to how we can best facilitate adoption.
This can be a subtle, and permeable distinction. The main point here is that it is okay to spend more
time working with people and really understanding whats getting in the way of facilitating learning
when starting down the road. At some point, we want to understand how to scale out our efforts to
support a sustainable change plan.
Changes based on the Self-Serve pattern is another step in this direction. At this point, we should
have enough understanding about what works in the organization, where we can standardize, where
we cant. We should also understand what parts of our target state are relatively stable, and which
parts continue to change rapidly. This allows us to start figuring out how to publish our knowledge
in a way that the organization can consume on their own with minimal support from agile coaches.
Many change management consultants recommend starting with defining some type of delivery
model and method publishing it out, and getting adoption going. Its really only at this point, but
I found it useful to get thoughts around how the organization is meant to work. At this point in
the transformation, a lot of learning has taken place based on the ground adoption. We now want
to switch our learning to understand how we can push change out to the edges of the organization,
supporting it in a way that creates a self-learning environment.
Changes based on the Capability Modernization pattern are really about cementing the change
and ingraining it into the supporting structures of the organization. New specializations and
competencies are modeled as appropriate using a combination of career ladders, capability models,
job specifications, and incentives. Functions like Human Resources, Finance, and even Legal play a
role, making sure that employees are on board, educated, and compensated according to the new
normal (if there is such a thing as normal for an agile organization).
The Quick Win

Agile and Lean transformation are at their greatest peril when they first start. Quick and tangible
results are a great way to prove the case for larger more ambitious change efforts. Early success
helps mitigate resistance from naysayers, and provides the organization with confidence to invest
further on more ambitious changes.
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.
Leverage Patterns to Build a Minimum Viable

Change
1. When designing your next MVC, consider adapting one of the patterns described in
this chapter. How much of the pattern needs to be modified to suit your context?
2. If running a larger enterprise transformation, consider how far along you are in this
journey, and select an appropriate pattern based on your progress. Have you passed
the Quick Wins stage? Are you ready to pilot a consolidated kernel of the target
options? Are change participants ready to self-start?
3. Are there any other patterns that you can think of that you could add to this
collection? Please talk to me and Ill add them to the book with attribution to you
of course!
205
III Managing Enterprise

Transformations
The third part of this book focuses on how to scale the Lean Change method to support larger
enterprisewide transformations. The first chapter in this part of the book discusses using the Change
Canvas as a Transformation Canvas in order to model and plan an enterprise scale change. Next,
a transformation cadence model is described, showing how a set of meetings, sessions, and
facilitated workshops can be used to create a synchronization heartbeat across the various change
stakeholders of an enterprise transformation.
7 The Transformation Canvas

In previous chapters, Ive talked about how to complete a change model using a Change Canvas.
The focus of these chapters have been on using the canvas to define a Minimum Viable Change.
In subsequent chapters, I showed how we could evaluate the MVC using the Validated Change
Lifecycle. Improvement Experiments provided a mechanism to validate a change; first through
discussion, then by checking behavior, and finally by checking performance.
The kinds of changes that you have read about so far have been aimed at a relatively small
segment of change participants, such as a team, program, or department. When engaged in a larger
transformation, we may want to take advantage of the Lean Change method to plan and manage
this larger transformation.
We have the option of repurposing the Change Canvas for this very purpose. We can use the change
canvas on a very different scale, to support planning for large-scale organizational transformations.
When using a Change Canvas this way, we call it a Transformation Canvas. The Transformation
Canvas can help senior executives who are looking to rewrite the Cultural DNA for their entire
organization, and want to execute large-scale change across the enterprise. During this chapter we
will talk about the Transformation Canvas, and how to use it to manage agile transformations. I will
also show how the Transformation Canvas can be used either on its own, or in conjunction with
Minimum Viable Changes, providing a hierarchical planning process.
The Purpose of the Transformation Canvas

Why Do We Need a Transformation Canvas?
As a quick review of how Lean Change work Sierra so far, change agent work with a cohort of change
participants to execute a set of Improvements Experiments within the context of a Minimum Viable
Change.
A Change Canvas is used to reflect all the components of the Minimum Viable Change, and that
canvas is then validated first through discussion, then by checking behavior, and finally by checking
performance.
The Transformation Canvas
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
A Transformation Canvas Models the Elements of an

Enterprise/Organizational Transformation
Just like a Change Canvas can be used to model the elements of a Minimum Viable Change, a Change
Canvas can also be used to model the elements of an organizational transformation. We call this type
of Change Canvas a Transformation Canvas.
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.
Run a Transformation Canvas Workshop To

Plan Out an Enterprise Agile Transformation
1. First, determine who will participate in your workshop. Try to get as many executive
stakeholders as possible to attend. Ensure that your primary stakeholder and chief
stakeholder also participate. Make sure you also get a good representation from
management, and line staff. Try to find employees within the organization who
are potential change champions, as getting their participation early is instrumental
in any large-scale change.
2. Decide if you need to run sessions for multiple groups; the more participation you
can get the better. Multiple sessions will require much more planning, coordination,
and communication. Results will then need to be integrated into a consolidated
model. This will be a lot more effort but it can pay off in the long run.
3. Conduct your transformation generation workshop(s), encourage attendees to engage in visual thinking, and be open-minded to the art of the possible.
214
215
Traversing the Canvas Based on Risk

Common Transformation Risks
The assumptions contained within a Transformation Canvas can be validated by traversing different
sections of the canvas. The order of this traversal depends on the risk that you want to mitigate. The
big risks to any organizational transformation are really our change risks that we have discussed
before.
The risk that the transformation will fail due to resistance.
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
Traversing the Canvas According to Risk

Each section of the Transformation Canvas contains assumptions that when validated, serve to
mitigate one of these risks. A good practice is to traverse the canvas section by section, highlight
any assumptions and key risks, and execute activities necessary to validating those risks.
Shown below is a Transformation Canvas with each section annotated based on the type of
risk mitigated by exploring that section. For example, validating assumptions behind the change
participant, communication, and actions section of the canvas will help you mitigate the risk of
resistance to change.
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.
3) Implement your change, working in collaboration with your guiding team.
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.
3) Validate the target options, demonstrating your vision.
4) Verify that your transformation is sustainable by validating achievement of success criteria

necessary to making sure change sticks.
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
4) Finally validate benefits by testing organizational performance is actually improving
Traversing the Canvas Across Multiple Risks

In reality, change agents are unlikely to mitigate all risks of one type by traversing the canvas
according to one type of risk, and then traverse the canvas according to another type of risk. It
is much more likely that risks will be mitigated by jumping across the canvas, switching between
risk types. For example, a change agent may start by mitigating change resistance risk through
exploration of the change participant section of the canvas. The change agent may subsequently
choose to mitigate change correctness risk by validating some aspect of the target options section
on the canvas. Finally the change agent may attempt to evaluate change sustainability by validating
an item within the Commitments section of the canvas.
Below is a canvas traversal map that shows how a change agent could execute change activities,
mitigating specific change risks across risk types as he does so. Navigate this map by going through
all the Change activities in row 1, then going through row 2, then through 3 and finally row 4. All of
these activities are identical to the ones shown above in the previous section, but are repeated again
in the order suggested by this map.
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.2) Validate the target options, demonstrating your vision.
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.
4.3) Finally validate benefits by testing organizational performance is actually improving.
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
Come Up with a Transformation Action Plan

Based on Risks Exposed by Your Transformation Canvas
1. Come up with a list of risk types that you believe will continue to resurface during
your transformation. Order each risk type according to severity.
2. Taking a look at your Transformation Canvas, go through it section by section and
outline key risks, prioritizing them against each other based on severity of the risk
type they belong to.
3. Traverse the canvas based on the severity of each risk, and come up with an action
plan that will both initiate change and validate assumptions within the canvas as
you do so, mitigating specific risks.
4. Consider whether any assumptions can be validated through the introduction of
specific Minimum Viable Changes. As an alternative, some risks may be mitigated
through discussion, research, analysis, or other activities.
Prioritizing MVCs For a Transformation

Once an Transformation Canvas has been sketched out and agreed to by a majority of stakeholders,
sponsors, and potential guiding teams, work can begin on suggesting how to implement the change.
One option is to roll out one or more Minimum Viable Changes. Each Minimum Viable Change that
is sketched out should tie into one or more of the elements of the Transformation Canvas.
Change agents often will be faced with the dilemma of which Minimum Viable Change to execute
first. One way to evaluate the priority of potential Minimum Viable Changes is to evaluate them
against each other from the perspective of how much transformation risk they help mitigate.
As mentioned previously, each section of the Transformation Canvas is based on assumptions that
when validated, mitigate specific types of risks. Different sections of the canvas can be validated in
an order suggested by the severity of the risks within that section. One way to prioritize specific
Minimum Viable Changes, is to design them so they expose assumptions of a particular type of risk.
In this way, MVCs can be targeted to validate specific sections of the Transformation Canvas.
One particular Minimum Viable Change may be directed at a highly resistant group of change
participants. Another Minimum Viable Change may ask change participants to adopt skills that
may be extremely challenging to master, risking burnout and a failed change.
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 and Communication
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.
Create a Minimum Viable Change Backlog

That Will Realize Your Transformation
1. Define a set of Minimum Viable Changes that you want to introduce to the
organization that you think will result in realizing your transformation model.
2. Try to design your Minimum Viable Changes so that they expose key risks contained
in a specific section of your Transformation Canvas.
3. Prioritize your backlog of Minimum Viable Changes based on the severity of the
risks that they are designed to expose. Balance the need to achieve early wins, with
the need for early validation of portions of your model that may be particularly
suspect.
8 Enterprise Transformation Cadence

Model
The following chapter is my attempt to describe a set of workshops, sessions, and other reoccurring
activities that help manage an agile transformation at scale. One of the benefits of the Lean Change
Method is that it generates a lot of information. This can also be a drawback of the method.
This information is captured mostly through observation. Captured information then needs to be
analyzed, synthesized, and transformed into action.
Frequent changes in direction can occur as a result, so using Lean Change (or any kind of change
method) requires a lot of discussion, communication, and collaboration. Creating a heartbeat of
change, where regularly established activities can occur at a steady rhythm, makes it a lot easier for
a large, diverse group of stakeholders to stay synchronized. This heartbeat can be designed using a
cadence model, outlining a reoccurring schedule of synchronization activities.
The model that I am suggesting in this chapter is not set in stone, in fact every transformation that
Im a part of uses a slightly (or very) different model. Choose the pieces that make sense for your
team and your transformation.
Overall Cadence Model

Large-Scale Transformations Require A Lot Of Coordination
Organizational transformations can require a lot of coordinating activities. If we look at transformations using the Lean Change method we could see the following:
Individual change agents will collaborate closely with a change participant segment, one for each
MVC being run.
Enterprise Transformation Cadence Model
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
The Need for a Cadence Model

One way to manage the complexity of running a large-scale transformation is to set up some
reoccurring workshops and sessions. The sessions and workshops make up a transformation
cadence model, defining the synchronization heartbeat for the change initiative.
Transformation Cadence Model Information Flow
The example that Ill provide below comes from one of my experiences running a complex
transformation, and the organization had a lot of moving parts.
I encourage you to come up with your own cadence model as the choice to use some, none, or all of
these sessions is left up to the discretion of the change agent team. Care needs to be taken to balance
transformation needs with process complexity and overhead.
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:
Reprioritizing the backlog of MVCs

Refreshing various MVC Change Canvas to ensure that all sections contain valid assumptions
Refreshing the Transformation Canvas so assumptions were also valid
Ensuring that metrics and charts that illustrate aggregate performance, success criteria, and
capability reflect the latest information.
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.
Come Up with Your Own Cadence Model for

Meetings, Review Sessions, and Workshops
1. Determine the overall flow of information for your transformation. Remember no
two transformations are alike, and you need to customize something that works for
you and your initiative.
2. Determine what tactics you want to do to synchronize this flow of data, consider
a combination of information radiators and explicit working sessions to help
update various artifacts, get feedback, and communicate those updates to all change
stakeholders.
3. Select a cadence model that describes the overall heartbeat for the specific activities.
Will specific activities reoccur on a daily, weekly, monthly, or even quarterly basis?
Will these activities take place just in time? Balance trade-offs between effort and
process overhead with the need to communicate progress and enable organization
wide learning.
Change Agent Standup
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
- Too much activity going on at once
- A MVC or Improvement Experiment stalling at
any particular state

Blockers typically are expressed as a hot colored ticket that is placed on the MVC or Improvement
Experiment.
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.
Run a Change Agent Standup

1. Collect your team of change agents, change champions, and anybody else deeply
involved in the change effort, and run a transformation standup.
2. Discuss the status of the Minimum Viable Changes that are currently in-flight,
as well as any Improvement Experiments currently in progress. Focus attention
on specific challenges and impediments, including any work that is stalled, or
assumptions that are invalid. Is there too much change in progress?
3. Assign responsibility to each challenge, have participants engage in an after standup
huddle to discuss countermeasures.
4. Be sure to collect insight, to feed the next key insight meeting.
246
Sponsor and Stakeholder Update
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.
Update Your Stakeholders on the Status of

the Transformation
1. Determine the overall format and channel that you will use to communicate updates
to sponsors and stakeholders of your change. Will you be meeting personally with
all of them? Will you hold one consolidated meeting or several?
2. Figure out the format of the communication, can you use existing information
radiators that are already generated as part of the Lean Change method and/or
existing agile practices, or will you be creating a specific view for your stakeholders?
Balance the need for communication with process overhead.
249
250
Change Agent Planning
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.
Transformations Generate Insight from a Variety of Sources

As discussed previously, this new information can come from a variety of data sources. Change
agents will be discovering new learnings through execution of the Validated Change and Improvement Experiment lifecycles.
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.
Running an Insight and Analysis Session with

Your Change Agents
1. Gather insight from various sources, including any insight collection boxes you have
created.
2. Determine whether youll run the sessions with change agents only, or invite a wider
audience, perhaps including change champions and influential stakeholders.
255
256
Reprioritizing and Changing the MVC Backlog
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.
Update Your Backlog of Minimum Viable

Changes
1. Based on new key insights, take a second look at the backlog of Minimum Viable
Changes. Do any of these need to be changed, reprioritized, or removed from the
backlog?
2. Based on the latest learnings, check if there are any new, unforeseen changes that
should be introduced into the organization?
3. If so, perform options analysis on the suggested change, evaluating the option from
a value and effort perspective. Also make sure to evaluate if the option fits into the
context of the overall transformation.
4. If warranted, convert the option into a Minimum Viable Change and move it into
the backlog.
258
259
Validate and Refresh Change Canvas
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.
Refresh Your Change Canvas

1. Run a working session with your change participants to evaluate different sections of
your Change Canvas based on the success of your previously adopted Improvement
Experiments.
2. Annotate different sections of the canvas, based on their validity, listing each
assumption that is now incorrect.
3. Update the canvas based on the latest thinking, including changing the backlog of
Improvement Experiments as required.
4. Take note of any insight that is generated as part of this process, and bring them to
the next insight analysis meeting.
264
265
Transformation Canvas Refresh
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
Refresh the Transformation Canvas

1. Based on your overall Transformation Canvas refresh approach, update the contents
of your Transformation Canvas. How many people will you include in this effort?
Who will they be? How much time and effort does it make sense to expend?
2. Identify any assumptions in your Transformation Canvas that are no longer correct,
and update your Transformation Canvas as required.
3. Make sure to capture any insight generated, and take note of the Minimum
Viable Changes currently in progress that will be impacted by changes to your
Transformation Canvas.
Update and Share Metrics
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.
Update Various Metrics, Reports and Dashboards

1. Across your team of change agents, determine which metrics, reports, and dashboards are out of date, determining responsibility for getting them up to date.
Where possible, have your change agents play a coaching position, helping change
participants to keep these metrics fresh.
2. Review your overall process for updating metrics. Can it be further automated? Can
we further move responsibility away from any centralized team of change agents to
change participant in the organization?
3. Work with change participants to perform analysis on metrics, generate new key
insight, and socialize with change stakeholders.
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.
This Traditional Thinking Is Suited to a Previous Era, One of

Economic Scarcity
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
Todays Business Environment Requires a Radically Different

Approach
For many organizations today, market success is achieved through offering differentiated products
and services to customers who can and are willing to pay a premium for the latest innovation.
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
Successful enterprises no longer provide a one-size-fits-all offering to their customers. Instead

differentiated products and services are made available to a variety of well researched customer
segments, in some cases products are offered as platforms to be uniquely customized to the individual
end-users needs. Product lifecycles are now much shorter, with obsolescence coming in months,
weeks, and even days.
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.
Agile and Lean Provide a Vision for Success in Todays Complex,

Customer Driven World
Lean and agile are concepts that cover a variety of principles, methods, practices, and perspectives.
Different approaches have unique and sometimes contradictory viewpoints. Nonetheless there are
some fundamental differences between how an agile or lean organization operates and one using
more traditional management methods. Perhaps one of the most important differences is that agile
organizations attempts to achieve business agility by creating a frequent feedback loop with its
customers. Agile methods do this by delivering work in short iterations, where working software is
delivered in iterations that last between one week and one month. Organizations following a lean
approach achieve this feedback using a just in time, pull-based approach, one that limits work in
process to the organizations capacity.
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.
Agile Transformation Is Extremely Hard

Executing on Lean and Agile Requires a Fundamental Shift In the
Way Most Organizations Work
Organizations using traditional management methods rely on detailed planning, command-andcontrol, and a hierarchical structure. Work is processed by departments that employ specialists of a
specific skill set. This work is typically passed across specialist departments in large batches.
By contrast, organizations using lean and agile methods place a much bigger emphasis on learning
rather than planning, and on self-organizing teams who rely on a network structure to deliver
business value. Work is consumed in short iterations, or just in time by teams. These teams are
typically cross-functional, and contain the majority of skills required to satisfy a particular unit of
customer demand.
Organizations using traditional methods can be thought of as an industrial cargo boat or cruise
ship. This design is incredibly efficient, and a lot of cargo or passengers can be carried across vast
distances for a relatively low cost.
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.
Using Scrum to Inspect and Adapt - A Better Approach to Agile

Change, but Often Results in Too Large a Change That Does Not
Fit All Contexts
Many organizations attempting to increase their agility and transform their technology delivery
capability to take advantage of lean and agile thinking have elected to use Scrum. Scrum is a
deliberately minimalistic agile method that is meant to help teams get started with agile, as well
as provide a framework to help technology knowledge workers adapt and improve.
Customer demand is placed into a product backlog, the content of this backlog is primarily the
responsibility of a Product Owner, who coordinates with other business stakeholders to prioritize,
refine, and otherwise groom this backlog. The Product Owner is considered to be the one throat to
choke when it comes to making sure that the right product features are being delivered according
to the desire of business. Work is typically delivered to the end-user in iterations of between five
and thirty days. This iteration is a heartbeat for delivery, and is known as a sprint.
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
with Scrum, and are threatened by this unfamiliar way of working.
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
Kanban - A Viral, Evolutionary Approach to Change Management,

Many Contexts Require Significant Investment and Expertise to
Be Truly Successful
Kanban has been quoted as being a viral, evolutionary change management approach designed to
help organizations gradually become more agile over time.
Kanban is designed to provide an even more gradual way for technology knowledge workers to
improve than the minimalist Scrum process framework. 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.
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
and continuously improve.
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.
The Eight Steps of Change

John Kotter, in his text The Heart of Change describes an eight step change lifecycle, showing a
number of case studies illustrating change agents working with an organization to enable significant
change following these steps. The eight step change lifecycle has been used for over a decade to
help guide large-scale managed change initiatives. Kotter argues that successful change requires
emotional resonance. People being asked to change have to feel the need to change in their gut.
Kotter recommends that organizational change start with building urgency, and institutionalizing
quick wins using a coalition of eager change adopters.
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
team can make the changes necessary to realize the vision.

It is critical that the guiding team structure their change management effort so that they receive
wins in the short-term, and not structure their change management activities so that benefits are
backloaded.
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.

Leanchangemethod PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Leanchangemethod PDF

Caricato da

Copyright:

Formati disponibili

The Lean Change Method

Managing Agile Organizational Transformation Using

Tweet This Book!

The Core Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 Explaining the Lean Change Method . . . . . . . . . . . . . . . . .

2 Managing Change with a Change Canvas . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Building a Minimum Viable Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 The Validated Change Lifecycle . . . . .

II Advanced Techniques and Topics . . . . . . . . . . . . . . . . . . . . . . . . . 113

6 A Pattern Language for Agile Change . . . . . . . . . . . . . . . . . . . . . . . . . . .

III Managing Enterprise Transformations . . . . . . . . . . . . . . . . . . . . . 206

8 Enterprise Transformation Cadence Model

Change Agent Planning . . . . . . . . . . . . .

Who Is the Lean Change Method for?

Focus Is on Practice Not Theory

This Book Assumes That the Reader Has Knowledge of

A Brief Thank You to the Giants Who Have Inspired

A Quick Blurb on Copyright/Legalese

What Is the Current Status of Lean Change?

The Lean Change Method Is Still a Work in Progress

I The Core Method

1 Explaining the Lean Change Method

Managing Agile Change

But Agile Change is Extremely Hard!

Traditional Organizations Are Focused on Efficiency Through

Explaining the Lean Change Method

Explaining the Lean Change Method

Check Out The Appendix for More Information

Lean and Agile Organizations Are Focused on Enabling Learning

Explaining the Lean Change Method

These methods and techniques include:

Check Out The Appendix for More Information

Explaining the Lean Change Method

Switching to Agile Is a Disruptive, Paradigm Shift for Traditional

Managing Agile Change Using Lean Thinking

The Big C Approach to Change Is Risky, Disrespectful, and

Explaining the Lean Change Method

My early forays into trying to improve performance of technology organizations followed a

Explaining the Lean Change Method

Explaining the Lean Change Method

Check Out The Appendix for More Information

The Lean Change Method Allows Change Agents to Initiate a

Explaining the Lean Change Method

Managing Change through the Kotter Eight Steps of

Explaining the Lean Change Method

Managing Change Like a Startup

Organizational Change Is Unpredictable

Explaining the Lean Change Method

The Change Canvas

Explaining the Lean Change Method

Minimum Viable Changes

Explaining the Lean Change Method

The Validated Change Lifecycle

Explaining the Lean Change Method

Explaining the Lean Change Method

An example of an Improvement Experiment could be approximately half of the developers within

Capability and Performance Metrics

Managing Change Flow through Kanban

Explaining the Lean Change Method

Both Minimum Viable Changes and Improvement Experiments

Explaining the Lean Change Method

Changes Eventually Need to Be Measured in Terms of Improved

Explaining the Lean Change Method