SAFe Controversy | Is It Cool To Hate On SAFe?
SAFe is like the lovechild of a control freak and a Project Manager on a power trip.
SAFe is a Scaled Agile Framework popular with large corporations while Agile practitioners can’t help but despise it.
In my last video, I tried to explain what SAFe is; in today’s article, we will tackle the SAFe controversy head-on. Why is there so much hate towards SAFe, or perhaps the question should be why would anyone defend such a process-heavy framework?
Here’s the thing: Is it a shame to admit that you actually like SAFe or find it useful? Will the Agile Community come at you with pitchforks if they find out? Is it the cool thing now to hate on SAFe? What’s the real deal here? Let’s get to the bottom of it!
A down-to-earth approach
I’m a down-to-earth kind of gal, OK? I am as practical as they come. I’ve moved on from all the touchy-feely stuff when it comes to frameworks. You hate Scrum and fancy giving Kanban a try? Knock yourself out! Prefer estimating in time instead of effort? Not my cup of tea, but hey, if you can show me a valid use case, maybe it’s got some merit for your situation. You won’t find me fighting for a framework, but you will find me championing the delivery of value through iterative manner and feedback loops.
The same goes for SAFe. Let me clarify one more thing — I am not an official SAFe trainer. I did obtain, though, some SAFe certification (SAFe Agilist 4.0) back in the day. I am not financially incentivized to promote, teach, or implement SAFe within any organization. And SAFe people don’t pay me to talk about it. However, I have had hands-on experience working with the framework in a few companies where it was adopted based on decisions from higher management, hence the sponsored certification.
SAFe from different angles
But first, we will review the opinions of the “official SAFe haters”, my dear friends, Maarten Dalmijn, David Pereira — let’s see why they hate it so much and what arguments they provide in their case.
When it comes the SAFe backers, though, this one is the most tricky because — can we trust the opinions of people who make their living from teaching or implementing SAFe? Not really sure about it.
Buckle up for this crazy un(SAFe) ride!
Let’s start with the haters. For that, I chose my estimated friends from Serious Scrum, David Pereira and Maarten Dalmijn. They are both Product Leaders, there must be something about it, don’t you think?
SAFe as an undercover waterfall agent
In his article “Why SAFe is the safest choice to fail with Agile” David Pereira goes on an epic rampage, proclaiming SAFe as the grand insult to all things Agile.
“SAFe is an insult to Agile.”
Note that SAFe is an abbreviation of Scaled Agile Framework. That’s why you’ll find so many people raging against its Agility.
Once upon a time, David was an empowered Product Owner, living life in the fast Agile lane. But then, along came SAFe, turning everything in that company into a slow-motion nightmare. With all those processes and rules, suffocating the Agile vibe he felt he switched from a Ferrari in the fast Agile lane to a reasonably-priced car in the Waterfall loser lane!
SAFe feeds the bureaucratic beast
He argues that SAFe merely feeds the bureaucratic beast within organizations, transforming them into process-driven zombies unable to innovate.
Processes and rules killed the Agile vibe!
He also points out that SAFe shamelessly spoils perfectly good practices, tools, and frameworks:
“SAFe masters the art of copying techniques and making them horrible. Design Thinking, Scrum, Kanban, and User Stories are just a few things that SAFe spoiled.”
What David basically says is:
You name it, and SAFe will ruin it for you!
SAFe as a pre-cooked meal
Now, let’s move on to the know-it-all part of SAFe, as apparently, it has an answer to everything. As I previously mentioned in my video, you won’t find much self-organization in SAFe. It’s all pre-packaged and pre-organized, like a pre-cooked meal to throw into a microwave.”
“Agile is about freedom. SAFe is about control.”
Martin Fowler, the Agile guru, couldn’t have said it better when he referred to SAFe as
“Shitty Agile for Enterprises.”
Product Owners as ticket holders
David has more on SAFe, especially when it comes to the separation of the Product Owner and Product Manager roles in the framework. David scoffs at the notion, calling it pure nonsense.
In his opinion, SAFe reduces Product Owners to mere ticket holders, mindlessly pumping out features that nobody gives a damn about. It’s like being trapped in a feature factory, churning out mindless work. And don’t even get him started on the mutated version of Scrum in SAFe. It’s a soulless, mechanical process that drains the joy out of Agile. Who needs a framework without a soul?
But wait, there’s more! SAFe creates a massive customer distance, where developers have to climb Mount Everest just to have a chat with the customers. It’s like a never-ending hierarchy: Business Owner, Product Manager, Product Owner, and finally, the poor Developer. What happened to the good old days of direct interaction? SAFe has too many roles and responsibilities, making it feel like we’re back in the industrial era. We’re not cogs in a machine, people!
All in all, he concludes that SAFe is just a fancy marketing framework that gives companies the illusion of control.
Next comes Maarten Dalmijn with his article “SAFe: Why Can’t We Be Friends?” he also considers SAFe to be like the troublemaker in the playground, intentionally stirring up conflict:
“Why does the Scaled Agile Framework (SAFe) divide so many people?
That’s because SAFe divides people by design. It’s intentional.”
He points out that SAFe takes successful concepts and frameworks and decides to give them a makeover. But instead of enhancing them,
“They take what’s good and bastardize, dilute and warp it beyond recognition. That’s because they don’t want to be scary, they want it to be SAFe.”
Maarten quotes some renowned agile practitioners like Manuel Pais, Jeff Gothelf, or Jeff Sutherland about what they think about how SAFe represents their concepts. Spoiler alert: they’re not impressed.
David and Maarten aren’t pulling any punches. Their opinion on SAFe can be best described as a blend of skepticism, frustration, and the occasional facepalm.
Emotional vs scientific
Let’s move on to Christiaan Verwijs and his deep analysis of SAFe: “In-Depth: Is SAFe® Really That Bad?”
Btw, you gotta love the Liberators! They have a scientific approach to Scrum and Agile and if you ever doubt whether to jump or not on a hate train of something not Agile enough, I recommend you first check with them. They will give you an objective view.
Christiaan did a lot of research in the scaling frameworks world. He has read scientific studies, conducted surveys, and offers a view on SAFe based on available evidence.
What are his conclusions?
First of all,
“VersionOne reported it as the most popular scaling framework in 2021 (37%).”
Then he moves on to compare SAFe to other frameworks based on five core factors of effective Scrum teams. He says that based on the negative opinion of Agile Community professionals on SAFe he would expect “lower team autonomy, lower responsiveness, lower concern for stakeholders, and fewer opportunities for continuous improvement.”
“We asked teams to specify which framework they use. The most prevalent ones are SAFe®, LeSS, Scrum of Scrums (a practice recommended in earlier iterations of the Scrum Guide), homegrown, and something else. We also added teams that don’t use scaling.”
His conclusion is that
“The quality of the core factors that make Scrum teams effective is not meaningfully different between the scaling approaches.”
He asks both the teams and the stakeholders for their satisfaction with the way they work and both seem to be similarly satisfied with the outcomes of SAFe. Christiaan writes:
“My interpretation of this is that frameworks don’t matter nearly as much as we assume they do and that other factors are far more important in shaping success or failure.”
Because what is a framework, really? It’s just a set of prescribed roles, events, artifacts, and some principles. It’s basically a blueprint that is divorced from the reality of a real organization, real teams, and real people. It’s a platonic ideal. But anyone who has applied frameworks knows that they are often loosely practiced and tend to differ from one organization to another. Christiaan believes there is a difference between what a framework prescribes and what actually happens on the ground.
Based on the many papers and surveys, Christiaan analyzed, the conclusion is that all those outside factors I just mentioned determine more the success of an approach than the choice of the framework itself.
Looks like the best approach to ways of working, and I purposely choose to say this as opposed to saying frameworks we use, is to free ourselves from the limitations any rulebook or guide provides and focus more on improving the way the teams and individuals collaborate. Is there trust in the teams, do they collaborate well with the stakeholders and customers, do they release frequently, are they autonomous to make decisions, and what’s the quality of their feedback loops.
That’s the SAFe saga. It’s a wild ride filled with challenges, coordination conundrums, and the eternal question of what truly makes Agile scale. I would love to learn about your opinion — let me know what’s your experience with scaling frameworks in the comments!