Software’s process value

Ajay Meganathan

I remember a release planning conversation about when and how to release each roadmap item. The tricky question concerned where we might track these decisions: in our dedicated product roadmap or release planning tool, perhaps, or in yet another spreadsheet.

When choosing between special-purpose software and Just Doing It In A Spreadsheet™, you often reach the following conclusion. You need the flexibility a spreadsheet gives you. Except when you don’t.

Flexibility’s price

At the time of writing, GitHub recently announced their first public roadmap. The roadmap’s guide lists release phases: namely alpha, beta and ga (which look like an odd compromise between an abbreviation for gamma and an initialism for general availability), and gives descriptions for each one. Most people’s spreadsheets don’t include that much documentation. Instead, they waste time in meetings caused by different interpretations of what beta release means.

The flexibility you get from a spreadsheet comes at a price: having to come up with your own terms and process, and then explaining them to everyone else. General-purpose tools provide flexibility; you get the naming problems and documentation problems for free. Product roadmapping software, on the other hand, might already include a release phase field.

Good enough process

The conventional alpha-beta-GA approach probably suits you fine. Unless you expect to get competitive advantage from an innovative release process, you have more important things to discuss. Special-purpose software can address this opportunity by offering a good enough built-in process, giving you time for more interesting problems.

This built-in process may even work better than whatever you could have come up with yourself, or at least what you would have time for. In particular, it may perform better in both its execution and how people learn to use it.

The best kind of documentation

Having decided to plan release phases, we would ideally discover that our software vendor had already thought about that, decided on the name release phase, included tool support, and documented it all.

Off-the-shelf third-party software has the best documentation: OPD - other people’s documentation. You save more time by not having to explain it yourself: the concepts, their names, how to complete tasks, and, significantly, the underlying process.

Other peoples’ documentation tends to have higher quality that what you would write for your ad hoc spreadsheet, in the unlikely event that you habitually add a README or Introduction sheet. In practice, your management team colleagues don’t document their spreadsheets and their presentation slides do they?

Requisite flexibility

Returning to the release planning example, we’d have a problem if our software didn’t give us any way to plan release phases. Even if we happily conformed to the tool’s basic process, we might not accept the software preventing us from planning release phases.

Using off-the-shelf software’s built-in terminology, data model and process does come with a catch: no flexibility at all would lead to unreasonable compromises. The art of special-purpose software, then, lies in figuring out how to provide just enough flexibility to make it useful without leaving you with a process design problem you don’t want.