Why most scaling frameworks are a fad that will blow over
The cautionary tale of the Spotify model
I have a confession to make: I have never seen a Scrum scaling framework succeed. Now, I do not claim to have seen all scaling frameworks that exist in action. I am highly doubtful there is a single person in the world who has concrete and substantial experience with all of them.
New scaling frameworks appear all the time, thank god still at a slower pace than JavaScript frameworks. If you’re that mythical unicorn who has experience with all scaling frameworks, please contact me. I want to learn from you.
Despite the many scaling frameworks I’ve become familiar with, I’m still waiting for a single positive encounter. I’ve had many challenges with the introduction of scaling frameworks over the years. I’m writing this article to express these concerns and share a better way to think about scaling.
I’m not the only person with reservations about scaling frameworks. When Jeremiah Lee published his post debunking the Spotify model's effectiveness, I let out a sigh of relief. Finally, someone provided concrete evidence of why this framework doesn’t work despite its popularity and savvy marketing.
Jeremiah’s post echoes my personal experience with the Spotify model. I’ve seen it introduced a couple of times, and I’ve never seen it make a positive impact.
It’s not the only scaling framework to receive harsh criticism. Stefan Wolpers determined that Scaled Agile Framework (SAFe) actually has a negative Net Promoter score among practitioners. In simple words, this means experts who work in a SAFe environment would actively discourage others from adopting it. Ouch!
I’ve worked at multiple companies using different scaling frameworks. All of them introduced needless complexity that made things worse. All I ever saw was bureaucratic overhead reigning supreme, with the actual problems being swept under the rug. Instead of solving problems, the scaling frameworks more often than not protected the status quo. They were destructive, induced laziness, and led to a path of mediocrity.
This leads me to ask the following question:
Why do scaling frameworks in practice often not fix the problems they promise to solve?
Well, I don’t believe there is a single, simple answer to this question. But I do believe there are a couple of important reasons that together explain why many scaling frameworks are doomed to fail by design.
1. Adherence to the framework becomes the default solution to all problems
Scaling frameworks shift the attention from solving the issues we’re experiencing to following the rules of the framework to a tee. The logic goes, if we’re still experiencing issues after introducing a scaling framework, then we must be doing something wrong in our implementation of the framework.
We believe the hype, so the solution the framework offers must be effective. Instead of digging deeper and becoming curious, we limit ourselves to the question: “What are we doing wrong in our scaling framework?” As a consequence, all solutions we come up with are limited to the framework. We miss the fact that the framework might not be good enough to fix our problems.
To be fair, many Scrum Teams suffer from the same problem. Instead of wondering how they can better deliver value, the main concern becomes how to do Scrum better. Doing Scrum is never the point. Keep in mind that Scrum, like a scaling framework, is a means to an end. It’s not the end itself.
The goal of Scrum is to help you figure out the best way of delivering products of the highest possible value. The delivery of value is what you should be most worried about, not perfectly following the rules of Scrum.
In my experience, we became much better at following the rules of the scaling framework over time. But no matter how much progress we made in our adherence and faithfulness to the rules, I never saw any of the issues we intended to fix disappear.
In fact, things invariably seemed to become worse. New issues appeared as a result of more bureaucracy and less flexibility, without any of the original issues being fixed. Scaling frameworks promise a shortcut to scaling issues like a fad diet you follow to lose weight. Just follow the steps, and success is guaranteed. If only it ever was that easy.
Scaling frameworks often promise a magical solution for the lazy and the hopeless. Don’t think, do as we say, and all will be good.
This is exactly counter to how Scrum is supposed to work. Scrum operates on the following adage: ”We won’t tell you what to do, but we’ll make those tough nuts visible that you’ll need to crack on your own”.
There are no shortcuts. You need to figure out what works by trying, failing, and keeping what delivers results. You shouldn’t replace common sense with blindly following the recipe of a framework.
2. Copy-pasting a scaling framework prevents learning from experience
The more prescriptive the scaling framework (e.g., SAFe), the more it conflicts with the empirical core of Scrum. What works in one context, might not work in another context. You can only figure this out by trying out things and evaluating if they truly work.
The problem is that most scaling frameworks bundle many different practices together. It’s a package deal. When you implement the whole shebang, how do you know what actually worked, and what didn’t?
Imagine there is a leak somewhere in your shower. You don’t take the time to figure out where it comes from. You decide to replace the floor and all pipes below your shower. Afterward, it still leaks. Did you fix the original problem, or did you introduce a new problem? Who knows if you change so many things at the same time.
This is exactly what happens when you introduce a scaling framework. When you introduce so many changes at once, it becomes difficult to determine what works and what doesn’t. When you follow an empirical approach, it is essential to try out small changes and keep what works. Otherwise, it isn’t empirical, based on experience and evidence. With many scaling frameworks you’re just adding a process cocktail based on gut-feel instead of concrete evidence.
In the case of the shower, we should first figure out the source of the leak before you make any changes, and then implement the simplest thing that you will believe fix or ameliorate the problem. This way, you are certain of the problem you’re facing, and then you can figure out if your solution really works. Another benefit is that you’re left with the simplest thing that works, and you don’t introduce needless complexity.
Implementing feature-rich scaling frameworks makes it difficult to learn from failure. The more changes you implement at the same time, the more difficult it is to determine what’s going well and what isn’t. You will end up keeping many redundant practices that often harbor new problems.
3. The whole point of Scrum is that it is purposefully incomplete
The whole point of Scrum is for you to invent your own rules to deliver value. This includes any scaling problems you will experience as your organization grows. If you can’t solve your scaling problems on your own, maybe you shouldn’t be using Scrum. It’s a clear sign you aren’t able to handle the process framework philosophy behind Scrum.
SAFe comes with its own variant of Scrum, ScrumXP, that might be better suited for you. No need to think, follow the SAFe bible by the letter and everything will be great. At least that’s what they promise.
Scrum requires you to add your own personal touch and enrich it with the process you need to deliver value. If you are not capable of doing that, then please don’t use Scrum. It will never work for you.
Do all scaling frameworks offer a lazy and destructive auto-pilot guiding you towards scaling failure?
Now, I can’t claim to have experience with all scaling frameworks, to support the position that all scaling frameworks are lazy and destructive, like a fad diet. There are examples of scaling frameworks that try to do it right. LeSS (Large Scale Scrum), as the acronym already implies, is light-weight and acknowledges there never will be a one size fits all solution.
Here’s one of the principles of LeSS that illustrates this:
More with less — (1) In empirical process control: more learning with less defined processes. (2) In lean thinking: more value with less waste and overhead. (3) In scaling, more ownership, purpose, and joy with less roles, artifacts, and special groups.
You can pick the right approach by being aware of the different problems that may arise when implementing a scaling framework. If you decide to use a scaling framework, choose a light-weight approach, like LeSS, before deciding to use any heavy-weight approach like SAFe.
Introduce aspects of this light-weight approach gradually, and evaluate if it really makes the difference you’re expecting. Otherwise, improve or drop it. LeSS was created in the same spirit — to remove as much unnecessary complexity as possible.
Look at different scaling frameworks and cherry-pick those parts that may solve the problems you are experiencing. Every scaling framework has its merits and weaknesses. Like losing weight, what works for one person, may not work for you. There even is a person who lost 111 kg by following a Subway diet. However, you can learn from others' experiences by making them your own and adapting them to your unique situation and problems.
It’s not easy to do, but the rewards you can expect are far greater than if you’d copy-paste a boilerplate solution. Tailor the value delivery process to your unique context and needs to deliver the most value. All complexity you add must pull its weight. If you add too much at once, you will never be able to figure out the exact contributions of each change.
To give a concrete example of this minimalist approach in action, I’ve introduced Feature Teams multiple times without implementing LeSS. I did benefit from the advice from the LeSS framework on how to best introduce Feature Teams. After implementing Feature Teams, many of the problems we had disappeared, and there was no necessity to introduce other aspects of LeSS.
In the wise words of statistician and economist Ernst F. Schumacher:
“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” — Ernst F. Schumacher
Most scaling frameworks are like the fidget spinner at the beginning of this article: they look nice and shiny. When you see someone play around with a fidget spinner, you can’t wait to get your hands on one. But when you finally buy one and spin them between your fingers for the first time, buyer remorse kicks in. You can’t help but wonder: “How did I get suckered into buying this exactly again?”.
Do you want to write for Serious Scrum or seriously discuss Scrum?
