Scrum Is Slowly Dying

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 working process 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 decreases, dependencies increase, and teams get lost. Executives don’t trust Scrum to provide the required empowerment; they long for robust structures. The old waterfall mindset comes into place, and frameworks like the Scaled Agile Framework (SAFe) become the answer.

Companies want to be agile but cannot renounce the old command and control style.

Now, Scrum faces more resistance than ever before. I’ve stumbled upon companies worldwide 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 method was used by companies to develop software. Despite an exhaustive process, the result was often poor — a solution that surprised customers because it didn’t solve their problems. Most people who worked with it experienced similar pains: siloed teams, lack of collaboration, low customer involvement, etc. 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.

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.

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. Many companies replaced waterfall with Scrum without solving their dysfunctions. No company can succeed with Scrum alone. For example, product management is not part of Scrum, yet delivering successful products is impossible with sound product management.

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
• Lack of Vision
• Unclear Goals
• Confusing or absent strategy
• Prioritization based on hierarchy

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, 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.”— Willem-Jan Ageling

I always get scared when I look at SAFe 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 find them. I wonder why they dare 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 relies 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, success might be on the way when the company is brave to evolve its culture.

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 in value.

“Top management believes it is too risky to have truly self-managing teams. This is why Scrum hits a glass ceiling.”— Willem-Jan Ageling

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 disappoints 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 I often wonder if somebody is a Scrum Product Owner. When I look back on my career, I, maybe, was close to being one but was never fully empowered, as the Scrum Guide suggests. My question is, 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

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. 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. Once again, I’ve never seen that.

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 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 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 from 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 seek opportunities to experiment with different frameworks.

Top management is coming back to its roots: command and control. Top management’s unwillingness to change 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. That’s why SAFe, the undercover waterfall agent, may get the spotlight.

How To Avoid the End of?Scrum

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. Companies can thrive with Scrum if they are willing to change their hearts and not only their heads. 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 worth solving.

It’s never about doing better Scrum. It’s all about delivering more value!