Deconstructing SAFe's Intent, Design Choices, Strengths, Weaknesses and Controversies

I started working with agile in product development back in 2006. Once I saw that it worked nicely at the team level, I started to feel the need to figure out how to improve agility for teams of teams working on bigger products and bigger solutions.

I played around with multiple things in the trenches—scrum, kanban, mashups, feature-driven development—and right around 2013, I learned SAFe from Dean Leffingwell.

The things I really liked in what I saw were the realization that agile cannot just happen by working with teams. It really needs leadership support and leadership engagement. And SAFe relied on modern change management practices, moving from “pigs and chickens” to actually involving leadership as part of your agile journey. A big reason why SAFe succeeded out there is because it tackled the change management challenge.

When you look at change management, Scrum back in the day was a “burn your ships” revolutionary approach. Kanban later provided a more evolutionary path: start with what you have, respect current controls, but agree to pursue continuous improvement.

SAFe is actually closer to Kanban from a change management perspective. A lot of agilists don’t realize that SAFe respects the way things are currently done—sometimes to a fault. But by meeting organizations where they are, it streamlines the path of change for enterprise leadership.

In the trenches, most traditional organizations struggle to figure out the Scrum Master role as defined in pure Scrum. In most companies, the person taking on the Scrum Master role ends up taking on active leadership, technical lead, or project management responsibilities, whether we talk about it in the Scrum Guide or not.

What SAFe did is bring that real-world practice from the trenches into the definitions in SAFe. Why did they do that? SAFe takes the approach of evolution rather than revolution. It respects the way things are done to start with, but the goal is to pursue evolutionary change—moving people over time to operate more from a coaching mindset and a servant leadership mindset.

The biggest gap and anti-pattern I see in safe implementations is that the Scrum Master is designated as the team’s representative or focal point in the Scrum of Scrums or in PI Planning. When you do that, you put that person into a mode of leading the team, and the team actually relinquishes power to the Scrum Master rather than growing into a self-managed unit. That is the biggest gap.

Additionally, SAFe splits the full scope of organizational coaching across three distinct roles: the Scrum Master at the team level, the Release Train Engineer (RTE) as the chief scrum master for the Agile Release Train, and the SAFe Practice Consultant (SPC) for the broader enterprise. While this prescription provides clear career paths for organizations that need them, it risks entrenching new layers of hierarchy if not managed with an eye toward empowerment.

PI Planning is an implementation of the agile planning onion. Scrum teams have been doing release planning at some level for ages; PI Planning is an evolution of that concept.

What are we trying to do with PI Planning? We are trying to come up with a reasonable understanding across a team of teams that has dependencies to hash out of what reality might look like in the next 8 to 12 weeks. The real magic in PI Planning is how it involves everybody throughout all the teams to align on what’s important and what’s possible.

What PI Planning is not is detailed planning for five or six iterations ahead. The outcome of PI Planning is not which specific user stories will happen in which iteration; the outcome is PI Objectives that we believe are realistic for each team and for the Agile Release Train.

Similarly to a Sprint Goal staying stable while the Sprint Backlog adapts, PI Objectives are expected to stay stable throughout the PI, while the detailed iteration plans are expected to change as reality happens.

Safe Principle #3 says: Assume variability; preserve options. The risk in the trenches is that organizations feel comfortable with defining all the details upfront and treat the PI plan as a locked contract. If an organization treats an 8-to-12-week forecast as unchangeable, it loses adaptability. High-profile operational meltdowns happen when an organization plans itself into a corner and forgets that a PI plan is a hypothesis to be continuously tested and adapted.

In SAFe, product ownership is addressed at multiple layers: at the team level you have the Product Owner, at the Agile Release Train level you have Product Management, and at higher portfolio levels you have Solution Management and Epic Owners.

Why did SAFe make this choice? In a large enterprise with 100 or 150 people working across a release train, asking a single person to manage market strategy, executive alignment, customer discovery, AND write user stories for 10 delivery teams is practically impossible.

SAFe chose to call the ART-level role “Product Management” because that practice is familiar to enterprise organizations and product companies.

However, this creates a severe risk: creating proxy product owners. When you put Product Management at the train level and Product Owners at the team level, team-level Product Owners easily degrade into order takers, story writers, or business analysts who lack true ownership.

The way out of this trap is descaling. If you can descaling your architecture and product boundaries into smaller empowered product teams, the team-level Product Owner becomes a true, empowered product owner for that sub-product, while Product Management provides lightweight strategic alignment.

Critics like Marty Cagan point out that SAFe can trap organizations in “feature factories,” feeding requirements down a conveyor belt rather than empowering product teams to discover and solve customer problems. Critics also note that big tech companies like Amazon, Google, Netflix, or Spotify do not use SAFe.

My view is straightforward: big tech companies do not use SAFe because they do not need it. They already have high technical prowess, decoupled microservice architectures, automated deployment pipelines, and a culture of empowered product teams. They have descaled the problem. SAFe targets mainstream enterprise organizations that lack that technical maturity and are struggling with how to even begin scaling agility.

However, the feature factory risk is genuine. As Jeff Bezos famously warned, when process becomes a proxy for results, people stop looking at outcomes and just focus on doing the process right.

If an enterprise installs SAFe as a commercial shortcut—buying training and checking process boxes without investing in technical excellence, product discovery, and empowered teams—it will simply build an elaborate, high-overhead feature factory.

Scrum co-creator Ken Schwaber famously criticized SAFe in his post “UnSAFE at any speed,” arguing that SAFe’s heavy prescription allows traditional organizations to buy their way into checking boxes while avoiding real agile transformation.

This reflects a fundamental philosophical tension in the agile community: prescription vs. emergence. Frameworks like Scrum and Kanban intentionally use minimal boundaries and provocative terminology to force organizations to confront their culture. SAFe takes an evolutionary change management approach, offering a detailed, prescribed map that feels safer to traditional enterprise leadership.

The danger arises when executives treat SAFe as a commercial shortcut—opening their checkbooks for certifications while remaining unengaged in the hard work of cultural change. As W. Edwards Deming put it, if leadership does not show up and engage in the transformation, don’t bother sending anyone else.

The way out of this trap is to measure real outcomes rather than framework compliance—focusing on customer value, flow metrics, and empirical feedback loops.

SAFe is a map, and the map is not the territory. What determines whether an implementation produces agility or theater is leadership intent and continuous improvement.

To move beyond mechanical SAFe:

• Treat SAFe as a starting scaffold, not a permanent ceiling.
• Evolve the Scrum of Scrums from a delivery status reporting meeting into a continuous improvement community of practice.
• Coach Scrum Masters to move away from being team focal points and toward true servant leadership.
• Connect Product Owners directly to customers, minimizing proxy translation layers.
• Focus on Flow Metrics and Evidence-Based Management (EBM) to measure actual value delivered rather than framework compliance.

Watch the Breaking the SAFe Series

Prefer to watch the full discussions? Check out the complete playlist from our Breaking the SAFe series with Ryan Ripley: