Change management applied to DevOps: a recipe for success

Comfort Zone

Over the course of previous blog posts, we have looked at the different steps and strategies we can follow to implement a DevOps approach in our organisation. We need to keep in mind that the change required within the organisation to implement DevOps is quite substantial and by no means easy. 


Apart from the technical difficulty involved in switching to DevOps, cultural and mindset changes must be taken into account as they relate to people. A change of this magnitude will undoubtedly be met with strong resistance to change.


Resistance to change has always been associated with something negative, but that doesn’t really have to be the case. In fact, resistance to change is the symptom of the change taking place. If this resistance did not exist, it would really mean that effective change is not taking place. What we have to learn is how to manage it.


One of the reasons why changes are difficult and why people resist them is because they force us out of our comfort zone and inevitably put us in a situation where we go from being experts at something to novices. We have all experienced some change being introduced into our lives or our work, and this is something quite normal.


In this post, we will explain a series of models for managing change, and emerging triumphant from it.


Satir Change Model: towards a new status quo

To understand the phases we go through when faced with a change, it is very useful to have the Satir Change Model in mind, usually represented by the diagram below:


Satir Change Model



Normally, when we start with a change, we go through a phase of resistance and chaos that makes us think that, given the initial situation, we were better off without the change we’ve made. Recognising this, we can move forward with the change and complete the transformation to the new status quo. Many change initiatives do not take this into account and cancel the change prematurely, resulting in the change never being implemented and failure. This curve is also called the J curve because of its shape.


Kotter Change Model: 8 steps to change

We’ve decided, then, that we’re going to try to achieve this new status quo by way of a change. But what do we need to do to implement and manage it successfully? At this point, I follow the Kotter Change Model – not strictly, but as a reference. According to this model, to manage a change successfully, eight steps must be followed, as shown in the figure below:


Kotter Change Model



I do not intend to describe the Kotter model in detail, but I do want to comment on how we can use it in our change management process.


For example, in our change for implementing DevOps, the following parallels can be drawn:


  1. Create a sense of urgency: It is important that we have a real, non-fictional, unenforced reason to implement a given change. In the post about the symptoms indicating that your company needs DevOps, we outlined some of the reasons why we would want to implement DevOps. If by identifying these symptoms we manage to create a sense of urgency, we will be able to get started with the change.
  2. Form a coalition to lead the change: In the post about transitioning to DevOps with a dedicated team, what we were really doing was forming a coalition to act as a catalyst for the change. It should be noted that this coalition must be sponsored and supported by the management team.
  3. Create a vision for the change and communicate that vision: for these two points, I use what is termed visual management, using information radiators, change canvases and Kanban boards, both physical and virtual. The important thing is to set clear objectives and use the tools to maximise dissemination of these objectives, as I described earlier in this post.
  4. Eliminate obstacles: this point is related, to a certain extent, to the post on the success of the Theory of Constraints in DevOps, in which we constantly seek out those aspects that limit us in achieving our goal with the aim of managing them.
  5. Create short-term wins: in a DevOps environment, we will be looking to make deliveries as quickly as possible by reducing the cycle time. The post about the use of Small Batches can help us with this because, by making small deliveries, we are guaranteeing very fast successes.
  6. Build on the change: once small successes have been achieved and we have shown that we are on the right track, we need to take a closer look at the change and perfect it through an iterative process. Using a framework such as SCRUM can help here.
  7. Anchor the change in corporate culture: for the change to become established in the company, it needs to spread throughout the order teams and be internalised by them. One of the most useful techniques is "cross pollination", whereby profiles are rotated within the teams. This last point is really crucial since we often find that, when a key leader of a change (an agile coach, for example) moves on, the change returns to its starting point.

        It is not uncommon for changes to last only as long as the change sponsor is present and to disappear when the sponsor leaves the project. We should not underestimate the second law of thermodynamics that tells us that level of entropy or disorder tends to increase over time. In other words, the change is only happening as a result of the work of the agents of change, and when that energy disappears, the system returns to its initial state. Therefore, we need to be aware that maintaining the change is always going to take effort. It is naive to think that, once the change has been achieved, it will be maintained indefinitely.


As we have seen, when it comes to managing the change necessary to transform our company, we can follow Kotter’s model more or less strictly, as best suits our situation. If we wanted to monitor the changes being implemented more closely and at a lower level, we could use other types of strategies such as Lean Change Management, although that is a topic for a later article.


Subscribe to our blog so that you don’t miss any of our articles on DevOps.


is a Project Manager at Xeridia