Rethink Change Management in an Agile and DevOps Era

the-eleventh-hour-1364076_960_720Change Management is probably one of the most unloved IT process. Often seen as bureaucratic, arbitrary and a waste of time, it is also one of the most difficult processes to get right.

Those who have read the initial chapters of “The Phoenix Project” novel will appreciate the fact that, when things go wrong – and sometimes things can go terribly wrong! – the first question people usually raise is “what has changed?”.

If support teams do not have records to tell them what has changed, it is likely that they will need to spend extra time trying to find out the answer before they are able to tackle an issue or address a service outage.

Hence, the benefits of Change Management cannot be measured in itself, but on the positive effects it causes on other areas of the Business and IT.

The fact is that IT people are keen to try out new technologies and configurations and the beauty of many business innovations derive exactly from this constant technical curiosity.

On the other hand, the IT environment is usually complex, interconnected and extremely sensitive. In the IT world, replacing a comma with a dot is all that it takes to cause a system to fail, which makes IT changes quite scary.

In large and complex environments, it is unlikely to find a professional with expertise in all technologies and applications. Hence, depending on a single person to make a decision regarding a change is as risky for that person as it is for the business. High risk changes should be discussed by the Change Advisory Board so that it can be assessed from different perspectives, and the decision, whichever it might be, is shared across all members of the CAB.

Being a control process, Change Management has a natural tendency to become a boring tick box exercise. There are many reasons for this:

  • The process needs to operate within agreed rules, which are usually defined in process documentation. However, once the rules are set and people get used to the process activities, it is easy to forget the reason why these rules and activities were established in the first place;
  • Considering that the process is repetitive and makes the IT environment more stable and reliable over time, people may get a false sense of security and forget that the reason the environment is stable and reliable is because changes are deployed in a controlled manner!;
  • New technology and automation can produce the same or better results than a manual Change Management process. However, these technologies may not be broadly available or may not be applicable to all IT environments, requiring organizations to maintain manual tasks;
  • Service Management tools may not be flexible enough to enable a smooth evolution of Change Management practices, sometims requiring costly customisation and forcing practitioners to follow obsolete ways of working.

It is vital that Change Management practitioners secure part of their bandwidth to question whether their current working practices are still applicable and look for opportunities of improvements both within and outside the organisation they work for. Looking for better practices should be an ongoing activity embedded in a good Change Management setup.

As far as efficiency is concerned, several mechanisms can be put in place in order to streamline Change Management. Some of the most common are:

  • Classifying services and applications according to their importance to the business: This helps Change Management to decide how much effort should be spent on assessing the change and defining the right level of approval required;
  • Creating change models: This consists in developing standard plans for testing, planning and implementing specific types of change. Apart from boosting standardisation and repeatability, these models enable reduction of turn-around times, increased efficiency and highlights the fact that the type of change that being proposed is as important as the service or application that is being changed. This prevents minor changes to business critical services and applications to follow the same costly and lengthy process that a major change would genuinely require;
  • Facilitating change approval by leveraging CMDB information: This consists in dynamically defining change approvers based on the affected CIs, and chasing these approvals automatically. This can be used as an alternative to a meeting to discuss and approve the change.

An area that may become a conflict zone if overlooked is the integration between Change and Configuration Management. Although it might be obvious that a good working relationship between Change Management and Configuration Management is mutually beneficial – on one side Change Management depends on accurate and up-to-date information about the IT landscape in order to perform a reliable impact assessment and ensure changes are approved by the right people, on the other, Change Management can help Configuration Management to identify out-of-date information, trigger actions to get the CMDB updated and monitor unauthorised changes to CI records – defining the correct scope and level for the Configuration Management System is still a challenge, particularly when the exercise is carried out in isolation.

There is clearly a difference between the information required for Systems Management and the information required for Service Management. Technical attributes that are essential for Systems Management are irrelevant for Service Management and vice-versa. Although technical attributes can automatically captured via discovery agents, Service Management attributes like owner, support group and approval group are likely to require some level of manual intervention. The mix of automated and manual updates to the CMDB can create tensions between Change and Configuration Management. The good news is that these tensions can be addressed by frequent connects between practitioners, continual learning and improvement.

Agile and DevOps approaches will also require a major mind set upgrade as far as change approvals are concerned. Change Management has historically focused on protecting the live environment by carefully assessing the best way and time to deploy the change into production and ensuring all stakeholders are happy with the approach. However, in an Agile and DevOps environment the question shifts from when or how to deploy a change to why to do the change in the first place. Addressing this new context entails answering questions like “how this change will improve the business?”, “what is the risk of not doing the change at all?”. This is a shift from “Approval to Deploy” to “Approval to Build” and requires a much more thoughtful and business oriented approach for Change Management. Apart from protecting the live environment, stakeholders will expect Change Management to protect the business from ill conceived changes that do not add value. In this new scenario, once a change is approved, its orderly and controlled progress throughout its lifecycle of build-test-deploy should work like a clockwork, and be automated as much as possible.

Automation will become mandatory. Risk assessment, identification of affected Configuration Items, identification of change collision, adherence to release and maintenance windows, approvals, communication and task management are a few examples of Change Management aspects that will require automated approaches to enable change owners to focus on what is really relevant: the value of the change to the business.

This is a new and exciting era for Change Management, which will require us to rethink the process and look for innovative ways of working to fulfil the new business mandate.


Take away:

  • Change management is there to protect business and people from their own mistakes
  • It is possible to avoid Change Management to become a hurdle for business innovation and a boring tick box exercise
  • Change and configuration can and need to have a happy marriage
  • Moving from Approval to Deploy to Approval to Build will require a mind set upgrade
  • Survival kit: Automation, Automation, Automation

2 thoughts on “Rethink Change Management in an Agile and DevOps Era

  1. Stephen Cull

    Fantastic article, many IT managers just think that change management in a Devops world is just a faster change process to deal with more frequent change, which naturally leads to automation. However, thinking of it as approval to build rather than approval to deploy is the real game changer to the process.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s