I’ve always had trouble with the poachers wanting to be in charge of the gamekeepers. We see it all the time: developers wanting to control the code repository, the PMO wanting to decide what goes in the release. But my favorite is the application delivery team wanting to own release management. It’s not right and it needs to stop.
Now I know what you’re thinking: I’m all good because we made it part of the service delivery team a decade ago. Well, you got it wrong too.
OK, so if release management doesn’t report to apps and it doesn’t report to ops, whom does it report to? Answer: the CIO, or at least it should in my view.
But before we can get there, we need to rethink the purpose of release management. For many organizations, release management has become a board-level discussion. The business has time-to-market imperatives that IT is just not satisfying. Application delivery wants to implement more agile ways of working, but the too-infrequent release windows stymie their ability to get perfectly good code out. And the data center is drowning not just in software changes but also in hardware and infrastructure changes, and they need to stem the flow so they can take a breath and understand the impact of all this change.
But we have to accept that change is going to happen. It is going to be more complex and contain more risk, and the cadence of release is just going to continue to increase in tempo. I have a customer who releases four times a day, and I read that Facebook releases three times an hour. Having four release windows a year might have been acceptable last century, but it isn’t anymore.
What is it that the operations teams need that they are not getting, and what is it that the application delivery teams are doing that overloads the system?
In my experience, there is a very long list of maladies that are surfacing as full-blown business-critical problems now that the squeeze is on release management. I’m sure in your own organization you have your own list, but here are just some of the issues that make release management a battleground:
Software quality is terrible. I know that we have had a focus on quality for decades now, and we have created vast departments of testers and armed them with world-class tools. But the truth remains: Initial build quality is unacceptably low, and developers do too little unit testing and are allowed to get away with delivering code that has had no rigor applied to prove it. And this is because they are under the time-to-market pressure.
Everyone is rightly business-focused, but we are just not putting code out that is good enough. Why do we give the automated test tools to QA? Make the developers get 100% rates from automated testing before they give it to QA. The QA team did not put the bugs in the code, so they deserve to get better-quality code when it is delivered.
Releases are too big. We have got into the habit of making releases that are the size of the Titanic and are likely to go the same way. These massive releases contain every last item the business analysts, project managers, release managers, architects and developers can squeeze into them. The releases end up having massive prerequisites and co-requisites, contain dozens of requirements, and hundreds of change requests that result in thousands of code changes.