Dealing with a scrum master who undermines the development team

Question

I'm hoping for some help in dealing with a scrum master who is directly going against the wishes of the development team.

The scrum master in question has an approach which puts completion of sprint stories above essentially everything else.

Generally, a developer (person A) might hit a bit of a road block and request assistance from a member (person B) of another, more experienced team. It should be noted that the latter team is a remote team working in a timezone 5 hours behind, so delays are expected, and sometimes issues can take a day or two to be resolved regardless.

What has started to happen is that even if the developer states that they're in control of the situation, the scrum master will email B, or sometimes email B's manager, stating that A is blocked and needs immediate assistance.

The development team brought this up at the last sprint retrospective, and the scrum master reluctantly agreed to stop unless assistance was directly requested by a developer.

The developers' concerns were that the scrum master was driving a wedge between the two teams and that his emails would lead to animosity between the teams, as it could be interpreted that the developer sanctioned the email.

Although agreeing to stop, the scrum master has continued to send these emails.

How could this be dealt with in a professional way, with the goal of making this stop for good?

Answer 1

One of the goals of a Scrum Master is to remove impediments that exist between teams. Your Scrum Master probably sees this "blocker" as an impediment, and then does their best to remove it by claiming a need for "immediate assistance".

Understanding that the Scrum Master is doing this as a perceived part of their role is key in solving the issue. So, don't make it part of their role.

Instead, schedule your friendly chats in the calendaring system. Then there's nothing blocked, just items planned. Be sure to tell the scrum master that progress is being made, and that the cross-team resources you require are available, scheduled at (whatever time) and that's sufficiently early enough to meet the deadlines.

If you remove the impediment, there's nothing to act upon. If the problem is solved before your Scrum Master attempts to solve it, then you can manage the cross-team relationships AND fall back upon your Scrum Master when self-management isn't an option.

Answer 2

Raise it again at a scrum meeting. Point out his failures and that he is poisoning the team atmosphere. Hit him - hard. A scrum master should not do that. SPrint story completion is not the goal in itself. If stories are delayed, analysis is important. His beahvrios is likely to lead to a lot of bad behavior, down into reporting false completes.

Answer 3

Chances are, the Scrum Master thinks they are helping. I'm curious what happens next in your situations. What does Person B respond with? What does Person B's manager respond with. Why does the Scrum Master feel that they need to take this action? Is there an SLA on person B's response or do they provide an checkin time that they expect to have more information for you?

From my experience, Scrum Masters act this way in one of three circumstances:

1. They think that them following up will get a faster turn-around than you following up.
2. They think that the team member will let it go and it will be forgotten
3. They are under personal pressure to deliver the work (perceived or real) and they may not think it'll make a difference, but they are taking action for the sake of relieving the impulse to do something.

Finding out if it is one of these three could inform your next steps. If it's the third, that might be a problem elsewhere - the Scrum Master is not personally responsible for the delivery of work like a PM is. If it's the first or third, you can try to set up a safe-to-fail experiment to find out if they are right (or show them that their actions aren't contributing).

Answer 4

You already told the scrum master that his behaviour is inappropriate in your opinion, they even agreed and said they would stop it, and still it is going on.

Obviously tell your scrum master again, very strongly this time, and if you find out it happens again, email B an B’s manager that the request was not urgent, that your scrum master sent this on his own, and that B’s response to your request was perfectly fine.