Why Engineers Hate Scrum

There are a lot of people out there burned by bad experiences with Agile and Scrum. And talking to them about it, what their team called “Agile” consisted of doing things that Scrum says to do without understanding why they’re done and consequently not getting benefits out of it.

(This reminds me of the legendary “cargo cults” – supposed Pacific Islanders who, after having their world transformed by WWII, constructed dirt runways and wooden planes in hopes of attracting cargo drops. All of the ritual, none of the benefits.)

I don’t have strong feelings about Scrum. If your team is doing well without it, great. If you’re using it successfully, great. If you’re using it “Just Because” and everyone on the team hates it, then something got lost in translation.

Here are some common Scrum mistakes:

Mistake 1: Not Explaining Why

It’s simple. If you are implementing Scrum, you *must* explain why Scrum techniques exist. Start with the problems that come up without Scrum, then explain how the techniques address those problems.

And if you’re implementing Scrum and don’t understand it well enough to explain it, then brush up on the “why”, not the “how”.

Mistake 2: Tying Story Points to Time

If each Story Point was equivalent to a fixed amount of time (hours, days, etc.) then we would just scrap Story Points and use time instead.

Story Points should be explicitly distanced from time, partly to prevent people outside the team telling customers, “Great news! The team will have this done in X hours!” and partly because 1 Story Point for team A will be different from 1 Story Point for team B. Story Points are only valid within the Scrum Team and lose meaning when transferred outside.

Story Points, along with their fibonacci options, are an acknowledgement that it’s a fuzzy estimate. We can compare and say that two features that are both labeled as 5 Story Points are very roughly the same complexity, but we can’t say much more than that. This should reduce the pressure for team members to fudge Story Points lest they be judged based on clock time.

Mistake 3: Turning Planning Poker into a Democracy

When I ran Planning Poker, I made everyone on the team participate and give Story Point estimates, even the product manager. It would be silly to think that a majority consensus among the new grads and PM would override a minority estimate from the tech lead.

Planning Poker serves as a launching point for discussions about complexity, not as a voting system. If everyone estimates roughly the same values, it might be a very brief discussion. If some estimates are outliers, then we talk about why there’s the outlier.

An outlier might just be because someone is not familiar with that part of the codebase. It’s nothing to be embarrassed about, but the expert at the table can simply explain, “Adding Foo would also require modifying Bar and Baz, which is why I gave it a 5.” And over time, everyone learns something.

However, an outlier might be unforeseen complexity, and finding out during Planning Poker is much much better than finding out in the middle of the Sprint. Because unforeseen complexity isn’t always due to code complexity, everyone has a chance to give input. So yes, if the product manager estimates a feature to be a 13 while everyone else gives it a 5, then alarm bells should be ringing.

This is also why all estimates are revealed simultaneously. Sometimes “strong” personalities can unduly influence others, or some people might not be as confident. If you can run Planning Poker in a welcoming, non-judgmental way, you’d be surprised at the insights coming from non-experts.

Mistake 4: Not focusing on the current Sprint

In any Sprint, someone will finish their stories before others. The natural next step should not be to work on random other stuff off the top of the backlog, but to help the team finish the original stories in the Sprint. Are there diffs waiting for review? Tests to be written? Stories that are just waiting to be started?

One objection I’ve heard is that their people are not interchangeable, that Story 1 needs to be done by person A, story 2 needs to be done by person B, etc. This is a red flag – how your team is defined might not be a good fit for Scrum, and I can imagine two situations.

One situation is that your team is composed of very different roles: designer, software engineer, product manager, etc., in which case you should step back and think about whether everyone should be participating in one Scrum team, or whether Scrum is right for your team at all.

Another situation is that each story involves a specific component and nobody else knows how to work on that component. For small teams, this might be a sign that expertise is too narrow and the “bus factor” for any one component is too low. For large teams, it could be a reason to break up the team into smaller sub-teams, each with their own Scrum.

Sprints should be able to offer some predictability on when things will be delivered (more consistent latency, you might say), but working on things from the backlog at the expense of the current Sprint hurts that benefit. Scrum, like rugby, should be a team effort. Whether it makes your team healthier or not is up to you.

Above all…

… don’t lose track of the Why. Doing Sprint because “the boss told us to” or “because this other company is doing it” are great ways to screw up the implementation. There’s a great This American Life podcast about how GM learned The Toyota Way through their NUMMI partnership with Toyota, then proceeded to botch its implementation at their other plants. There are no magic bullets to software engineering, and implementing a good process poorly can be worse than not changing anything.