SAFe Strengths, Weaknesses, and Controversies

Is SAFe good? Is SAFe agile? What are its real strengths and weaknesses? These are among the most hotly debated questions in agile circles, and most of the debate generates more heat than light. I sit in an unusual spot: I am a SAFe Fellow and SPCT, and also a Professional Scrum Trainer, which means I can argue both sides honestly — explain SAFe’s intent and rationale, and challenge its choices, without it being a loyalty test. This post is built from a special episode of Scaling with Agility that featured an AI-generated overview of the Breaking the SAFe video series I recorded with Ryan Ripley, deconstructing the framework and separating the fair criticism from the fear, uncertainty, and doubt.

The honest summary: SAFe is popular for a real reason — it gives large organizations a recipe, with roles, ceremonies, and cadences, when “where do we even start with hundreds of developers” is a genuine problem. PI planning is genuinely powerful for coordinating dependencies, and genuinely risky as an invitation to over-plan. The most-debated choices — a Scrum Master role that drifts toward project management, and a “fractured” product ownership structure spread across many titles — are real weaknesses and deliberate attempts to meet large organizations where they are. The thing that actually determines the outcome is not the framework. It is whether leadership bought into the why, and whether the organization keeps challenging the status quo instead of checking boxes.

Updated June 2026: The podcast episode was originally published on August 13, 2025. I refreshed this companion article with the podcast link, the YouTube episode, and a cleaner written version of the main takeaways.

It is worth starting honestly: SAFe is everywhere. It is not a niche thing, and there is a reason so many large organizations have adopted it. The reason is that it gives you a recipe. Here is how you do it — here are the roles, here are the ceremonies, here are the cadences for getting work done. When you are inside a large organization that is used to operating from a recipe, that feels comfortable and safe.

And the problem SAFe is answering is a real one. If you are a leader staring at hundreds of developers across multiple product lines, “be more agile” is not actionable advice. Where do I even start? is a legitimate question, and SAFe gives you a roadmap to point at. It is especially appealing to organizations early in their agile journey, where the alternative feels like staring at a blank page. On top of that, executives are asking the eternal questions — how are we doing, what’s the progress, when can we expect this — and they want to see dependencies and timing laid out. SAFe checks that box. It looks like agile and it still has the structure leaders are asking for.

That last sentence is also the opening for the central criticism. Looking like agile and being agile are not the same thing.

The sharpest version of the criticism is the line about putting agile lipstick on a waterfall pig — that SAFe is just waterfall rebranded. I do not think that is fair as a blanket statement, but I also do not think it is baseless, and the place it lands hardest is PI planning.

Program Increment planning is SAFe’s mechanism for getting all the teams on the same page on a shared plan, usually across a roughly three-month time box. When you have a lot of teams with a lot of dependencies, that can be genuinely powerful — it is hard to coordinate that many moving parts without some shared planning moment. But it also introduces a real risk: doing too much planning up front. Agile is supposed to be about adaptability, about responding to change. If you lock yourself into a detailed three-month plan and treat it as fixed, you have quietly traded away the thing that made agility valuable.

The Southwest Airlines holiday meltdown gets cited here, and it is worth being careful with it. There were many factors in that event — outdated technology chief among them — and pinning it on SAFe alone is lazy. But the criticism that surfaced is directional: an organization that has planned itself into a corner cannot adapt when things inevitably go wrong. That is the real failure mode to watch for.

In fairness, even SAFe’s own proponents will tell you the PI plan is meant to be a guide and a starting point, not set in stone — the framework explicitly emphasizes inspect-and-adapt, checkpoints, and feedback loops. So the honest question is not “is SAFe waterfall?” It is whether a given organization actually uses the adaptive mechanisms, or just performs them. You can have every ceremony in place and, if you are not embodying the principles behind them, it is theater. The real challenge is the delicate dance of finding enough structure to coordinate effectively without so much structure that you lose adaptability — and that balance is different for every organization, and sometimes different for teams inside the same organization.

The first role-level controversy is the SAFe Scrum Master, and the phrase that gets thrown around is “project manager in disguise.”

In Scrum, the Scrum Master serves the team — removing impediments, helping the team gel, coaching the values, acting as something of a shield from the rest of the organization. In SAFe, the role picks up additional responsibilities: coordinating with other teams, facilitating larger ceremonies like PI planning, and managing up to some degree, including a reporting element. Once you add reporting and cross-team coordination, you can see why critics say it has drifted well past serving the team and toward project management. And the deeper objection is principled: if the whole point is self-managing, empowered teams, why hand them a project manager in a different guise? It puts the Scrum Master in a genuine bind — coach or referee, serving the team or enforcing the structure — and it is hard to be both at once.

SAFe’s answer is the “meet organizations where they are” argument, and it deserves a fair hearing. Most large organizations cannot flip a switch and suddenly have fully self-managing teams; that is too much of a culture shock. So SAFe positions this role as a stepping stone — give people a role that feels familiar and carries some traditional management responsibilities, then coach those Scrum Masters over time to step back and grow into genuine servant leaders. Evolution, not revolution. I find that logic reasonable. I also think it backfires easily: someone comfortable in command-and-control mode will happily stay there, and without the right training, guidance, and support, the “stepping stone” just reinforces the old habits it was supposed to replace.

The second controversy is product ownership, and it is the one I think matters most. In agile, the product owner is the North Star — the voice of the customer, the single point of accountability for the product’s success. SAFe spreads that across a chorus of roles: product owners, product managers, solution managers, epic owners, all with hands in the pot, with different titles, different levels of authority, and potentially different priorities.

The concern is straightforward. With so many roles, who is actually in charge? Where does the buck stop? And more importantly, the layers dilute customer focus. Agile is supposed to be relentlessly customer-centric — who are we building this for, what is their pain, are we solving their problem, are we building the right thing. The more layers you put between the team and the customer, the easier it is for that signal to get muddled in translation.

SAFe’s defense is again pragmatic: large organizations already have these layers, these hierarchies, these decision-making structures. SAFe is not trying to blow them up; it is trying to give them a way to work within the system they actually have. I understand that logic, and I have seen it help organizations get started. But the honest question is “at what cost?” — are you genuinely moving toward agility, or slapping a new label on the same old thing with more steps? That answer is context-dependent, and any organization considering SAFe needs to grapple with it directly rather than wave it away.

If there is one thing I want a leader to take from breaking SAFe down honestly, it is this: SAFe is a tool, and like any tool it can be used well or used badly. It is a powerful, comprehensive framework with a lot of components, and it can genuinely help organizations that need structure and a recipe to scale agile. It can also become an elaborate way to perform agility while changing nothing.

What separates those two outcomes is not the framework. It is leadership. The question underneath every SAFe adoption is how much the leaders are bought into the why — the why behind agile. Are they adopting it because it is the buzzword, because it promises faster or cheaper delivery? Or are they actually trying to change how the organization thinks about work? You cannot tell from the certifications on the wall or the ceremonies on the calendar. You can only tell from whether the organization keeps asking hard questions, keeps challenging its own assumptions, and keeps inspecting and adapting — not just its product, but its process.

That is the heart of agile, and no framework supplies it for you. If you are living and breathing continuous improvement, SAFe can be a useful scaffold. If you are not, it will not magically transform anything — and neither will any other framework or certification. Keep the agile principles close; they are the guiding lights. The framework is just the map, and the map is not the territory.

This article is based on a special Scaling with Agility episode featuring an AI-generated audio overview of the Breaking the SAFe video series I recorded with Ryan Ripley — a full-season deconstruction of the framework, its intent, and its most contested choices.

Listen on the episode page, open it directly on Spotify, or browse the rest of the podcast.

SAFe is neither the villain nor the savior its loudest critics and defenders make it out to be. It is a tool. Whether it produces agility or theater is decided by leadership intent and the willingness to keep challenging the status quo — not by the framework itself.