“Since evil is specially characterized by its diffusion, and attains its greatest height when it simulates the appearance of the good…”
— Origen, on recognizing the Antichrist
Origen wasn’t talking about enterprise Agile frameworks—yet his words feel eerily relevant when looking at the Scaled Agile Framework for Enterprise (SAFe). SAFe presents itself as the path to alignment, clarity, and true business agility. It looks good. It sounds good. It promises miracles.
And yet, once implemented at scale, it often diffuses dysfunction instead of curing it.
Since its introduction in 2011, SAFe has exploded in popularity—hundreds of thousands certified, countless enterprises adopting it. If you work in product, design, or engineering, you will likely encounter SAFe at some point. And if you do, it’s worth asking: Does this framework generate agility, or does it simulate the appearance of agility while reinforcing the exact opposite?
My view: SAFe is unsafe—especially when foundational Scrum isn’t healthy.
SAFe Fails Because It Scales What Already Isn’t Working
Here’s the central premise:
If basic Scrum isn’t functioning, scaling Scrum will amplify the dysfunction.
Trying to “fix” weak Scrum by layering SAFe on top is like trying to stabilize a shaky table by attaching a second, larger shaky table underneath.
Before we talk about Portfolio Epics, Agile Release Trains, or multiple levels of planning hierarchy, we need to address the real root cause:
Most organizations never achieve working Scrum in the first place.
Below are the seven most common Scrum dysfunctions. If any of these exist, SAFe doesn’t fix them.
It institutionalizes them.
1. Undone Scrum
Teams that can’t deliver a “Done” increment each Sprint can’t inspect and adapt meaningfully. SAFe assumes reliable two-week increments, but if you can’t finish work in two weeks, planning ten-week increments (PIs) is pure theatre.
Scaled effect: Undone work gets buried under layers of trains, dependencies, and PI plans.
2. Mechanical (Zombie) Scrum
Events occur but without intention or empiricism. SAFe adds more ceremonies and governance, but without a heartbeat of continuous improvement they just become more motions to go through.
3. Dogmatic Scrum
Scrum experts enforcing “best practices” kill team self-organization. SAFe, being prescriptive at scale, becomes dogma with job titles.
4. One-Size-Fits-All Scrum
Scrum is intentionally lightweight so teams can shape their own ways of working. SAFe standardizes practices across dozens or hundreds of teams.
5. Water-Scrum-Fall
Micro-waterfall within Sprints or “Sprint execution” surrounded by big upfront planning. SAFe’s PI Planning can easily bring back waterfall—just with sticky notes.
6. Good Enough Scrum
Teams get some efficiency while tolerating major impediments. SAFe bakes these organizational impediments into its governance model.
7. Snowflake Scrum
Teams believe they’re unique and distort Scrum to hide problems. SAFe offers an even bigger environment to hide dysfunction under “alignment.”
SAFe’s Top-Down Control: A Familiar Smell from PRINCE2 Agile
Some argue that SAFe’s top-down control is similar to PRINCE2 Agile, and they’re right—and this isn’t always bad. When Scrum teams lack a strong, empowered Product Owner, the team is effectively rudderless. Scrum doesn’t fail for lack of mechanics; it fails because:
- The Product Owner isn’t making decisions
- Backlog items aren’t shaped or prioritized
- Vision isn’t communicated
- No one owns value
Scrum’s design is explicit:
The Product Owner should place Epics and Stories onto the backlog, prioritize them, and provide leadership. The team selects work based on that prioritization.
When the Product Owner is weak, disengaged, or stripped of authority, the whole system collapses.
SAFe attempts to solve this through structure—Portfolio, Product Managers, System Architects, Release Train Engineers—but structure doesn’t create leadership. What often happens is dilution: decision-making is spread across multiple roles, and no one is truly accountable for the product.
This mirrors PRINCE2 and PRINCE2 Agile where the Project Board Executive is effectively the Product Owner. If that leader is weak, indecisive, or politically constrained, the entire governance system collapses, regardless of how well-documented the framework is.
And this is the uncomfortable truth:
A weak Product Owner in Scrum almost always becomes a weak Product Owner in SAFe.
SAFe cannot manufacture courage, clarity, or accountability.
It can only scale whatever you already have—good or bad.
SAFe Doesn’t Remove Root Causes — It Scales Them
Applying the classic 5 Whys, almost every release delay or dysfunction eventually traces back to:
- Backlog items are too large
- Work isn’t broken down early enough
- Progress isn’t transparent
- Silos persist
- Risks aren’t surfaced early
- Team collaboration is weak
- Ownership is unclear
SAFe does not remove any of these conditions. It just adds dependencies, roles, and ceremonies that make the symptoms harder to see.
So… When Is SAFe Safe?
Only when:
- Teams deliver “Done” increments every Sprint
- The Product Owner is strong, empowered, and accountable
- Scrum is practiced with intention, not mechanics
- Dependencies are shrinking, not growing
- Leadership understands empiricism and trusts teams
In short: SAFe only works when you already don’t really need SAFe.
Conclusion
Scaling agility is possible—but only when the basics are strong. Healthy Scrum teams with clear ownership, transparency, and courage can scale. Dysfunctional teams cannot.
Origen warned that the greatest dangers appear when evil imitates the good. SAFe often looks like agility, sounds like agility, brands itself as agility… but without healthy Scrum beneath it, it becomes bureaucracy with a new coat of paint.
If Scrum is weak, SAFe will be unsafe.