Scrum Bastard

Today I learned a new term. Maybe better/worse than ‘Dark Scrum’. (TL;DR: If it isn’t joyful, we’re doing it wrong.)

Someone posted a screed on Scrum.org’s forum. I suspect the article may not remain long.

The screed goes like this:

Controlling my anger from insubordination

I am working with teams that are blatantly being insubordinate. I have informed management and they keep telling me to just coach them and remind them… I sent out an email last week stating that all participants on daily scrums must be on video if they are remote, and must be standing (I know that’s not viewed well here but my management considers it mandatory atm). I start each call by reminding the team of the importance of keeping Jira updated, using comments to communicate instead of just emails, and that Video / Standing is required. Then I literally watch the entire team sit and only half the people get on video, and Jira remains un-updated…

I’ve escalated several times to management but they’re just literally not doing anything, and I’m starting to get pissed, I want to practically yell at my teams and that is so outside of a scrum masters nature. I’m somewhat of a hot tempered person to begin with but have taken many classes on psychology and working with people, but at a certain point I just want to drop the hammer so to speak…

I’ve even asked individual members to help me out by leading by example and they just cave to peer pressure… I ask the team why they don’t want to stand and they just say it’s silly and why is it important, I of course re-iterate that it’s what management is expecting and they just ignore it and move on…

I am to the point of needing a mental health day to avoid having an outburst, does anyone else experience this kind of blatant disrespect?

I replied in line:

This is the most outrageous public intentional example of Dark Scrum that I have ever seen.

The very notion of “insubordination” is counter to Scrum principles and Agile principles.

The notion that the ScrumMaster (thanks above for term ScrumBastard) can give any orders is directly opposed to the notion of ScrumMaster as a servant leader.

The idea that management gets to say whether people stand up or sit down is ludicrous.

Jira is a terrible tool for team communication. Either Slack or email are far better. If the SM wants Jira updated, they should do it themselves. 

This is horrible and ridiculous all at the same time.

If this is the kind of understanding of Scrum that Scrum.org people have, it’s no wonder that Dark Scrum is endemic.

I am advised by a Tweep that the SM in question is new. That’s as may be, but as far as I can see, I’ve spoken to the practice and ideas, not about the individual, so my remarks stand.

The replies on the forum are all pretty mature. Perhaps cooler heads will talk OP down to a better understanding of Scrum and their job.

What we see here, experienced or not, is a near perfect example of Scrum / Agile going wrong. I am near livid at the use of the term “insubordination” in any situation, but in a would-be Scrum / Agile situation it is so wrong as to be perilously close to evil. (I could do a pretty good argument that it’s always evil, but I will save that for another day.¹)

Why I Do What I Do

It’s ideas like the topic idea here, which is a really stellar example, that lead me to do what I do in recent days and years.

I have urged developers to Abandon “Agile” in favor of learning how to produce an incremental, growing, always working increment of product software, producing same, and centering the real working software in every conversation with management.

I write innumerable articles, using various toy products, to show how I work to produce a live increment, so that people can learn from my mistakes and perhaps even from the occasional good thing that I manage to do.

I’m working to find small ideas and practices that are hard to water down, and that can be adopted quickly without too much effort (Strawberries), so that individuals and teams can improve incrementally, without spending more money or time than they have available.

It comes down to this, at least for me: writing valuable software well is fun. It is joyful. It usually also pays well, but the real payoff is in the joy of exercising one’s growing skills together with a team of other people finding the same joy in their joint enterprise.

If it isn’t joyful, we’re doing it wrong. Let’s continue to find ways to make it joyful, and keep it that way.