When Will Scrum Die?

Some people would argue it already is.

There's so much inauthentic, unprofessional Scrum happening in the world today that it's fair to ask whether the thing we call "Scrum" in most organizations is really Scrum at all. But the picture isn't all bleak — and the answer to the question matters more than you might think.

The Inauthentic Problem

A lot of what passes for Scrum today is actually what I'd call Water Scrum Fall — Scrum dropped into the middle of a predictive, deterministic system. We're predicting exactly when work will be finished, even though we're dealing with so much uncertainty that we don't know what we don't know.

One of the most telling symptoms is how teams talk about "done." In these environments, "done" gets reduced to we met the acceptance criteria. That's not what done means. Done is closer to a checklist of how we do things around here — the technical standards, the product quality standards, the international standards we need to comply with. If that concept isn't alive in the team, you're not really doing Scrum.

So yes, in that sense, Scrum is dying.

But There's Reason for Hope

The encouraging half of the story is the level of authentic agility that's quietly growing.

I see it in the advanced practitioners showing up to my PSM II classes. Many of them arrive a bit deflated, because they're stuck in systems that expect them to do things they shouldn't be doing: creating dashboards, coordinating between teams, managing work, acting as delivery managers who are on the hook for delivery rather than the effectiveness of the Scrum team.

Once they work through PSM II, the penny drops. We're not supposed to be doing these things.

What they are supposed to be doing is observing, and — with permission — coaching, teaching, advising, and acting as change agents. Working with the organization at all levels. Helping managers and executives cultivate the environment in which real agility can grow.

I send them off as ambassadors. When the next person is hiring a Scrum Master, or wondering what one should actually do, these practitioners will set the record straight.

The Product Owner Problem

When the Scrum Master is on-message, it increases the odds that the Product Owner is a real Product Owner — not just a team-level one. And that matters, because there is only one owner for a product.

You might have product managers inside each team. You don't have product owners inside each team. The most common failure mode I see is organizations assigning someone as Product Owner because they have the time to do the work, rather than because they have the power to do it.

Occasionally you see the opposite — an executive who genuinely owns a product and sits with the team because they're working on something new and important. That's wonderful, and rare.

We've also been slowly moving away from treating business analysts as Product Owners. Business analysts are excellent professionals, but from a Scrum perspective they're Developers — because in Scrum, "Developer" just means someone who does the work.

From Feature Factories to Discovery + Delivery

Where I see real hope is in teams that aren't just delivering — they're discovering in order to deliver. Discovery-to-delivery teams, not feature factories cranking out whatever was asked for.

These teams are more likely to have UX practitioners working alongside everyone else. They're more likely to realize that maybe 70% of the ideas in the backlog should never be built, and then find the better ideas that should. They behave almost like heat-seeking missiles for value.

That's the Scrum I'm excited about. That, combined with resources like evidence-based management and professional Scrum training from Scrum.org, keeps me hopeful that the authentic version of this thing can win out.

When Scrum Isn't the Right Fit

Here's where I want to be honest, though: Scrum isn't for everyone, and pretending otherwise is part of what's hurting it.

Agility has been growing beyond software for years. In non-software contexts, it can be genuinely difficult to deliver something valuable within a 30-day increment. I worked with a team in the oil industry whose initial cycle time for delivering real value was four months. We got it down to under a month over time, and at that point they had the option to step into Scrum and really commoditize their agility.

But before that point? Scrum would have been the wrong tool.

That's why I've been introducing Kanplexity — Kanban for complexity — into the market. It's aimed primarily at non-software, non-tech teams operating in complex domains where a 30-day valuable increment isn't yet realistic.

I'd much rather someone do something they genuinely believe in and can be authentic about than pretend to follow the Scrum values when their context isn't actually compatible with them.

The Real Answer

So — when will Scrum die?

It will die in the places where it was never really alive: where "done" is a checklist of acceptance criteria, where Scrum Masters are delivery managers in disguise, where Product Owners are chosen for availability rather than authority, where teams deliver features instead of discovering value.

And it will keep thriving in the places where practitioners stay honest about what the framework is actually for.

I love Scrum. I think it's brilliant. I also think people deserve more options, so they can do what's genuinely right for their context rather than have something imposed on them that was never going to fit.

That's the future I'm working toward — and it's the one worth building.