SAFe® and FLEX

This page acts as a micro-site about SAFe and FLEX.


FLEX Practices That Help SAFe

About SAFe

Using SAFe in Small to Medium Size Organizations



The page shows 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 process
    • 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

How FLEX and SAFe Manifest Different Behaviors




How to start All in, all the way Based on where people are, who is driving, and culture
Where to start Start at Essential SAFe Start based on who is driving and what the organization’s challenges are
Attends to culture No Yes
Direction of adoption in value stream Start at program level and move up. Start as high as you can based on who is supporting the adoption
ART formation Gives suggestions in general Provides several patterns

  • Has methods for when have vertical applications using horizontal platforms that are also products
  • Dynamic Mobbing
  • When teams are not quite cross-functional
  • Other structures
Has agreements people make in adoption other than support SAFe No Yes, the guardrails


Uses Middle-up-down management? Yes, implicitly Yes, explicitly

Principles and mindset

Based on Don Reinertsen’s work Partly. Some principles modified and not consistent with Reinertsen’s work Yes. Completely consistent
WSJF Simplified, has flaws & will not resolve disputes of importance relating to strategies from different areas of the business Consistent with slight extension to help calculate business value.
Focus on the work more than the framework No Yes
Systems thinking Not completely Yes
Defined around Levels of the organization Value stream


Value stream network architect No Yes
Business architect Role is implicit. Role is explicit

Portfolio and Product Management

Portfolio management approach is intended for large companies. This requires many roles, more than a small company needs. Based on standard business practices of portfolio management. Includes discussion of Beyond Budgeting when requested.
Explicitly use MBI (or original MMF) No Yes
Level of complexity of portfolio and product management High Low


Planning done incrementally or via flow Incrementally Incrementally or flow
Program increment Length 2-3 months 2 weeks to 3 months (recommend no more than 1 month except in extreme cases

Team Training

When is doing ATDD Training suggested After first round As part of first round. Cost of Scrum/FLEX for teams and ATDD about the same as SAFe for teams
Require ATDD training to have PO, Dev, Test? Recommended, but not usually done Yes


Redefine standard industry terms Yes (MMF) No
Overload standard industry terms Yes (Epic) No
Use specialized standard terms in a way they were not intended Yes (MVP) No

Introductory Training

What does introductory training cover? Two day course. Always the same. 2.5 day course for internal change agents. Includes assessment and tailoring of course for internal delivery of customized course.

Licensed Training Materials

For licensed courses include how to teach them? No Yes
Can training materials be modified for an organization? No Yes (are tailored to company being delivered to)
Has online training for ScrumMasters/Kanban coaches? No Yes
Has online technical training for developers? No Yes

FLEX Practices That Help SAFe

Using MBIs in the SAFe Planning Event

We use MBIs as the core of our planning event instead of epics or features because computing Weighted Shortest Job First (WSJF) on either epics or features does not provide an effective ordering. Epics are bigger than the actual work we will implement. Hence, doing WSJF on an epic doesn’t really make any sense since some (most?) of the epic will never be implemented. Rather an epic can be thought of being a container for the features we will be creating.

Improving WSJF

Weight Shortest Job First (WSJF) was defined by Don Reinertsen as a way of ordering work to be done to lower overall cost of delay. SAFe modified Mr Reinertsen’s definition in WSJF ways.

FLEX and SAFe Essentials

Here are the ten SAFe Essential’s and how FLEX implements them: Lean-Agile Principles.  FLEX’s core is Lean-Agile. It takes a fully systems-thinking approach, looking at the realization of business value as a whole.  FLEX is truly flow based while SAFe is essentially large batches (3 month planning cycles) with Lean attempting to speed it up.

Sequencing the Work To Be Done

We often hear from prioritizing our work. But everything can be important. Sequencing is a better model because it forces decisions on which item is more important than another. Not making this decision sets the stage for ambiguity throughout the organization on what to work on. This leads to less important work holding up more important work and often starting more work than should be started. This sequence of work allows people throughout the organization to have a common view of what is most important to be worked on.

About SAFe

The Value Stream in SAFe

SAFe’s definition of the value stream is “Value Streams represent the series of steps that an organization uses to build Solutions that provide a continuous flow of value to a Customer. SAFe value streams are used to define and realize Portfolio-level business objectives and organize Agile Release Trains (ARTs) to deliver value more rapidly.”  This is a subtle difference from the long-standing definition of a value stream – “A value stream represents the series of steps undertaken from beginning to end for a specific product or service in order to provide business value.”  In other words, value streams are about our current state and not what we want it to be.  We don’t define a value stream as much as we refine one. Value stream mapping is a way to see what is working and what isn’t. It focuses on the delays in delivering value.

Understanding Pull in SAFe

Plans are worthless, but planning is everything. Dwight D. Eisenhower. One of the more misunderstood aspects of SAFe is its Program Increment (PI)/release planning event. At mid to large scale, this is one of the most innovative aspects of SAFe. It greatly increases the opportunity for collaboration, Some misunderstand it and consider it to be inherently a big batch up-front planning mechanism and then infer that the implementation of the plan is also based on big planning. While it definitely can be a bigger planning event than required, it doesn’t have to be implemented as a big implementation.

What SAFe® Provides Us

SAFe provides many good concepts to organizations that are either planning to go Agile or who have already been doing it but have not been able to get their teams to work together well. While there are many things to learn from SAFe and the overall view it provides is useful, the solutions it provides are often not the best available or deep enough to truly help. In many ways SAFe is a waterfall analysis and planning approach using Agile teams for implementation. It can definitely move large organizations towards Agile but will not achieve it on its own.

Why Is SAFe Popular?

SAFe is a very practical approach to applying Agile in mid- to large-scale organizations. This is in large part because SAFe implements a number of practices derived from Lean, and that have proven effective in these larger organizations. This article describes how SAFe implements several of these practices.

The Interesting Parallel Between SAFe and the Kanban Method

Many people would consider SAFe and the Kanban Method to be at opposite ends of the spectrum. The Kanban Method is a way for an organization to start where it is and to make gradual changes.  Nothing appears further from this than SAFe’s “all-in-all-the-way” approach.

Northwestern Mutual Case Study: A SAFe Implementation Retrospection

This article discusses Northwestern Mutual’s SAFe adoption from the perspective of the lead consulting company leading the adoption. It starts with how the implementation was done and, in particular, cover those things that were done that were not in SAFe at the time but were common practice for Net Objectives. It will discuss what worked, what could have been better, and what we would have done differently if we were to do it again. It closes with what we can learn from this engagement and provide some resources for further reading. The bottom line is that even though SAFe has improved over the last six years, there are still several key things that are either not addressed or could be improved. The bottom line is that SAFe is a framework for project management at scale. It may be a good start, but it should not be the targeted end state. As a framework, follow Bruce Lee’s advice, “Absorb what is useful, discard what is useless, and add what is specifically your own.”


Using SAFe in Small to Medium Size Organizations

Using SAFe as a Starting Framework

FLEX and SAFe at mid-scale SAFe provides the following guidance that is useful at mid-scale: Have a single backlog for initiating ideas Create the role of product manager to align the business side with technology Have teams work in a common cadence Do planning events with everybody present.  Note that his event does not need to be for 8-14 weeks out.  In fact, it should be for as short a period as the organization can manage effectively.  Otherwise the organization will be working on larger batches than necessary. Attend to technical practices and quality of design and code While these are consistent with FLEX they are more batch oriented instead of flow oriented. This enables the adopter of SAFe to either start with SAFe as is or to recognize the adjustments to SAFe that FLEX suggests to be more flow-oriented.

Using SAFe in Smaller Organizations

SAFe can be applied to smaller scales than those for which it was designed by treating it, not as an “off-the-shelf” approach, but rather as a thinking framework and collection of valuable practices to be mined according to an organization’s situation. This article discusses some of the issues in using SAFe in this way.

Adopting SAFe® at Small to Mid-Scale (Overview)

Executive overview This article is for someone considering SAFe® for their small to mid-scale adoption. Many organizations are adopting SAFe because it provides a method for multiple teams to work better together. SAFe is attractive because it provides more structure than “Scrum-of-Scrums” and provides guidance on business strategy, budgeting, management, shared services and DevOps. But it can also be overly complicated, particularly for small to medium sized organizations.

Adopting SAFe® at Small to Mid-Scale (in Depth)

Executive overview This chapter is intended for someone considering SAFe® for their small to mid-scale adoption. Many organizations are adopting SAFe because it provides a method for multiple teams to better work together. SAFe is attractive because it provides more structure than “Scrum-of-Scrums”  but can be overly complicated for technology organizations of less than 1000 people. This article will discuss: Why Essential SAFe appears attractive but leaves organizations adopting it have both a more complex process than they need while having gaps in it as well How to implement those parts of SAFe that are useful in small to mid-scale A simpler, more effective method of Lean-Agile Product Management that works well at small to mid-scales How to decide whether you should use SAFe Note: for an overview of this chapter see Adopting SAFe at small to mid-scale overview.


Tailoring SAFe® to Your Organization (Webinar Sessions)

This page offers the recordings, slide decks, and resources for the webinar series, Tailoring SAFe to Your Organization. This was a one-day event on December 16, 2014. It is intended for SPCs and SAs who are wondering if and how their companies should adopt SAFe.  It covered the material Net Objectives uses to extend SAI’s basic Leading-SAFe class to answer questions we’ve seen are virtually always asked

Elaborating SAFe® (Webinar Sessions)

This page offers the recordings, slide decks, and resources for the webinar series, Elaborating SAFe®. This day presents a quick overview of SAFe followed by four elaborations we’ve seen useful in most of our SAFe implementations.

Simplifying SAFe® (Webinar Series)

A webinar series for people who have adopted SAFe and are looking to both understand it and use it better or are considering SAFe or alternatives.

Tuning SAFe® (Webinar Sessions)

Webinar description SAFe® has been used successfully by many companies in many industries. Success depends upon properly configuring it to work within your organization. This requires a deep understanding of SAFe as well as experience in implementing it in multiple situations. This series begins with an explanation of the issues that must be managed when transforming to Agile at scale. Later sessions explore particular issues in configuring SAFe that go beyond what is provided in standard SAFe courses.