Can you rely on SAFe to deliver elite-performer gains?

The cadence got shorter; the shape didn’t change: SAFe is what happens when you keep the waterfall org chart, rename the meetings and run a PI Planning event over the top.

Photo by Natalia Marcelewicz on Unsplash

I recently wrote about the gains product teams reliably post. But that article left an opening: what exactly is a product team? In part, that’s a question this article answers — as well as, “can a product team use SAFe?” (If you haven’t read it, Receipts is the lead-in).

Just about every large pre-Internet company out there today has some sort of “digital transformation initiative,” but what most of them don’t realize is that the heart of this transformation is moving from project-mindset to product-mindset. — Marty Cagan, Founder, Partner, Product at SVPG

Forty-plus people, a chunk of a week blocked off, a cavernous meeting room commandeered. Sticky notes color-coded by team. Butcher paper taped along the walls. Somewhere near the front, a Release Train Engineer is walking the room with a Sharpie, drawing red strings between dependent features. By the end of day two, every team has its slice of a 10-week plan committed to the wall, and a senior leader is asking each team for a five-finger confidence vote.

I’ve watched that scene play out. I know what comes next. Six weeks from now, three of those red strings will have moved, two features will be quietly cut and one team will be rebuilding a thing nobody asked for. The plan that got committed is not the plan that ships. Everyone in the room knows. Nobody says it.

But the plan got a vote. The Release Train left the station. It’s now truth — until the next PI, when a slightly different plan will become the next truth. The change orders get signed and project budgets run over in the guise of “increased scope.”

That’s PI Planning. And I’m going to argue, carefully and with receipts, that what just happened in that room is waterfall on short cycle — and almost nothing about it is recognizably agile.

If you're new, welcome to Customer Obsessed Engineering! I publish about one article each week. Free subscribers can read about half of every article, plus all of my free articles.

The premise we're not going to relitigate

I am not going to relitigate whether product teams outperform. I made the case in Product teams really do outperform: bringing the receipts. DORA, McKinsey, Pendo, Standish and Project Aristotle converge unambiguously. Small, durable, cross-functional teams that own a problem end-to-end deploy 182× more frequently, ship higher quality, redefine “done” around outcomes and drive four to five times faster revenue growth than the alternatives.¹

Take that as given. The question for today is narrower: if that is what real agility looks like, where exactly does SAFe land on the map?

The short answer — the one I will spend the rest of this article defending — is that SAFe lands far closer to waterfall than its name implies. Not because its proponents are dishonest. Because its structural unit of planning, funding and authority is the Agile Release Train, not the team. And that single design choice quietly recreates every handoff, gate and silo agile was meant to eliminate.

Before I break the case, let me make it

I owe SAFe and the people who chose it a fair hearing — and a fair hearing means arguing with its strongest version, not its sales deck. So let me make SAFe's case the way its creator makes it.

Dean Leffingwell does not justify SAFe by appeal to certifications or board-deck optics. He grounds it in flow economics — specifically Don Reinertsen's Principles of Product Development Flow, a serious book that the continuous-delivery world draws on too. The argument lives in SAFe's seventh principle, “apply cadence, synchronize with cross-domain planning,” and it runs like this. “Solution development is an inherently uncertain process… This risk conflicts with the need for businesses to manage investments, track progress, and have enough confidence in future outcomes to plan and commit to a reasonable course of action.” The resolution Leffingwell offers is a, “safety zone, where enough uncertainty actually provides the freedom to pursue innovation, while sufficient confidence allows the business to operate.” Cadence and synchronization are how you buy that confidence without freezing the work. PI Planning, in this telling, is not a commitment ritual — it is a periodic re-baselining of the plan against the objective state of working systems, which is SAFe's fifth principle.²

Take that seriously. The coordination problem SAFe addresses is real. Eight teams shipping into the same product surface need to know about each other's plans. Two hundred teams across a portfolio need someone to decide the trade-offs. Lean Budgets — funding value streams instead of approving each project individually — are genuinely better than the alternative most enterprises were running before. Inspect & Adapt at the end of each PI is a retrospective at scale, and that’s not nothing. PI Planning, for all its flaws, beats no planning. At the team level, SAFe leaves Scrum or Kanban in place. The bottom-up practices are still there.

There is also a colder, political version of the case, and it deserves the same hearing. SAFe is, in many enterprises, the only model executive leadership will fund. The CFO can read it. The PMO can map their roles into it (that’s a key point; hold on to it). The risk officer can find their gates. There is a certification track, a vendor, a roadmap. For an organization that needs to tell a board, “we are being agile,” SAFe is the politically survivable option. The choice between SAFe and a Cagan-style product transformation is rarely the choice on the table. The actual choice — for many large organizations — is between SAFe and the project-funded, requirements-thrown-over-the-wall, six-month-release waterfall it replaced.

So the honest steelman has two layers. Intellectually, SAFe is an attempt to operationalize real flow economics at enterprise scale. Politically, it is the floor, not the ceiling — and the floor is higher than what came before. For organizations starting from heavy-handed waterfall, SAFe is an upgrade on both counts.

That is the strongest case I can make, and I built it from SAFe's own foundations. Now let me explain why it isn't enough — and why the upgrade comes at a steeper price than its buyers usually realize.

Five tells that betray the waterfall underneath

If you want to know whether something is waterfall, do not read its marketing. Read its structure. Waterfall has diagnostic attributes — sequential phases, big-batch commitments, multi-team handoffs, stage gates with formal approval, plan-driven coordination above team level — and any process that exhibits those attributes will behave like waterfall whether or not it carries the name.

What follows are five attributes that SAFe exhibits, with the practices that produce each. Some of these will look familiar from the structural critique Marty Cagan put on the record in 2018. Others are mine, drawn from watching the framework operate across enterprise programs. The attributes are independent. Any one of them is a yellow flag. Three of them is a diagnosis. Five of them is what we are looking at.

Tell #1: the Release Train is a waterfall, on rails

Start with the name. Agile Release Train. The naming is not accidental — it is defensive. Strip the adjective and you are left with release train, which is exactly what waterfall organizations have always called their integrated, scheduled, multi-team delivery cycles. Pull a release train out of a 1995 PMO and it would have looked nearly identical to a SAFe ART: 50 to 125 people working toward a synchronized release at a fixed cadence, a release manager coordinating dependencies, a portfolio manager approving the work and a steering committee voting on the plan. SAFe replaced the release manager with a Release Train Engineer, the portfolio manager with a Lean Portfolio Manager and the steering committee with a PI Planning ceremony. The roles got new titles. The meeting got a Sharpie. The cadence shrank from six months to ten weeks. The shape did not change.

Look at what an ART actually does. It locks 50 to 125 people into a shared 10-week commitment. It synchronizes their backlogs into a single Program Backlog. It coordinates their dependencies — through a Solution Train, when the ART is too small to contain the dependencies on its own. It runs ceremonies — PI Planning, ART Sync, Scrum of Scrums, System Demo, Inspect & Adapt — whose entire purpose is to manage the friction created by the ART's own existence. Every one of those ceremonies is overhead a real product team does not pay, because a real product team does not have a 50-to-125-person commitment to coordinate around in the first place.³

Marty Cagan put this plainly enough that I want to quote him directly. In Revenge of the PMO, he writes that, “the critical notion of a dedicated product team (aka squad) has been gutted. In SAFe, this concept of a true product team has been undermined and demoted, and the core concept is now a Program, which has a top-down model of a product manager, an architect, and a release train manager, and these people make all the key decisions, and then some number of engineering teams with a low-level product owner are assigned various parts to build.” That is a verbatim description of a feature team inside a project structure. SAFe just renamed the project a Program and the project manager an RTE.⁴

Dave Farley — co-author of Continuous Delivery and not a man with a Scrum axe to grind — reached the same place from the engineering side. Writing about the clients he had watched adopt SAFe, he was blunt: “the orgs that I have seen try SAFe look indistinguishable from the orgs that pay lip-service to Scrum to me. In both cases, they look like waterfall orgs to me.” His objection is structural, and it lands on the load-bearing artifact directly. He dislikes the Release Train itself — “I think that they are an anti-Continuous Integration step,” one that, “represent[s] a plateau that halts team's progress towards a more effective flow-based approach.” The author of the canonical book on continuous delivery looked at the Release Train and saw the thing standing between teams and flow.⁵

Pull the Release Train out and SAFe collapses. Keep it in and you have kept every structural property that makes waterfall what it is — synchronized big-batch commitments, multi-team handoffs, a coordinator above the team, a plan that hardens the moment the room votes on it.

Tell #2: cadence as commitment

A 10-week PI plan is functionally a specification.

SAFe will tell you it is a forecast — soft alignment, not a frozen commitment. Confidence votes are five-finger, not yes-or-no. Teams can replan. Deployment is not locked to the PI. The wording is all soft. Look at what actually happens, though. The room agrees on a set of features for the PI. Those features get pulled into the Program Backlog. Engineers start work against them. Dependencies get committed to other teams' plans. Stakeholders are told what is coming. Mid-PI, the cost of dropping a feature is not zero — it is the team's confidence vote, the dependent teams' rework, the stakeholder's roadmap update, the RTE's coordination tax, the System Demo's missing slot.

So features almost never get dropped mid-PI — the discovery that should happen during the increment rarely does, and when it surfaces a problem, the dependencies make dropping the feature more expensive than shipping it anyway. The plan, framed as soft, hardens into something tighter than waterfall ever was — because waterfall at least admitted to being a commitment. PI Planning insists it is not a commitment, then behaves like one, and punishes anyone who treats it as if it isn't.

Compare this to a real product team. A team starting Monday morning with a hypothesis runs the cheapest possible test by Friday. If the data says no, the hypothesis dies before week two. The team has lost five days. No roadmap vote, no red strings. The stakeholder isn’t told anything because there is nothing to tell. One of these is research. The other is a Gantt chart that happens to be 10 weeks wide instead of 10 months wide.

Royce warned about this in 1970 — and it is worth remembering, because the diagram he drew has been the most consequential misreading in software engineering history. In Managing the Development of Large Software Systems, Royce presented the now-familiar sequential flow of phases and then said in the same paper that an implementation plan keyed only to those steps was “risky and invites failure.” The bulk of his paper argues that any large software system needs to iterate — that every commitment to a plan should be tested against working software before it hardens. People extracted his diagrams and ignored his warnings. PI Planning ships Royce's exact failure mode under a different name, on a shorter cycle. The cadence being shorter is the entire thing that is “agile” about it. Strip the cadence and what is left is a stage-gated portfolio process.⁶

This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.

Tell #3: the decomposition pyramid

Epic → Feature → Story is requirements → design → implementation, in different fonts.

The Epic is approved upstream by Lean Portfolio Management before it lands at the ART. The Feature is decomposed by a Product Manager and a System Architect before it lands at the team. The team's Product Owner — a role title borrowed from Scrum and stripped of Scrum's authority — turns Features into Stories. Each step down the pyramid is a translation from one set of vocabulary to another. Each translation loses information. By the time a Story is in front of a developer, the original customer intent has been refracted through three layers of people who did not sit with the customer and who do not sit on the team that will build the thing.

Where, exactly, does product discovery happen?

Discovery — as Cagan, Torres and the discovery-coaching tradition mean it — is hypothesis-testing with real customers before commitment. In SAFe, that work happens before the Epic enters the funnel, in a separate process, performed by people who do not sit on the team that will build it. The feature team receives a Feature already shaped by a Product Manager, refined by a System Architect, approved by Lean Portfolio Management and committed to by 50 to 125 of their colleagues at PI Planning. The team's role is to decompose the Feature into Stories and execute. That is not discovery. That is a business analyst with new vocabulary.⁷

I am not the first person to point this out. Jeff Gothelf, the co-creator of Lean UX, put it bluntly:

“All the principles we've built into Lean UX don't seem to exist in SAFe.”

He went on to note that customer-centricity, evidence-based decision-making, experimentation and course correction, “are visibly absent from the SAFe conversation.” He is right because the conversation cannot include them. The framework has placed those activities upstream of the team, and made the team's slot in the value chain a unit of execution, not a unit of inquiry.⁸

The Delivery Playbook focuses on customer value as a core practice — through value stream engineering and customer-centric design. These are not optional — they are table stakes. SAFe cuts both out of the conversation.

Tell #4: the team-ownership ceiling

A SAFe team does not own a value stream. It owns its slice of an ART.

End-to-end ownership of the customer outcome — what separates product teams from feature teams — lives at the ART or Solution Train level. That is the line Receipts drew with Cagan's framing of product, feature and project teams. SAFe puts the team on the wrong side of that line by design. The framework cannot fix this because the line is the design. The Release Train is the unit of ownership. The team is the unit of execution. Move the unit of ownership down to the team and you do not have an ART anymore — you have a portfolio of small product teams, which is what Cagan, Team Topologies and DORA's elite-tier qualitative findings all converge on.⁹

This is the structural reason SAFe transformations stall. The ceremonies improve. The ART runs more smoothly. PI Planning gets more efficient. Nobody on the team feels more agile, because nothing about the operating model above the team has changed. The team is still being handed Features it did not discover, against a 10-week commitment it did not negotiate, with deployment dependencies it cannot break. The agile-coach stack is workable. The teams are not.

Teams cannot build ownership in what they don’t own.

Tell #5: Lean Portfolio Management is the PMO with new business cards

The title is mine; the diagnosis is Cagan's — his article is literally called Revenge of the PMO.¹⁰

Look at what Lean Portfolio Management actually does. It captures Epics in a Funnel. It moves them through Reviewing and Analyzing states. It requires a Lean Business Case for each Epic before that Epic can advance. It gates approval at a Portfolio Backlog state. It tracks Implementation against the original case.

State the same workflow in 2005 vocabulary: capture projects in an intake queue, move them through analysis with required business cases, gate approval at portfolio review, track implementation against the original case. The verbs are identical. The artifacts are identical. The decision rights are identical.

SAFe's defenders will say Lean Budgets are different — funded to value streams, not projects — and that is fair, in principle. Funding value streams is a real improvement over funding projects. But the governance overlay — the gates, the cases, the approvals, the portfolio reporting — is the project portfolio management discipline that PMOs have run for thirty years. It’s not bad because it’s old. It’s bad because it sits above the team and makes the team's authority subordinate to the portfolio's case-building exercise. Authority for “what to build” still flows top-down. The team gets to decide how. That is exactly the bargain SAFe strikes: the project mindset wearing a costume.

If you have a PMO that has been quietly converting itself into Lean Portfolio Management, the costume is the only thing that has changed. The decisions are still being made by the same people, in the same room, against the same business cases, with the same approval ladder. Agile pushed the PMO to the side; Lean Portfolio Management is its path back into the room.

The DORA test

Here is the test I keep coming back to. It is short. It is fatal.