SAFe destroys more then you bargain for

Organizations have been working with new ways of working for some time now. Think of frameworks such as Scrum and Kanban. But when Scrum was introduced at the time, it turned out that it was not well thought out how to apply it in larger organizations. When multiple teams have to work together towards a common goal. Scrum of Scrums was a nice first thought from Schwaber and Sutherland but it was too lean and left a gap when it came to scaling. The gap was quickly filled with SAFe (scaled agile framework) and LeSS (large scale scrum). The latter gained popularity due to people who saw that SAFe would not work everywhere.

Break it again

For some time now I have been seeing the introduction of SAFe at various organizations and I must confess that I have not seen it work well anywhere or that I hear stories that it works well. The Prince2 in Agile sheep's clothing as Dave Snowden described it is often used only as a layer over existing ways of working. The SAFe model is very well fitted for this. Everything has been thought through. In contrast to LeSS, which still leaves much room for interpretation. You could say that the latter is more agile. SAFe is actually intended as a transformation model. The exact implementation of the scaling framework ensures that you can actually touch everything within a large organization, so that you can make things visible. But then it is a good idea to break it down slowly. To get rid of things you don't really need. Think of it a bit like Lean. First make it visible and then make it effective and eliminate waste. SAFe as a transition step not as the ultimate goal in itself. Unfortunately, this is rarely ever done. New roles are even being invented to make SAFe work by the book at all costs. That was never the intention of any way of working. Use what works and get rid of what gets in the way.

Suffocate

Proper application of SAFe means that you can get an organization moving. But what I only see is that organizations are getting suffocated because of it. Often all focus is on the Program Increment Planning (PI planning), a quarterly party that is often desired by management. Every quarter, teams are allowed to tell their product owner what they will be working on in the coming quarter. How agile is that? Sometimes commitments are even expected from the teams on that schedule. SAFe is far from agile in this regard. Ken Schwaber has even questioned this. The whole idea of Agile is that the people who do the work also know very well how to do that work and that management should support them in this. And don't suffocate the teams under a framework like SAFe. And Schwaber is not alone in this. All heavyweights who have used their expertise to work within an agile mindset and with frameworks have expressed their reservations about working with SAFe. I think that says something. If experts in the field of agile have doubts from the start and are strongly against it, then you should do something about this. In any case, delve into the matter. Why does SAFe not work?

It's not Scrum

SAFe is quite clever. There is a solution for everything and some can be used perfectly, but that is where the danger lies. It's like the raisins in the porridge, fish them out and use them, but don't eat your whole bowl. It was never the intention of the creators of SAFe to offer a click and play solution. And don't think it is that it's scaled-up Scrum, because it really isn't. SAFe has nothing to do with the idea behind Scrum. You know, working iteratively on solutions and therefore checking together every short working period whether people are on the right track. Scrum has no quarterly schedules. Release train engineers. Program managers, Epic owners and SAFe coaches (WTF). And scaled Agile, how can you scale a mindset?

Team nightmare

Now you can say that SAFe works everywhere and that many organizations have successfully implemented it. That could be, I'd be happy to come and see if you've made it a success. But until then, you can explain to me why everywhere I go, the people who actually have to deliver the products, the teams who have to work with them, find it horrifying. Unworkable, bureaucratic, stifling, unclear and a party of management (management that often goes against all decisions and sails its own course after every PI). Those teams that need a foothold to be able to work together within a clear vision, who need a clear goal but are stifled by rules, an excess of meetings and in some cases even a planning that comes in between and has no added value. I have seen SAFe applied within organizations where only support was done. How do you plan quarterly support in advance if you get new questions on your plate every day? But yes, management wants a PI planning, you know Program Increment Planning for something where no incremental work is applicable because that is how it is described in SAFe.

Fundamentalism

If I said something about it then I was crazy because this way of working was simply chosen and it cannot be changed because ehhhh it was simply chosen. How agile is it if you don't need the tools you use? Or it turns out to be the wrong tool. I don't want to come across as an Agile fundamentalist, I'm far from that, but I do find the first line of the agile manifesto interesting. People and interaction over processes and tools. I don't think I need to explain it further. If as an organization you are so proud of the fact that you want to be agile and that within your Agile Excellence program, or whatever name you have called your elite program, it is important that people become agile (as far as that is possible), then dare to challenge that way of working. Within SAFe there is a so-called Continuous Learning Culture, one that advises improving Relentless. It gives me goosebumps, but oh well. So continuously improve.. Dare to attack your framework. If your teams say they find it unworkable, break things down or change it for them.

Shit

I know it's very easy to say that SAFe doesn't work. But dare to remove or adapt parts. Take something away from other models. Check out what LeSS, Nexus, Scrum@Scale, Kanban and as far as I'm concerned even Prince2 have to offer. What works well there and what doesn't? Combine and mix. (Stay far away from Spotify though, that one worked only for Spotify for a while). But don't be afraid to just break down SAFe again. To hold onto the lesson of SAFe and continue to grow. SAFe is not Agile. SAFe is very far from Scrum. The shitty agile for enterprises as Martin Fowler has put it so beautifully destroys more than you would like. Often a well-intended solution to a non-existent problem. Because many organizations that scale up are often not able to let their teams work within basic Scrum and resort to scaling up. When you scale shit, you get a lot of shit.

So what then?

First, see what is really needed. It often starts with a good vision. Making decisions based on that vision and then together with the people who have to work with it. A clear goal is often more powerful than a way of working. That will follow. You cannot solve indecision with a framework. What is needed next? Overview. What are we going to work on? What do we need? A clear roadmap, you really don't need two or sometimes even four days of PI planning for that. You want to be agile and able to respond to the market. Then don't tie yourself down. "Yes, but if something comes up, we adapt." Then why are you committing to three months of planning? Waste of energy and time. And once you know what you are going to do together and why, only then do you focus on the way of working together and fill it in according to need. People central. The great thing is that things such as trust, motivation, communication, knowledge, transparency, openness and respect come to the fore. And it is very difficult to find these in that SAFe model.

I published this article earlier in Dutch but got a lot of requests to translate it. I'm happy to oblige.