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 urgent queue or the backlog of work we haven’t started yet. They just can’t mess with anything we have started. And, they love seeing all the features and fixes piling up in the done queue. With release trains, we have at least a shot of getting releases out to our customers regularly."
When Should You Use Release Trains?
Release trains are great when you need more flexibility in when you offer which features to your customers. They don’t offer you the same flexibility as an agile lifecycle, but they do offer you more flexibility than other lifecycles. What’s really nice about the train concept is the regularity it provides. Because you commit to the trains in advance, you know what to expect, and your customers know what to expect. That means you have more leverage with your customers.
Want to urge your customers to upgrade to your most recent release of your product more often? With release trains, it’s much easier. You build a reputation for releasing reliably—on time and with a quality release—and your customers will upgrade.
In the agile community, we often think of software as a service as product that can be continuously released. But, there are some customers who don’t want to take new product all the time. Just because you can release all the time doesn’t mean you should. Release trains allow you to have that give and take with your customers—to prepare them for the product update that they will take.Release Trains May Allow You to Start Your Agile Journey
If you are one of those teams considering how to start an agile journey, you may want to start with release trains. You can use the heartbeat of the iterations to force yourself to release your product to your customers on a regular basis. Your internal and external promises of working product to your customer may be just the nudge you need to try something more agile than you have been using before.
A note of caution: You may discover that an iteration of twelve weeks is too long and that you need to move to a much shorter, internal timebox for features of, say, two to three weeks to actually achieve working software. Don’t be afraid to use timeboxes inside your trains to achieve the results you need. What matters is that you are able to release working product on your release date so that your trains run on time.
