After having given my talk on release strategy in replacement projects on Agile 2009 (here are the slides and paper) I got to thinking about release strategy in general. I find it strange that Scrum is prescriptive about iteration length but says nothing about release length. I believe that release length is more important than iteration length in many projects. Real feedback comes from putting things into production.
Most people agree that one should primarily base releases on business value. Deliver the features that have the greatest business value first. One example of this approach is the use of Minimal marketable features (MMF) as described in the book Software by Numbers. The problem with this approach is that one will often end up with at least one release that is very long. Any release that is more than about three months long risks delivering something that is not aligned with the real needs of the business. The longer the release the bigger the problem. To minimize this risk one needs to look at strategies that reduce the length of a release, even if that means that some business value is lost. The figure below is an attempt to show how efforts to reduce release length should increase in proportion to the initial length of a release. Project B should really focus on reducing release length even at the price of sacrificing some business value. Project A has a reasonably short release length and should primarily focus of maximizing business value.
The point here is not that all projects should have a release length of three months. In some projects the cost of achieving this would be prohibitively large. What is important is that projects with long release cycles should always be looking for ways to reduce it. Delivering “potentially shippable” software to a test environment is only a partial solution.
Johannes Brodwall and I have decided to start writing a book that has the working title: “Agile Release Strategy”. This book will go through the various strategies that can be used to reduce release size. The inherent strengths and weaknesses of the different strategies will also be described. We have set up a wiki that will collect and document these strategies.
If you have been part of a project where release strategy was (or should have been) an important issue we would like to interview you. Just contact me at: email@example.com