LF

The Agile Release Train Explained

23

April, 2018

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:

Relevant Articles

Why Is Test Data Management So Important?

18 NOVEMBER, 2019 by Carlos Schults Test data management is vital for achieving a healthy test automation strategy, yet many professionals are still not familiar with the term. They don’t know what the concept means, nor why it’s so important. But why would that be a...

Incorporating Test Data / Data Compliance in DevOps

03 NOVEMBER, 2019 by Arnab Roy Chowdhury DevOps, a word that combines “development” and “operations,” is a business process that shortens the time taken to gather customer feedback. Besides, it also enables progressive software delivery and helps clients grab market...

Are You TEM Savvy?

30 OCTOBER, 2019 by Erik Dietrich Measuring TEM Capability in Your Enterprise Once upon a time, testing your software was easy. Or, at least, relatively speaking, it was. Your team would write some code, tag an unreleased version of the software, build it, and hand it...

Software Security Anti-Patterns

22 OCTOBER, 2019 by Eric Boersma If 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 messages. Each time you...

How Data Breaches Happen?

08 OCTOBER, 2019 by Michiel Mulders Preamble You’ve probably seen some recent articles asserting that the world’s most valuable resource is no longer oil—it’s data. New internet titans like Google, Amazon, Apple, Facebook, and Microsoft look unstoppable. In fact,...

DevOps and TEM Go Hand in Glove

25 SEPTEMBER, 2019 by Mark Henke DevOps is overall a healthy practice for most development teams, but it doesn’t come for free. Enterprises are eager to adopt the practice but their tools often lag behind DevOps practices. This is a bit like walking out into the...