The Agile Handbook

Scaled Agile Framework (SAFe): An Honest Assessment

Last updated on

Scaled Agile Framework (SAFe): An Honest Assessment

SAFe Is Not Agile. It’s Enterprise Change Management Wearing Agile Clothes.

That’s not a criticism. It’s a clarification that most organizations need before they adopt SAFe and end up confused about why it feels so heavy.

SAFe — the Scaled Agile Framework — solves a real problem: how do you get 200 developers working on the same product without descending into coordination chaos? That’s a genuine, hard problem and SAFe addresses it. But the solution involves layers of roles, ceremonies, and governance that have more in common with program management than with the lean collaboration the Agile Manifesto describes.

This isn’t a dealbreaker. It’s context you need to evaluate SAFe honestly.

What SAFe Actually Is

SAFe is a comprehensive framework for coordinating Agile teams at scale. It was developed by Dean Leffingwell and launched in 2011, drawing from Scrum, Kanban, XP, Lean, and DevOps. It organizes work across four levels:

The framework’s defining artifact is the Program Increment (PI) — a 10-12 week planning and delivery cycle that synchronizes all teams. Every PI begins with “PI Planning” — a large, often in-person event where all teams plan their work for the coming quarter together, identify dependencies, and make commitments.

If that sounds like quarterly planning with extra steps, you’re not wrong, and that’s simultaneously its strength and its limitation.

The Case for SAFe

Here’s what SAFe genuinely solves:

Cross-team dependencies become visible. When 15 Scrum teams are independently planning their sprints, dependencies between teams are invisible until they become crises. PI Planning surfaces these dependencies explicitly. Teams identify them, negotiate them, and commit to resolving them. This is valuable organizational engineering.

Strategy connects to execution. SAFe’s Portfolio level links business strategy (Epics and Strategic Themes) to program-level features to team-level stories. This chain of alignment is something most large organizations lack. Executives fund initiatives; teams build features; nobody is sure how the features relate to the initiatives.

It provides a change management path. Large organizations can’t transform to Agile overnight. SAFe provides a structured, incremental path that works within existing governance and reporting structures. This isn’t ideally Agile, but it’s pragmatically achievable.

The Case Against SAFe (Or At Least For Skepticism)

A three-person startup trying SAFe is like bringing heavy construction equipment to plant a herb garden. SAFe is specifically designed for large, complex organizations with many teams. For teams of fewer than 50 people, Scrum, Kanban, or just good communication practices will serve you better with dramatically less overhead. SAFe’s complexity is justified by the coordination problems of large organizations; if you don’t have those problems, you don’t need that solution.

PI Planning can become theater. The two-day PI Planning event is powerful when teams are genuinely empowered to influence plans and surface risks. It becomes expensive theater when executives have already decided the priorities and teams are playing along. I’ve seen PI Planning events where the top features were decided before anyone entered the room and the two-day “planning” was essentially a communication exercise. That’s not nothing, but it’s not worth the cost of flying 200 people to a conference center.

SAFe can institutionalize Waterfall at the portfolio level. The quarterly PI cycle creates a planning horizon that can become a commitment horizon. If your organization treats the PI plan as a contract — if there are consequences for not delivering what was committed in PI Planning — you’ve recreated the problems of Waterfall at a higher level of abstraction. True agility requires the ability to change direction mid-PI when circumstances change. Many SAFe implementations resist this.

The role explosion creates overhead. The Release Train Engineer, Solution Train Engineer, System Architect, Business Owner, and Product Management layers add coordination capacity but also communication overhead. Every additional role is a potential bottleneck or translation point. Teams in lean SAFe implementations often find their best productivity when they minimize the number of handoffs between roles.

When SAFe Is the Right Call

Use SAFe when:

Don’t use SAFe when:

Implementing SAFe Without Drinking All the Kool-Aid

SAFe is modular. You don’t have to implement all four levels simultaneously. Many organizations start with Team and Program levels only, adding Large Solution and Portfolio levels when they have demonstrated need for them.

The highest-leverage starting point is almost always PI Planning. Even if you don’t adopt SAFe wholesale, the practice of bringing all your teams together for two days of cross-team dependency identification and synchronized planning is valuable and underutilized. Many organizations do this informally without calling it SAFe; formalizing it pays dividends.

Start with three practices:

  1. PI Planning every 10-12 weeks
  2. A single prioritized Program Backlog that all teams draw from
  3. Regular System Demo showing integrated work from all teams

That’s a SAFe foundation. Evaluate what’s working. Add complexity deliberately, not because the SAFe training recommends it.

The Bottom Line

SAFe is a real solution to a real problem that exists at scale. Its critics are right that it’s heavy and can calcify into bureaucracy. Its advocates are right that uncoordinated Agile at scale is frequently worse — teams racing in different directions, dependencies exploding, strategy disconnected from execution.

The question is not “is SAFe Agile enough?” The question is “does my organization’s coordination problem require SAFe’s solution?” If you have 10 teams with serious dependency problems and strategic misalignment, SAFe probably helps. If you have 3 teams who mostly work independently, SAFe will make you slower.

Apply the right tool to the right problem. That’s the most Agile thing you can do.