The Agile Release Train Explained
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 (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. 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:
- 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.
16September, 2021 by Carlos SchultsLet me start with a question: as a leader in tech, are you satisfied with the budget you have? If I had to guess, I'd say the answer is no. Because of that, calculating the return on investment of the many activities in software...
14AUGUST, 2021 by Ukpai UgochiIt is the goal of every software engineer and software development firm to continuously ship products to end users. This can only be achieved through software deployment. In this post, we'll explore deployment and deployment planning,...
09SEPTEMBER, 2021 by Eric GoebelbeckerLet’s talk about container essentials. Over the past few years, containers have transitioned from the hottest new trend to essential IT architecture. But are they are good fit for you? Are you wondering whether or not you’re using...
05AUGUST, 2021 by Alexander FridmanIn the beginning there was nothing. Then there was the monolith, though we used to simply call monoliths "software." Today we have two rival architectural types: monoliths and microservices. This post will explain what monoliths and...
15JULY, 2021 by Justin ReynoldsCompanies go to great lengths to protect their physical environments, using deterrents like locks, fences, and cameras to ward off intruders. Yet this same logic doesn’t always translate to digital security. Corporate networks — which...
06JULY, 2021 by Justin ReynoldsCompanies today face increasing challenges around reducing the time and cost of software development. Many are thus using DevOps methodologies, which combine software development and IT operations to achieve continuous delivery and...