Sorry Scrum, the Game Might Be Over for You!
Professionals are getting tired of Scrum, can the framework still find its space?
It’s impossible to ignore how well-known Scrum is. Scrum has been most companies’ first choice among Agile frameworks worldwide for years. Only a few would challenge it. But over the last few years, something drastically changed.
Organizations are losing trust in Scrum. After failing to get to the promised land of steady value creation, many places are replacing Scrum with SAFe (undercover waterfall agent), Scrumban, Kanban, or other frameworks.
Beyond unsatisfied organizations, experienced professionals are tired of hearing about Scrum and want something else.
Many even feel embarrassed to be called a Product Owner or a Scrum Master. The market is shifting in a new direction, will there still be space for Scrum?
Companies want to be Agile but struggle to renounce the old command and control style.
Let me elaborate on why I believe the game might be over for Scrum.
This post is sponsored by
Notice: The content of this post is based on my experience and observations over the last ten years. That’s why I invite you to share your perspective as well.
Scrum Is Not a Process!
Software Development is still new. The first piece of software appeared only in 1948. I guess Tom Kilburn couldn’t imagine how fast the world would advance since then.
Computer scientist Tom Kilburn is responsible for writing the world’s very first piece of software, which was run at 11 a.m. on June 21, 1948, at the University of Manchester in England.
For decades, most companies have focused on improving the processes around software development. Until the new millennium, companies lacked techniques to match customers’ expectations. Despite all efforts to implement heavy processes like Rational Unified Process, the quality was still debatable, and customers were unhappy.
Building useless software frustrated many people. A revolution was needed.
Although Agile frameworks like Scrum and eXtreme Programming already existed, it was in 2001 when the Agile Manifesto came into place that significantly changed how software is developed globally. After that, the Scrum framework became the most popular of the alternatives.
Given the situation at the beginning of this millennial, would Scrum solve all problems with software development?
It was essential to understand the root cause, but many companies ignored this step and decided to find a new process. Just replacing the process of how people worked couldn’t be enough. That’s the reason most organizations failed to benefit from Scrum.
The root cause was not the process but the lack of an Agile mindset.
Let’s use football as an example.
Barcelona won 14 titles in four years under Pep Guardiola’s leadership. From 2008 to 2012, Barcelona was absolutely the best football team in the world. Many people attributed the success to how Guardiola coached the team. One of the remarkable aspects was the dominant game. Barcelona often had 70%+ of ball possession. Does that mean applying “Tiki Taka” to another team is enough to reach similar results?
Guardiola coached Bayern München from 2013 to 2016 and applied the same style as Barcelona. Yet, the success was not comparable with Barcelona. With Bayern München, he won five national titles and no European title. Just a process is not enough to achieve greatness. More than that is needed.
Companies that treated Scrum as a process failed. No Agile framework can lead teams to success without mindset changes. Until companies solve their dysfunctions, the environment won’t allow teams to thrive.
I’ve observed many powerless Scrum Teams because the environment was dysfunctional. The most common dysfunctions are:
Lack of trust
Lack of empowerment
Lack of direction
Prioritization based on titles
Micromanagement
Failing with Scrum is inevitable for dysfunctional companies. Yet, Scrum will get the blame.
Scrum is not a framework for organizations that fear change. It’s impossible to succeed with Scrum without changing the culture.
Many people understand the technical aspects of Scrum. They know the roles, events, and artifacts by heart, but only a few know the values. Without living the values behind Scrum, it’s impossible to achieve what Scrum promises.
Why Is Scrum About to Collapse?
Scrum claims to be simple to understand but hard to master. Almost everyone I know agrees with this statement, yet, I would challenge how simple Scrum is. A critical part of the framework is often ignored.
Try asking teams what the Scrum values are. You will be surprised. Almost no one knows them. Still, the values are a crucial part of Scrum.
Successful use of Scrum depends on people becoming more proficient in living five values:
Commitment, Focus, Openness, Respect, and Courage
— The Scrum Guide, November 2020
When organizations treat Scrum as a process to implement, setbacks are inevitable. By design, Scrum is incomplete, and no team can succeed without adapting it to its scenario. For example, product management is not part of Scrum, yet, it’s a key discipline to deliver valuable products.
To succeed with Scrum, organizations have to go through a massive transformation. Unfortunately, most executives are unwilling to do what it takes to prepare an environment that allows teams to thrive.
I’ve come across the following paradigms in business:
Empowerment versus micromanagement
Outcome versus output
Alignment versus consensus
Taking risks versus following a plan
“Top management believes it is too risky to have truly self-managing teams. This is why Scrum hits a glass ceiling.”
Top management often cannot empower individuals because 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 frustrates everyone. When Scrum becomes a process, the roles mutate into something pointless.
Let me share some of my learnings.
The Product Owner
Without being accountable for outcomes, Product Owners will behave like waiters. They take orders, suggest a side dish, and give the order to the kitchen. It’s frustrating to be an order taker. Your main obligation is to manage stakeholders’ expectations and bridge communication with developers.
Unfortunately, mutations with the Product Owner role are more the rule than the exception. That’s why I wonder if somebody can be a Scrum Product Owner.
Looking back on my career, maybe I was close to being a Product Owner but never fully empowered, as the Scrum Guide recommends. My question to you: does a Scrum Product Owner exist in the corporate world?
How many companies can you name where the Product Owner really has the final say over all product decisions? And if they don’t have the final say, are those people still a Product Owner? Yet, there are hundreds of thousands of people who claim the title of Product Owner, without owning any product.
— Maarten Dalmijn , Will the real Product Owner please stand up?
On top of the anti-patterns, many product-minded people are losing interest in the Product Owner role. They find a hard time connecting it with the Product Manager.
Although companies frequently hire Product Owners, many professionals are embarrassed to be called so because of the perception of references like Marty Cagan, who claims that Product Owner is not a job, it’s a role, and the job is much more than what Scrum suggests.
Developers
Developers are the ones who decide how to do their work. They are responsible for the implementation, which tech stack to use, and so on. That’s a beautiful theory. But in practice, I’ve never seen that.
It’s common to have a Chief Technology Officer (CTO), a Tech Lead, or somebody else outside the team making the decisions instead of developers. Yet, developers get the blame for poor implementation when things go wrong.
Scrum claims autonomy for developers, but do they get that? I think that’s rarely the case. Sadly, most developers receive orders to follow. Only seldom are developers empowered to work on problems without a 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 Scrum Master is the most despised role in Scrum.
It’s common to find Scrum Teams without a dedicated Scrum Master because companies are reluctant to hire someone for this job. Still, some companies that employ Scrum Masters often leave them powerless.
Inevitably Scrum Masters fail because they cannot foster the needed change to allow Scrum to flourish.
The Scrum Master 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.
Scrum Masters are generally powerless to foster the required changes in organizations.
Will Scrum Survive?
Many experienced professionals are done with Scrum because they lost faith in it. They want something else, and such professionals seek opportunities to experiment with different frameworks.
The fear of change from executives blocks Scrum Teams from prospering. A sequence of wrong decisions and misconceptions might lead Scrum to its end. Top management cannot leave its inadequate command and control style in the past.
A sad outcome might happen, SAFe, the undercover waterfall agent, is ready to take the throne.
I fear SAFe because it’s a heavy process, and it doesn’t look like an agile approach. How can someone memorize how this heavy machine works? I wonder how they dare to call this Agile.
Scrum Might Need a Restart to Survive
The Scrum roles are not as charming as they once were. The faulty Scrum perception from many companies leads professionals to resist working with it.
In scenarios where Scrum becomes a process, people don’t want to be Scrum Masters or Product Owners.
I believe Scrum needs a restart to remain relevant.
We live in different times than we did 20 years ago. In 2001, Scrum was the new kid on the block. The world has changed. Now Scrum is a commodity. For Scrum to remain on the frontline, the creators need to have the courage to embrace the core of the framework and address the barnacles. Some of these (possible) barnacles may be cash cows now. Think (Scrum Master and Product Owner) certifications.
— Willem-Jan Ageling, Will Scrum Fall Victim to Its Own Success?
Regardless of what happens, companies brave enough to change their hearts can excel with Scrum. It’s never about defining a process. It’s all about having a culture focused on delivering value sooner.
There’s hope, some bold companies can embrace change, and the signs they show are:
Chief Product Officer becomes part of the executive team.
Top management focuses on giving directions instead of instructions.
Scrum Teams are empowered to experiment with alternatives to reach the key results.
Product Discovery is established. Executives know it’s indispensable to invest proper time finding problems worth solving.
Don’t let the status quo limit you. Challenge it to grow step by step.
Thanks David, it resonates a lot. As long as people still think scrum is something for the team to do ( in the existing environment ), in that case it will be impossible to do well in my opinion. It is to the company leadership in the first place to create the environment to make scrum possible for the teams. Indeed a complete other mindset. Existing structures must be refactored. Very difficult but big improvements cannot come without extensive but rewarding efforts. If scrum does not work, Scrum is not to blame, it only shows how stiff the organisation still is. If this mindset change can happen, I am confident, the future of scrum will still be bright! It is a slow learning path where we all are still in the very beginning I am afraid.
An excellent text David!