by Gary Worthington, More Than Monkeys

I’m bored.

Not because Scrum is boring (it isn’t, when done well), but because every few weeks, someone resurfaces the same tired hot take:

“Scrum is perfect for building X, every team should use it!”

or

“Scrum is terrible! It’s just micro-management and pointless ceremonies!”

These posts rack up thousands of likes, spark polarised comment threads, and make absolutely zero difference to how real teams ship software.

So let’s get this out of the way:

Scrum is an incomplete framework and thats ok. That’s the point.

It’s not meant to be complete. It’s meant to be adapted.

Frameworks Don’t Save You

Scrum doesn’t make your team high-performing. Neither does Kanban, SAFe, XP, or whichever Notion template is flavour of the month.

You know what does?

• Honest conversations
• Clear priorities
• Trust between product and engineering
• And continuous improvement driven by real feedback

You can do all of that in Scrum. You can also fail spectacularly in Scrum if you treat it as dogma instead of a tool.

The Extremes Miss the Point

Let’s look at both ends of the spectrum:

Scrum Is Perfect™
This usually comes from certified trainers and agile coaches clinging to authority, or people whose careers depend on selling “by-the-book” Scrum.

They’ll tell you that if Scrum isn’t working, it’s because you’re not doing it properly. Which is like saying:

“The parachute failed? Must’ve been user error.”

The reality is, you don’t get better outcomes by doubling down on process. You get better outcomes by asking whether the process supports your goals, your team, and your context.

Scrum Is Awful™
This group is often reacting to bad experiences, and rightly so. But they throw the baby out with the bathwater because they’ve seen it misused.

Maybe they sat through 2-hour daily standups. Maybe they were forced to point every ticket while velocity was used as a performance metric. Maybe they were in an “agile” org where planning was still command-and-control behind the scenes.

None of that is Scrum. It’s just bad implementation wrapped in buzzwords.

Scrum Is a Starting Point, Not a Solution

Scrum gives you a minimal structure:

• Roles: Product Owner, Scrum Master, Developers
• Events: Sprint Planning, Daily Scrum, Sprint Review, Retrospective
• Artefacts: Product Backlog, Sprint Backlog, Increment

That’s it. There’s nothing in the Scrum Guide that tells you how to do roadmapping, team topology, estimation, release planning, technical quality, …... It’s deliberately incomplete because it expects you to do the work of tailoring it to your organisation, because how could the creators of Scrum know how your business works?

You’re supposed to reflect, adapt, and evolve. Not cargo-cult. Not cookie cutter.

If You Implement It Poorly, It Will Suck

Here’s the truth:

• If you run Scrum without business context, you’ll end up with busywork.
• If your retros are performative, nothing will change.
• If you treat velocity as a target, you’ll optimise for the metric and tank your quality.
• If you copy Spotify’s squads without Spotify’s culture, you’ll get organisational theatre.

None of this means Scrum is bad or inappropriate. It means you built a bad implementation.

You can build a bad implementation of anything. It doesn’t make the thing fundamentally flawed , it just means you didn’t do the hard work of shaping it to fit your context.

So What Should You Do?

1. Start with principles, not process.
   Ask what outcomes you’re trying to achieve. Then use frameworks to support those outcomes, not replace the thinking.
2. Run experiments.
   Try things, observe what happens and then adjust. If your planning isn’t working, fix that. Don’t throw out Scrum , just fix the thing.
3. Give your team autonomy.
   High-performing teams shape their own ways of working. The framework is the scaffolding, not the building.
4. Respect your constraints.
   Regulated industry? Distributed team? Fast-moving startup? Your Scrum should look different, and that’s fine.
5. Stop playing framework top trumps.
   The goal is working software, not winning arguments on LinkedIn.

Final Thought

Scrum isn’t perfect.
It’s not terrible either.
It’s a tool.

Like any tool, it depends on how you use it and whether you’re willing to adapt it to your environment, rather than expecting it to solve your problems for you.

You wouldn’t blame a hammer if you used it to stir soup.

Gary Worthington is a software engineer, delivery consultant, and agile coach who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance