Frank Neff
SAFe gives leaders a comforting sense of order: roles, layers, roadmaps, and predictable increments. But too often, that “safety” hides something familiar – Waterfall dressed up with agile terminology.
On paper, SAFe promises agility at scale. In practice, it often turns into months-long planning cycles, extra layers of governance, and top-down control with new names. The labels change – “epics” instead of projects, “program increments” instead of deadlines – but the behaviors stay the same.
Which brings us to the real question: Is SAFe actually helping companies become agile, or is it just Waterfall in disguise?
SAFe wasn’t designed as a trick. It’s a genuine attempt to solve the problem of scaling Agile in large, complex enterprises. And at first glance, it offers structure, alignment, and predictability.
But those same qualities are also where it stumbles:
At its best, SAFe creates clarity. At its worst, it rebuilds the rigidity Agile was meant to dismantle.
The framework is heavy on its own, but the way companies use it is often worse. Too many organizations adopt SAFe as a way to rebrand old behaviors instead of changing them.
Patterns show up quickly:
The result? More process, not less. Teams carry the weight while executives get dashboards and optics.
It’s not hard to see why SAFe is appealing in the boardroom.
Executives crave control and predictability. Quarterly PI planning feels reassuring; it provides roadmaps, milestones, and a sense of certainty. For leaders raised on Gantt charts and status reports, SAFe speaks their native language.
It also provides familiarity. Unlike lightweight approaches such as LeSS or Nexus, SAFe doesn’t ask leaders to give up much power. It wraps Agile practices in layers of structure that feel comfortable to those used to hierarchical management.
And let’s be blunt: SAFe enables optics without discomfort. Leaders can say, “We’ve gone Agile” without changing how they actually lead. The culture – empowerment, trust, experimentation – stays the same. The framework becomes a costume, not a catalyst.
That’s why SAFe spreads so easily. It lets organizations rebrand themselves without doing the hard, uncomfortable work of cultural transformation.
This illusion of agility comes with a price.
Teams quickly realize that despite the new titles, they don’t actually have more empowerment. Decisions are still centralized. Priorities are still handed down. Their autonomy is mostly rhetorical.
The additional layers and ceremonies mean that delivery slows down instead of speeding up. By the time a feature makes it through the governance maze, the market has often moved on.
And perhaps most damaging, the core values of Agile get buried. Customer collaboration, rapid feedback, small experiments – they get replaced by process compliance and meeting cadence. The energy that was supposed to go into learning and adapting ends up going into producing artifacts and aligning with roadmaps.
In short: SAFe risks giving organizations the worst of both worlds – the rigidity of Waterfall combined with the overhead of scaled Agile.
Scaling Agile doesn’t have to mean adopting the heaviest framework in the catalog. The goal isn’t to scale
bureaucracy, it’s to scale principles: autonomy, collaboration, and a relentless focus on delivering value.
Below are some approaches that tend to work better in practice.
Big transformations often fail because they start big. Instead of designing a full-blown operating model up front, begin with the lightest structure you can get away with.
Add layers of coordination only when the pain of not having them becomes impossible to ignore. This way, your scaling approach grows out of real needs rather than wishful planning.
Agility at scale lives and dies with team autonomy. If your “Release Train Engineer” functions like a renamed project manager, you’re just recreating old command-and-control dynamics.
Push decision-making closer to the people doing the work. Give teams ownership not just of delivery but of direction: what gets built, how it’s built, and how it’s validated with users.
Too many organizations still measure success by whether features ship “on time.” But a feature that arrives on schedule and fails to move the needle for customers is just waste delivered efficiently.
Shift your metrics to outcomes: churn reduced, adoption increased, satisfaction improved. When teams are measured by impact rather than activity, agility starts to mean something tangible.
Before reaching for SAFe, try lighter approaches. Frameworks like LeSS or Nexus emphasize simplicity and transparency over ceremony. I’ve seen 100-person orgs align with nothing more than Scrum of Scrums plus a quarterly strategy workshop.
These models won’t impress with giant posters, but they’ll often deliver faster learning and less overhead.
No framework will succeed if leadership clings to control. Culture change has to come first. That means training leaders to embrace empowerment, trust, and experimentation, even when it feels uncomfortable.
Frameworks can be helpful scaffolding, but without a cultural shift, they quickly turn into theater – process for the sake of optics rather than progress.
Is SAFe just Waterfall wearing a hoodie? Not entirely. On its own, SAFe isn’t pure Waterfall – it contains practices that can help align large organizations. In the right hands, with the right culture, it can work.
But here’s the catch: In most companies, SAFe doesn’t make agility easier. It makes it harder. Its layers and ceremonies provide cover for leaders who want the optics of “agile” while keeping their old command-and-control mindsets. For them, SAFe becomes the perfect disguise: Waterfall in fancy new wording.
If you suspect your SAFe rollout looks more like an excuse than a transformation, don’t double down. Strip back the layers. Focus less on the framework and more on the principles: Empowered teams, fast feedback, and delivering outcomes that matter.
Written By
I see myself as a curious problem solver. On a life-long mission to enable people, improve tools and optimize processes, I build software to make things work. Moreover, I like to talk about technology and sharing know-how in a team to improve my own …
Frank Neff
Most agile teams say they use a Definition of Ready (DoR) and Definition of Done (DoD). In practice? They’re often ignored, overcomplicated, or so vague they don’t help anyone.
Over the years, I’ve refined a lean, practical version of both. It’s sharp enough to be useful across companies and simple enough that people actually use it.
Read More
Frank Neff
Almost every company today claims they’re “agile.” They run standups, hold retros, track velocity. The word shows up in job postings, investor decks, and board meetings.
But let’s be honest: In 99% of cases, “agile” is just a buzzword. It’s a label slapped on the same old waterfall process, dressed up with sticky notes and Jira boards.
I’ve stepped into SaaS companies where work still moved in quarterly chunks, QA was a final-phase bottleneck, and priorities were dictated top-down. Nothing about that was Scrum or Kanban — it was waterfall in an agile costume.
Read More