Release Management - Making it Lean and Agile

• Integration
• Deliver/Install
• Maintain/upgrade

Perhaps not surprisingly, all of these activities can have an effect on how easy it is to release a product or system.

Lean Software Development Principles

This is a fascinating book by Mary & Tom Poppendieck which I heartily recommend [4]. I also attended a keynote talk by them a few months ago in which they talked about how to " Make More Money " [5] - an attention grabbing title! You do this by increasing the ratio of outputs to inputs, and a key recommendation was to do less work .

She mentioned Jim Johnson (also noted Martin Fowler's summary of the XP2002 conference [6]) on the large proportion of features that aren't used in a software product. He quoted two studies: a DuPont study quoted only 25% of a system's features were really needed. A Standish study found that 45% of features were never used and only 20% of features were used often or always. 65% of features in systems are rarely or never used. A system that has fewer features is likely to be easier to release!

Mary referred to the term "Minimum Marketable Feature Sets" in the book Software by Numbers; Low-Risk, High Return Development  by Mark Denne & Jane Cleland-Huang [7], as a way to conduct your requirements gathering (along with a proposal, theory and metrics for an incremental funding method - IFM ).

Some other concepts from Lean Software Development that are of interest, particularly from the principles of lean thinking [8] and rules of lean programming [9]:

• Streamline your process using value stream mapping - if you track a change request or similar through your development system and record the amount of time it is being worked on vs. the amount of time it is waiting for something to happen, you will typically find most time is spent waiting. For example, waiting for customer reviews can often take weeks to be scheduled. Processes like Agile methods look to minimise this "down time".
• Delay commitment on decisions
• Shorten the customer feedback loop and deliver fast
• Requirements change so you need to manage this.

See Appleton's presentation on "Agile Configuration Management Environments" [10] for some ideas on how some of these principles and rules can be applied to configuration and release management.

Architecture

The architecture of a system is often already defined as part of the business case, but it can have a tremendous affect on the ease of release. Thus the tremendous growth in browser based applications where the only thing that needs to be upgraded is the server. This is in contrast to the greater usability that is still achievable with thicker client applications. Of course Microsoft recognised the major problems that organisations had with installing fat client applications and versioning conflicts inherent in "DLL Hell". Their approach has been to produce the .NET framework with its "xcopy deployment" architecture.

One of the problems in deciding on the architecture for a windows based application at the moment is that developing with the .NET framework requires a 20Mb download for many end users. This requirement alone may negate all the development advantages that .NET brings in comparison to COM based solutions since it reduces the potential market. When are the majority of users going to have the .NET runtime installed, or is the broadband penetration going to be such as to make this less of an issue? (Of course it still won't go away since there will be several versions of the .NET framework out there - you may need to develop for the lowest common denominator).

There was an interesting piece recently in the June issue