Why Does Scrum Suck? (And What Do We Do About It?)

November 02, 2026

This is one of the videos in my Agile-ish series: the good parts of agile, minus the ceremony.

Shameless plug: Want to answer "what's stuck?" and "are we on track?" without the ceremony? Honest Cheetah answers the three questions straight from your Azure DevOps or GitHub data. It measures the system, not the people.

▶ Watch this video on YouTube (opens in a new tab)

A friend of mine's team was frustrated with how they were working. Basically, they were frustrated with Scrum. So he asked them what they'd type into a search box first if they were frustrated and wanted to actually do something about it.

The reply was: "why does Scrum suck?"

Yikes.

TL;DR

Steal.

Dump Scrum if you want to, and don't feel bad about it. Then steal all the good ideas from Scrum and run your projects the way you want. The rest of this post is about understanding the decisions, and pointing out the things you'll still need to worry about and do.

Let's Face It: A Lot of the Time, Scrum Really Did Suck

As someone who spent a decade or so in the Scrum consulting and training world, you might expect that I'd try to defend Scrum. Instead, I'll freely admit it: Scrum as experienced by a whole lot of teams was pretty darned sucky. It was a whole lot of pointless meetings and ceremonies that ultimately didn't deliver much software and just made people feel hopeless.

So Scrum was sucking for those teams, they weren't feeling great, and they were being told to use it anyway. Sound familiar?

The Skeptic in the Room

Whenever I'd do a "fix our Scrum" consulting engagement or teach a class, I'd almost always start by saying the following thing:

"Scrum is not the point."

Which is a pretty weird thing to hear from a Scrum trainer.

And then I'd say something like, "I don't even particularly care if you're using Scrum." Another weird thing to hear from a Scrum trainer. But the thing is, I actually meant it. I've always been a bit of a Scrum skeptic, and because of that I think I taught Scrum differently. Basically, I taught it backwards.

Backwards, in this case, meant starting with the point of doing Scrum rather than with Scrum itself. You're trying to ship done software that makes your customers' (or at least your bosses') dreams come true. Everything in Scrum is supposed to tie back to that delivery.

Oh, and I also stressed that everything works better when you think of what you're doing as software delivery rather than software development. If you talk about "development," you tend to have a code-centric view of the world. If you talk about "delivery," you tend to think about the team-based process of actually getting stuff out the door.

Hang on to that phrase, done working software, because we're going to keep coming back to it.

Two Flavors of Scrum

Here's the thing most people miss. There are two Scrums.

There's the official version of Scrum, developed by the guys who created it. That's the stuff that's governed by the Scrum Guide, and you can download it for free.

And then there's the "everything else" version of Scrum, which is pretty much whatever anyone theoretically thinks or says that it is. I call it feral, free-range Scrum. The really nifty part is that there are zillions of people who got trained at various times over the last 25 years, and depending on when they did their training, they've got completely different ideas about what Scrum is.

Let's compare them.

Slide: Two Different Scrums. Scrum on Paper: a short guide, getting less prescriptive, focused on done software. Scrum in the Wild: mostly meetings, a pile of practices treated as mandatory, focused on the ceremony.

Scrum on paper is a short document. You could read the whole Scrum Guide over lunch. It's been getting shorter and less prescriptive over time, which is kind of the opposite of what you'd expect. And at its core, it's about getting to done software over and over again.

Scrum in the wild, the one the industry decided it was, is mostly meetings. Lots and lots of meetings. Meetings for the sake of meetings, because Scrum is all about meetings, and furthermore, more meetings. Plus a whole pile of practices that everybody treats as mandatory, even though they aren't. And way too often, the focus drifts onto the ceremony instead of the software.

Most of what people hate about Scrum? It lives in that second one.

Scrum on Paper Keeps Getting Lighter

Let's start with Scrum on paper, because I bet this part surprises you.

The 2020 Scrum Guide explicitly set out to bring Scrum back to being a "minimally sufficient framework" by removing or softening prescriptive language. Their words, not mine.

An example of something that got tossed: the three Daily Scrum questions. What did I do yesterday? What am I doing today? What's in my way? Gone from the guide.

But here's where the branding problem comes back to bite. Scrum took on a life of its own, and practically nobody noticed these changes. Honestly, I'm not surprised, because just about nobody had any reason to care. The typical normal person is maybe going to read the Scrum Guide once, to prep for the PSM I exam. Take the exam, pass the test, and sayonara, Scrum Guide.

Nobody Cares

Just let that sink in for a second. What the Scrum Guide says doesn't matter. Most people don't know it exists, and even if they know it exists, they probably don't care. And just like that, Scrum pretty much means whatever anyone thinks it means.

"Required By Scrum"

The big ol' bummer is that the world of software thinks there are a whole bunch of things they "have to do" that they really don't have to do.

The practice	In the Scrum Guide?
Story points	Nope
Velocity	Nope
Planning poker	Nope
Story mapping	Nope
Dot voting	Nope
Retro icebreakers	Nope

Story points and velocity? They're popular practices that grew up around Scrum, but Scrum doesn't require them. Planning poker? A nifty idea to make estimating go faster, and it's not in there either. Story mapping and dot voting? Once again, they can be useful tools, but they're not in the guide. And those touchy-feely icebreakers at the start of every retro? Definitely not in the guide. Somebody just really, really liked them.

That's the whole list, and not one of them is actually required by Scrum. Not one.

"I Hate Estimating."

Here's the part I really want you to hear. If you hate estimating, and you hate story points, and you hate planning poker? That's not required by Scrum, and I'd encourage you to stop.

There are better options, like throughput and cycle time, that are a whole lot easier to do. I wrote about why in Why Do Our Estimates Suck?, and there's a whole series on flow metrics if you want to go deeper.

Then the World Moved

On top of all that, the world just kept on moving.

New thinking about estimates. The #NoEstimates folks and the flow metrics crowd basically said story points were a waste of time and average velocity was pretty useless. By the way, I happen to agree with them.

The pandemic. Co-located teams became a lot less common when we all switched to working remote in a matter of weeks.

Face-to-face, gone. That's a big deal, because the Agile Manifesto says the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Then nobody was in the same room.

Same rituals, now on video calls. And what did most teams do about it? They just moved all the same meetings onto video calls, which somehow made them more boring and more useless and more painful.

Honestly, some of the stuff that used to make perfect sense in Scrum has gotten a little weird over time. But that's a whole other video.

My Advice: Steal

Dump Scrum, and steal.

If no one wants to do Scrum, or your team wants to try something else, or your bosses never want to hear the word "agile" again, then just dump Scrum. Because remember: Scrum is not the point, and it never was the point.

But buried under all those meetings was a lot of wisdom and a bunch of good ideas. Go steal those good ideas and use them without ever saying "Scrum" or "agile" or "sprint planning." Take the good stuff and run.

Steal the Good Stuff

So what are the ideas you're going to want to steal?

Done software. The focus on done, working software is the whole point. That's the entire game, and the whole reason you're getting paid. Focus on done.

Fast feedback. You want feedback as fast as possible. There was a feedback loop buried in those meetings, to make sure you're building the right software, that you're on track to actually deliver it, and that the vision for the product is valid. You need that feedback, and the faster you get it, the better off you'll be.

The metrics mirror. Scrum felt bad a lot of the time because you saw how slow your delivery was and how hard it was to get stuff done. Scrum didn't slow you down. It showed you how slow you already were. You're inevitably going to be asked "when will my features be done?" and you'll need accurate, honest metrics to answer it. Here's a hint, based on experience: story points and velocity aren't actually all that great at this, and you should try something else.

Focus. Finish things before you start new things, minimize work in progress, and stop multitasking. Focus on getting things done.

Steal all of that, and leave the rest behind. If you want the meeting-by-meeting version of this, I've got a whole post on that.

Three Questions Instead of a Framework

Once you've stolen the good stuff, here's a simple way to run things without all the baggage. Three questions.

What are we going to work on? One prioritized list, in order, in one place.
What are we working on right now? What's in progress, what's stuck, and what's been sitting there too long?
Are we on track? Are we actually finishing things, or are we just busy?

Every one of those ties right back to done working software. And if your board and your data can answer all three at any time, without a meeting, you've got a process. Everything else is optional.

Quick Recap

There are two Scrums. The Scrum in the Scrum Guide, and feral, free-range Scrum. Most of what people hate lives in that second bucket.
Nobody cares what the guide says. The guide keeps getting lighter, but honestly, nobody noticed, so Scrum means whatever people think it means.
Hate estimating? Not required. Story points, velocity, planning poker, and retro icebreakers aren't in the guide, and there are better options.
Dump Scrum if you want. Steal the good stuff. Done working software is the point, and it always was.

Shameless Plug

I built a tool called Honest Cheetah that answers the three questions straight from your Azure DevOps or GitHub data, without the ceremony. Give it a try and let me know what you think.

-Ben

-- Is your team sick of Scrum but not sure what to do instead? Want help keeping the good parts and dropping the rest? We can help. Drop us a line at info@benday.com.