SAFe® and FLEX

Net Objectives has been helping companies do Agile at scale for over a dozen years. This enabled us to be both a contributor and early adopter of SAFe. Our SAFe adoption with Northwestern Mutual became a SAFe case study. Read our insights on how we did SAFe a little differently even from the beginning.We don’t do SAFe by the book, we go beyond it. If you want guidance on any of the following please contact us (see info at bottom of page):

  • Lean portfolio management
  • Agile product management
  • Getting teams up quickly with Scrum & ATDD training (for the same cost and time as a SAFe for Teams course, get your teams trained in SAFe, Scrum and ATDD)
  • SAFe architecture
  • Kanban for SAFe teams
  • Using Kanban at Shared Services and ops

This site presents how to adopt SAFe being guided by our own mid to large-scale approach which we call FLEX (FLow for Enterprise Transformation). While SAFe can be a good foundation, there are many places where going deeper than what’s available in the framework would be helpful. Also, our experience with Lean Thinking enables us to simplify how SAFe is normally used.  This page is a good launching point for those using SAFe® or considering it.

Since our early involvement with SAFe, we have used it as a true framework, adding new mechanisms to it when valuable. SAFe presents a solid foundation for people to quickly pick it up. But this strength has the downside that some things are not easy to pick up in a few days (or even years). This where having someone pull in extra concepts can be useful. This not only fills in the framework but can tailor it to fit the needs of the organization. For an example, see retrospection on the Northwestern Mutual adoption of SAFe case study .

Our approach to SAFe relies heavily upon what we’ve learned over the last decade and a half of creating our FLEX system. This page (and those it references)  integrates many of those learnings into it so as to make SAFe easier and more effective to adopt.

Understanding Agile at Scale in a Nutshell

Before trying to understand SAFe, one should understand the problem SAFe is attempting to solve. In a nutshell, Agile at Scale requires the following:

  1. Stakeholders setting the direction the company is going
  2. Product managers deciding on what to build that is consistent with this direction and effectively uses the capacity of the organization
  3. Technology being able to efficiently manifest product manager’s plans through
    • use of an effective development process
    • people organized so they can more easily get their job done
    • proper management of the workflow through the development system
    • technologists knowing how to work on what’s being built in an Agile manner
  4. use of proper technical skills (e.g., software design, automated testing)
    • having a test-first mentality
    • being able to write high-quality code
  5. an effective release proces
    • DevOps
    • product/service support
  6. Management that works to create effective eco-systems and to coordinate its components

These objectives are hopefully self-evident. While just described in a linear fashion, they are not implemented linearly since feedback is needed at each step. But it is important to observe that each step sets the stage for the next.

Looking at the Value Stream Instead of Levels

It is easier to understand what SAFe is attempting to accomplish by looking at it as a way to manage value streams instead of it being comprised of multiple levels. “A value stream encompasses all activities undertaken from beginning to end for a specific product or service in order to provide business value.”

Although SAFe is described in terms of levels (e.g., portfolio, program, team), SAFe requires us to think of these as interdependent components in a complex system. The challenge is that these relationships are hard to see in the SAFe big picture. Looking at a value stream running across the organization makes it easier to see what SAFe is proposing. Figure 1 depicts how to look at the workflow for an organization. For simplicity, only one portfolio and backlog is shown.

Figure 1. Conceptual flow of value in an organization.

The advantage of looking at it this way is that it applies to almost all organizations. SAFe’s levels imply a relationship to the levels in an organization. There may not actually be a ‘program’ level but rather programs may consist of multiple levels, as may portfolios. But the concept of going from what we want to invest in to strategies to initiatives to business increments to minimum business increments to a program backlog and so on works everywhere. While it is true that Figure 1 shows a set number of backlogs, we must be explicit about that this is just an example; we are not defining the value stream based on the number of backlogs shown.

Looking at SAFe through this picture shows the relationship between the different levels but from a flow perspective. Not all roles, artifacts, or processes are shown in Figure 2. It is just intended to illustrate how the SAFe levels flow through the organization’s value stream.

Figure 2: SAFe viewed as a value stream

Key resources to explore

Here are some recommendations about SAFe and using SAFe in your organization.

Improving your SAFe implementation with FLEX

FLEX is designed to work as a standalone approach or to help improve other approaches. FLEX provides those implementing, or about to implement SAFe the following:

  • A deeper understanding of what the SAFe practices are trying to accomplish
  • Alternative practices that can be substituted when needed
  • A deeper understanding how the components of SAFe work together
  • A more effective way of doing Agile Product Management
  • A tool box of ideas for improving the formation of trains
  • Greater clarity on the role of management in creating eco-systems for the teams
  • A consistent, but tailorable, method for team process (Team Agility)
  • A method to do shorter program planning increment events than SAFe prescribes or to have SAFe follow a flow model instead of its batch model
  • More insights on the use of shared-services
  • An enhanced WSJF that can be used across different portfolios
  • An often better estimation method than planning poker (team-estimation by Steve Bockman)

Additional Useful Resources

Upcoming Articles

  • Enterprise Portfolio Management
  • How to use MBIs in SAFe

Play a learning game of Sailboat regarding SAFe®

Sailboat is a modification of Luke Hohmann’s Innovation Games. It is a great way to do retrospectives or to learn how things are going. We have created an instance of the game to help you think about SAFe. Click here to here to join the game and play for yourself.

For more information about Innovation Games and how to use these yourself, visit the site at

Portal resources about ‘FLEX and SAFe’

Contents Moved (Article)
Introduction to FLEX (Article)
Northwestern Mutual Case Study: A SAFe Implementation Retrospection (Article)
Right Sized Epics in SAFe (Article)
The Interesting Parallel Between SAFe and the Kanban Method (Article)
Understanding the Pull of SAFe (Article)
Using MBIs in the SAFe Planning Event (Article)
Using SAFe in Smaller Organizations (Article)
Weighted Shortest Job First (Article)
Why WSJF Should Be Done on MBIs and Not Features or Epics (Article)

Note: SAFe® is a registered trademark of Scaled Agile Inc.