Davide la Locomotive

Scrum gets a bad rap.

Ask most developers and you’ll get eye-rolls, sighs,
and maybe a flashback to a 40-minute “stand-up” that wasn’t standing.

But here’s the thing:
Scrum isn’t broken.
The way we do Scrum is.

This post is part dunk, part explainer.
It’s about the cargo-cult chaos we’ve built around Scrum—
and what it was actually meant to be.

---

When I started doing Scrum, I didn’t know what it was or how it worked.

I found someone who looked like they were doing Scrum and copied what they were doing.

I call this “Scrum by Induction”—and honestly, I think it’s how most people “learn” Scrum, too.

The problem?
The person I was copying didn’t know Scrum.
They were copying someone they thought knew.
And that person was copying someone else.

No one in the chain knew how to do Scrum.

 

When I became a Scrum Master, I had a sudden realization:

I had no idea what Scrum really was.

So I signed up for some courses.

The course trainers described Scrum in a very prescriptive way.
One said daily catch-ups should involve sitting down, going around the room.
Another said they should be whilst standing up, going down the board.

Well… which is it?
It can’t be both.

I got confused.

In an act of random panic, I Googled: “What is Scrum?”

 

Finally, I got an answer.

I found the Scrum Guide—a document that actually describes Scrum.

Its full title is “The Definitive Guide to Scrum: The Rules of the Game”
It is literally the rules of the game.
It even says so in the title.

Scrum without the Scrum Guide is like playing Monopoly when no one knows the rules…
the first time someone lands on Free Parking, the board goes flying.

 

I’d been doing Scrum as a developer for a couple of years by then.
I knew what it felt like when it didn’t work.

When I became a Scrum Master, I kept doing what I’d seen the previous Scrum Masters do—at least for the first few weeks, while I scrambled through training courses and tried to figure things out.

Then I found out the actual rules of the game I thought I’d been playing for years.

 

The first time I read the Scrum Guide, it blew my mind.

I suddenly understood how it was supposed to work and what the purpose of all those meetings was.

I also realized: the way we’d been doing it was completely wrong.
We’d just been making it up.

I felt bad.
Because the purpose of Scrum is to support the development team—to adapt, to make the development process smoother and more consistent.

But most days?
It just felt like it was in the way.

 

Here’s a link to the Scrum Guide.

It’s free.

It’s 14 pages.
(And two of those are the title page and table of contents.)

Not 140.
Fourteen.

The barrier isn’t cost.
It’s effort.

 

The Scrum Guide isn’t prescriptive.
It’s a framework—like an abstract class.

It tells you the methods (ceremonies),
and the properties (artifacts).

It tells you what each method does,
what it’s meant to produce.

But it doesn’t fill in the implementation.

Each development team works with the Scrum Master to decide how they want to apply it.
It’s not set in stone.
It adapts.

The Scrum Guide doesn’t say whether you should stand up or sit down during the daily catch-up.
Each team decides that for themselves.

 

If you’re a developer: imagine Scrum as an abstract class you need to implement:

 

I’ve asked more than one Scrum Master if they’ve ever read the Scrum Guide.

They always laugh.

“No,” they say. “I don’t need to.”

Apparently, Scrum knowledge is passed down genetically.
Or absorbed through the pores by standing near a whiteboard.
Or inherited through herd behavior, collected while roaming inside a rationalization of Scrum Masters.

 

Here’s the part that really gets me.

Scrum Master is a coaching role—they’re supposed to guide the development team in how to apply Scrum.
If they don’t know what it is… how can they teach it to their developers?

It’s no wonder so few people even know what Scrum actually is.
And that’s crazy when you think about how ubiquitous it is.
Learning a programming language is great—but your next company might not use that language.

They will almost certainly be doing Scrum.

 

It’s ridiculous, really.

Trainers who haven’t read the Scrum Guide,
teaching Scrum Masters who also skipped the manual,
leading teams who don’t know what they’re doing,
held together by cargo-cult rituals,
and vague memories of a two-day certification course.

It’s no surprise most developers hate it.

 

But here’s the thing:
this isn’t funny.

It’s people’s jobs.
Their mental health.
Their confidence.
Their joy.

Scrum isn’t broken.

But when we let people run it without knowing the rules…
we end up breaking our colleagues.

 

---

Agile Glossary (Unofficial Edition)

Rationalization of Scrum Masters (n.)
The unofficial collective noun for a group of Scrum Masters.

Officially, the plural of Scrum Master is just… Scrum.
As in: a Scrum of Scrums.

But let’s be honest.
When you get a room full of Scrum Masters together, what you actually have is a rationalization—a gathering where every participant explains why they’re skipping the parts of Scrum they don’t like.
Everyone else takes notes… so they can justify skipping the parts they don’t like.

Example usage:

“We had a rationalization of Scrum Masters— they were all explaining why they skip retrospectives. One said if he runs a retro, people start fighting.”

---