Delivering at Scale, Why SAFe Is Essential for Agile Teams


April, 2019

by Eric Goebelbecker

Your organization is in the midst of an agile transformation. You know that agile is the way to go, and you’re looking forward to, or maybe already reaping, some of the benefits.

Who can argue with what agile brings to the table? Here’s a short, and incomplete, list of benefits an enterprise gets when they implement it.

  • Increased team autonomy
  • Improved response to customer input
  • Enhanced ability to respond to change
  • Better visibility into results

But even with the possibility of realizing these perks, you might be skeptical about adopting SAFe and the agile release train. Why does something called “agile” come with so much bureaucracy? Isn’t the point to get away from meetings, diagrams, and milestones, not make them official?

Well, the thing is, large organizations have a problem; agile doesn’t scale on its own. Agile works well with small and medium-sized teams. But a large number of small groups organized around independent agile programs isn’t efficient. So when enterprises want to become agile, they need SAFe. Let’s take a look at why.

Shared Vision Between Management and Development

Essential SAFe starts with the Vision. The term “vision” sounds lofty and idealistic, but there’s something essential hiding underneath the rhetoric. It’s a shared picture of where the enterprise is going, and an agreement on how important it is to get there.

So, let’s look at part of vision’s definition from the SAFe website:

The Vision is a description of the future state of the Solution under development. It reflects Customer and stakeholder needs, as well as the Feature and Capabilities, proposed to meet those needs.
Copyright © Scaled Agile, Inc.

What does that mean? Well, let’s look at what happens when we don’t have a shared vision. Maybe something like this happened to you once.

A development team works with a stakeholder to define the features and the schedule for a project. Perhaps it’s a set of new features, or maybe it’s a new product. Once it’s all agreed upon, the team starts working on making it happen. But before they can finish, priorities change. The project goes on the shelf, or it’s altered so significantly that it’s no longer what was originally designed and a lot of work is thrown away.

SAFe’s vision prevents this by design. By creating a checklist of features and benefits and transforming it into a plan, stakeholders are more apt to stick with the program. The vision provides a long-term context for short-term decisions. It gives the development team a way to explain how a change in priorities today will affect the team’s ability to met goals tomorrow.

SAFe’s vision is essential for agile teams. It provides a shared set of goals, priorities, and milestones for all team members.

Program Increments Provide Focus

But let’s not throw management under the bus when it comes to derailing projects. At least, not without throwing a few more roles under the wheels to keep them company. Developers are just as capable of creating distractions for themselves and are adept at finding reasons to delay a release.

That’s why after the team agrees on vision, they break it down into Program Increments (PI). Some people call PIs the heartbeat of the agile release train. They provide teams with a reliable cadence for delivering product to customers. Whatever label you use for PIs, they’re what keeps the program participants focused. If you’re not delivering features and value at regular intervals, you don’t have a program.

Planning PIs gets everyone together, hopefully face-to-face, and gives them an opportunity to take the shared vision and design a plan that delivers value on a regular basis. Once the program is formed, everyone has an agenda, and it’s time to get the agile release train (ART) rolling.

The Agile Release Train Is What Makes SAFe Essential

The ART is what makes SAFe essential. Agile is about iteration. By focusing on short, digestible, and manageable increments of work, teams receive immediate feedback that they can use to fine-tune their efforts.

These increments work for a small team of five to ten people. They don’t scale well for larger groups because the feedback can’t be applied to the overall program. At the same time, managing a large number of small teams from a central vantage doesn’t scale well either.

So in SAFe, we establish the PI and then use it to build and direct the ART. The PI creates a feedback loop at the program level, usually lasting a calendar quarter, but never more. Then scrum teams are established inside the program.

During each PI, teams work on two-week sprints. From their viewpoint, it’s agile scrum. Under ideal circumstances, they don’t care whether they’re working inside SAFe or not. They’re working on sprints that provide them with the regular feedback they need to operate efficiently. The development teams work on a half-dozen or so sprints comprised from the backlog the current PI has defined.

The train metaphor models how releases work in this system. Each quarter the teams assemble and define the next increment. If a feature doesn’t make it in, it’s not addressed during that increment. It can try to get on the train at the “next stop” when a new program increment is defined. This discipline is what keeps everyone focused.

What happens without the train?

Well, the teams may quietly fall into a waterfall of sprints. Even though they lack the pressure of picking a set of features and executing on them on a regular schedule, they need to stay busy. So they’ll just keep scheduling sprints and adding features as they go. Since they’re making up these deliverables on their own, they may never add up to a releasable product or something that a customer wants.

Or, they may define their releases without input from other teams. When this happens, the enterprise product portfolio is a disjointed mess. The train doesn’t only determine the interval. It also translates the shared vision into a plan. Without that plan, the enterprise may look like a federation.

What Makes an Organization Agile?

Does a collection of teams using scrum add up to an agile enterprise? Or does it require teams with a shared vision and common schedule? SAFe’s orchestration is essential, and without it, the enterprise is less than the sum of its parts.

The agile release train is the structure SAFe employs to deliver value to customers. Its composition will differ depending on the program and organization that’s using it, but the core principles remain the same. When implemented correctly, the ART keeps teams focused and working in harmony across the enterprise.

Are you interested in learning more about implementing an agile release train in your organization? Contact us about Enov8 release management, 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 (systems and component-centric), and automation.


Eric Goebelbecker

This post was written by Eric Goebelbecker. Eric a regular Enov8 blogger, has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!)

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...