After years of developing software by (incorrectly) applying the Scrum methodology, I have come to this conclusion: Scrum is the new death march. Or rather, Scrum does more harm than good when it's mindlessly requested by managers who are merely trying to show how modern and trendy their development teams are.

I recently received a message from an ex-colleague of mine, so what follows is, unfortunately, a real situation.

"Dear CodesAndNotes…

How are you doing? We are working in Scrum, two-week sprints. The first two sprints went all okay; then the business came and added a lot of pressure. We were at 25 story points per sprint, but the business pushed. So we took 35 and worked like crazies for two weeks. When we presented the job to the stakeholders, the Scrum Master promised the business we would push it to 45. I got really angry. We came out tired and burned from the previous sprint, and this guy makes impossible promises! He keeps on reminding us that we have to get to 45 points, every single day. I raised the issue last Friday but I was the only one to complain; the other devs just looked down at the floor. So, I’m trying to get involved and spend my time helping my colleagues, but I’m actually just exhausting myself. Maybe I should go into my corner, focus on the tasks and tell the others to find help elsewhere. I’m sure you had this situation before…what should I do?"

This is where my heart sank. Yes, I’ve has this situation before. Alas!

I remember being amazed by the wisdom that could be extracted from the Scrum methodology, and I was convinced that it would work…in theory. Scrum was my first contact with iterative development. Certified Scrum Masters swear by it (no kiddin'). Developers…well, the reactions I’ve met range from “meh” to “bullsh*t” with 50 shades of swear words in between.

So how come Scrum is such a drag in practice? What’s going wrong?

Scrum as a Tool to Pressure Developers

Those of you who are Scrum experts will know what is wrong with the situation described above.
I’m no Scrum expert and I won’t pretend to be one, but let me have a go at this…

Since when is Scrum a tool to pressure developers?

Story points are supposed to measure the effort a team of developers is able to provide. We use that measurement to see whether the team will be able to meet the deadline or whether the estimations are way off. We also use that measurement to detect whether something is going wrong for some reason so that we can react and fix whatever is bringing the team down.

But in this case, it’s more like:

Scrum Master: “Alright! We managed to do 25 points. Now I demand you to do 35!”

Developer: “But, but, but…”

Business: *whispering in Scrum Master's ear* “We demand more.”

Scrum Master: “Right. Ah…hm. WHAT’S THAT, PUNY DEVELOPER? ARE YOU COMPLAINING? OKAY THEN! I DEMAND…45 POINTS!!! MUHAHAHAHA!!!”

Fade to black. Project is botched. Developers seize the occasion to leave the company and get a raise while they’re at it.

What a Difference a Point Makes

I advised my friend to start raising the points at the planning poker. You estimate the effort to three? Give it an eight! I mean sure, why not? If the Scrum Master is convinced that story points are actually the goal to achieve, let’s help him achieve the goal so everybody’s happy:

Developers: “So, we’re giving it an eight.”

Scrum Master: “What? Why? I mean, that’s way too much for that story!”

Developers: “Yeah, well, it looks like the effort we have to put to complete that story is higher than we thought. I mean, we only have eight hours a day, for ten days (minus the meetings), to achieve that. We work full steam already and we can’t reach those 45 points. So, we deduced that we’re probably underestimating the efforts. That explains why we can’t achieve 45 points, right?”

Scrum Master: “…”

Fade to black. Scrum Master and Developers hate each other. A war begins. Project is botched. Developers seize the occasion…okay. You get the point.

Story points only have a meaning if they represent something to the team. Imagine asking two teams to complete the same set of stories: team A estimates the effort at 25 points and team B at 45 points. What difference does it make? Maybe Team A is optimistic while team B is pessimistic. Maybe team A has measured an average of 25 story points while team B has an average of 45. The only thing the Scrum Master can gather from that is how much work they are able to achieve per Sprint. The rest is just numbers…

Your Promise, Not Mine

When the Scrum Master went on and promised 45 story points in front of the business, he betrayed the whole team.

A Scrum Master is supposed to be the team’s friend! He’s there to serve "as a facilitator for both the Product Owner and the team. The Scrum Master has no authority within the team (thus couldn’t also be the Product Owner!) and may never commit to work on behalf of the team."

So my advice would be to have a chat with the Scrum Master.

Scrum Master: “Guys! The sprint is almost over and you have done 20 points so far!”

Developers: “Yes. Yes indeed.”

Scrum Master: “But you promised 45 points to the business!!! I AM NOT HAPPY!!! GLARBLARBLBL…” (Incomprehensible gibberish follows.)

Developers: “Hold it there. You promised, not us. That’s your promise. And we were not happy about it.”

Scrum Master: “Oh, I see. Where did your team spirit go?”

Developers: “It vanished when you committed to work on behalf of the team.”

Scrum Master – “…”

Fade to black. Scrum Master is fired. In the meantime, the team faces alone the management demands. It’s a huge mess. Developers seize the occ…okay, okay.

Conclusion

“I’ve seen things you people wouldn’t believe. Attack Teams enraged off the shoulders of Management. I watched devs’ eyes glitter in the dark reading LinkedIn’s Job Alerts. All those efforts will be lost in time, like tears in the rain. Time to change.” — Rutger Hauer, Blade Runner (well, something like it!)

Scrum is a tool, and like any other tool, it can be used the right way or the wrong way.

I would initially avoid using Scrum and rather start with something simpler (like, say, Kanban) unless everybody, management included, is willing to put the time needed to understand the philosophy behind Scrum, what can come out of it (responsible developers, communication, iterative feedback on the project status, etc.), and what must be avoided (micro-management and unrealistic 10x productivity).

Unfortunately, all of the Scrum that I have seen so far is a by-the-book application of methodology rules with no understanding the reasoning behind those rules. Consequently, Scrum is now starting to strike fear amongst good-willing developers. They get that sense of dread some of us recognize from those moral-churning death marches we were confronted to back in those Waterfall days…

Until next time. Cheers!