Why scrum is dumb

You would be hard-pressed to find a software manager who didn’t want to be “agile.” But I’m guessing that a vanishingly small percentage of them have actually read the Agile Manifesto. And I’m guessing even fewer have given any real thought to what agile means and how it might be applied in the real world. 

Sure, the Agile Manifesto is revered by software developers. Most of us feel like there is something there — some deep-seated truth that we all know. But the problem arises when we try to figure out the answer to the question, “Okay, now what do we do?”

The norm seems to be, “We need to be agile, so let’s hire a scrum consultant and implement scrum. Then we’ll be agile!” The market forces to provide scrum services are strong. And there is certainly no shortage of eager consultants who are ever-ready to offer their services.

Why this is true is a mystery to me. I fail utterly to see how scrum is a manifestation of the Agile Principles. In my view, scrum is in direct opposition to them, and in the end, doesn’t even remotely fulfill their purpose.

Cramming it with scrum

Everything about scrum tries to squeeze a large peg into a small hole. Scrum creates a fixed-sized hole of a given chunk of time, takes a large wooden block of effort, and tries to make a series of small, properly sized blocks fit into that hole.

Never mind that the size of the hole may or may not fit the blocks that you have. You are supposed to whittle them down so they fit, even if what you end up with isn’t really what you want or need. You are not allowed to change the size of the hole that the blocks are supposed to fit into. That block must fit into that hole, and that hole ain’t getting any bigger.

I have no clue why this is a good idea, and I certainly don’t see how it prioritizes “individuals and interactions over processes and tools.”

So, we whittle down the pegs into these unnatural shapes that will allegedly fit the rigid holes we’re given. Only they don’t. The peg rarely if ever ends up fitting in the hole. As the sprint nears its conclusion, the work is either already done (what to do with three extra days?) or it will never be done in time (“Can we extend the sprint a week?” “No!”), in which case we “fail” the sprint.

Sprint, sprint, and sprint again

And who wants to continuously sprint anyway? Who wants to always and forever be approaching a deadline? Constantly pushing for “finishing” something leads to shallow solutions that are rushed. Requirements and constraints in software development change all the time as unknown unknowns are discovered. Doing something properly and thoroughly often takes time. But the process of scrum says that if you want to change course, you must wait until the sprint is over. How is that “Responding to change over following a plan?”

A sprint is a very narrowly focused chunk of work. If you constantly focus on narrow things, you can easily lose sight of the bigger picture.

And all too often, scrum becomes a large ceremony. Does anyone look forward to the daily standup where you have to drop everything, go to a meeting room (or a Zoom meeting), and tell everybody what you did and will do? Be honest — aren’t you relieved whenever the scrum master says, “Email scrum today!”?

What’s more, retrospectives are frequently forced and held even if there isn’t any feedback to be had. There ends up being much too much going through the motions — the very antithesis of agility and adaptability.

And that isn’t even talking about the never-ending sprint planning and backlog grooming meetings that inevitably become part of the process that you are supposed to put in the back seat behind individuals and interactions.

A better scrum process

In the end, scrum becomes an endless series of short software projects that end like most software projects. They take longer than you expect, don’t accomplish what they set out to do, and involve many hours of meetings that most folks would rather not be in.

How about doing something like this instead?

Break the work up into natural chunks that match the needs of the project. Some will be small chunks, and some will be big chunks. 

Do each chunk in the order that makes sense, with each chunk taking a given amount of time. Perhaps a chunk needs more than one developer — not a problem.

Recognize that the time for each chunk will vary from what you expect at the beginning.  Track each trunk separately, and don’t force every chunk to finish at a fixed, inflexible time.

If you are in the middle of something, and what you are doing no longer makes sense because of changing circumstances and shifting winds, change to a new, better course immediately.

When the time is right — not when the calendar dictates — review what you’ve done, ask for feedback from customers and stakeholders, and adjust accordingly.

If the list of chunks needs to change, let the list change.

Lather, rinse, repeat, until all the chunks you need are complete, then ship the software.

Maybe even ship each chunk as it completes.

In other words — be flexible, nimble, and… agile.