Is IT Change Management and DevOps in conflict?

Is IT Change Management and DevOps in conflict?
How is it possible that continually deploying fast and often using DevOps methods doesn’t cause more issues?
This is a question I’m asked frequently especially from IT Change Management colleagues who have spent much of their career fixing and reducing the occurrences of outages.
Established IT Change Management frameworks are in place to help reduce the risk of an outage when a change is planned. For example a request to make a change that poses a risk of impact and failure must go through a level of rigour and governance prior to be deployed. In general there are standard lead times before a change request can be deployed.
So isn’t deploying multiple times daily a conflict with IT Change Management?
This is often a heated topic when introducing DevOps practices into an IT environment.
Our missing variable in this debate is the risk of an outage. In order to address this conflict between 'IT Change Management controlling risk' and 'DevOps deploying often' we need to ignore the tactical side of reducing risk (looking at the steps involved in the change itself) and take a more strategic view by looking at our overall technology.
If we modernise our applications so that we can make changes frequently without causing an outage then it is safer to continually deploy with less need for high risk Change controls.
This is achievable through-
Making every aspect of our solution as modular and as interchangeable as possible.
Automating all our steps for deployment ensuring we can roll back in an instant.
Empowering our DevOps team so no other team or 'handoffs' are required.
Our aim is to have a highly resilient technology foundation that can be modified often with little risk and that is also supported by the one team who is able to deploy both often and fast.
IT Change Management is still required to provide controls over high risk activity. Deploying often can now be performed with little risk and is more acceptable from Change Management.
Would love to hear how you have balanced IT Change Management whilst introducing DevOps methods. Just send me a message or leave a comment below.
------------------------------------
change management,devops,it change management,it change management and devops,,change management process,it service management,change management and devops,itil change management,change management plan,project change management,devops release management,change management training,change management tutorial,change management fundamentals,change management certification,organizational change management,devops and service management

[@michal4561]

So i assume the solution would be to push your stories towards change management at the sprint planning stage in the form of standard changes and if they are of significant impact using a normal change template with all the bells and whistles. But what about rollbacks, do you use a standard change rollback as well? What is the balance (i personally don't believe in change enablement as a replacement for change management as you will have a ton of more paperwork for your audits)

[@ittransformationfaq]

I think the main point is we architect our solutions so there are hardly any scenarios that could have a significant impact. Change management is still required and there should be many low risk changes which by their low risk nature should require less paperwork.

[@mty1966]

Are you saying the prerequisite for change management to adopt DevOps is for example the adoption of agile in the development team, application software architecture change, technology change, etc?

[@ittransformationfaq]

Hi, it could help but adopting agile isnt a prerequisite. The key for this topic was deploying fast and often doesnt need to be in conflict with Change Management controls which are designed to reduce the risk of impact. If the underlying technology is modernised in a way to reduce risk constant deployments could be a regular occurrence as a low risk change.