Breaking the SAFe: Reclaiming Professional Scrum

SAFe is not a niche argument in the agile community. It is everywhere, especially in large organizations that need some answer to a very real question: how do we coordinate hundreds or thousands of people without pretending a single Scrum Team pattern is enough? That is why the framework keeps showing up. It gives leaders roles, planning events, training paths, and a language they can put around a scary change. The trouble starts when that structure becomes the point. Then the organization gets the ceremonies, the terminology, the predictability charts, and the certifications, but the work still flows through the same old decision bottlenecks.

That is the line Ryan Ripley and I kept pulling on in the first season of Breaking the SAFe. I come at this as someone who has lived inside both worlds: SAFe Fellow and SPCT on one side, Professional Scrum Trainer on the other. So this series is not a loyalty test. It is an attempt to separate the useful change-management scaffolding from the places where SAFe can quietly preserve command and control with agile words wrapped around it. If you are working in a SAFe environment, the practical move is not to win a framework debate. It is to keep asking where the framework is helping you get closer to real agility, and where it has hardened into Agile Theater.

The opening episode sets the stance for the whole season. Ryan and I wanted to get out of the usual SAFe argument, where one side treats the framework as the only adult answer for the enterprise and the other side treats it as rebranded waterfall. Both reactions miss something. SAFe did not become popular by accident. It answered a real enterprise anxiety: “Where do we even start when we have multiple products, many teams, old architecture, dependencies everywhere, and executives asking when things will land?”

That is the appeal of the recipe. SAFe gives people names for roles, events, artifacts, planning horizons, and leadership responsibilities. For an organization coming from project portfolios, annual funding, and dependency-heavy delivery, that can feel like a huge relief. But a recipe is not the meal. The point of adopting a scaling framework should be to create better flow of value, better learning, and better decisions. If the organization stops at the recipe, it can look more agile while becoming less willing to inspect the system underneath.

The move I would make while watching this episode is simple: ask what problem SAFe is actually solving in your environment. Is it giving leaders a way to engage with change they had been avoiding? Good. Is it giving delivery managers a new set of labels for the same control system? That is where the danger starts.

The Scrum Master role is one of the quickest places to see whether a SAFe implementation is growing agility or just managing work with new words. In Scrum, the Scrum Master serves the team and the organization by helping people understand and live Scrum, removing impediments, and coaching self-management. In many SAFe environments, the Scrum Master also becomes the person who represents the team in cross-team coordination, tracks delivery, escalates issues, and explains progress upward.

Ryan’s challenge is fair: when the Scrum Master becomes the team’s official spokesperson, the team can lose the muscle of self-management. The role starts to look like project management with different training. My defense of SAFe here is also real, but it is not a blank check. SAFe is making a change-management concession. Many organizations are not ready to move directly from command-and-control delivery to truly self-managing teams. SAFe splits the broader coaching load across Scrum Masters, Release Train Engineers, and SAFe Practice Consultants because that maps more closely to the structures many enterprises already understand.

The risk is that the concession becomes permanent. If you are a Scrum Master in a SAFe environment, the practical question is not “what does the framework say I attend?” It is “where am I still standing between the team and the responsibility they need to own?” Try having team members represent their own dependencies in Scrum of Scrums or ART Sync. Use the role to reduce the need for you as a delivery broker, not to become better at brokering delivery.

PI Planning is probably the SAFe practice people either defend or attack most loudly. And again, the honest answer is less satisfying than the slogan. A quarterly planning event is not automatically anti-agile. Product organizations need medium-range alignment. Multiple teams working through real dependencies need shared conversations. Leaders need a way to see where strategy and funding are colliding with capacity, architecture, and reality.

The problem is what too many organizations do with the plan after the event. If PI Planning becomes a three-month commitment factory, it fights the very adaptability agile was supposed to create. Teams leave with sprint-by-sprint backlogs that are treated as fixed contracts. Executives get a confidence score and start acting as if uncertainty has been handled. Then reality arrives: dependencies shift, technology behaves badly, customers learn something, and the plan becomes a source of pressure instead of a tool for learning.

The better use of PI Planning is to create shared intent. PI Objectives should behave more like Sprint Goals than like a roll-up of story lists. Sprint plans inside the PI should be treated as hypotheses. The IP iteration should not become a garbage bin for slipped work. And the most important scaling move is often outside the planning event entirely: build the engineering and release capability to deliver value continuously so the organization does not need to batch all its learning into one giant cadence.

The Product Owner split is the SAFe choice I would watch most carefully. In Scrum, the Product Owner is accountable for maximizing product value. That does not mean one person writes every story or makes every decision alone, but it does mean accountability is clear. In SAFe, product responsibility is spread across Product Owners, Product Managers, Solution Managers, Epic Owners, and other roles. That can be a pragmatic map of how large companies already work. It can also create the proxy ownership trap.

The failure mode is familiar: the Product Manager owns budget, market context, and strategic choices, while the team-level PO becomes a backlog administrator. The team asks the PO for answers. The PO asks the Product Manager. The Product Manager asks stakeholders. By the time the answer gets back to the team, the decision has already cost more than it should have. Worse, the team learns that product ownership is something that happens elsewhere.

The reason SAFe made this choice is cognitive load. In a large enterprise, one person often cannot hold market strategy, stakeholder management, daily team availability, and backlog refinement for a large product or value stream. That is a real constraint. But the answer cannot be to settle for story writers. The healthier direction is descaling: shape product boundaries and architecture so more teams can own meaningful product slices end to end. Until then, PMs and POs need to work as a peer product team, with explicit conversations about which decisions are centralized for now, which ones can move closer to teams, and what would have to change for more ownership to move down.

Marty Cagan’s critique lands because he is pointing at something real: the strongest product companies do not scale by installing a heavy process framework. They scale through empowered product teams, strong product leadership, technical excellence, and architecture that lets teams move without waiting on everyone else. From that vantage point, SAFe can look like a process answer to a product and engineering problem.

My pushback is about context. A regulated enterprise like a bank or health care company does not start from the same baseline as a digital-native product company. It may need scaffolding to create leadership engagement, portfolio conversations, and cross-team coordination. That does not make the scaffolding the destination. The danger is when an organization installs the process layer and thinks it has earned the outcomes of a product company without doing the harder work underneath.

This is also where technical excellence becomes non-negotiable. You cannot scale a mess. If architecture forces every change through many teams, no planning ceremony will save you. If automated testing is weak, the PI becomes a negotiation about risk instead of a plan for value. If deployment is painful, the organization will keep batching and calling it coordination. Use the framework, if it is already in your environment, to make the case for decoupling, automation, smaller batches, and stronger product discovery. Otherwise the process becomes a wrapper around the same old constraints.

Ken Schwaber’s 2013 critique, “UnSAFE at any Speed,” is one of the sharpest Scrum-community objections to SAFe. The core concern is that SAFe can repave the old waterfall road with agile vocabulary. That criticism is uncomfortable because it is easy to find examples where it is true. A company keeps the same approval chains, same project funding, same dependency structure, same release pain, and same top-down planning habits, then adds agile roles and calls it transformation.

Scrum and SAFe also have different theories of change. Scrum is intentionally disruptive. It gives you odd roles, short feedback loops, and a simple framework that exposes organizational impediments fast. SAFe is more evolutionary. It maps onto existing structures so the enterprise can start moving without feeling like everything was blown up on day one. Both moves have tradeoffs. Shock therapy can be rejected by the system. Evolution can become a polite way to leave the system unchanged.

The escape hatch is Evidence-Based Management. If leaders measure process compliance, teams will optimize for compliance. If leaders compare teams on velocity or weaponize predictability scores, teams will learn how to look predictable. If leaders measure outcomes, time to market, ability to innovate, customer satisfaction, and the current ability to deliver value, the conversation changes. The practical test for your scaled environment is this: are your metrics helping you descale and improve flow, or are they helping you defend the current operating model?

The final episode gets very practical: Ryan studies for the SAFe Practice Consultant exam from the perspective of a Professional Scrum Trainer. That creates a useful tension. To pass the exam, you have to answer in SAFe’s language and logic. You cannot answer every question from the Scrum Guide and expect the scoring system to reward you. That is not a moral failure. It is a reminder that certification tests whether you understand a model, not whether you can coach a real organization through messy change.

The SPC path matters because SPCs are often the people who shape how SAFe shows up in an organization. A strong SPC can help leaders understand the intent behind the framework and adapt responsibly. A weak one can turn the implementation into courseware compliance. The exam may be rigorous as a knowledge check, but it cannot prove someone has the judgment to work with power, incentives, architecture, product boundaries, and leadership habits.

If you are pursuing SPC certification, use the practice test as a diagnostic, then study the articles behind the workbook rather than memorizing slides. More importantly, decide what kind of SPC you want to be. The useful version understands SAFe well enough to explain the intent, challenge weak implementation choices, and help the organization move toward better outcomes. The dangerous version enforces the framework as if compliance were the goal.

If you are working inside a SAFe environment, the useful next step is not to declare the framework good or bad. Pick one place where a SAFe concession has hardened into a constraint, then run a small experiment that moves ownership and learning closer to the work.

See where you are now, identify your #1 constraint, and get a focused next step. Take the Product Agility Health Check (11 questions, ~5 minutes).