SAFe is the most deployed scaled Agile framework (according to the digital.ai 16th State of Agile Report), but it might also be the most hated Agile framework.
To illustrate this, let’s look at u/PhilosopherOfCS post on Reddit. u/PhilosopherOfCS asked which SAFe certification would be the best suited for them and they got 13 main responses. 2 of them recommended a SAFe certification and almost all the others explained how bad SAFe is:
Sometimes, when you dive into the Agile world, you have the feeling that there are only two choices: be a SAFe hater or be a heretic who will never dare mention the word « manifesto » for the rest of their life. (There is even a website dedicated to sharing “evidence” about how not very good SAFe is.)
At this point, you might ask: “How did we get here?”
That’s an interesting question, thank you. It turns out that SAFe hate can be broken down into two parts: criticism of the framework (the biggest part) and criticism of the business model. Let’s take a look.
Part I: Criticism of the framework
On paper, SAFe is quite simple (bear with me). It is mostly composed of already existing and recognized things, put together:
- Take Scrum or Kanban at the team level
- Strengthen it with XP development practices
- Create 2 scaled levels (which simply are a scaled and a scaled-scaled version of Scrum)
- Plug it to a DevSecOps culture
- Add a few common UX tools
- Refer to Kotter for change management, to Kersten for the Project to Product paradigm shift, and to a bit of Skelton and Pais’ Team Topologies
- Roll it into the Agile Manifesto
- Tie it all together with some Lean principles
And there you go. You have almost fully recreated the infamous Scaled Agile Framework. See?! It wasn’t that complicated. (Yeah, I skipped the portfolio part, nobody ever gets it.)
But how can a framework simply based on “existing and recognized things” be so heavily criticized? Let me explain.
- SAFe is a scaled Agile framework. It was designed for teams of teams. In other words, it was designed to be used when several teams are working together on the same solution. In a software development context, that means: same pipeline, same repository, same database, and so on. Yes, I know, that also means dependencies and we have been trained to avoid that. Teams should remain small and autonomous to be as nimble as possible. However, some pieces of software are so large that a hundred people are working on it and this is a pain point. On one hand, part of the Agile community sees this as the problem to solve (probably by breaking this piece of software down into components, to make each team autonomous). On the other hand, SAFe proposes to form one large Agile team of teams with shared events and so on. SAFe is then seen not as solving the problem, but as encouraging it.
- SAFe is entirely pre-built. Some coaches work very hard to find the perfect mix of Agile tools for each of the teams they work with. They read every Agile article and book and say things like: “oh, I know, we should use the Gragas-Jax wheel principle! You’ve never heard of it?” (and you feel like an idiot, so you say something like: “er, maybe, remind me what it is again…”). Whereas, SAFe is completely pre-built with an already existing set of tools to meet almost any need. SAFe is therefore seen as a standardized, but poorly adjusted solution.
- SAFe is heavy. As explained above, SAFe is a large box of already existing things (Scrum, Kanban, XP, etc.), with two scaled levels. It is therefore much heavier than the usual frameworks. For some Agile coaches, Scrum is already far too big, and for the most radical of them, the Agile Manifesto (with its 4 values and its 12 principles) is all you need. SAFe is then seen as impeding the teams and the company with unnecessary and overwhelming things (mainly because of the scaled roles and events).
- SAFe is widely misunderstood and therefore misused (this is my favorite point). SAFe was designed to meet rare operational needs (delivery value through a solution requiring a cross functional team of teams). However, many people saw it not as an operational framework, but as an organizational one. Let me explain. SAFe provides a Product Owner role (at the team level) and scales it with a Product Manager role (at the team of teams level) and scales it again with a Solution Manager role (at the team of teams of teams level – which is optional). Do you see it coming? Yes, absolutely, some people saw it as the hierarchical tree that would enable the Agile transformation of their company. Many of them then started to deploy this organizational SAFe. All the teams had to be in a team of teams, all the POs had to be under a PM, who themselves had to be under a SM, most of the time with little to no real operational reason. A lot of people were caught out by this deviant SAFe wave. Logically, they started hating it (it’s complicated to spend two days in a room with teams you don’t care about, pretending you do, when you’ve got real work to do on the side).
- SAFe adapts the things it is built on. SAFe does indeed refer to a large number of existing and recognized things, but SAFe tends to adapt them a little or take only a small part of them. SAFe is then seen as not respecting these references or their authors.
Part II – Criticism of the business model
Some Agile purists don’t like learning models based on a certification system. To them, in a nutshell:
- Monetizing agility is a bad thing
- Having passed an exam doesn’t mean you’re pure enough to be blessed by the seventeen saints
You guessed it, SAFe offers a large number of certifications (and you have to pay a 4-figure course to have the right to take them). But there is more… *dramatic music starts playing. They expire after one year *dramatic music goes wild. SAFe is therefore seen as making money on the back of agility.
So, what should you think of all this?
Whatever you want, you’re grown-ups. But here is what I think.
About Agile at scale: one day, an experienced agile coach and SPC-T (a sort of SAFe demigod) told me: “when someone asks you to scale, your first answer must be ‘no’. Then you start discussing”. I keep that in mind. In rare cases, you will have no choice but to create one Agile team of teams. In these rare cases, from my own experience, using scaled Agile frameworks brings a lot of positive things.
About SAFe being entirely pre-built and heavy: as far as I know, when implementing it, it is written nowhere that you must use all and only SAFe. You are still the coach, and you can freely adapt your use of it according to your needs. No, I don’t do 2-day PI Planning (one day is enough for the scaled team I’m currently working with). No, we don’t use the WSJF (even though I like this tool, I haven’t imposed it on the teams). Yes, I use SAFe as a toolbox from which I take what I need, when I need it. Most of the time, I find something useful. If not, I look elsewhere, no big deal. I’ve heard of consultants doing day-one 100% SAFe deployments. I think that’s a mistake. Because, yes, 100% SAFe is heavy and it contains things that are not always necessary.
About SAFe being widely misunderstood and therefore misused: frankly, if you’re in such a situation, good luck. Until SAFe has the courage to address the problem, you will have to duck. These contexts are complicated to manage. They generate a lot of frustration and it’s stupid to think that the execs will go “oh, lol, we actually misunderstood the thing, sorry guys, let’s rollback”. Sad story.
About SAFe adapting the work of others: having to explain the SAFe version of Scrum to teams who are already practicing Scrum is always a bit annoying. That said, no SAFe adaptation has ever caused me any major problems in the field. What I find disturbing is when people allow their content to be used in SAFe but criticize how it is use. I don’t think that’s a healthy stance to take.
About SAFe economical model: The investment required to obtain a SAFe certification is significant, particularly for freelancers or small businesses. I think that’s an issue. However, the renewal cost is not that high and yet few people I know renew their certifications. They simply continue to practice, with an expired badge on their LinkedIn. Does it cause them to grow mold and start decaying? Not that I ever witnessed.
In conclusion: SAFe is only a tool. In itself, it can do no harm. Its impact depends solely on how it is used. However, as it is big, it can bring big benefits but it can also bring big mishaps too. And that would be my main concern. Its size and potential impact mean that it should be handled with care (and that may not always be the case).
I’m a SAFe Practice Consultant, I’ve been practicing and deploying it for several years and I used to be a SAFe hater, posting bad things about it on Reddit…
RTFManifesto (Read the F*cking Manifesto) 