This page acts as a micro-site about SAFe and FLEX.
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:
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.
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.
How FLEX and SAFe Manifest Different Behaviors
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.”
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.
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.
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.
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.
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
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.
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.
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.