Scrum is the new death march

Scrum was my first contact with iterative development. Certified Scrum Masters swear by it (no sh!t). Developers… well, the reactions I’ve met range from “meh” to “bullsh!t” with 50 shades of swear words in between.
I remember being amazed by the wisdom that could be extracted from the methodology, and I was convinced that it would work… in theory. So how come Scrum is such a drag in practice? What’s going wrong?

Dear CodesAndNotes…

(I recently received this DM from an ex-colleague of mine, so what follows is a real situation)

How are you doing? We are working in Scrum, 2-week sprints. The first two sprints went all ok, 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!

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 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… Hum. WHAT’S THAT, PUNY DEVELOPER? ARE YOU COMPLAINING? OKAY THEN! I DEMAND… 45 POINTS!!! MUHAHAHAAAHAAAAA!!!”

boat-rowers-whipped

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 3? Give it an 8!
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 8.”

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 8 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 – “…”

lando-calrissian-_-bargaining

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.“.

winston-wolf-solves-problems-2

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!)

rutger-hauer-ive-seen-things-you-people-wouldnt-believe

Scrum is a tool, and like any other tools 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 the Scrum I have seen so far is a by-the-book application of methodology rules, with no understanding the reasoning behind those rules.
So it’s like grabbing a fork and jabbing it in a person’s ass instead of using it to eat: the tool is there, but that’s not its intended use.
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!