SAFe is dangerous


Here follows something more akin to a rant than a considered article, but I’m wound up by it!

The Agile approach to software development has been around for some time now. Scrum and XP were formed in the mid-90s and the Agile manifesto was published in 2001. It and its contribution to the slow eradication of waterfall in most areas of software development are now part of history.

We’ll take a brief look at why I believe SAFe is a harmful anti-pattern to Agile, how it abuses the term Agile and attempts to push software development back to the dark ages before the Agile manifesto condensed the experiences of so many software developers. Agile empowered developers to explain to a business that their Gantt chart approach was not appropriate for software development. SAFe takes a torch to that.

Scaled Agile Framework

SAFe is not a tool for people trying to develop software. It’s by bad management, for bad management. Just watch their introduction video. If it doesn’t make your skin crawl I probably can’t help you.

It hides behind vagueness. Instead of a succinct summary, the front page of the website is focuseed on selling training, partnerships and 13 different certifications.

Instead of a succinct set of principles that stand the test of time they roll out frequent version updates to their framework, ensuring that the certifications they sell are out of date by the time the next training budget rolls in.

SAFe is waterfall. It plans the long term, it creates milestone dependencies between teams that must be met or a team falls behind and the plan fails. It pushes decision making up, away from the development itself and into management.

I’ll reference the wikipedia page on the Scaled Agile Framework as it’s a relatively concise, reviewed summary. It presents business “problems” that SAFe seeks to address:

  • Coping with longer planning horizons
  • Authority delegated to product owners
  • Synchronising deliverables
  • Allowing time for innovation and planning

These aren’t problems with Agile development, they’re problems with not understanding how and why Agile works the way it does.


The manifesto summarises Agile as:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

Agile doesn’t say the things on the right don’t have value, but it explicitly calls out those on the left as having more value. These weren’t paired by accident, but because those on the right often limit the ability of those on the left.

Yet choosing SAFe is choosing reams of process and hampers the effectiveness of individuals and their interactions. It demands comprehensive documentation to prove to the organisation that the process is being followed. And it only exists to plan and plans only exist to limit responsiveness to change.

I’ve seen SAFe projects run for years without delivering software to a customer. Where changes to the plan are forced to go through committee.

Agile was formed because of the lived experiences of people watching software projects fail because of waterfall. SAFe is the modern day apologist and poster boy for all those malpractices.


Does this mean SAFe can never work? No, it’s possible to cook a meal in a burning building and escape with the meal and your life. But I wouldn’t recommend it. It suffers with the same afflictions as Communism; where it fails its proponents only blame the implementors; they just weren’t applying it right. Where it succeeds, nobody knows.

The unusually brutal criticisms of SAFe aren’t even new. As Neil Kilick wrote all the way back in 2012:

…this framework is a horrible, pure money-making bastardisation and Frankenstein of Scrum, Agile and Waterfall that is being sold to large companies who are too afraid to really change…

Hear, hear.