Release Management - Making it Lean and Agile

Release Management is an awesome responsibility that plays a vital role in the success of a software development project. Releasing is often considered to be an activity that happens near the end of the process - a necessary evil perhaps, but no more.

What can make our releasing easier? Perhaps not surprisingly, quite a bit - the challenge is to influence the appropriate parts of the process.I hope to provoke some thought and give some pointers to more detailed explanations of individual ideas and references.

What is a Release?

My definition is getting a version of "the system" into the hands of the users, where the system may be one or more executables, web pages or web sites, associated documentation and help, related backend or third party systems, associated support systems, embedded systems, etc. The system needs to be something that works and that performs valuable functionality for those users. A release of the system "on the shelf" is about as much use as a chocolate teapot.

For many internal systems, organisations would benefit tremendously from treating it as a product development for external use, which typically have higher standards applied to them.

Common Release Problems

From the view point of the business, releases frequently:

    • take too long - a new release which misses the market opportunity may miss millions in potential revenue.
    • are unpredictable - one of the best diagrams I saw about the advantages of CMM showed the predictability of project schedules
    • coming down from an average variance of 30 weeks to a variance of less than 4 weeks over a 2 year period as the organisation moved to level 2. One example I have come across is Symbian. They produce the operating system to go in millions of mobile handsets. Software release dates are planned in to schedules including factories making those handsets. The cost of unpredictable or missed schedules is potentially massive.
    • have poor quality - systems with too many support calls and too many bugs. The impact on public trust caused by bad releases can have a very long-term effect. Look at Microsoft's efforts with " Trustworthy Computing " [3] and other related efforts to improve public perception of some of their products (though other factors are of course also present in this case).
    • are not useful - does the system actually support useful functionality needed by the business, or is it mainly technical bells and whistles?

The business typically wants to manage risk sensibly andgain the maximum advantage from releases.

There are many other problems with releases, such as:

    • contents of the release not being planned - the contents are produced in a rather ad hoc manner with all code finished by a certain date integrated in some fashion and shoved out the door.
    • contents unknown and uncontrolled - I have seen many systems where people did not know exactly what had gone in to particular releases. I know of one company producing a fairly widely sold tool where they had very loose "controls" on releases. They didn't know what had gone out the door to various customers, and which variants were in the field. Myriad versions lay around which might or might not have been released. Support and reliability were a nightmare.
    • distribution/installation - frequently overlooked areas, or at least overlooked until too late. A system that can't be got easily into the hands of users and installed on their system is not terribly useful. Upgrade/downgrade are also vital considerations.

Making Releases Easier

Let's look at what we can do to make releasing easier.


As with most things, the better we plan, the better the end result is likely to be. So what activities do we need to plan? Well if we consider the typical lifecycle of software products, it contains activities such as:

    • Identifying the Business case and gathering requirements (market/features)
    • Architecture/Design
    • Detailed Design, Code and Test


About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!