Scrum Isn’t Dead But Its Mutation In The Wild Today Needs A Cure

Here are my top 4 root causes and treatments.

I’m not keen to give up on Scrum.

Scrum has been my trusted ally for over 20 years, helping me deliver effective software and products. I’ve written 57 articles on it and edited as many for Serious Scrum. Despite its faults, such as a gap in addressing technical excellence, I hold a deep affection for Scrum.

Yet, seeing its current state in the wild today, I’m deeply saddened.

• Sad to see its potential wasted.
• Sad to see it become what it aimed to fix.
• Sad to see the feature factories it often produces.

Scrum is a pale shadow of what it should be.

Why have we arrived here?

You will hear many explanations if you pay attention to social media.

• “You can’t simply install it and expect it to thrive.”
• “It’s easy to understand but difficult to implement.”
• “Everyone has a certificate, but nobody has experience.”
• “It can’t match the scale required by today’s organizations.”

There is truth in these. I could take the rest of this article to elaborate on each. But I won’t.

I would rather address the top problems I see as companies struggle to make it work, and compromise it to death.

We’re not going to touch on running a better Daily Scrum or making Retrospectives fun. We won’t be debating the blunted roles of the Scrum Master and the Product Owner (tempting as this is). We’re not going to belabor the history of Scrum and its many evolutions.

I don’t think Scrum is the problem.

Here’s what we will do: get down to the brass-tacks of the root cause issues. We will explore why they have led to the mutated version of Scrum we all suffer. And we will dive into what we can do to solve for them.

I want to save Scrum (and any attempt to embrace empiricism) by curing what I see as the underlying disease.

---

The 4 Main Problems I See Leading to Scrum’s Demise and What to Do About Them

“Scrum may not be a fit for you. Your work may not need experimentation and learning. That’s why Scrum isn’t working.”

Ever heard this? I have. It’s a common explanation to make you feel good even when you don’t go all-in on the Scrum framework.

I find this reasoning as passive-aggressive.

What you likely need to hear: “You aren’t willing to change to embrace learning, so Scrum isn’t working for you.” Ouch, that smarts. But I would want to hear that instead of smokescreen nonsense.

Few would claim today’s products have simple concerns and learning is unnecessary. Go ahead, try to name one where this is true. I’ll wait.

It’s OK. You can stop racking your brain. I know the answer. Product development is complex and uncertain—a universal truth.

In product, you don’t know what’s needed to get to a desired outcome beforehand. You have to emerge the right path. We don’t know what will work before it does.

Let’s be honest, the reason I see Scrum failing is our resistance to change and learning. It’s as simple as that. Fixing the misuse of Scrum requires us to want to change our habits, commit to doing so, and actually do it.

But that’s not so simple. You can tell by how few companies do it. Scrum is a square peg that doesn’t fit in the round hole of our existing habits.

Scrum often loses to long-held, rigid conventions.

And, to say it straight, many of us have stubborn, bad habits.

Scrum—or any agile framework—won’t stick if you don’t change habits that squash your speed of learning.

This is why I want to share with you the 4 top problems undermining change that I’ve seen companies struggle to break. And we will explore examples of how I’ve helped many overcome them.

Let’s dive in.

Problem №1: Management doesn’t trust the teams and vice versa.

The classic, unfortunate divide between managers and teams still persists today, spreading like a pathogen.

This lack of trust is pervasive. Managers don’t trust teams, teams don’t trust management, and teams don’t trust each other.

And when you don’t have trust, change can’t thrive.

Take one of my teams facing an unrealistic deadline.

Management felt they had to set a deadline. They didn’t trust the team to perform, and they had to set stakeholder expectations. In turn, the team felt no ownership of the deadline. But what they did feel was a fear of missing it. So, here’s how the team reacted:

• Presented untested features as “done.”
• Blamed management for the unreasonable deadline.
• Hid issues until it was too late to avoid looking stupid.
• Stopped doing retrospectives to preserve time to work.
• Delayed solving problems to “show progress” to the deadline.
• Delivered what managers promised, not what the user needed.

Did they hit the deadline? You bet they did. Did they deliver the right thing? No way. Did quality suffer? Yep.

No trust drives fear. Fear kills transparency. And without transparency, you can’t inspect and adapt to win.

If you can’t, don’t, or won’t adapt, Scrum is useless.

Try this: Management and teams co-create.

I’m always surprised with how fast trust can start to rebuild.

It’s actually quite simple. You have to remove the walls between managers and teams. They have to start working together.

When teams and managers act as one, trust thrives.

Here’s how one of my teams did this earlier this year:

• Managers stopped requiring status reports.
• Teams included managers in all Sprint Events.
• Teams pulled managers into the work of the Sprint.
• Managers included teams in all stakeholder meetings.
• Managers made space for the teams to iterate and improve.
• Managers let teams decide what’s possible by when and how to do it.

And you know what? Fear dissolved and trust emerged. It didn’t happen overnight. But with the renewed trust, the team began to embrace change and managers started enabling it.

Walls create a divide that erodes trust. Break them down.

Teams and managers working together is what we want. But its meaningless without the customer in focus. On to problem number 2.

Problem №2: Customer? What Customer?

Getting to “Done” is a joke on most teams I see.

Does done mean developed? Tested? Deployed to production? These are the usual suspects. It’s so bad, folks don’t ask, “Are you done?” They ask, “Are you done, done?” or, “Are you done, done, done?”. As I’ve described before, many teams misunderstand and misuse the Definition of Done.

Why does this happen?

It’s simple and unfortunate. Most teams I see drive to output, not outcomes.

Scrum has produced something akin to a factory that cranks out widgets. And teams have no connection to their customers. You won’t find a customer in deadlines, velocity targets, tasks, tickets, or throughput. Yet, this is how today’s Scrum Teams get measured.

Most Scrum Teams know their ticketing system better than they know their customers. Many don’t even know they have a customer. Like short-order cooks, they hear, “Order up!” Then, they cook to specification.

Teams like this struggle trying to bolt Scrum onto their command-and-control environment. They don’t self-manage, and they don’t iterate. They own a tiny job of a larger purpose they know nothing about. Their engagement hangs on by a thread or is already tanking.

I find these teams fed up with an uninspiring, unending ticket race to nowhere.

Try this: Let the customer decide when you reach “done”

Being done means what you produce is usable, used, and useful.

And only customers can answer if that’s true.

The Scrum Framework can help you do this, but you must first stop the common behaviors preventing it. Here are some radical moves my teams make to put the customer in the driver’s seat:

• Our customer engages with us before, during, and after delivery.
• Done means customers use it, keep using it, and say good things.
• We start basic, evolve with our customer until good enough, and stop.

We refuse to focus on how many tasks we can churn out and how fast. Customer delight is our only metric of success.

For the first time in years, our customers started getting value sooner (at least every two weeks). And we were working easier and smarter because we didn’t have to build a giant pile of unneeded features. Now, our customers have a renewed trust in our team to deliver useful things sooner.

Customer and team trust further enhances a foundation of team and management trust. It’s what I call a win-win-win scenario.

But other walls remain that need to crumble.

Problem №3: Silos within a team has become an epidemic.

I run into Scrum “teams” today who have been together for years but are not a team.

The members don’t know each other. Everyone works alone and only on their specialty. Each person gets partially allocated to several teams and switches back and forth.

This is not a team.

At best, today’s Scrum Teams have become a loose collection of individuals.

The result? It’s not Scrum.

• Opaque progress and issues.
• Wasteful hand-offs and rework.
• Piles of unfinished, unintegrated tasks.
• Low internal quality and compromises to make things fit.
• No discussion between members except at the Daily Scrum.
• Every team member working on many unrelated tickets in parallel.

A Scrum Team needs teamwork, not boundaries.

Try this: slow down and work together on less at once.

Four of my recent teams cracked the code for teamwork. How?

They slowed down and worked together on one goal and one solution at a time. Sounds simple, huh? Well, it wasn’t.

The initial resistance was strong:

• No common ground as relationships had not formed.
• Team members felt they had to sacrifice “alone” time.
• Learning new collaboration skills exhausted the team.
• Performance meant individual (not team) productivity.
• Many felt hired to do one job, not help others do theirs.

See why the habit is so difficult to break?

The change did not happen fast. On average, these four teams took 3–6 months to get comfortable with collaborative focus. It took that long to admit the old way of working sucked and let it go.

But don’t let this discourage you. The struggle was worth it. The benefits we achieved in the end blew our minds:

• Team member feedback cycles improved from monthly to daily. We just weren’t talking before.
• Defects diminished to a point where they didn’t need tracking. Turns out, team decision-making crushes solo decision quality.
• Concept-to-cash lead times went from 6 months to 2 weeks. Nobody saw this coming before we tried it.
  

To thrive, teamwork needs space to emerge—time to learn new behaviors and unlearn the old. This brings us to the final problem we need to solve.

Problem №4: Learning has no space to breathe.

Can a fire rage without oxygen? Nope, it flames out. And in the same way, learning can’t thrive without space to try, mess up, and try again.

Most Scrum Teams I meet have given up on learning. The flame has died out for them. Here are the signs I look for:

• Imposed deadlines suck all improvement out of the Sprint.
• Sprint Reviews get canceled until robust solutions are ready.
• Upfront promises outweigh new evidence of a better solution.
• Learning is always pushed to later (usually a quarter or worse).
• Retrospectives target surface changes, not thorny, root causes.

New evidence loses out and learning disappears with no space to change. And Scrum becomes unrecognizable.

Try this: Expect to be wrong and plan to iterate.

First, some good news.

Resolving problems 1-3 will give you back time. You won’t have the waste of mistrust, feature bloat, and hand-offs to deal with. And what will you do with all that extra time?

I’ll tell you what I’ve done: I’ve made space for learning.

Don’t jump to fill the space you’ve gained with more features. Instead, refine your last step based on evidence. Plan on this. Make it your priority.

Here are some ways I have done this with my teams:

• Assume every solution will be wrong (in some way).
• Don’t create a masterpiece; start simple and evolve.
• Keep capacity in the Sprint to iterate (play around to get it right).
• Assume front-loaded learning; no timeline until learning levels out.
• Pull new features after iterating at least once on the current feature.
• Increase the feedback speed with your customers to every 1–3 days.

Being wrong becomes expected when you care about emerging what’s right with your actions.

---

To sum it up, Scrum requires a learning culture. And having one requires trust, customers, teamwork, and space to evolve.

This will take you a long way toward embracing agility. You could argue that if you do these things, you might not even need Scrum. But if you’re going to use Scrum, this will let you do it in a way that you take advantage of its strengths.

If you’re putting Scrum lipstick on top of a broken system that rejects change, you might want to stop. Don’t half-try to use Scrum until you get your base habits in order.

1. Bring managers and teams together to solve problems.
2. Let your customers dictate when you reach done.
3. Slow down and work on less as a team.
4. Use the extra time to iterate.

Products need learning. Teams need learning. Organizations need learning. Scrum needs learning.

So, embrace learning first. Scrum can and should come later.

---

➡️ Sign up here for weekly deep dives like this. You’ll get practical tips on what it takes create an environment that enables change.