David, at 37signals, writes an interesting post about changing the way their company is managing the naming of new versions of their Backpack information manager product.
David starts with the premise that there is too much feature-creep when scheduling deliveries of software updates.
We’ve previously tackled how to manage this prioritization process via scheduling of changes and managing iterations with timeboxes.
David’s approach to this problem is refreshing – he has provided an out of the box way of solving the problem.
With 37signals’ approach, an update to the software has a major element. We can think of this as the scheduling of a market requirement (or collection of use cases) that provides additional value to the users. This specific focus aligns with our approach of using use cases to communicate delivery schedules.
David’s insight is that once you schedule a release, say 2.1, then other features will try and get themselves included in that release. When I read this, I immediately thought of the riders and provisions tacked onto “clean” bills as they pass through congress. Each little bit satisfies a splinter-group or contingency, at the expense of “more important” stuff.
Imagine if people decided they didn’t want to accelerate the time table on their pet project / feature. That’s what David is doing.
The next release of Backback is titled “Widget Overhaul”, not “2.0.” Suddenly, there’s a lot of clarity about what to include in the next release – overhauled widgets, and not much else.
In a web-release world, this is awesome. In a world where legacy versions of an application will coexist with the latest version, this approach falls down a little (but the idea is still good). Imagine a user calling in for support, and telling the IT guys that he’s running the “Improved Security” release. The IT guys suggest he try upgrading (or is it downgrading?) to the “Improved Performance” release.
There’s a benefit to having a clearly sequential element in the naming of releases. But, as David points out, it comes at a cost – of people adding features until a release is too delayed or too expensive.
How do we get the same benefit with distributed releases? Another approach would be to use dates, for example, the 20060815 release, in conjunction with the benefit-naming approach. Or build numbers.
Identifying a headliner release element is a great idea. Thanks David!
Becareful with the date release numbers. If this is the “April 10th” release does it have to be released on the date April 10? What if it slips to April 11? Do you have to change the release name? From personal experience date orientated release names suggest it should be released on that date. And I think we all know that sometimes you miss dates.
Aaron, thanks for reading and commenting!
I completely agree about the risk. One possible approach is to manage code development with a combination of continuous development techniques and good branching practices (like those enabled with subversion).
I’ve had the pleasure of working on and managing a couple projects that were maintained in a “release ready state”, where on any given day, we could release the trunk version of the code (it passed ALL automated tests) – the only question was content. A feature is not promoted to the trunk until it passes all of its associated tests.
With this approach, you can always hit the date, but occasionally have to adjust the content. Just a matter of which dials you want to turn.
Hey Scott,
I agree 100% that if you are already doing CI and have an always working product that the date thing works. But…if you already have excellent engineering practices such as those in place, then the debate about which functionality goes into a release more than likely will be a very short debate.
Cheers!
Actually, the convention fits nicely in the way releases should be handled within RUP. For every release a problem statement and a product position statement are developed AND agreed upon between all stakeholders of the project.
The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved.
The product position statement is the “mission statement†for the system to be built (the solution). The product position statement is a vehicle for communicating a brief definition of the system to all stakeholders (definitions from safari).
The problem statement and the product position statement are excellent tools to use in the CCB (Change & Control Board) who decides on including or excluding new features in the (next) release. Both statements are documented in the RUP Vision document.
If you have a hard time defining these statements, you will definitely have a hard time with scope-creep. Now you see why!
http://hij2mc.wordpress.com/2006/08/21/handling-feature-creep-on-your-next-release/