Disciplined Agile

Lean Change Management

Lean change management (LCM) is an evolutionary, continuous flow strategy to process improvement that can be applied at the individual, team, and organization levels. In Disciplined Agile (DA) transformations we recommend that LCM be used at the organization level as described below. LCM strategies were developed in parallel by Jeff Anderson and Jason Little.

Figure 1 provides an overview of the Lean Change management flow. As you can see there are three main activities:

  1. Insights. Maintain a backlog/work item list of insights which are important things to understand about your organization, its people, and the type of changes desired. These insights often illustrate aspects of perceived pain points that are impediments to enterprise agility. An example of an insight could be “People have difficulty focusing because they are working on multiple initiatives.”  Insights are often generated via the creation, and evolution, of change canvases or from/to charts.
  2. Options. For each insight various options are identified which might address these impediments. The DA toolkit is a rich and comprehensive source of possible fit-for-context options!  You then weigh each option based on how long they might take, how hard, and what the value of the option might be. What is the organization’s appetite for change? You could play it safe, or be more disruptive. An option to address this insight could be “Move team members to dedicated teams that deliver work from one common backlog.”
  3. Experiments. You then treat each option to be implemented as a small “experiment”, a.k.a. a minimal viable change (MVC). An experiment tends to work through four potential states – Prepare, Introduce, Learn, and Done – which are typically visualized via a Kanban board.  
Lean Agile Management

Figure 1. Jason Little’s lean change management flow (click to enlarge).

Change experiments will work through four states:

  1. Prepare. For each change, ensure that you have done preparatory work to negotiate, schedule, communicate, and to discuss the merits of chosen options with the change recipients. The people who will be living with the day-to-day outcome of the change must be actively involved with the design of the change and must pull the appropriate change(s) into their team. Pushing change into teams greatly reduces the chance that the change will stick. Change recipients should understand that change that impacts them is just an experiment. If it doesn’t work (as they may be skeptical) there will be an opportunity to roll back the change or for them to try something different. For each change write a simple hypothesis for the expected benefit of the change. This is useful to assess if the option adopted is truly an improvement and thus should be adopted, or if the change needs to abandoned.
  2. Introduce. The next step is for the affected team(s) to experiment with the change. Since we are using a lean approach to change, it is important for each team to keep the work in progress (WIP) to a minimum. Working on too much change at the same time means that lots of things are started but nothing is getting done. Focus on a small number of changes and keep the flow of small changes moving.
  3. Learn. At this point we monitor the effects of the change to see if it achieves the expected positive result. This review or “learn state” may be short, just a few days, or may last many months. This is a key aspect of this change management approach, understanding that we don’t prematurely declare success when a change has been introduced.
  4. Done (adopt/abandon). If we consider the experiment a success or failure and we don't need to monitor it as closely, we can move the option/experiment to the “done” status. At this point it is no longer an experiment and you may add further work items to your Kanban backlog to rollout the change to the rest of the enterprise, with the requisite communications, training if required, and updates to other organizational assets such as wikis or intranets.

Lean Change Management (LCM) and Guided Continuous Improvement (GCI)

LCM is very similar conceptually to Guided Continuous Improvement (GCI), as you can see in Figure 2. As we mentioned early, in DA we tend to recommend LCM at the cross-team/organizational level whereas GCI is better suited for team-level improvement. Having said that, both can be applied at individual, team, and organizational levels. A critical difference between the two strategies.

GCI Process

Figure 2. The Guided Continuous Improvement (GCI) flow (click to enlarge).