So, What Is It We Do Again?

One of the fallacies of our Release Management profession is the apparent simplicity. Every software release process essentially works like this:

The devil is in the details. Nevertheless, this diagram is helpful, as it structures our work and helps describe what is being done, and when it's done.

The funny thing is: none of the boxes in the diagram are things release management should be doing. Our job is to ensure they get done, but the doing is usually performed by others:

• Release Criteria are ultimately set by the customer. In most cases, this will be some combination of business development, marketing and product design people who represent the customer. Our job is to collect the input and ensure it's actually written down (lots of opportunity for bikeshedding crop up when debating the difference between functional specification, technical specifications and test plans, but in the end, these are all supporting documents for the release criteria).
• Software is built by developers. We may on occasion assist them by providing good build infrastructure and other support tools, but we're doing this partly out of self-interest. After all, we do need to provide some reasonable guess as to what changes were actually made to the software, so that the next step can be performed based on actual data.
• Deciding whether the software meets the criteria set forth at the outset is mainly QA's job. Our job is to ensure that the people who defined the release criteria don't get involved at this stage. They get their shot after QA fails the release candidate. They can address the failure by relaxing the release criteria - it's their company in the end, but it's important that they take responsibility for it. Our job is to protect QA's integrity by enforcing this process.
• Even shipping itself is not really our job. Our job is to catch or prevent undocumented last minute tweaks in production.

So what is it again what we do?

• We're the umpires of the process: we ensure it's followed and tracked.
• We facilitate the process. We ensure the documents are collected and are transparently accessible to all the players and we ensure that the build and change processes allow proper inferences to be made when making the release/no-go decision.

That's it.

My focus on this blog is on the Build Software box, simply because I consider it the least well understood part of the process and also the one with the most opportunity for data collection and automation:

• The build process is the ideal place to collect change data and interact with the revision control system and various other tracking systems.
• The build process is also the ideal hook for test automation, including a variety of coverage and complexity analysis, again providing supporting data for the release/no-go decision.

It's also in the Build Software box where way too many mistakes are made:

• Not releasing the bits that were tested (i.e. rebuilding for release)
• Blindsiding developers by using build processes that are different from those used by developers.
• Failure to track all dependencies
• ...

But even with the focus on build processes, it is the flow chart above that really matters and at the heart of our job as Release Manager:

• To ensure that all stakeholders are aware of the process and their role
• To ensure that comprehensive and correct data is available when making the release/no-go decision.

Happy New Year!