Is Scrum Dying?
The promised land of fruitful value seems unreachable for most companies. No wonder they’re searching for alternatives
The promised land of fruitful value seems unreachable for most companies. No wonder they’re searching for alternatives
In 2010, the first Scrum Guide was released. After that, the world would never be the same. What was supposed to be a lightweight framework became the world’s standard process of working for most digital companies. The market welcomed Scrum with open arms by creating thousands of Scrum Masters and Product Owners positions. What Scrum calls roles became careers for many people — including myself.
Many companies worldwide treated Scrum as a silver bullet; they believed Scrum would ensure success. Yet, only a few companies could reach the promised land of fruitful value. Such companies excelled in their business, while those that didn’t get there crucified Scrum.
When companies fail to get the results they want with Scrum, they search for alternatives. A common failure happens while scaling: productivity goes down, dependencies increase, and teams get lost. Executives don’t trust Scrum to provide the control they require, and then they long for more robust structures. The old waterfall mindset comes into place, and then frameworks like Scaled Agile Framework (SAFe) become the answer. Companies want to be agile, but they cannot renounce the old command and control style.
Now, Scrum faces more resistance than ever before. I’ve stumbled upon companies over the world despising Scrum, and they want something different. Sentences like the following are common among decision-makers:
It doesn’t work for us.
Scrum is like politicians: they promise you heaven, and you get hell instead.
It only works for small teams.
Scrum overwhelms people with tons of meetings.
Let me elaborate more on why I believe Scrum is on the border of collapsing.
Scrum Is No Silver Bullet
For many decades, the waterfall was how companies developed software. Most people who worked with it experienced similar pains: siloed teams, lack of collaboration, low customer involvement, etc. Despite an exhaustive process, the result was often poor — a solution that surprised customers because it didn’t solve their problems. Companies couldn’t succeed with the traditional waterfall, and a change was urgently needed. That’s when Scrum came in.
What was the problem? The process or something else? Before you answer this question, consider a football team that doesn’t win a championship for decades. Then, a new coach takes over, and they decide to implement total football — that’s how the Holland National team amazed the world in the seventies. Despite the coach’s optimism, the result remained as bad as before.
Can a team be victorious only by changing how they play the game? Probably not, because there are more critical aspects than just how the team plays, e.g., adapting the mindset, support from the management, and having the right players.
Many companies replaced waterfall with Scrum without solving their dysfunctions. The first massive misconception is to treat Scrum as a process instead of a framework. As a matter of fact, Scrum is incomplete by design. No company can succeed with Scrum alone. For example, product management is not part of Scrum, yet it’s vital to deliver successful products.
No matter which development process companies work with, it will never run smoothly until the dysfunctions are solved. Some of them are:
Command and Control
Unclear Goals
Prioritization based on hierarchy
Micromanagement
Failing with Scrum is inevitable for companies that don’t solve their dysfunctions. Yet, Scrum will get the blame.
Scrum is not a framework for organizations that fear change. It’s impossible to succeed with Scrum without adopting an agile mindset. That’s why more conservative companies find their haven with SAFe, which is a highly prescriptive framework that has nothing to do with Scrum.
“Then again, SAFe has a different purpose than Scrum. SAFe is in much a delivery framework. Scrum exists to address complex problems while delivering the highest possible value. This is an important difference. SAFe is much more in line with traditional approaches and company structures. It is less threatening for top management. But it also doesn’t bring the best possible agility. It does not bring the highest value products.”
When I look at SAFe, I always get scared because it’s a heavy process. It reminds me of my electronic circuit lessons; it doesn’t look like an agile approach at all. For example, who is responsible for what? To understand the dynamics with the customer, I need some time until I can even find them. I wonder why they have the audacity to call this Agile.
Why Is Scrum Endangered?
Scrum is the most used agile framework around the world, but how companies implement it varies dramatically. The difference between successful and broken attempts rely on how much organizations are willing to change. When the implementation of Scrum touches only the execution, the results might be similar to the previous scenario. Still, when the company is brave to touch its culture, then success might be on the way.
Which is the most common way of implementing Scrum? I guess you know what happens. Top management is unwilling to change the culture without certainty that such a significant transformation will result in a meaningful increase of value.
“Top management believes it is too risky to have truly self-managing teams. This is why Scrum hits a glass ceiling.”
Top management is not ready to empower Scrum Teams; they want to remain in control. That’s why they take the shortcut. First, change execution. Then, if Scrum proves its value, change the culture. Well, it won’t work like this, and the outcome is a disappointment for everyone. When Scrum is only used for execution, the roles mutate to something awkward. Let me share some of my observations.
The Product Owner
Product Owners will behave like waiters until they are accountable for prioritization. They take orders, recommend a side dish, and send the order to the kitchen. It’s frustrating to be an order taker; the only thing you do is manage stakeholders’ expectations and bridge communication with developers.
Mutations with the Product Owner role are so common that many times I wonder if somebody is a Scrum Product Owner. When I look back in my career, I, maybe, was close to being one but was never fully empowered as the Scrum Guide suggests. My question to you: does a Scrum Product Owner exist in the corporate world?
“Is the Product Owner role like the monster of Loch Ness, only existing in our imagination? Is it something we can only talk, read and fantasize about, but will never witness in the real world?”
— Maarten Dalmijn, Will the real Product Owner please stand up?
Developers
In theory, developers are the ones who decide how to do their work. They are fully responsible for how to implement, which tech stack to use, and so on. Once again, I’ve never seen that. It’s common to have a Chief Technology Officer (CTO), a Tech Lead, or somebody else, who is not only calling the shots but micromanaging developers.
Developers were promised autonomy with Scrum, but do they get that? I don’t think it’s the case. Unfortunately, most developers receive clear solutions to implement; rarely are developers empowered to work on problems without an exact deadline.
Scrum Developers might be together with Scrum Product Owners in the fantasy world, but not in reality. What we find easily are developers locked in a feature factory.
Scrum Master
The most ignored role in Scrum is the Scrum Master. It’s common to find Scrum Teams without a Scrum Master because companies consider it to be a waste of money to pay someone for this job. But when they are part of the team, Scrum Masters are often powerless because they cannot foster the needed change to allow Scrum to flourish.
The Scrum Master role is no different than the other roles. It’s unlikely to find a person who can be exactly the one as the Scrum Guide suggests.
Will Scrum Survive?
Given all the Scrum Roles' mutations, many highly qualified professionals are tired of Scrum; they lost their faith in it. They long for something else, and such professionals are looking for opportunities to experiment with different frameworks.
The unwillingness of change from top management leads teams to a watered-down Scrum Version, which leads to poor results. A sequence of bad decisions and misconceptions might lead Scrum to its death. Top management is coming back to its roots: command and control. That’s the reason SAFe, the undercover waterfall agent, may get the spotlight.
How To Avoid the End of Scrum
Companies can thrive with Scrum if they are willing to change their hearts and not only their heads. Scrum requires a mindset change, and it doesn’t matter which agile framework companies work with — they will fail until they change their old mindset. But there’s hope. Some companies are willing to change, and some signs they show are:
Top management understands the need for Product Management, and a Chief Product Officer becomes part of the executive team.
The roadmap is planned based on Objective Key Results, where top management defines the objectives and Scrum Teams the results.
Scrum Teams are empowered to experiment with different alternatives to reach the key results.
Product Discovery is established. Executives know that it’s vital to invest proper time in finding problems that worth solving.
It’s never about doing better Scrum. It’s all about delivering more value!