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.
In this post, we’ll talk more in-depth about the Agile Release Train covering the following:
- SAFe and the Agile Release Train
- Setting Up The ART
- Program Increments And Sprints
- Operating Principles And Philosophies
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?”
There are 4 core values of SAFe:
- Built-in quality
- Program execution
Having understood what SAFe is in brief, let’s dive into agile release trains.
What is an Agile release train?
The agile release train, often abbreviated to ART, is SAFe’s core means of value delivery from IT organizations to end customers. 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. 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.
Which are the major ART Agile Release train roles?
You can find the following major roles in an ART:
- Release Train Engineer – Leads the ART and is responsible to provide the resources for ARTs to deliver their tasks.
- Scrum Master – Makes sure that the teams are on track via meetings, processes, and guidance.
- Product Manager – Responsible for the value the agile team produces. The main goal of a product manager is to make sure that the ART follows the operating philosophies and principles (discussed later).
- Team Member – An individual with certain expertise who works towards incremental delivery.
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 (Agile Release)
If you’re looking to locate the ART on a map, so to speak, think program-level.
An ART corresponds to an enterprise program. 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.
How do you make an Agile Release Train?
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 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:
- Take an economic view
- Apply systems thinking
- Assume variability; preserve options
- Build incrementally with fast, integrated learning cycles
- Base milestones on an objective evaluation of working systems
- Visualize and limit WIP, reduce batch sizes, and manage queue lengths
- Apply cadence, synchronize with cross-domain planning
- Unlock the intrinsic motivation of knowledge workers
- Decentralize decision-making
- Organize around value
© Scaled Agile, Inc.
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 from 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:
- Agile Release Trains Need Tracks (the Need for IT & Test Environments Management)
- Benchmarking Release Management (ERM and Deployment)
- Why we need release gates
Learn More or Share Ideas
If you’d like to learn more about Data, Release or Environment Management or perhaps just share your own ideas then feel free to contact the enov8 team. Enov8 provides a complete platform for addressing organisations “DevOps at Scale” requirements. Providing advanced “out of the box” Holistic Test Data Management, IT & Test Environment Management & Release Management capabilities.
This post was written by Jane Temov.
02NOVEMBER, 2022 by Sylvia Froncza Original March 11 2019An IT and Test Environment Perspective Traditionally, test environments have been difficult to manage. For one, data exists in unpredictable or unknown states. Additionally, various applications and services...
01NOVEMBER, 2022 by Justin Reynolds.Businesses across the board are spinning their tires when it comes to data and analytics, with many of them failing to unlock maximum value from their investments. According to one study, 89% of companies face challenges around how...
02NOVEMBER, 2022 by Eric Boersma *Original 22 October 2019If you're like a lot of developers, you might not think much about software security. Sure, you hash your users' passwords before they're stored in your database. You don't return sensitive information in error...
14 OCTOBER 2022 by Daniel de OliveiraIn today’s application-based world, companies are releasing more applications than ever before. Software delivery life cycles are becoming more complicated. As a result, large companies require hundreds and even thousands of test...
01NOVEMBER, 2022 by EricStaging Server Success: The Essential Guide To Setup and Use Release issues happen. Maybe it's a new regression you didn't catch in QA. Sometimes it's a failed deploy. Or, it might even be an unexpected hardware conflict. How do you catch...
19 NOVEMBER, 2020 by Michiel Mulders What Makes a Good Test Data Manager? Have you implemented test data management at your organization? It will surely benefit you if your organization processes critical or sensitive business data. The importance of test data is...