Using Release Trains to Get on Track

One problem when you have a program with agile projects and non-agile projects is how to marry the two parts. The agile projects deliver value every couple of weeks. The non-agile projects? Well, it’s possible they don’t deliver value for months to years.

In Managing Programs with Agile and Traditional Projects, I suggested that you start with deliverable-based planning and provide incremental delivery of something. One way to do that is to use release trains.

What Are Release Trains?

When you use release trains externally, you commit to yourself and to your customers to release your product on a particular date every quarter. The quarter is the iteration. If you are a program manager, you can ask your non-agile teams to consider an iteration of somewhere between six weeks and eight weeks. At worse, you can ask your non-agile project teams to commit to an iteration of 12 weeks.

In a program, you are not an external customer—you are internal. Because you are working with project teams–feature teams–you don’t need marketing collateral or training to be ready internally; you only need the software to be integrated and possibly to be married to the hardware. That is difficult enough—you want the non-agile project teams to start learning how to use deliverable-based planning in small chunks, and to focus on what the customer will be able to use.

The release train is not agile, because it takes too long to obtain feedback from a product owner or a customer. However, release trains allow you to manage risk. These teams will likely be using small waterfalls, unless you can convince them to use iterative or incremental lifecycles. But you as a program manager can manage the program risk better with the train because it allows you to obtain those small deliverables periodically. Sure, the deliverables aren’t every two weeks; they probably aren’t every four weeks, either. But they are more often than every six months, and that’s an improvement.

Release trains decouple the releasing of the product from the projects. That is, release trains set their dates in stone in advance, and are often tied to a specific date in the quarter or the month, like a train’s timetable. Then the contents of the train are determined by what the teams think they can accomplish. 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.

Now, in the United States, some trains have trouble running on time. Let’s use the European model of trains running on time here. Figure 1 is what a release train looks like:

release.train

Figure 1: Release Train: Each train releases on the same relative day each quarter.

I am using quarters here because the picture looks better; you could use months as an alternative. You can use any periodic iteration, such as six weeks or eight weeks–as long as you use a consistent iteration, that’s what counts. You are building a cadence here. Between the iteration, you organize the project so that you build in chunk(s), by feature. Often, teams use an incremental lifecycle such as design-to-schedule or a staged delivery lifecycle because they fit the parameters of the release train so well. Some teams who are comfortable with RUP use that.

You could use a Kanban system (see a picture of what one board might look like) to limit work in progress and still make sure features get to done. Remember, it doesn’t matter what lifecycle the non-agile project team uses; it only matters that you have finished features in the codebase by the end of the iteration, when the train is ready to pull away from the station.

A release train does not have the same focus and urgency a shorter timebox has. When your timebox is eight or 12 weeks, other problems can arise and change the backlog for the timebox. Remember, the project team only gets feedback once their train leaves the station.

In programs, committing to a ranked backlog for a train can be tricky. Why? Because life changes for the agile teams, which changes the priority for the non-agile teams. In that case, I recommend you can use a Kanban system for the non-agile team. They take work off the queue, always working on the most important feature. Since they are working in a timebox, does it matter which features they work on? No.

When Should You Use Release Trains in Your Agile Program?

Release trains are great when you need more predictability from your non-agile teams. You may not know what you are going to receive from your non-agile teams, but you will know when you will receive the features. The trains will run on time. If you have a large program that is SaaS (Software as a Service) with agile and non-agile teams, using release trains for your non-agile teams will help your program’s cadence. That allows you as the program manager to reduce risk.

And what about those of you who have long lead-time items, such as hardware of some variety or mechanical engineering parts? Use deliverable-based planning and rolling-wave scheduling, and keep those parts of the program using release trains for their design. When I taught an agile workshop to analog chip designers, we were all struck by how similar chip design was to software. The big difference was in when they went to fabrication–which was the expensive, long lead-time part of the program.

Managing a program of agile and non-agile projects is a fact of program management life; it’s not going to go away. You will need all the tips and tricks to make it easy. Release trains are an old technique, but you can apply them in a new way. What have you got to lose?

This article was originally published on projectmanagement.com

Tags: , , , , ,
Previous/Next Posts
« »

Submit a Comment

Your email address will not be published. Required fields are marked *