Making the Trains Run on Time: Software Release

I recently took part in a  small reunion of folks who worked on the “router  software release” team at Cisco in the early years and I took it as an opportunity to jot down some rules of thumb I learned, mostly the hard way, about managing software releases.

There is always a strong reason to slip the schedule. It can be one more critical feature needed to close a major opportunity or one more critical bug fix that can’t wait for the next release.

Once you start to slip the schedule it’s very hard to stop.

A “train schedule” model, where you establish a predictable schedule and then manage feature content against a fixed ship date, seems like it’s less efficient but I have found it to be far more effective. You can make exceptions for a handful of major features agreed to well  in advance or a very few critical bugs affecting significant functionality for many customers.

In the minds of many developers the release is one more “all nighter” or at worst “a long weekend” away form being ready. Sometimes they are right.

A software roadmap is a complex multi-party treaty, negotiated not only internally between sales, marketing, support, and development but externally with customers  and other interested parties. It’s not a real plan until everyone is somewhat dissatisfied.

The challenges of managing a roadmap are exacerbated by politics in a large organization,  while startups often wrestle with the significant uncertainties  of if and when  prospects, each with their own are needs, are going to close.