Lean Change Management: The key to managing change in your organisation

Lean change management

In our previous post, we described how to learn to manage change in our transformation towards DevOps. That first article focused on describing the Satir and Kotter change models and sought to explain the different steps that change processes go through.


In this post, we are going to discuss how to effectively implement specific changes using the Lean Change Management model. This change management model is described by Jason Little in his book Lean Change Management: Innovative Practices For Managing Organizational Change[1] and provides a framework for successfully implementing change initiatives.




What is the Lean Change Management model?

This model can be described using the following diagram:

Lean Change cycle

We will briefly describe what the Lean Change Management model involves, and then we will look at how to apply it in a specific example. The aim of this article is not to carry out a comprehensive analysis of the model, but to highlight the important points that will help us understand it.


  • Insights: Any change process begins by determining the system’s current baseline situation. What we are looking for at this stage is to understand what is really going on within the organisation, with the aim of trying to identify problems or shortcomings and obtaining as much feedback as possible. To do this, we can use different techniques such as informal meetings, interviews, surveys, retrospectives, etc. We can leverage any tool we want to obtain this feedback. Personally, I find informal meetings held with teams and at different levels very useful.


  • Options: From the insights obtained in the previous step, we can identify the options that could be implemented. It is important to assess the balance between cost and value at this stage, in order to determine the viability of the different options identified.


  • Experiments: It is at this point that the experiments or minimum viable changes (MVCs) are designed. An MVC takes its name from the concept of Lean Startup MVP (minimum viable product). In this case, an MVC is the smallest and least intrusive change that we need to introduce to test our hypotheses. This approach, based on testing or proving hypotheses, is also characteristic of the Lean Startup model, in which nothing is taken for granted. Instead, everything we know is based on proven hypotheses or actionable knowledge. If we think about it carefully, this way of operating is nothing more than implementing the scientific method.


Once we have designed our MVCs, we move into the implementation phase of the change, which is divided into three distinct stages: prepare, introduce and review.


  1. Prepare: In the Prepare stage, the experiment is designed, and different visual tools are used that will help communicate the experiment. These tools might be a Kanban Board to manage the activities, or a Change Canvas. 
  2. Introduce: This is the point at which we work on the change. Meetings are usually held in front of a Scrum-style Kanban Board. Keep in mind that during these meetings new Insights may emerge that feed the model and may make it necessary to pivot the change, i.e. change direction.
  3. Review: As the change is implemented, we need to review how it is performing in order to validate the experiment’s hypotheses. It is important to take into account the measures associated with the experiment and the time at which the change was designed to be implemented. It is during this stage that we review whether our change has been successful or not.


In a nutshell, this is the basic cycle presented by Lean Change Management for implementing changes. This cycle is described in more detail in the previously mentioned book by Jason Little, which I recommend you read. At this point, I would like to focus on the key element of the model, the Minimum Viable Change or MVC.


What is a Minimum Viable Change or MVC?

As I mentioned earlier, an MVC is the smallest and least intrusive change that we need to introduce to test our hypotheses. It is important that this change is small so that the overall impact is not huge, but it must not be so insignificant that it has no effect at all. This is difficult to assess, and we need to take into account who is going to be affected by our change and how it is going to affect them. We often introduce a change that is too big. And it fails. Not because it was a bad idea, but because the impact it has is significant. This can prevent us from moving beyond the resistance or chaos phase (remember the Satir Change Model).


To design a good MVC, we need to remember that it must have four components:


  • Hypotheses: We need to define the hypotheses that need to be validated for the change we are considering.


  • Measures: To validate the change’s hypotheses, we need to define what we are going to measure and how. These measures must be unambiguous and as specific as possible. We need to bear in mind that the success or failure of the change will be determined based on these measures.


  • Change recipients: Our MVC must clearly define who will be affected and then communicate it to them. If we fail to do this, the likelihood of success will decrease.


  • Implementation time for the change: We need to define when we are going to implement the change to ensure it will be successful. At this point, we need to keep the Satir model in mind to avoid abandoning the change prematurely.


Example of a change using Lean Change Management

So far, we have described the Lean Change Management model. Now let’s look at a scenario that uses the model.


Suppose that an organisation is having problems with deployments to production (this is one of the symptoms indicating that your company needs DevOps). Following the model, the first thing you need to do is to identify the insights to determine what the current, real situation is. To do this, you can hold meetings with the departments involved, talk with those in charge, arrange informal meetings, conduct surveys, and so on. From the findings of these activities, different options can be identified. For example: start using a Kanban board for production changes, use Scrum, automate the deployment process, automate the validation process, etc.


Once the options have been evaluated based on their cost and impact, one option is selected and an MVC is designed. For example, you might choose to automate the deployment process using a language designed for that purpose such as Ansible, Puppet or Chef.


We could define the MVC as follows:


We establish the hypothesis that using automatic instead of manual deployment, we can reduce the current cycle time by 50% and totally eliminate manual errors. This change will mainly affect the Development and Operations teams and will be effective after 4 sprints of 2 weeks (two months).

From this point on, we will work on the change following the prepare-introduce-review cycle.


Final conclusions on Change Management

In the two articles dealing with change management, we have seen how to apply the Satir, Kotter and Lean Change Management models. There are other models that are just as effective. The key point is that, when introducing changes into an organisation, it must be done in a coherent and rational way. Many initiatives fail to take factors like these into account.


At Xeridia, we have seen how customers who adopt agile frameworks and overcome the resistance to change in their organisations achieve a significant advantage over their competitors, making substantial improvements in all their processes. Learn more about our agile frameworks and start managing change in your organisation now.



is a Project Manager at Xeridia


[1] Little, J. (2014). Lean Change Management: Innovative Practices for Managing Organizational Change.