Why Scrum is a Scum

I read the book. The original one. By Sutherland himself. Highlighted passages, took notes, the whole nine yards. Then I tried it. Two different teams, two different contexts, two identical results: bureaucratic theatre masquerading as agility.

Let me be clear, I'm not a Waterfall refugee looking for someone to blame. I have never touched Waterfall. I use Lean, where waste is the enemy and flow is the goal. Which is precisely why Scrum's carnival of ceremonies felt like watching someone solve a Rubik's cube by repainting it.

The Overhead Paradox

Scrum promises agility but delivers liturgy. Daily standups that aren't daily or standing. Sprint planning that plans nothing beyond ticket shuffling. Retrospectives where the same issues get "action-itemed" into the void, sprint after sprint.

The irony is exquisite: a methodology designed to eliminate waste creates an entire economy of waste. Scrum Masters who master nothing but Jira configurations. Story points that measure everything except value. Velocity charts that track speed toward nowhere in particular.

I've sat through sprint reviews where we demonstrated features nobody asked for to stakeholders who stopped listening two sprints ago. The burn-down chart was perfect though.

The Cult of Ritual

Here's what Scrum gets wrong: it mistakes process for progress. It assumes that if you do the ceremonies correctly, good software will emerge like some cargo cult of development. Stand in the circle, chant the three questions, and the gods of working code will smile upon you.

Except they don't.

What actually happens is teams spend 30% of their time in meetings about work instead of doing work. The "empirical process control" becomes empirical meeting control. You're inspecting and adapting your inspection and adaptation process.

Requirements Wearing a Disguise

And then there's the user story con.

Requirements: "The system shall allow users to filter products by price range."

User stories: "As a user, I want to filter products by price range so that I can find items within my budget."

Scrum will tell you this is different. That user stories force you to think about the who and the why, not just the what. That they create empathy and focus on value.

In practice? Mad Libs for adults.

"As a [persona we made up in a workshop], I want to [thing we already knew we needed], so that [obvious reason we copy-paste between stories]."

The beautiful part is that requirements used to have acceptance criteria built in - clear, testable conditions. User stories? Also have acceptance criteria. Which are requirements. We've gone full circle, just with more words and a template.

The genuine insight about understanding user motivation gets completely buried because teams treat "As a user" as a magic prefix that transforms boring requirements into agile artifacts. Cargo cult empathy. We're not thinking about users, we're filling out a form about thinking about users.

User stories aren't inherently bad. But Scrum turned them into another mandatory ceremony. And when process becomes mandatory, thinking becomes optional. You end up with teams religiously formatting requirements as user stories while understanding their users no better than before.

Lean just asks: "What problem are we solving and how do we know it worked?" No template required. No personas. No pretending that syntax creates empathy.

What Actually Works

When I work with teams now, we have exactly two rules:

Ship value to users frequently
Remove whatever prevents #1

No sprints. No story points. No sprint planning poker where grown engineers debate whether a button is a 3 or a 5. We build, we ship, we measure, we learn. Repeat.

Is it perfectly structured? No. Does everyone always know what everyone else is doing? Not always. Do we deliver better software faster? Consistently.

The Uncomfortable Truth

Scrum isn't entirely wrong; it's just 80% overhead for 20% insight. The core ideas (iterative development, frequent feedback, empowered teams) are solid. But then it wraps them in so much process that the signal drowns in noise.

The real problem isn't Scrum itself, but it's that organizations adopt it as a silver bullet. "We're agile now!" they declare, right before mandating two-week sprints and full story point estimation. They're doing Scrum, but they're not shipping better software. They're just shipping with more meetings.

I'm sure Scrum works somewhere, for someone. Maybe for teams who literally had zero process before and need training wheels. But for teams who understand their craft, who care about their users, who want to actually be agile rather than do Agile™?

It's overhead in search of a problem.

I don't use Scrum. I ship software. The difference is subtle but shipping.