Agile Change Management (How to eliminate risk)

Do you think development teams really update those BMC Remedy tickets with all the changes contained in a release?  They don’t.  Most of them just “check the box” and move on.

They choose a risk level that won’t raise questions from the change management managers and they work around the checks and balances.  The alternative is to stop and wait for a department that still thinks releases are rare events. When a release happens every day there’s just not enough time for people to attend CAB meetings and file never-ending streams of CR tickets. Agile change management can’t keep up with development.

To be an effective Agile Release Manager at many organizations is to master the skill of knowing how to work around change management processes. When someone asks how risky a release is the answer often depends on who is asking.

You’ll hear release managers say things like, “mark every release as a Risk Level 2 so we don’t have to document potential business impact” or “just go ahead and clone the last CR ticket, no one ever checks the CR.”

Agile Change Management: The illusion of governance and have the risk under control

Departments in charge of tools like BMC Remedy understand this and some accept that the change requests entered rarely contain accurate or complete information. For many, the process and ceremony of ITIL is more important accuracy.  It’s governance for the sake of governance, and without accurate CR tickets, it creates the illusion of risk management.  And, from a management perspective, it is a massive waste of resources and a drag on productivity.

When a development team is ready to deploy features once a day, and when a development team has transitioned away from big, monthly releases the distinction between an “emergency” fix, a “minor” release, and a “major” release no longer makes any sense. When developers are singularly responsible for implementing a change and triggering a continuous deployment to production that complex flowchart involving a change advisory board and change coordinator has become irrelevant to the reality of your releases.

On one side of the fence is a development team that is ready to deploy to production multiple times a day.  On the other side is an ITIL-based production control team that looks less relevant every single day because they haven’t adapted to the increasing pace of change. An enterprise experiencing this disconnect has lost track of why changes to production are tracked in the first place.

Bridging the gap to reduce risk

Something needs to be one to bridge this gap. This disconnect between ITIL-based process mandated by large enterprises and the way that development teams operate is getting worse. While many organizations have started to err on the side of enabling development teams they’ve also started to understand that some process is necessary – especially for the largest, most risk-averse systems in production.

When a company uses Plutora they gain the ability to bridge this gap seamlessly with a tool that can assemble information from the tools developers and project managers use with tools such as BMC Remedy and ServiceNow. When it comes time for your developers to perform a daily or weekly release process they can create accurate CR tickets at the click of a button. Issue and story details from JIRA or Rally can be configured to flow automatically into a CR ticket and your change management teams can operate with accurate up-to-date information.

The choice is simple – use a tool that can bridge the differences between Agile and ITIL providing change control with an accurate picture of releases or continue down the path of making change management irrelevant.

At Plutora, we believe that you can have your Agile and practice ITIL-based change management too. You don’t have to accept the inefficient and inaccurate state of change control in your increasingly agile software development organization, and you don’t have to keep on sacrificing a release manager to manage the change control process.

Keeping the systems that manage software development in sync with systems that track changes to production should be as continuous and automated as the continuous deployment and integration pipelines your developers are starting to implement, and no one should have to lie on a CR ticket to work around a broken change management process.