Scrum at 30: Is It Still Solving Problems, or Creating New Ones?

[#1]

NOTE: I use Scrum actively in my daily work and genuinely believe in its value.
Still, loving a framework doesn’t mean avoiding questions about it.

This piece wasn’t written to criticize, but to challenge its boundaries and gain a different perspective.
I’m not against Scrum. I want to understand it more deeply and reconnect with the agility at its core.

Scrum.
For some, the word inspires confidence.
For others, exhaustion, or perhaps memories of a calendar full of ceremonies.

After 30 years, it’s become the symbol of “agility” across teams and industries.
But one question still echoes quietly, rarely asked aloud:
“Is Scrum still solving problems, or has it become the problem itself?”

🔍 Is “Simple” Really That Simple?

Scrum calls itself a lightweight framework.
“Scrum is simple. Try it as is,” says the Guide.

And yet, this simplicity often proves to be an illusion.
Scrum’s true power lies in its tolerance for uncertainty, but organizations hate uncertainty.

So what happens?
Every Sprint becomes a cycle of repetition, not experimentation.
Empiricism turns into a fixation on predictability.
Inspection happens, but adaptation fades.

Because everyone feels at peace once the ritual box is checked.

⚙️ Experimentation or Predictability?

The theory of Scrum rests on empiricism and lean thinking: learn by doing, eliminate waste.
But in practice, Scrum teams often pursue measurable performance, not learning through experimentation.

If the burn-down chart falls, success is declared.
Yet sometimes the most valuable learning comes from failing to make it fall.
That part, the Guide doesn’t teach, but reality does.

🧭 The Myth of Self-Management

Scrum speaks of self-managing teams.
Beautiful in theory.

But the same text says: the Product Owner decides, the Scrum Master coaches, Developers execute.
In most organizations, this triangle becomes a battle of roles.

Decision boundaries blur, accountability turns into ping-pong politics.
Autonomy, so loudly promised, ends up living only on PowerPoint slides.

💰 What Is “Value,” and for Whom?

The Guide declares the Product Owner accountable for maximizing value, yet the term value remains undefined.
Customer satisfaction? Revenue? Innovation?
No one knows for sure.

And that void is filled by whoever holds the most power.
Thus Scrum, instead of being a value-creation framework, can easily morph into a language that legitimizes internal power dynamics.

⏱️ Timeboxes and the War Against Time

Timeboxes are meant to create focus, and they do.
But some complex problems simply refuse to fit inside them.

Creativity doesn’t always arrive on schedule; sometimes the real idea comes five days after the retrospective, not five minutes before.

Here, Scrum’s discipline can quietly strangle spontaneity.
The clock ticks, but inspiration doesn’t obey the clock.

🧩 The “All or Nothing” Dogma

The Guide is clear:
“Implementing only parts of Scrum is not Scrum.”

This, philosophically, contradicts Scrum’s own foundations.
Empiricism means to experiment and adapt, yet Scrum itself forbids adaptation of its framework.

Declaring it immutable turns agility into rigidity.
It’s ironic: the manifesto for change resists changing itself.

👥 People, Not Roles

Scrum claims to be people-centric, but in practice, it abstracts humans into roles: PO, SM, Developer.

In reality, people bring more than job titles: fears, egos, ambitions, doubts.
The Guide doesn’t touch these.

Yet the success of Scrum doesn’t live in post-its, it lives in trust.

⚖️ Transparency or Visibility Pressure?

Transparency is one of Scrum’s three pillars.
But full visibility is not always healthy.

In certain cultures, being visible means being vulnerable, and vulnerability can be punished.
Thus, transparency can mutate into performance theater.

People stop being honest.
Daily Scrums turn into status reports.
The learning dies behind polite smiles.

🧬 The Paradox of an “Immutable” Agile Method

The Guide declares itself immutable.
In the modern software world, that’s almost poetic irony.

A philosophy built on continuous adaptation has encased itself in static perfection.
Maybe it’s time for a new question:

“Scrum carried Agile for decades.
Who, or what, will carry Agile next?”

🌱 With Respect to Its Roots: Time to Rethink

These criticisms are not meant to destroy Scrum, but to revive it.
Scrum should not be a dogma, but a dialogue.

When Sutherland and Schwaber wrote the first guide, they weren’t creating a formula, they were planting an idea:
“People can work better, together.”

Perhaps it’s time to reinterpret that idea again.
Maybe in its next evolution, Scrum won’t live in post-its or ceremonies, but in how we think.

✍️ Maybe true agility begins when we become agile enough to question Scrum itself.

[Björn Döhler]

I absolutely love this reflection, especially because it dares to ask the uncomfortable questions without falling into the usual “Scrum is dead” rhetoric.

I also use Scrum every day and deeply believe in its value. But I also see how, in many organizations, the framework has quietly become too complex and too self-referential.

Scrum was meant to be lightweight, but somewhere along the way, we started managing Scrum more than we managed work.

What I keep observing is this:

The true success or failure of Agile doesn’t lie in the framework itself - it lies in the ceremonies.

When ceremonies lose their purpose, everything else follows.

A poorly run Daily, a meaningless Retrospective, or a Sprint Planning that’s just task assignment in disguise - that’s where agility starts to feel wrong.

I also couldn’t agree more with your point about timeboxes.

They truly bring focus - and I’ve seen what happens when teams let them slip.

When timeboxes become too loose, creativity quickly turns into endless polishing, chasing “perfect.”

And as we all know, perfect is the enemy of good.

The real power of Agile lies in understanding that there’s always another iteration to make things better - not perfect, just better.

In my experience, teams don’t struggle because they “don’t follow the Guide.”

They struggle because they lose sight of why these meetings exist: preparation, visibility, alignment, and feedback.

Once those four cornerstones are gone, the whole mindset collapses into ritual.

That’s why I’m so passionate about helping teams rediscover these basics - both through our app NASA, which brings structure and collaboration back into Agile meetings, and through my free training Agile Ceremonies for Impact.

I’d be genuinely curious to hear your thoughts on these approaches - and how you see them fitting into the broader reflection on where Scrum goes next.

Looking forward to your feedback!

[SilkeS]

@Björn Döhler, if you're part of a Marketplace App team, we would like to ask you to follow the steps outlined  here  to get an 'Atlassian Partner' lozenge for your profile! Cheers!