SAFe®, Mapped

Where SAFe Sits on the Map

From the Primer: the Scaled Agile Framework® (SAFe®) is a framework used in software development. Saying “we are doing SAFe” actually communicates little about what is really happening. But observe the Org Topologies map for SAFe: anyone can easily see that SAFe is mostly implemented with interdependent incomplete teams working on components at the task level, and fast-flow teams at the capabilities level.

The book 10X ORG puts it this way: the Scaled Agile Framework (SAFe) and the McKinsey-popularized Spotify Model can drive the creation of a Delivery Topology when skills mandates expand and real teams form. But in our experience, in most cases, due to a lack of org design skills and other political factors, these frameworks result in Resource Topologies, driving no real change. They are widely adopted, but popularity does not equate to fitness: fit is all you need.

Delivery Teams, Not Product Teams

The book quotes Marty Cagan, author of Inspired, Empowered and Transformed:

The most common in terms of sheer numbers are not really product teams at all, they are delivery teams. Also referred to as ‘dev teams’ or ‘scrum teams’ or ‘engineering teams,’ and if your company is running something like SAFe, then unfortunately, this is you. In this situation, there are a number of developers and a product owner. The product owner in this model is what I refer to as a ‘backlog administrator.’

Our analysis of Cagan’s empowered product teams agrees: SAFe won’t create a proper environment for empowered product teams to flourish. Instead, it creates disempowered delivery teams focusing mainly on execution, with separate team-level, feature-oriented backlogs. One significant difference: an empowered product team can decide which features to build to satisfy a given objective, whereas teams in SAFe are simply given features to build. See Empowered Product Teams, mapped.

Why SAFe Adoptions Need to Be Elevated

The reasons below come from numerous observed SAFe adoptions of various sizes. If your adoption avoids many of these drawbacks, you are an exemplary exception: keep up the great work.

1. Lack of true agility. Many organizations implementing SAFe get stuck with significant dependencies that slow down development and reduce responsiveness to change.
2. Dependency management. SAFe tends to manage rather than eliminate dependencies. That consumes time and resources and reduces the system’s effectiveness in delivering value.
3. Push system pitfalls. Although SAFe is designed to operate as a pull system, it often functions as a push system, which decreases adaptability and responsiveness to customer needs.
4. Siloed teams and fragmented backlogs. Teams often work in silos with their own backlogs, resulting in local optimizations that do not align with the broader organizational goals.
5. Inadequate organizational design. The typical implementation does not address the root causes of organizational inefficiencies.
6. Slow feedback loops. Program increments (PIs) of 8 to 12 weeks limit the frequency of customer feedback.
7. Suboptimal use of Agile Release Trains. ARTs frequently operate as loosely connected teams rather than cohesive units focused on common goals.
8. Misalignment with business needs. SAFe’s structure often separates product management from teams, leading to designs that are difficult to implement and creating waste.

Release Trains and Divide and Conquer

The book lists “release trains” among the industry’s many best practices for slicing organizations into parts, next to value streams, platform teams and stream-aligned teams. It calls the pattern divide and conquer: each unit owns a clearly bounded area, has a focused mandate, and has a prioritized backlog. Locally, this works. But how long before strategy adapts, priorities move, and the work that once fit neatly into each team’s mandate starts falling between the cracks?

It also names the cost. In Gene Gendel’s concept of Triple Taxation, organizations are taxed three times: first by large consultancies selling big-bang transformations, then by frameworks that require extensive retraining and licensing, and finally by the tools that lock those frameworks in place. Each layer adds costs and complexity.

An ART Is Not a Team of Teams

A team of teams integrates multiple teams to work collaboratively on broader business problems as one larger, cohesive unit. The teams coordinate among themselves without external coordinators, use a single business-level backlog, and work synchronously in a shared cadence on shared business objectives, like a great Scrum team that completes one end-to-end piece of customer-facing functionality before moving to the next.

A traditional Agile Release Train is not a team of teams. The dependencies between its teams are analyzed upfront and managed externally, which deprives the teams of the ability to collaborate just in time, share work, and work synchronously. This is so by design: because SAFe takes blocking dependencies between teams as a given, the framework sets out to save the teams from dealing with them. From a systems thinking perspective, such over-management is a quick fix: the system will always require that intervention (PI Planning and upfront dependency management) to work.

Our core belief: a framework should 1) improve that ecosystem, not merely provide a crutch, and 2) become less needed in the long run as the system has healed, improved and acquired new capabilities to deal with those historical problems in an inherent way.

Towards Elevated ARTs, One at a Time

1. Pick an ART to elevate. SAFe adoption is usually advised as a big bang, but nothing stops you from experimenting on the ART level. Pick an ART with more intrinsic chances of becoming a team of teams, and make sure its members understand the goal and want to solve the challenges.
2. Elevate the ART’s backlog to business objectives. Present a united backlog formulated as business objectives to all teams in the ART. You don’t need special roles: the existing product managers and Product Owners, plus selected team members and stakeholders, can come up with the list. In most cases, it already exists.
3. Contain the dependencies and allow synchronous work. Minimize work in progress and let the teams work together on a single business objective in a shared cadence. Some technical coaching will usually be needed to integrate across teams continuously.
4. Improve one ART at a time. Don’t cancel existing SAFe rituals; first add processes for shared context and cadence: overall retrospectives, joint backlog refinements, cross-team mobbing, multi-team architectural workshops and joint increment reviews.

The result is an Elevated ART (eART). As our reflection on SAFe’s flow fundamentals concludes: aligning on a single backlog at the ART level and merging teams into a team of teams are powerful levers to achieve sustainable flow, without losing the framework’s structural benefits.

A Framework Comes Last

From the Primer: framework thinking assumes that implementing an industry-standard management framework is the key to success. Organizations apply such frameworks without understanding the implications, which leads to not solving the root-cause problems, a lack of enthusiastic support from people who did not create it themselves, and a cargo-cult mentality. Org Topologies offers strategic org design instead: business objectives, then the org goal, then the topology, then the framework. A framework is the last thing you choose, not the first.

Read how to elevate a SAFe adoption, see the three topologies, or map your own release trains in the C-OTC class. The whole argument is in the book 10X ORG at 10xorg.com.