Release Management And The "First Rule Of Holes"


Ever hear about the "First Rule of Holes"? It's pretty simple — if you find yourself in a hole with a shovel, the first thing to do is.... stop digging!

That's kind of what it's like in app dev when it comes to release management: We've dug ourselves a pretty deep hole, and it's impacting our overall ability to ship software on time. We recently ran a survey of app dev professionals that confirms what we hear in our client inquiries: Most development leaders are frustrated with slow software delivery and their release management process (see Figure). While Agile speeds software design and development, it doesn't do much to speed up release and deployment — creating a flash point where frequent releases collide with slower release practices.

But some organizations have stopped digging themselves in deeper. They are working with their peers in operations to streamline release management and cutting steps into the side wall of their hole so that they can climb out, step by step. Here are five steps that they are taking:

  1. Investing in improving their pre-build processes. Many problems that occur during a release cycle have their root cause in inadequate pre-build tasks and activities.
  2. Expanding release management throughput. Projects that have large code bases or extensive testing cycles are using parallelism and intelligent testing processes to speed up the early stages of the release cycle.
  3. Optimizing their release pipeline. After taking care of the early stages of the release pipeline, advanced teams are implementing virtualization, parallel testing, and developer self service to further compress their release cycles.
  4. Architecting software for rapid change. Developers like to build software quickly but are not always as attentive to building software that they can change quickly. Improving system modularity and adopting a configuration-based release model can help improve the resilience of the release process.
  5. Creating common release portals. A release portal is a project's “home base”; it's where managers, testers, developers and even business stakeholders go to find out what's in the pipeline and when they can expect updates to the system.

If you're interested in some of the specific tactics that are behind these steps, check out the new research I've published on the topic. 



Hi Jeffrey,
Interesting article - could you tell me how many of your 101 IT professionals were interested in Mobile Release Management processes? At either (1) an enterprise releasing mobile apps to their users or (2) Mobile Handset/Operator professionals releasing devices/apps to their customers?

My hunch would be that your chart would be even 'bluer' ?
(in more ways than one)


Mobile release management

I don't think I could tell you what they were releasing, but I suspect you'd be right. Especially with indeterminate approval periods on some devices - to say nothing of the difficulty of over the air provisioning at this point. I can tell you that 5 of the respondents were in the utility/telco industry classification. Their averages were:

Visibility: 4.4
Automation: 4.6
Flexibility: 5.2
Recoverability: 5.0
Speed: 7.6
Reliability: 5.4
Quality: 5.6

So it appears that these folks can release a lot of stuff quickly, but they're not sure what it is, or why it works and often it doesn't. :-)



PaaS and Dev Ops to help Release Management

Great article – too often I speak to customers who think that agile can be implemented in a silo and the rest of the value delivery chain and for that matter the rest of the organization will just follow suite and be able to adapt to this new way of working, but in both small and in particular large scale enterprises this isn’t the case.

You mention some very practical advice in the post – I wonder if you have any data points on adoption of PaaS and DevOps agendas as they align to:
1. Architecting software for rapid change
2. Expanding release management throughput

I.e. are you seeing more customers looking to align their DEV and Operations organizations in order to “smooth” out the release process in a continuous world and actually taking steps towards doing this, e.g. creating a Dev Ops team, investing in Dev Ops tooling?



Thanks for sharing your

Thanks for sharing your suggestion on improving the release management process. While finding experts on release management, I found your website.

I am now building a release management software and I would like to kindly receive your expertise feedback on the software by trying the beta version. Therefore, could you please visit the project website: and join the beta user list?