“Scrum Is A Cancer. Stop Doing Scrum!” — Thoughts On A Post I Read
Are entering a post-Scrum era?
Do we hate on Scrum now? Can it be that we are entering a post-Scrum era?
I stumbled upon Maarten Dalmijn’s skeptical view on Scrum in his article “Scrum: Failure By Design?”, stating that it “might be flawed by design”.
Then there is also David Pereira’s article “Sorry Scrum, the Game Might Be Over for You!”
Yesterday a friend shared a post with me. He was interested in my thoughts about it.
It was a post starting with “Scrum is a cancer” by Santiago @svpino. It was accompanied by this black and white image, screaming “Stop Doing Scrum”.
You can find it on the social media X that used to be Twitter but now you can post there with a XXXX number of characters — depriving the medium of a character.
Was I this bored?
Today you will find my commentary on Santiago’s rant about Scrum.
People love to dance on Agile’s grave or declare Scrum dead just for the clicks. Santiago added a touch of charm and humor, so let’s Agile McCoach this.
Scrum doesn’t exist
First of all, there is no such thing as Scrum implementation. Scrum only exists as a concept in the Scrum Guide and the heads of Ken Schwaber and Jeff Sutherland. Any “Scrum” you see is like a remix of Maria’s Events with Joan’s Artifacts all mixed into a Karen’s Consulting playlist. It’s their take on Scrum, not Scrum’s fault. Just like many blame SAFe for the boss’ love of command and control. Judge away yourself!
Let me tell you an anecdote…
Santiago has nine of them! Nine humorous anecdotes expressing him killing Scrum softly.
#1 They tried to convince me that Poker is a planning tool, not a game.
I mean, poker faces for story estimations? Hilarious!
Yeah, there is a planning poker invention out there however it has nothing to do with Scrum. It has to do with story points that are described in XP and then with someone who invented the planning poker game.
Isn’t it funny that the first Scrum tale isn’t even about Scrum? It’s like complaining about the cooking recipe by saying the scale in your kitchen doesn’t work.
#2. If you want to be more efficient, you must add process, not remove it. They had us attending the “ceremonies,” a fancy name for a buttload of meetings: stand-ups, groomings, planning, retrospectives, and Scrum of Scrums. We spent more time talking than doing.
In the wild world of all-remote setups, some of these Scrum events (Seriously, ceremonies? Who says that? Are we summoning spirits? ) are about as effective as using a banana as a phone.
I would even dare say the daily scrum can become a waste when you have many people working in different time zones. It might get in the way of someone’s focus time.
But wait for it — here’s the fix: Imagine a standup channel where everyone writes a daily recap before they clock out. Genius, isn’t it?
Grooming, or should I say “refinement,” is the grown-up stuff. It’s making sure you know why the heck you’re building that user story. And as for Scrum of Scrums, it’s not some cult ritual — it’s just what happens when you scale your Scrum. Again, let’s understand the menu before we complain about the food!
#3 We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
This is funny and I agree, might seem a bit infantile. Grown-up people needing a ball to pay attention? I mean, what’s next, using building blocks for brainstorming? And let’s not forget the impeccable attention spans in meetings, shall we? Flawless, every time.
Now, laptops are banned from meetings. In a world gone virtual, are we going to conduct business via smoke signals? Are we complaining here about the world before 2020 when people wore jeans as opposed to pajama pants to meetings?
#4 We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.
Oh, not again! The lecture on story points in Scrum is back. Where do I start? Maybe again that story points are not part of Scrum?
And yeah, I also prefer the #noestimation way and just count the number of items. But how do you know that the team has arrived at a shared understanding of what needs to be done in a given user story. If you vote 13 and your colleague 3 — Houston, we have a problem.
Many of those practices and tools were developed to facilitate teamwork. Teamwork is king or if you prefer, two heads are better than one! That’s the real deal behind this. Besides, how else can you know how many items can be done in a given period of time?
#5 I had to use t-shirt sizes to estimate software.
Well, I had to use water glasses to measure flour for the pancakes.
#6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of “500 story points.”
This is my personal favorite. Shows how incompetent the management or whoever decided on this one was. Like wow! It’s like selling packages of “500 story points.”
Reminds me of the scene in Dumb and Dumber where Loyd explains the suitcase where instead of money he filled it with their IOUs “That’s as good as money, sir!”
But wait, did we finish talking about Scrum and start complaining about the wrongful usage of story points in consulting companies?
#7 Management lost it when they found that 500 story points in one project weren’t the same as 500 story points on another project. We had many meetings to fix this.
No way! But hey did you fix that? I would love to see how one does fix that!
#8 Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer all of them and none simultaneously.
Oh I hate that one myself. Who is the “real” manager? I bet they were trying to figure out that one on their own by competing for power. Very typical of Scrum!
Scrum accountabilities are raging for power, especially given that:
“Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”
The Scrum Guide, 2020
#9 We paid people who told us whether we were “burning down points” fast enough. Weren’t story points about complexity instead of time? Never mind.
Is this proof enough that the story points can lead to severe trauma? If it wasn’t so, I believe we could summarize the whole complaint in three points instead of stretching it to nine just to repetitively complain about the evil story points.
“I believe in Agile, but this ain’t agile.”
I couldn’t agree more. This guy had the bad luck of stumbling upon the most incomprehensive processes that I won’t even dare to call agile, not to mention scrum.
“We brought professional Scrum trainers. We paid people from our team to get certified. We tried Scrum this way and that other way. We spent years doing it.
The result was always the same: It didn’t work.”
Now that explains the trauma. The guy spent years working in that peculiar way, who wouldn’t get story-point-traumatized after all these years?
“Scrum is a cancer that will eat your development team. Scrum is not for developers; it’s another tool for managers to feel they are in control.”
So it’s a cancer that produces the trauma. Makes sense.
But the best about Scrum are those who look you in the eye and tell you: “If it doesn’t work for you, you are doing it wrong. Scrum is anything that works for your team.”
Sure it is.
Well, it’s like running around after a ball in a chaotic manner and complaining you don’t see any body-building effects. Are you sure it was meant to help with your muscles? Sounds more like random cardio! And oh, then we complain there goes my motivation. So I better sit on the sofa and eat my chocolate bar because what I call “playing football” doesn’t work.
Don’t get me wrong. I understand Santiago’s frustration. His experience is shared by many. You can find people traumatized by the processes all over the world and in many companies that boast of being agile!
What I imagine happened where he worked for so many years (one would ask, why stay so long if you hated it so much?). It sounds like a company where it seems like the higher-ups dipped their toes into the agile ocean but never really took the plunge.
It’s like they heard the term “Scrum” and thought, “Why not give it a spin?” One person caught wind of it at a water cooler chat, another skimmed an article while waiting for a latte, and the third nodded along to a YouTube video like it was a catchy tune. And voilà, welcome to Scrum 101 — where reading the actual Scrum Guide was about as likely as finding a unicorn in the break room.
Oh and a friend of the first one told them about the story points. Sounds like a cool idea. “Let’s gamify the work with story points!” Classic!
What I would expect though, would be that Santiago himself read the Scrum Guide. Did you know it’s far shorter than Shape Up? Or could it be that he hasn’t read that one either?
Instead what we see here is like blaming the language for a bad teacher. The teacher is too strict, serious and overloads the class with complicated grammar as opposed to focusing on conversational skills. It’s the same with the frameworks, you can overload the developers with bureaucracy or simply help them to communicate and collaborate.
I would love to hear your thoughts about the post-Scrum era. Let’s start a conversation below this post!
