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.

This articles was originally published on TechWell
 

Trackback(0)

TrackBack URI for this entry

Comments (5)

...
written by Russell Pannone, September 20, 2011

You stated “In the agile community, we often think of software as a service as product that can be continuously released.” This is confusing. Did you mean “…as a service or product…” or possibly “…as a service (product)…”?

• 
• +0
• 
• 

...
written by Johanna Rothman, September 14, 2011

You are correct, agile is not a lifecycle. But some lifecycles can be described as agile. They are all iterative and incremental.

Release trains, even though they are iterative and incremental, in my opinion, cannot be. That is because of the delay in incorporating change, and because they do not make allowances *in the lifecycle* for incorporating customer feedback.

• 
• +0
• 
• 

...
written by Russell Pannone, September 14, 2011

Agile is not a lifecycle.

Agile development is a term that was derived from the Agile Manifesto, which was written in 2001 by a group that included the creators of Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), and Crystal; a representative of feature-driven development; and several other thought leaders in the software industry. The Agile Manifesto established a common set of overarching values and principles for all of the individual agile methodologies at the time. It details four core values for enabling high-performing teams.

•Individuals and their interactions
•Delivering working software
•Customer collaboration
•Responding to change

• 
• +0
• 
• 

...
written by Johanna Rothman, September 14, 2011

Hi Russell. To me, agile also incorporates the notion of customer or customer surrogate involvement. And, with an iteration as long as 12 weeks, that's not fast feedback. To me, that's not fast feedback, so the flexibility is not the same as an agile lifecycle.

Your other question about customers who don't want to take new product all the time: I have a client who sells SaaS who has customers who do NOT want to take new software all the time. That's just one. I'm another :-) I just can't stand it when my browser tells me it's time to stop what I'm doing because it wants to reboot because it's ready with a new version. It makes me nuts.

• 
• +0
• 
• 

...
written by Russell Pannone, September 13, 2011

You stated: “Release trains are an iterative and incremental lifecycle, but they are not agile.” My question is what is your definition of agile then?

You stated: "They don’t offer you the same flexibility as an agile lifecycle".
My question to you why not?

You stated: "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." My question to you is where is the empirical evidence to back up this statement? Secondly, anyone can be agile, work in short time boxes and stage the releasing of the product to meet existing product release cycles. Eventually, over time the organization will adapt to shorter product release cycles.

• 
• +0
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview