Hey Reader,

In the past couple of weeks, I was presented with a few interesting points about Scrum from the Scrum-hating community. So I decided to address a few because most of them are so irrelevant. And I hope that this can help you be more confident when talking with people about Scrum.

I think the most popular phrase I've been seeing a lot is "Scrum is cancer". This is extremely disrespectful to people who lived or are living through cancer. Firstly, you can simply walk away from Scrum if you don't want to work in the company that is implementing it. Secondly, the purpose of Scrum is to make the lives of people working in this environment better. So, honestly, I don't even know what to say to that statement...

I got into a debate with someone in the comments on one of my videos. And I asked them to give me an argument against Scrum so that I can either address it (debunk it), or agree to the fact that this is indeed a downside of Scrum.

The argument that they brought up was about story points. And we all know that story points are not Scrum.

And then there was this post on Twitter that an ex-colleague shared with me. I'd like to break it down into multiple screenshots to address all of the points in detail.

​

"Scrum is cancer" - a great way to start your argument 🤦‍♀️

Number 1. I guess that was supposed to sound clever. Moving on...

Number 2. Based just on this I can see that OP didn't learn anything about Scrum. I'm sure that if I misname a tech term, devs would easily call me an idiot. But somehow in this one paragraph, OP managed to misname most Scrum terms and added non-Scrum ones in the pile as well. "Ceremonies", "stand-ups", "groomings", and "Scrum of Scrums" are not Scrum. Plus, "grooming" is not even supposed to be a meeting originally.

On the point of "We spent more time talking than doing" - when we work in a complex environment, we MUST spend enough time talking (i.e. planning) before we start the work, otherwise, we'll be just doing something and not advancing toward our goals. That sounds like a bigger waste of time.

Number 3. What does any of these have to do with Scrum exactly? Absolutely nothing. Moving on...

​

Number 4. Yes, your primary responsibility is writing software. But planning, estimating, refining, collaborating, teaching, learning, etc. are also part of your job.

From the point about "deciding on how many story points fit in a sprint", I felt confused. Story points (if we used them) help us get some historical data on how much work (approximately) we are able to accomplish within a Sprint, so it's easier to plan. You don't need to decide anything. Just use the data you've collected to help you make this decision. And it's not like you are held accountable for delivering a specific number of points. It's just a planning tool.

Number 5. I guess that was supposed to be another clever one. Maybe we should talk about "master" and "slave" in software.....

Number 6. That sounds like the dumbest thing I've seen. Also has nothing to do with Scrum.

Number 7. Another one that has nothing to do with Scrum. So your management wasn't well educated on how to use story points. Neither was the team it seems. It could all be solved with a couple of workshops.

​

Number 8. A Scrum Master and a Product Owner have no authority over you, they are your teammates. Why didn't you also list your team members, the developers, QAs then? I would also assume that your Tech Lead and Manager should be the same person. Basically, it was an org chart problem.

Number 9. Again about story points. There is no ... point ... in talking about this one again since we've already established that it has nothing to do with Scrum and the company was not well educated on how to use this Agile practice anyway.

​

I think what I also was interested in was reading through the comments. And I found this small exchange insightful:

​

Here's why I found it insightful.

In OP's response we can see one thing: it seemed that they wanted someone else to come and fix things for them. We can see this through the language like: "We hired Scrum trainers", "We offered money... to teach us the right way."

And what I can read between the lines is: we didn't want to do anything ourselves, we just hoped others would do it for us.

Because I didn't see anything about that team (or the author) taking a step forward to learn about what Scrum is and isn't, what practices can be useful, and which ones should be put aside.

So all I saw in this post was admittance of ignorance.

If you decide to talk about something with some much spite, you should make sure you actually understand the topic. Or just say - hey, it's my opinion based on some anecdotal evidence and minor experience.

Anyway, I think that's everything I wanted to share today.

I hope you found some insights you can use. Or maybe, it was just an interesting read - that's cool too.