HELP!!! The Scrum Master IS the Impediment!

At the heart of the scrum master role is servant leadership. We are driven by serving our teams as teachers, mentors, and coaches. It’s our job to help the team remove impediments, not to become one.

Brandon Glasley | Facepalm |

Brandon Glasley | Facepalm |

As a newly minted Professional Scrum Master (PSM I), I returned to my team excited and ready to get underway. Unfortunately, I brought back a purist view of scrum and had not fully grasped the concept of servant leadership. In other words, I failed miserably.

The problem started in the daily scrum’s. I took a heavy handed approach and ran the meeting how *I* saw fit. I asked the questions of each scrum team member and asked follow-ups where I felt *I* needed more information.

During a sprint planning meeting, I pressed the team to use the AS AI WANTIN ORDER TO format for user stories. The team came up with their own format that they felt more comfortable with. And still I pressed on.

Why I felt the authority to do so is beyond me. User story formats are not prescribed by scrum. A development team member approached me and very respectfully disagreed with me in many of these areas. Tension grew between us.

After a particularly stressful daily scrum, he stormed out and I was left with a team of amazed developers staring back at me…disappointed. And they were fully justified.

I tracked down the developer that stormed out and after a tense, but respectful meeting I finally started to see the errors of my ways.

Scrum – A Pocket Guide tell us that “The scrum master has no interest in scope, budget, delivery, or tasks but coaches and facilitates the complete ecosystem in scrum to manage them.”

I was still being a project manager. That was no longer my role.

I apologized to the team and they showed me a lot of grace by giving me another chance. We went on to deliver some amazing sprints and managed to bring some real value to bear for the business. But why did the conflict happen?

I struggled with giving up the command and control mentality.

Scrum masters who transition from a traditional project manager role must initially cope with the fact that they are not in control of the team. Scrum masters have no direct authority. We are a servant to our team. Our role calls us to help the team get better at playing the game of scrum.

As coaches, we must be careful to not turn adopting scrum in to people being coerced to follow new practices. People can typically handle change given enough support, but they are universally defensive in the face of coercion.

The developer – who rightly challenged the way I was behaving – embodied the scrum values of respect, commitment, focus, openness, and courage. He had the courage to speak up, the commitment to the team to want to do things better, the openness to air a grievance, the respect to keep things civil, and the desire to focus the team on valuable work.

If you find yourself on a team where the scrum master has become an impediment you have a number of choices:

  1. Do Nothing: Allowing the behavior of an errant scrum master to continue undermines the scrum adoption and disrespects the entire scrum team. This option isn’t really an option.
  2. Address the Issue Privately:  The advantage of this approach is that you give the scrum master the opportunity to realize their mistake without an audience. I appreciated this approach when I had lost my way. If it’s difficult for you to address the issue 1:1 then the next venue is the sprint retrospective meeting.
  3. Address the Issue During the Sprint Retrospective: If the 1:1 approach did not work, the team can bring up the behavior of the scrum master as an impediment during the sprint retrospective meeting. When the team discusses what did not go well or what made them mad/sad the scrum master should be brought up. Done respectfully, this conversation could lead to a positive outcome.
  4. Self-Organize/Self-Manage: The scrum team is a self-organizing/self-managing entity. If the scrum master is not getting the message after multiple attempts, the scrum team does have the right to select a new scrum master. It would be an unfortunate turn of events, but in some cases this drastic step is necessary.

I’m thankful for the developer who challenged me to be a better scrum master. He made me confront my fear of giving up control and helped me become the servant leader that I needed to become for the scrum team to be successful.

Question: Have you ever been on a scrum team where the scrum master was an impediment to the team? How did you handle it personally? How did you handle it as a team? You can leave a comment by clicking here.

Please note: I reserve the right to delete comments that are offensive or off-topic.

  • Pingback: Five Blogs – 18 January 2016 | 5blogs()

  • Pingback: Agile Indy 2015 Notes | Agile Answer Man()

  • Pingback: Scrum Master Heroics Can Hurt Agile Teams | Agile Answer Man()

  • Pingback: The Transition from Project Manager to Scrum Master is Hard | Agile Answer Man | Scrum Lean Kanban | by Ryan Ripley()

  • Pingback: Scrum Master is a Title, Servant Leadership is a Mindset | Agile Answer Man | Scrum Lean Kanban | by Ryan Ripley()

  • Дарко Максимовић

    I wonder if all the details from this story were true. I do believe the whole story was indeed like this, but were all the details too? For example, I assume the SM did feel wounded by the developer and tried to undermine his position with the management. These “subtle things” are important, because courage is one thing, and “crazy courage” is something most people will not do, because it may make the business process better, but will hurt the “hero”. I assume the SM author would not admit this in order to achieve romance in the article. Another example, did the developer really always approach the SM “respectfully”? If he was unsatisfied, non-understood, eventually “stormed out”, what was his “respect” like? Like fear? Or maybe the whole respect thing is only something the article author wanted but didn’t get, and in this article they want to say “in order to have the scenario I described, it would’ve helped if the dev was respectful”? Most probably he didn’t, because that’s the way people behave when they are not happy. Still, the product manager soul in this author’s scrum master’s body demands respect. The one thing I truly believe in this story is that the SM eventually got enlightened, and that’s most important, but why still count the bulletpoints, like “1) 2) respect 3) focus 4) etc.”, the formalist seems to have remained. I am very OPEN in this comment – can the author now answer: was I also respectful? Or did I have to conceal my dissatisfaction in order to achieve understanding?

    • Hi Darko,
      Thanks for the questions and comments. The story I told in the post is a true one. I am the SM in question and had to learn the hard way about becoming a servant leader.
      I did feel wounded by the developer, but I did not try to undermine his position with his manager. For all of the faults in the story, we did manage to handle this problem as a team…eventually.

      The developer was respectful. Just because there is conflict does not mean that people have to be uncivil. Constructive conflict can lead to good things – as this story demonstrates. I wasn’t after respect. I was looking for authority through my position which was wrong minded.

      I’m not sure if I’m a formalist, I’ve certainly been called worse. 🙂 I listed the scrum values to show how they can be used as guidelines for actions on a scrum team. Keeping them in mind can help scrum team members “do the right thing”.

      Darko, I think your comment is fine. I’m grateful for your feedback. I’m sorry to read that you were dissatisfied with the post. I hope that a future effort hits the mark for you.
      If there is a topic that you would like to see covered, I’d love to hear from you:

      Best wishes,
      –Ryan Ripley

      • Дарко Максимовић

        I would like you to cover the servant part of the SM role. Most SM’s feel good about being a “master”, want to educate team members, advise, organize meetings and enforce “best practices”, thinking the “servant” role is contained in that, with a very vague understanding of their “servant” role, taking it more as another compliment to them selves, as in “I am so cool, I lead and organize, I am the man, – and I am also modest”. When it comes to taking care of e.g. missing permissions to a resource, the SM then reminds that the team should be able to take care of it alone, and starts advising again. The developers are thirsty, but they don’t have time to cook some coffee, of course the SM is not going to bring them some. After all, the team should be able to do it by them selves. If they aren’t, the SM will advise to take that into next planning. When team members want a different practice, just like you explained, the SM doesn’t find a way to implement that, they still “know best” and “won’t allow the team to hurt best practices” – after all they’re responsible for the team. But where in practice does the SM meat their servant role, can you give some concrete examples? How do you SERVE your teams, as opposed to LEAD? Do you buy bus tickets for the team so that on Wednesday they can go to the beach?

        • Thanks Darko for the topic. I will cover servant leadership with concrete examples in my next post.

          Thanks again,
          –Ryan Ripley

  • Pingback: Kindness is the Missing Agile Value()