SAFe without the religion: what scaling frameworks are actually for

Few topics make software people roll their eyes faster than SAFe. I’ve lived on every side of this argument: I’ve delivered large-scale products through the framework, co-authored a peer-reviewed paper on its adoption, hold the certifications, and I’ve also watched SAFe implementations collapse into ceremony theater. So here’s the position I’ve actually earned: scaling frameworks are scaffolding, and scaffolding is not the building.

What the framework genuinely solves

At one or two teams, you don’t need SAFe and adopting it would be malpractice by overhead. The problems it addresses appear later and are real:

• Synchronized planning. Past a handful of squads, “we’ll coordinate as we go” produces integration surprises at the worst moments. A shared planning cadence — whatever you call it — forces dependencies into the open before the quarter, not during it.
• A vocabulary for the seams. Most large-org dysfunction lives between teams, where no one’s job description reaches. Frameworks name those seams and assign someone to care about them.
• Legibility for leadership. Executives fund what they can see. A framework gives delivery a shape that finance and strategy can engage with — which buys engineering room to work.

Our research on large-scale delivery pointed the same direction: outcomes correlated less with which framework was chosen and more with whether the coordination problems the framework targets were actually being solved.

Where it curdles into religion

The failure mode is always the same: the map replaces the territory. Ceremonies run because the framework says so, not because anyone can name the problem they solve. Roles multiply faster than decisions. The transformation office measures adoption of the framework instead of flow of the work.

My heuristic: for every practice, someone must be able to finish the sentence “we do this because otherwise ___.” If the blank is “the consultants said so,” delete the practice and see what breaks. Usually: nothing.

Adopt problems, not frameworks

The sequence that has worked for me — at enterprise scale and again now, running a delivery process where the “team” is largely AI agents:

1. Name the top three coordination failures you actually have.
2. Steal the minimum mechanism that addresses each — from SAFe, LeSS, Scrum, or a blog post; nobody checks the license.
3. Instrument whether the failure rate drops.
4. Delete anything that hasn’t earned its meeting time in a quarter.

Frameworks are libraries, not operating systems. Import the functions you need. Vendoring the whole thing is how you end up maintaining someone else’s religion.

Related: what actually breaks when you scale delivery.