Controlling my anger from insubordination?

First, take the mental health day and I suggest it be a Monday or Friday.  You need the chance to decompress. 

As for disrespect part.  I see two versions of disrespect.  One by/for your management staff and the other for Scrum practice.  All that you can realistically address is the Scrum part.  But you are going to have do to that up to management and down to the team. I suggest you pick your battles.  

I have informed management and they keep telling me to just coach them and remind them ...

If I were in your shoes, I would take this as a directive to be a real Scrum Master and not a Scrum Bastard (sorry but couldn't come up with a better way to describe it).  A Scrum Master will help the team to become self-organizing, self-directed.  If the team doesn't see the benefit of standing then why should they?  It isn't called a Daily Stand Up in Scrum. It is called a Daily Scrum and the team could sit naked in a hot tub if they still accomplish the goal of the event. If Management has a problem with it, work with management to allow the team to experiment with their choice and if there is a obvious reduction in productivity you, as a Scrum Master, will work the team to improve. 

Updating Jira.... Been there, done that, still in that place for some teams.  Again, don't force things.  Let the team discover how their actions are impacting them and the organization in total. Let them find out how by not updating for their individual work it is impacting the rest of the team in understanding what is being done and what isn't.  If they keep up the practice it will eventually start to cause problems and lead to the Product Owner constantly having to ask for "status". But given your description, this is one of the things that they will have to feel the pain on in order to decide to change their behavior. I would not stop suggesting that they update but in the end this bullet from the Scrum Guide section describing the Development Team says it best. 

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Above all else remember that Scrum Masters are servant-leaders.  You serve their improvement by example of how Scrum, Agile, Empiricism is beneficial.  But don't forget the "leader" part. Leading can involve a lot of stuff and at some points it means making a decision when the team cannot come to consensus.  But make it based on all the input you get from the Scrum Team first, always be transparent on how you arrived at the decision, and remind the team that they can change the decision based on their experiences in order to improve their efficiency. 

Being a good Scrum Master can often be frustrating, at least in my experience.  But you have to remember your charter from the Scrum Guide

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Find peace, stay calm and don't promote bloodshed or violence.  :-)

Have you considered that your team is correct and you should be coaching both the team and management about good habits and practices instead of enforcing things that really don't matter?

There is absolutely no need for people to be on video during Daily Scrums - some teams find it helpful, others don't, and if there is screensharing happening, it may be difficult to see people's faces anyway so it ends up not mattering. There is also absolutely no need for people to stand up - some teams find it helpful because it does help keep the meeting shorter and more focused, but other teams prefer to sit and some individuals have medical needs where they must sit.

Of the things that you mention, the only thing that I would encourage the team to do is to update Jira. It doesn't matter what tool you are using, the state of work should be updated prior to the Daily Scrum to the extent possible. The Daily Scrum is a time to inspect the current state of work and adapt plans, and to make this go more smoothly, the current state of work should be correct at the outset.

You shouldn't simply be re-iterating management's wishes. You should be working with and coaching both management (and the rest of the organization) as well as the teams to effectively deliver products and services that add value.

@Jon Joe, wanted to add something. If I remember right from some of your other recent posts, this is fairly new team.  New as together but not new to Scrum.  Any team, especially newly formed ones, will progress forward/backward through Tuckman's stages of group development.  It sounds like your current team is somewhere between forming and storming.  Read that article on Wikipedia (so you know it is true) and see if it helps you understand what is going on with the team.  You can find shorter explanations by searching the name but the Wikipedia article has a lot of good info in my opinion.

Again, good luck.  Don't Panic and Keep Calm.  Always know where your towel is.

@Daniel - RIP Douglas Adams!

--------------------------------------------------

Jon Joe, a significant trait that I had to acquire and develop in my transition from Project Manager to Scrum Master is patience.   You need to be consistent and measured in all your dealings with your team.   Resist the urge to "lay down the hammer", as this is reflective of Command & Control behavior that you need to divest yourself from.

It is hard, but you need to become comfortable with watching your team crash and burn.   Don't get emotional, but pick up on all of the items that are causing them pain, and provide as many suggestions as possible on how they can lessen the pain, without having it come across as "I told you this would happen".

Think of a Scrum Master as a personal trainer for a sports team.   Your job is to try and help them perform better, even if they turn a deaf ear to you.   You need to have trust that there will come a point in time when they will tire of losing, and will turn to you and ask "What was it you suggested we do differently?".

Also, you need to be a solid defender of Scrum to your management.   Don't act as a pass-thru for whatever they wish to impose upon your team.   One of the easiest ways to ingratiate yourself with your team is to come to their defense when they object to doing something because they were simply told to do it.   Reading your example, you were simply being a controlling voice of management, telling them that they needed to stand, and they needed to be on video.   You shouldn't be surprised that they're lumping you in negatively with the rest of their management.

I'll give you a personal example just from today about the behavior I'm talking about.   Parts of my organization still play the contract game, and don't want teams to work on initiatives unless time/cost have been pre-determined and signed off on.   I won't even get into what is anti-Agile and anti-Scrum here - I know!

Just today, a line manager expressed frustration that my team was working on items that were not "signed off" on.   To me, this is an issue that needs to be addressed with their PO.   The Development Team should not have to police the viability of work being offered based on the completion of a SOW.   The line manager then explicitly requested that my team add a criterion into their Definition of Ready (I know - not Scrum!) to verify that an SOW was completed before even considering such items.   Nevermind that this whole approach is reflective of BPUF (Big Planning Up Front) and anti-Agile.



So, I pushed back on this line manager, in the interest of protecting my team from having to deal with such a consideration around work offered by their PO.   The line manager insisted, at which time I let the discussion end, but with every intention of having a discussion with our PO about the issue, and making sure that my Development Team does NOTHING to conform to this request.   Risky?   Perhaps, but as a Scrum Master, this decision is clear.

One of the 5 Scrum values is Courage.   Sometimes you need to demonstrate that, even if it puts you at risk.

Hope all of this advice, from me and others, is helpful.  Good luck to you.

I am working with teams that are blatantly being insubordinate

Do you believe teams ought to be subordinate in Scrum, and if so to whom?

I would behave that way too by your descriptions of the situation. I probably would be looking for a new job. Where do you work so I know not to ever go there and look for a job?

There could be x problems:

1) Team has a misunderstanding of scrum

2) Management has a misunderstanding of scrum

3) You have a misunderstanding of your role or scrum

Depending on each of these you can try to attack the problem differently.

If you have a suspicion that the team has a misunderstanding of scrum you could do this in an retrospective or another meeting ?

Put the discussion in the Teams court and match it with the goals of Scrum. This may take some time to get through. 

1)  Lets define the minimal scrum process through the scrum.org or scrum allaince or other sources of authority. (take the minimal "why we do scrum ").

Write this on a whiteboard.

2)  Ask the Team what is the purpose of Scrum ? (no judging just write em down per team member)

3)  Ask the Team honestly how do you all think dayly scrum, review and retrospective (or the subject matter under discussion )  should be done and why we do this ?

Then honestly let the team and you review the result (could be more than one session not to branch of in a lot discussions and run into meeting tiredness).

I can’t imagine how frustrating that must be. In this situation, I believe a mental health day would greatly help you recalibrate your thoughts and be prepared to take on this challenge. Is it possible that your co-workers don’t have a full understanding of Scrum methodology? Perhaps after your mental health day, you and your coworkers or management could schedule a time to have an open dialogue on what each party believes the current problems are, and what each party’s goals are. At my company (https://www.digitalmaelstrom.net), internal issues are handled as quickly as possible so that work can efficiently continue. We’re rooting for you, Jon!

If I can chime in here? Just for some background: I'm a fairly new Scrum Master (Dutch native speaker, so please excuse my potentially wonky English :) ) with 1.5 years experience and currently studying for my PSM2 exam. So take my words with that in mind. But your story touched me.

Let me get straight to the TL;DR: our job is not to force development team members to do their work the way we would do it if we were them. Because we aren't them, they are them. We are just the guys making sure as little as possible gets in their way so they can work on the Product Backlog, and help them find ways to get better at it with time.

Now, sorry for getting long-winded in my first post here and I know that others have answered along the same lines, but I'd still like to share my thoughts about a few points in your post.

I have informed management and they keep telling me to just coach them and remind them... 

Are you aware: in many organisations, a scrum master would typically spend significant chunks of time and energy to convince their management to do exactly what yours is already doing :)

I sent out an email last week stating that all participants on daily scrums must (...)

I'm deliberately stopping the quote at "must". Our work is about convincing, not about commanding. Commanding works in clear hierarchical power structures - as Scrum Masters we should endeavor not to be in one.

and Jira remains un-updated...

Does this lead to problems, like a frustrated product owner and/or stakeholders? If so, what are the team's answers to those problems? And if not, then why should anyone consider it important? Not a rhetorical question. As noted before, it can increase transparency, sure, but is that transparency actually used or even usable for inspection and adaptation? If not, it may not be necessary, at least not now, and may not be a battle you want to pick at this point. Also remember the first value of Agile: value people and interactions over processes and tools. Try and challenge the urge for providing transparency in more stimulating and constructive ways. That would be very interesting starting points for new discussions on this forum!

literally not doing anything (...) I'm starting to get pissed (...) yell at my teams (...) mental health day

If I can make a suggestion: please take that day if you can. Take it and try to focus on your inspection and adaptation. Scrum masters often forget they don't just need to facilitate their teams' growth through transparency, inspection and adaptation, but their own as well. As a scrum master you do *not* have to carry the world on your shoulders. But you do have a very particular set of responsibilities. If you need help with that, maybe ask your management to help with an experienced scrum master or Agile coach to be your sparring partner for a few hours per sprint for a while... It may take your edge off and free up your team a bit, and help you discover new ways to approach things. No shame in asking for help to do your job, IMHO probably better than asking management to force things because you can't get through.

does anyone else experience this kind of blatant disrespect?

In all honesty, you may have some work ahead of you to earn more of your teams' respect. Leave the demanding of respect up front to gangsta rappers :)

I wish you all the best and greetings from Amsterdam. Where spring has started, by the way. We took a good long team walk 'round the park yesterday. Can do wonders!



Wow, that was long. Sorry for that. Hope it helps anyone :)

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.

In fairness, let me say that the replies to OP are pretty sensible and mature. That said, the position taken by OP and their management ... simple not compatible with Scrum or Agile ideals.

Hi @RonJeffries,

Please note that this was a Forum Post from 2019 of someone coming to Scrum.org and the greater Scrum community for help and guidance.  As you note, the guidance was "pretty sensible and mature".  The forum responses provided Jonathan with the guidance that he was looking for and support he needed within his team and organization.

Maybe the OP could gather stats on sitting/standing and video on/off.

Targets for these could be added to the sprint goals that the team commit to. They could reviewed at the demo ceremony with the team. Make it fun for the team to beat their numbers.

So, I had no idea this got resurrected or even that it would attract such attention... When I was using this forum heavily back in 2019, I was still very new to being a scrum master and still had to learn the hard way many of the values and principles that are not understood after just a 2 day course and an open book exam. 



Since then, I've learned very much the silliness of trying to control a teams actions, specifically in this case making them get on camera and stand etc. Which is actually an OSHA violation I was informed later.



These days I'm not dogmatically trying to impose my will on teams. If they don't want to stand or don't want to get on camera I am not worried about it. 



I do however have to express that the environment I was in was one where I was being pressured to provide specific results and I was too inexperienced to realize that what was being asked for wasn't helpful, and that the teams resistance and leaderships controlling behavior was a symptom of a much greater issue.

I did ultimately maneuver with that company to a better mode of working, got more training, learned more with hands on experience of course, and now I almost kind of know something about the world of Scrum, unfortunately the certification says Master on it, I am no master imo.

Sorry @Ron Jeffries Certainly wasn't the kind of first impression I'd like to leave, I assure you the guy who made this post has definitely learned from this for the better. :)