The Agile Release Train Explained
by Jane Temov
If your organization is starting an agile transformation, you might be looking at it as an opportunity. Or perhaps you’re looking at it with some healthy skepticism. Either is understandable—or even both at the same time.
The opportunity arises from the fact that various flavors of agile have come to dominate the IT landscape. So, such experience can only help. But the skepticism comes from the idea that a freewheeling series of philosophies and mottos can replace application portfolio management and program governance. And all of the new acronyms, terms, and buzzwords aren’t helping, either.
So today, let’s demystify some terms a little while setting your mind at ease about responsible program management.
Introducing SAFe and the Agile Release Train
First, here’s a brief definition of the important terms this post will cover. The scaled agile framework, commonly abbreviated as SAFe, is an agile software development methodology aimed specifically at the enterprise. More to the point, it answers the question, “How does one scale agile software development across multiple teams?”
The agile release train, often abbreviated to ART, is SAFe’s core means of value delivery from IT organizations to end-customers. The exact structure and nature of the ART will vary by program and organization, but it has common principles and methodological constructs that we’ll dive into today.
Motivation: SAFe and Agile in the Enterprise
With a basic understanding of what SAFe and its ART are, let’s consider the “why” of it before going into more extensive details on the “what.”
Earlier, I mentioned a skepticism that you might have regarding the idea of agile in the enterprise. You’ve probably heard a lot of high-minded ideas tossed around by staunch agile advocates, such as
- Self-organizing teams
- Customer collaboration
- Demonstrated, working software is more important than documentation
- Response to change rather than plans
- Team retrospection and introspection
There is an admittedly halcyon feel to a lot of this. It hearkens back to a time when you could say, “Let’s just forget everything else, start writing code, and figure it out as we go.” It’s a nice sentiment, and it might work for startups or midterm assignments in college Computer Science programs. But as for you, well, you’re skeptical that it can apply neatly to the enterprise, at least as the overwhelming majority of enterprises exist.
And rightfully so.
SAFe exists to bridge this gap. It aims to capture the core value propositions of the agile movement but in a framework that makes practical sense for the enterprise and for large programs. With that in mind, let’s look in more detail at how it works.
The Agile Release Train Generally Corresponds to an Enterprise Program
If you’re looking to locate the ART on a map, so to speak, think program-level.
An ART corresponds to an enterprise program. This means that you’re probably going to be talking about something like 50–150+ people. And they’ll probably be spread across something like 5–15+ delivery teams, not including program management personnel. Of course, programs can be larger than this. But if you have a significantly larger program, you’re probably going to want to think about the program having multiple ARTs.
At the program level, you capture the agile idea of self-organization. SAFe describes the ART as a “virtual organization,” which means that it will decide its own organization and collaboration models rather than being subject to the imposition of these by the broader enterprise.
The teams within the ART generally operate as Scrum teams, within the broader context of the program.
Setting Up the ART
Core to both SAFe and to the ART is the idea of a value stream*. An enterprise program exists to deliver business value to some constituency, and the value stream is the series of actions that the program takes to deliver that value. So, setting up the ART means defining the program org structure and processes that put your business value into production.
Methodologically, this borrows heavily from the lean management concepts. And in lean management, you’ll also find the notion of value stream mapping, which involves designing a waste-minimizing structure for value delivery. Setting up the ART is an exercise in exactly this.
You’ll need to set up roles within the organization. This means defining leadership positions, of course, but it also involves decisions about team composition and the relationships among teams. Will you have groups of similar, cross-functional delivery teams? Or do you need specialized teams for concerns like security and database management? You’ll need to make such key decisions as you set up the agile release train.
Here’s another point of emphasis you’ll have: building out the program backlog. This is where you define the actual work to be done among the delivery teams, and it consists of features (realizations of business benefits) and so-called enablers (supporting work necessary to deliver that business value, such as architectural constructs). Think of this as a program-level implementation of Scrum’s product backlog, aimed at the enterprise. Or put in the plainest terms, it’s a to-do list for the program.
Steady State: Program Increments and Sprints
Once you’ve done the work to set up the release train, it’s time to, well, start on delivery. And once you start to deliver, you’ll understand the rationale behind the “train” in “agile release train.”
Delivery in the ART centers around the idea of a program increment. This is SAFe’s implementation of the general agile concept of a potentially shippable product increment (PSPI). Since SAFe emphasizes the ART and the program, it stands to reason that we called it a program increment.
A program increment lasts for a fixed width of time, typically something like a calendar quarter. And the idea behind this is one that’s core to agile, writ large: tightening feedback loops. Historically, organizations have started on program-level projects and left the entire thing as a work in progress for years, delivering value in one big bang at the end. This product increment front loads IT’s accountability and forces the program to deliver value at least once per quarter.
This is where the train metaphor enters the picture. Every quarter, you plan out that quarter’s worth of work out of the backlog, and you forget about the rest until at least the following quarter. If a feature doesn’t make it aboard this quarter’s “train,” then it has to catch the next one.
Within the program increment timebox, the individual teams behave a lot like Scrum teams. They’ll execute two-week sprints—four to six of them, depending on the length of the program increment.
Operating Principles and Philosophies to Sustain and Improve
At a high level, that covers the mechanics of how SAFe and the agile release train operate. You’ll obviously have to dive into a lot more detail as your program implements the methodology. But that’s the gist.
So having talked about the mechanics, let’s close by understanding the philosophy. SAFe has a series of principles to help guide you as you go. These orient heavily around the fusion of agile and lean methodologies. You should think in economic terms, eliminate waste, tighten feedback loops, and learn as quickly as possible.
But I’d say the most important thing to take away is common both to SAFe and to the agile movement in general. No matter the specifics of your process or your implementation, you should always be actively looking for ways to sustain, tune, and improve your performance, taking nothing for granted.
If you are interested in learning more about implementing an Agile Release Train in your organizations then speak to enov8 about enov8 Release Management. Enov8 RM is a complete platform that takes you across the Release Spectrum form ART (enterprise program centric) through to Implementation Planning (typically project-centric), System Deployment Operations (system and component centric) and Automation.
Time for another coffee, here are some other Release Management articles:
19 MARCH, 2020 by Michiel Mulders SRE vs DevOps: Friends or Foes? Nowadays, there’s a lack of clarity about the difference between site reliability engineering (SRE) and development and operations (DevOps). There’s definitely an overlap between the roles, even though...
06 MARCH, 2020 by Arnab Roy Chowdhury Top 10 SRE Practices Do you know what the key to a successful website is? Well, you’re probably going to say that it’s quality coding. However, today, there’s one more aspect that we should consider. That’s reliability. There are...
20 FEBRUARY, 2020 by Arnab Row Chowdhury Technically, the world today has advanced to a level we never could’ve imagined a few years ago. What do you think made it possible? We now understand complexities. And how do you think that became possible? Literacy! Since...
14 FEBRUARY, 2020 by Michiel Mulders A site reliability engineer loves optimizing inefficient processes but also needs coding skills. He or she must have a deep understanding of the software to optimize processes. Therefore, we can say an SRE contributes directly to...
07 February, 2020 by Arnab Roy Chowdhury Do you remember what Uncle Ben said to young Peter Parker? “With great power comes great responsibility.” The same applies to companies. At present, businesses hold a huge amount of data—not only the data of a company but also...
17 JANUARY, 2020 by Sylvia Fronczak Site reliability engineering (SRE) uses techniques and approaches from software engineering to tackle reliability problems with a team’s operations and a site’s infrastructure. Knowing the history of SRE and understanding which...