Agile Release Management

So teams in your organisation have decided to embrace Agile development for some Projects and/or BAU development and things are going great guns, your deploying code changes and releases in prod every week.

Over on the other side of the fence IT ops are screaming at the various portfolio dev teams for releasing highly risky functionality way too frequently but since the Agile dev adoption production has only had a couple of low priority P4 incidents caused by bad code releases. Things must be looking good with the new dev process but then a few months down the track BAM a P1 incident the Monday morning after a agile delivered release is deployed. Highly important business functionality is broken in one of the downstream systems. It’s all hands to the pump and both IT dev and IT Ops team are getting frustrated with each other trying to resolve the incident holding back blame on which side of the fence caused the incident. A few hours later all fixed and the communication goes out to the business that prod incident is resolved.

Now the fun begins trying to de-construct what happened with the deployment over the weekend. Questions are being asked by management:

• “Why didn’t post verification testing (PVT) pick up the problem?”

• “Was it the test team who screwed up and didn’t do proper regression testing?”

• “Was it a problem with the deployment activities?”

The list of questions goes on until somebody starts blaming the Agile development process for short-circuiting the impact assessment process. Comments such as an impact assessment weren’t required to get floated by the development and test teams. The reason always boils down to “this was a discrete code change we are making to one system and we didn’t know it will impact the downstream system.” Agile is now showing its true ugly side, IT Dev only had 1 week to develop and test this small code release. Documentation was barely existent and the JIRA ticket had hardly any information about the Impact Assessment.

Unfortunately the scenario described above is very common in a large organisation and can be eliminated by enforcing Agile Release Management. Agile Release Management allows for the proper planning, sequencing, completion of system impact assessments and production failure risk mitigation strategies. Without performing Agile Release Management IT Departments are playing Russian roulette with production stability. Tools such as Plutora provide step by step wizards to allow Release Management gatekeepers the mechanism to implement and govern the control of each agile release.

Agile Development approaches such as iterative, scrum and kanban have the benefits of increasing the frequency of code change being released into production but the side effect is that production is exposed to higher risks of failure. Impact assessments and risk ratings of each Agile release need to be managed at a micro release management layer to ensure system impacts are known against up and downstream integrated system.