You are here

SAFe 4.0 in plain English

Matthew Heusser, Managing Consultant, Excelon Development

"The primary motivation of the Value Stream Kanban Board is to ensure that Capabilities and Enablers are reasoned and analyzed prior to reaching a PI boundary ..."

— Value Stream Kanban Board, from the Metrics Page of the Scaled Agile Framework (SAFe) 4.0


I have no idea what that means, either. At least, I didn't know what it meant without flipping between the quote, the scaled agile glossary, and a fair amount of deep thought.

Today, I'd like to take a step back, covering what's new in SAFe Version 4.0, the newest release of the framework, along with enough of the basics so that your eyes won't glaze over reading it.

Buyer’s Guide to Software Test Automation Tools

Getting started: SAFe's big picture and recurring themes

First, take a look at the SAFe 4.0 "big picture" diagram. 

You can also view a larger version of the big picture diagram at the main SAFe website.

SAFe provides a way for organizations to manage work beyond the Scrum team, scaling up to teams of teams (the Program level, 50 to 150 people) and then the Portfolio level, where large companies pick what to invest in.

Before we get to what's new, let's talk about what's common. As shown in the diagram, each level has three different core roles:

  • Someone to figure out what to build
  • Someone to do the technical work or manage it
  • Someone to coordinate the work.

This pattern repeats at every level down: the Portfolio and Program/Portfolio management, epic owners, and enterprise architects. The Program level has the release train engineer (RTE), product management, and system architect. Technical teams have a Scrum master, product owner, and technical staff.

SAFe also suggests visualizing the work in Kanban board: a visual display of work in progress. Whether you call it a Kanban board, a Scrum board, or a "lean management system," the point is to see all the work in progress at the appropriate level of detail. For a team, the board is full of stories at the stages Ready, Doing, and Done; at the Program level it might be features and enablers; at the Portfolio level, it might be the major epics the company is working on right now and what is coming next.

SAFe suggests visualizing the work in Kanban board, a visual display of work in progress, as show above.

SAFe also provides metrics appropriate to each level. These metrics are a bit like those in baseball, where you might be interested in a team's overall performance (win/loss), or you might be more interested in performance at an individual game level (overall score) or within an inning (strikes, balls, errors, outs, and runs.) SAFe metrics provide metrics guidance at the levels of Portfolio (investments, on-time completion), Program (burn-up chart), and Team (iteration metrics, team self-assessment).

In addition to metrics, the coordination and process guidance changes at each level. Teams need basic Scrum methods, while a Program needs to coordinate large releases between teams, and the Portfolio needs to select initiatives to fund, create business cases, and measure and track performance.
You can think of these as themes. At every level in SAFe, you'll find a Kanban, three roles, appropriate metrics, and guidance for the process and coordination of work. Those are just the themes, the elements of SAFe that repeat at each level.

SAFe 4.0 also recognizes that for large companies, the 50-to-150-person "team of teams" is just not enough. Fortune 100 information service companies can have as many as 8,000 people in IT—that's somewhere between 60 and 200 teams, far too many to understand at one time. To simplify portfolio management, SAFe adds a new, optional level called the Value Stream, which appears as a new "tab" at right on the big picture. The value stream represents a single type of investment (say $2 million a week) that might involve coordinating multiple programs.

[ Get Report: Gartner Magic Quadrant for Software Test Automation ]

But what is the SAFe 4.0 Value Stream?

I asked Dean Leffingwell, the CEO of Scaled Agile Inc., for an example of a Value Stream. He suggested a satellite communications system. That might comprise as many as three value streams: the satellite hardware and firmware, the ground station it communicates with, and the web server farm that shares that information with the world. Each of those major products might involve multiple Program-level teams and could be managed separately. The metrics for each of those components might roll up to the Value Stream level and not above it. Unit test coverage, for example, could be measured for the web server farm as an average, while the hardware teams working on the satellite might have entirely different metrics.

One new item at the Value Stream level is Solution Intent. That is, something that expresses what the system will do (future, what to build) along with what it does do, which is in present tense. What the system "does" includes all features that would happen if we 1) immediately stopped future progress, 2) ran a quick test process, then 3) put the system into production.

In the days of waterfall, teams tried to achieve something like Solution intent with a systems requirements specification, or SRS, often defined up front. The schedule was a guess, and the SRS would become outdated around the time people started coding. The great tragedy of all this is that we would insist on an SRS because we NEEDED it (in all capital letters), then would make a system that did not meet the SRS, except in some military, government, or regulated spaces, when the project would simply become amazingly late and over budget.

SAFe 4.0's Solution Intent feature

SAFe 4.0 suggests a different approach to Solution Intent. Instead of trying to nail down the full solution up front, each story is added to the SRS when it is completed and ready to ship. The stories provide a link to the test approach for that story, including examples that are automated. In the ideal process, a release engineer clicks build, the software packages the stories according to a protocol to build an electronic SRS, then runs through all the automated checks, providing an audit of that build. By having the stories made just in time and the examples for the story part of the engineering work, the accurate, up-to-date SRS "pops out" of the process for every release. 

This term "SRS" is really more common on large, real-time systems, such as an airplane or missile, that include physical components. Which brings us to the second big change in SAFe 4.0: the inclusion of hardware and firmware.

From software to systems

The letters in SAFe stand for "Scaled Agile Framework," and Version 4.0 adds a new subtitle "For Lean Software and Systems Engineering." It is a subtle shift, but one that allows SAFe to encompass the entire aircraft, not just the software. While agile techniques originated in software, Lean concepts came from manufacturing and apply directly to improving physical products. Combining the two means that SAFe can apply to consumer electronics, radiological imaging systems, and military-grade equipment.

The primary interest in previous versions of SAFe was mostly at the program level—the idea of a team of teams that coordinated every eight to twelve weeks, delivering a "product increment" (PI) every four to six sprints; this came along with the tools to make the coordination of the "release train" happen, which aided the agile transition of organizations of a certain size. SAFe 4.0 focuses on the top (Value Stream) and the bottom (team level).

SAFe 4.0 supports more agile methods for technical staff

The previous version of SAFe suggested Scrum at the team level. Scrum is a project management wrapper; it doesn't describe how technical teams will do the work. The newest versions add extreme programming (XP) techniques, such as test-driven development and continuous integration, to provide examples for how teams can do the technical work. The new version includes Kanban as an alternative way to manage work. This is not Kanban used as a simple board to visualize tickets; the recommendation is from a mindset that encourages whole-team thinking and continuous improvement. 

Version 4.0 also includes a few new terms, including explicit support for a community of practice (CoP), a "tribe" that supports a role, such as testing, and can meet informally. Anyone can participate in a CoP, and participation is not required. That makes CoPs more flexible and emergent than the so-called centers of excellence approach. 

SAFe also separates the kind of work into two categories: Enablers and Capabilities. At the team level, a Capability is what we might think of as a feature; at the Value Stream level it might be a product or add-on. Enablers are the kind of work that might not have direct benefit to the customer but make some new value possible. At the team level, enablers might be "spike" stories; at the higher level, they are features the teams themselves can use. For example, a private cloud to enable a new style of continuous integration, or quick builds or development and test environments, might only happen if it stands alone. It is possible to calculate the value of that project—at least the broad strokes—in terms of additional delivery speed of the entire organization. 

Putting it all together

Companies need to decide what projects to fund, then break that work down into pieces and measure whether the pieces are performing. The breakdown needs to keep happening all the way down, until the pieces are very small. This breakdown should get you to the level of "stories" in classic Scrum. Using Kanban at every level provides a way to visualize and manage the work, while the separation of roles balances competing forces. Version 4.0 shifts the focus from "agile" to "lean," which includes hardware and firmware systems, while improving the advice at the team level.

The benefit of SAFe is that it is comprehensive if you have a problem. The challenge of SAFe is that it is comprehensive; it is easy to get lost in all the details. Small organizations may find SAFE to be overkill, with too much process, guidance, and metrics. Tailoring SAFe concepts to fit an organization of one program or less may create a significant challenge.

There's much more to SAFe beyond these basics, including a set of core values and principles that lead to improvement, along with what the authors mean by developing lean-agile leaders and the lean-agile mindset.  In this article, I've simply tried to hit the highlights.

Where to go for more on SAFe 4.0

Perhaps now that introductory quote makes more sense, and you are ready to go to the source. While the quote from the beginning of this article is a real example from, it is taken from the material designed for people already familiar with SAFe basics. The site also includes introductory material, such as Safe 4.0 Foundations, what's new in Safe 4.0—both slides and a videoand a blog. If you find yourself confused at first by the material, my advice is not to skim over it. Dive in. Also note: The glossary is your friend.

Image credit: Kristina D.C. Hoeppner

[ Webinar: How to Fit Security Into Your Software Lifecycle With Automation and Integration ]