Change management and Agile: compatible?

In organizations that have undergone the implementation of ITIL, one frequently encounters a popular practice: Change Management. However, this often cumbersome process raises questions about its compatibility with agility.

Change Management

Change Management is an ITIL practice that mandates a process for securing any change that is introduced into production (software, applications, equipment, hardware, configuration, documentation, procedures, and more).

Generally, there are three types of Change Management:

• Standard: A standard procedure for specific recurring changes.
• Normal: A general procedure for changes that are neither standard nor urgent.
• Urgent: An adapted procedure for changes of absolute urgency.

Any individual needing to implement a change must complete the relevant change type document, including the production implementation procedure, rollback procedure, and all the necessary information to trace the change.

The change is subject to validation by the Change Advisory Board (CAB), which convenes regularly and systematically (except in emergency cases).

For those interested in delving deeper into this subject, visiting specialized ITIL websites is recommended.

Change Management and Agile?

Can the concept of Change Management adapt to agile environments? Could it hinder the acceleration often sought after by companies today?

The core objective of Change Management is to maximize the security of production implementations. However, in my recent experiences, I have quickly observed some drawbacks to this practice.

• Teams often dislike bureaucracy, leading to numerous back-and-forths with the CAB.
• Teams, disliking bureaucracy, tend to hastily complete documents, resulting in a lack of procedural quality.
• The CAB convenes only once a week or even every two weeks, which prolongs delivery times.

While Change Management is intended to bring quality to production deliveries, the final outcome is not as beneficial as expected. The CAB sometimes validates changes without having the expertise to ensure that the described procedure is flawless. Additionally, those providing support, who will be present in case of potentially complex rollbacks, are rarely trained in the intricacies of the various professions they must manage.

Ultimately, the results I have observed in various organizations where I have intervened are quite mixed. Yes, it adds value to the security of production implementations; however, the overall cost of such a procedure questions its application in comparison to the benefits it provides.

It is possible to have a more agile concept of Change Management with a CAB that convenes on-demand; however, in the case of high activity, delays may increase.

Thank You, DevOps, and Craftsmanship

The solution to removing this ITIL procedure lies in the practices of continuous integration and continuous delivery/deployment. By significantly reducing the risk of regression or implementing strategies like chaos engineering, Change Management becomes unnecessary and obsolete.

I highly recommend investing in these software engineering techniques, which, after proper maturation, will allow the elimination of this Change Management procedure.

Please note that Change Management is not a negative practice and provides additional security when an organization lacks the maturity to secure its production implementations. However, for real benefits to be realized, it must be optimized (which is a highly complex endeavor).

In agile environments, it is preferable to transition toward DevOps and Craftsmanship approaches.