‘The Lean Change Method: Managing Agile Transformation through Kanban, Kotter, and Lean Startup Thinking’ by Jeff Anderson
Who should read this book?
This book is intended for Agile Coaches. More in general, Change Managers could also benefit from using the Lean Change Canvas, although the explanations in the book all relate to Agile change.
Why you should read this book (or not)?
Honestly, I can’t recommend the book. The style is not entertaining. There is so much repetition (e.g. the car with square wheels is used about 10 times!).
The examples are abstract and do not tell a personal story. In general, the description is abstract and seems rather complex. Almost never did I make so little markings in a book. I recommend you to read a summary instead: e.g. Lean Change Canvas — How to Deliver Change Best • Plays-In-Business. Whether I am right or wrong, I feel not inclined to really give it a try.
Interesting extracts
“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.”
“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. (…)
Change agents start by working with potential change stakeholders to Agree on 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 co-created by both the change recipients and change agents.
Once the change model behind the MVC has been developed, change participants Validate Adoption 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.”
“Both minimum viable changes and improvement experiments are managed visually using kanban systems.”
“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. “
“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.”
“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. We don’t want to make it so small that we wouldn’t 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. (…)
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:
- 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 (ie, 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”
“Writing Testable Improvement Experiments. I try to design my Improvement Experiments so that they contain the following key items:
- 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
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 constraint-
An 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. It’s 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, L.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.”
It’s 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 dojo’s” isn’t as good as “developers will indicate their mastery of TDD after three coding dojo’s.”
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. It’s 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.”