Agile Examples – Scrum Masters

This is an excerpt from the textbook that I am writing with a co-author on Agile.  Here are examples of a strong and weak Scrum Master. (Names are made-up so don’t think you know them  🙂

Would love to hear your thoughts and comments.

Scrum Master

Let’s look at examples of good and bad Scrum Masters.  Everyone has their strengths and sometimes the role of being a Scrum Master is not assigned to the best person and other times, it is a natural fit.ScrumMaster

Consider Steve.  He was brought in from another team to be the Scrum Master of a team that was really struggling.  Steve started by getting to know all of the developers on his team. He met with each person individually to learn what their impressions of the problems were.  Then Steve began actively advocating for the team. When decisions were not being made in a timely fashion, Steve escalated the issue so his team could get the answers they needed to write the best code.  When the team had a disagreement, Steve jumped right in and facilitated a healthy but heated discussion about how to best solve the problem.  And when required to make decisions, Steve gathered the best information available at the time, consulted with people internal and external to the team to check his facts and then he chose a path, informed all parties and stood behind his decision when it was questioned.  His leadership allowed the team to focus on the code that they were designing, writing and testing so that they could make their commitments and feel a real sense of accomplishment.  Steve is a great Scrum Master.

Steve’s team sits very near Ray’s team who is not sharing in their success.  Ray is the Scrum Master and he has a rather timid personality.  When conflicts on Ray’s team arise, he watches nervously and encourages everyone to be nice but he doesn’t help them resolve it.  He acts more like a disengaged referee.  On Ray’s team, he has two very strong, dominant personalities and two very introverted and quiet people.  Ray doesn’t like confrontation so when the two strong personalities dominate the conversation, Ray allows it to happen.  Therefore, the weaker, more timid people don’t say anything and just go along because they don’t want to rock the boat.  This is very unfortunate, because the two quiet developers are quite knowledgeable about the system and they have noticed flaws in the design of the code but the strong personalities don’t seem to understand or care about the risks in the way that they are proceeding so the quiet people just sit back and hope that their in-depth understanding is somehow wrong and the path they are on will work out fine, despite their gut feeling that the design is flawed.  Because Ray allows this dominance on the team, he is part of the problem instead of being part of the solution.  For a Scrum Master, avoiding confrontation is not healthy or helpful.   Confrontation does not have to be negative, it can be respectful and it can often lead to the best deliverable.  Ray is not an effective Scrum Master and he is jeopardizing the success of his team.

Want to read more?  We have examples for Product Owners and Teams too.

 

Leave a Reply

Your email address will not be published. Required fields are marked *