While looking into IT Service Change Management, and primarily in accordance with ITIL, there was one thing that stood out. There seems to be a disconnect between the the development point of view and how change management is implemented by operations. With that I mean that the implementations I have seems to be more applicable for finished product than with software developed in house. The change management processes works when a change is either adding a new product or installing a new version. When it comes to full software development, the change management process gets fuzzy and drawn out. This gets even more distinct when looking at the more agile or DevOps ways of working of development.
That said, while reading up on ITIL I see no reason why that should be the case. There does not seem to be any innate reasons why the change management process should hinder the agile or DevOps development processes. Both have a focus on ensuring the best way of working by focusing on the outcome and improving it through reviews or retrospectives.
My take is that both methods have an inherent focus on minimizing the risk in system development. The approaches are however different. To show this we first have to look at the definition of risk. Most literature define risk as the product of likelihood and impact. Traditional change management have a focus on the likelihood part of risk. Through testing and analysis the likelihood of a change impacting the production environment is reduced.
DevOps on the other hand focuses on minimising the impact by making small, revertible changes. When something goes wrong the main goal is to use the swiftness of the dev team to revert or fix the issue as quick as possible.
This miss-match is likely one of the reasons conflict often arise between development organisations and operations. This observation might not be a quick fix, but I think that if we observe the expectations of our counterpart we can get a better understanding helping us to create a way of working that fits our organization. When we see that we have the same goal (reducing risk) but different approaches we also get a common language to reach that common goal.