Leave Scrum To Rugby - 4 Major Issues With Using Scrum

Scrum is a buzzword, the virtue signal of choice for middle-management in software organizations.

If your goal as a manager is to implement a system by which you:

• Speed up the appearance of progress
• Pay for 2x the number of people you need
• Gather fine-grained data based on meaningless metrics

Then Scrum is exactly what you are looking for!

"Oh you had problems with Scrum at your last employer? Well, that's not real Scrum."
- your scrum master, who is not a true Scotsman

Needless to say, we don't use scrum at Qvault. Which brings us to our first problem...

Problem #1 - Scrum Is Vague

It's hard to criticize Scrum. The idea of "Scrum" in my mind is likely very different from the one you are familiar with. This is by design, and by admission. In the official Scrum Guide we find Scrum's definition:

A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

I like to put it more tersely:

Scrum (noun) - 1. [software] Any good process that works good

Because the definition is so vague, the only thing I'll be able to criticize throughout the rest of my tirade is the common practices of "Scrummers" that I'm familiar with. Hopefully, some of you lovely readers can relate.

Problem #2 - The "Sprint"

According to the official guide:

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created

Sprints are useful like achievements in video games are useful; they make us feel warm and fuzzy inside. Motivation is a powerful tool, don't misunderstand me. The problem is that those warm fuzzies are mostly for the sake of the management team. It makes them feel in control and informed. They know exactly what was done and when it was completed.

I'm not against management being informed... but at what cost?

Sprints require achievable short-term goals. Let's pretend that I'm part of a team that does two-week sprints (because the duration must be consistent) and I'm assigned to build an API that isn't useful until the whole thing is completed. Let's also say that in my head I believe the whole task to take two months if I can work consistently.

I need to break the API into pieces that can be completed in 2-week increments. I might be able to get some of the endpoints done in as little as a day or two, but I don't want to miss any of my goals, and I know some of the more difficult logic could take as long as an entire week per endpoint. There are 14 endpoints so I decide on a round figure of 2 endpoints per sprint.

An API that could have been completed in 2 months will now take almost 4 months because I've wasted time putting in artificial stopping points along the way. My imposter syndrome starts to set in, but at least management will have pretty burndown charts.

Problem #3 - The Scrum Master

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.

Depending on how the idea of the scrum master is implemented, it can be a bad idea or a worse one. Let's just talk about what seems to me to be the most common scenario.

The scrum master is a non-technical, middle-management type that likes to be in charge of stuff.

In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the "Java code" for the React app will be done.

The very individual whose purpose it is to stop the outside world from bothering their developers is the single biggest bother. In my opinion, non-technical people should rarely, if ever, be managing technical people (except the CEO). I should be able to go to my boss for help and advice with my tasks, or at the very least I should expect them to understand my assignments.

Even if the scrum master is a lovable person who grasps the technical issues from a high-level, Scrum Master isn't a full-time job. Too often scrum masters daily tasks involve a stand-up or two in the morning, a meeting with higher-ups in the afternoon, and not much else.

If you still feel the need for a "scrum master", just let the lead developers handle the job. They are already at stand-up and likely have a better idea of what is going on. You aren't putting more on their plates, you are likely taking something off.

Problem #4 - Estimates

Within Scrum, estimates have a primary purpose - to figure out how much work the team can accomplish in a given sprint. If I were to grant that Sprints were a good idea (which I obviously don't believe) then the description of estimates in the official Scrum guide wouldn't be a problem.

The problem is that estimates in practice are a bastardization of reality. The Scrum guide is vague on the topic so managers take matters into their own hands. With this in mind, I am again going to criticize some common practices that I have seen in regards to estimates.

Fibonacci and T-Shirt Sizes

Many super-hip organizations enjoy using the most confusing scales for estimates. They claim that this somehow makes estimating a faster and less stressful process. I remain woefully unconvinced.

My first day at a new company during our estimation meeting after hearing they used the dreaded "story points" system:

Me: "What is the scale used here for points?"

Scrum master: "Fibonacci, where 8 points is the max because we defined it as the amount of work a developer can handle during a two-week sprint".

I eventually learned the actual system.

1 point: 0 - 8 hours

2 points: 8 hours - 2.4 days

3 points: 2.4 days - 1 week

5 points: 1 week - 1.5 weeks

8 points: 2 weeks

The end goal of an estimate is to convert workload -> time. Why do we need to add an extra step of workload -> story points -> time? A simple estimate of "how many days?" would have been easier to think and reason about, while also providing more granularity.

A common objection to using such a barbarically simple system is:

We use fibonacci because its hard to imagine the difference between 7 and 8 days. No one can estimate that closely. Fibonacci sequences go up by ~60% at each step so you aren't forced to get very close to your estimate.

To that, I propose base-2 exponentiation based on the scale you care about in the first place, time.

1, 2, 4, 8. Hours, days or weeks.

It seems we have solved the problem! Until another good-intentioned scrum master pipes up:

If estimates are grounded in measurable time then engineers will feel like they've screwed up if they miss their estimate.

Good point, estimating is hard and we don't want anyone to feel like they are a bad engineer just because they aren't the perfect estiamtor. That said, maybe instead of starting a game of "Whose Line Is It Anyway?"

the reasonable expectation could be set that estimates are just that, estimates.

Estimate - roughly calculate or judge the value, number, quantity, or extent of.

If an estimate turns out to be bad it can be re-estimated at no detriment to the estimator.

Final Note: Agile != Scrum

I'm a fan of agile methodologies and the Agile Manifesto. I'm not a fan of Scrum. In a later article, I plan to go over my thoughts on what to do in lieu of Scrum while still running an "agile" organization.

fin.

Thanks For Reading

Follow us on Twitter @q_vault if you have any questions or comments

Take game-like coding courses on Qvault Classroom

Subscribe to our Newsletter for more educational articles