Release Train? Or Release Metro? What cadence works for you?

We have all heard about the Release Train as a concept for managing agile at scale. It's a pretty good metaphor. A train leaves the station according to a set timetable. The passengers fill up the train when they are ready to depart and if you arrive late, you miss the train and catch the next one. Software releases under a release train work the same way - the train leaves the station (releases to production) according to a set timetable. While waiting, the train gets filled with completed features and if a feature arrives late, it waits for the next train.

Not a bad metaphor, and, for some businesses, not a bad way to organise a release cadence either. However, for other businesses, a release cadence like that is not appropriate. It may be too fast. Or too slow. Maybe what you need isn't a train, but a metro. On a metro, smaller trains arrive and leave so frequently that no timetables are needed. Just turn up and hop on the next train. Or is your release more like an ocean liner? Their arrival and departure is large, infrequent and marked by a lot of fanfare (and more than a little cursing by those doing the hard work of steering the thing in).

The thing is that no one cadence is appropriate to every situation. Businesses have different needs. For many businesses, the release train is appropriate. A release every 3 months or so is fine. For others though, 3 months is way too slow. For a business in the online or mobile app space, a 3 month release cycle would be commercial death. For them a metro makes more sense. Small releases delivered very frequently. Maybe every day.

What about more frequently than that? What about the moving pavement so beloved of early science fiction authors? Just step onto the moving road at any point and it whisks you to your destination. No waiting at all. In the IT industry we call this continual delivery. As soon as something is checked in, it runs through its automated tests and goes straight in to production (provided everything passes, of course). If you are in a purely digital business, this may well be an appropriate cadence for you.

In the agile community we have become somewhat obsessed with the idea of faster = better. For feedback this is certainly true. For production releases it may not be. There are many businesses where faster releases would be detrimental. If you look at industries whose customers have high upgrade costs, more frequent releases will increase costs to their customers. Those who have only ever worked in online businesses find it hard to understand upgrade costs. Surely you just install the software and away you go? Script it up, and if it takes more than 5 minutes, you are doing it wrong.

Imagine now a large factory with a control system in it. The control system might talk to many thousands of sensors and machine controllers. Whenever you are controlling the physical world through your software, things change. Each one of those connections must be re-tested after an upgrade. You can do as many simulated tests as you like, but you must re-test each and every physical connection in the field just in case it's wired up slightly wrongly and that causes something unexpected. What's wrong with unexpected? Unexpected in an online shop might be a product missing from a shopping cart. Unexpected in the case of a factory control system might be a giant machine moving at the wrong time - like when the operator is loading something into it. Upgrading a large factory can take weeks and every day that factory is off line for upgrade it may be costing millions of dollars. You just don't go out and upgrade these systems every week or so. If you can get an upgrade in once every few years you are doing well. Many factories get installed, then never upgraded at all for their 20+ years of life.

Or think about a hospital. Many of the software systems there are safety critical - patient health depends on them. Each time you upgrade them, all the medical staff must be re-trained and re-certified on the new version. That exercise can cost millions for a large facility. There are some businesses that just can't handle frequent releases. For them, the ocean liner model is a more appropriate cadence - large, infrequent and accompanied by a lot of hard work to get the thing docked.

They key is to pick a release cadence that matches the needs of your business and customers. Don't assume that more frequent releases are always better.

While frequent releases to customers may not always be better, faster feedback is always better. The faster we can get feedback from stakeholders and customers, the more likely it is that we build the right thing to meet their needs. So how do we balance the need for fast feedback with the need for a slow release schedule? The key is to separate the two. Do fast releases internally for stakeholder feedback but don't make them production releases. Make them release ready, just don't release them. This way we get fast feedback and release becomes a business decision rather than a technical constraint. As soon as the business thinks there are enough new features delivered, and the customers are able to absorb a new release, release it. You can also make every release a customer release, but only for new customers, or those who are ready for an upgrade - everyone else continues to run on the old version. Or make each new version available for customers to download, test and comment on (fast feedback) but not necessarily install into production. They can do that when they are ready. There are a bunch of ways to maintain a slow release schedule and a fast feedback cycle.

The main message here is that you need two cadences - a feedback cadence and a release cadence. These may not necessarily be the same. The feedback cadence should be as fast as possible. The release cadence should be what makes sense for your business, whether that is fast or slow. Don't assume that you need a release train. Maybe you need a metro, or a moving walkway, or an ocean liner instead.