Not every organization is prepared to dive into the swift, short iterations of agile, but that doesn’t mean the organization isn’t ready for a change. Johanna Rothman suggests looking to an iterative lifecycle called “release trains” as you begin your journey.
A colleague was looking for a way to move toward agile but not really transition all the way. “I don’t think we’re ready for two- or three-week iterations,” he said. “We want to move a little more slowly than that. But, we do want to do something more agile than waterfall. And, we want to help our customers move toward taking more frequent releases. They aren’t ready to take a release every month, even if we were ready to release that often. Is there some sort of middle ground?”
Release trains are that middle ground. When you use release trains, you commit to yourself and your customers to release your product on a particular date every quarter. That’s the iteration.
What Are Release Trains
Release trains are an iterative and incremental lifecycle, but they are not agile. The iterations are typically twelve weeks long (a quarter), but sometimes they are as long as a half-year or as short as six weeks. In the iteration, the project team builds chunks of working product. At the end of the iteration, the team releases the product to the customer. The train has a timetable, always leaving the station at the same time every quarter. The team commits to itself and its customers that it will deliver working product every train and that the train will not be late.
Maintaining that heartbeat—that timebox—is key to the success of the release train. You can de-scope features from a particular train, but you can never allow a train to be late. That helps the project team focus on delivering value and helps your customer become accustomed to taking the product on a more frequent basis.
Release trains decouple the releasing of the product from the projects—that is, release dates are set in stone in advance and often are tied to a specific date in the quarter, just like a train’s timetable. Then, the contents of the train are determined by what the team completes. When a feature is done, it is eligible to be released. Release trains never extend the timebox, just as trains never change the time they leave the station. (In the US, trains rarely run on time. I am told that trains run on time in Europe. I’m using the European model of trains running on time here.)
Figure 1 is what a release train looks like.
Figure 1: Each train releases on the same relative day each quarter.
For each iteration, you organize the project so that you build in chunks. Often, teams use a design to schedule or a staged delivery lifecycle because it fits the parameters of the release train so well. You could use a kanban system to limit work in progress and still make sure features get to done. And, yes, some teams that are ready for agile do choose an agile lifecycle for each iteration, just to ensure they make the train with completed features. The key is that the codebase only has finished features at the end of each iteration.
A release train does not have the same focus and urgency a shorter timebox has. When your timebox is twelve weeks, other problems can arise and change the backlog for the timebox. If your management has trouble committing to a backlog, a release train can be tricky.
Here’s what one project manager said:
My management must have ADHD. They can’t commit to anything for longer than thirty minutes. But, that just means we use a kanban system, not a timebox, to organize our features inside our train. They can futz around all they want with the