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.