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!
Latest Articles
Comments on all Articles
