I’ve been teaching and coaching Scrum for nearly 20 years. During that time, I’ve always tried to stay true to the basic Scrum guidance and the Scrum Guide. But I’ve also shared my own practical experience.
One of the things that I’ve been consistent about in my guidance is that the ScrumMaster is NOT a manager or HR role. That is, they should not be “mucking around” with personnel performance issues. At least not directly.
For example, they should not be writing/executing Performance Improvement Plans (PIPs) or removing folks from teams or firing folks.
So, you can imagine my shock & chagrin when I saw an article by Barry Overeem that seemed to be saying the opposite. Now I’ve followed Barry for many years and I normally align with his recommendations. Or at least I see the soundness in his perspective. And often he simply makes me think about things in new ways. Which I appreciate.
But in this case, I think this is a very dangerous point of view and flat out wrong. So, let me share my thoughts…
Introduction
A colleague of mine in Dallas, Jack Schwartz, sent me an email asking the following:
Bob,
I’m working on a presentation focused towards Hiring a ScrumMaster and I wonder if you could provide some insights to the following questions:
- What are the top skills you like to see in a good Scrum Master?
- How can a hiring manager tell if a prospect is truly an agilest and not just using scrum words with ‘legacy’ project management? (other than clairvoyance)
Thanks,
Jack.
Well, Jack here is my initial stab at a response…
What are the top skills you like to see in a good ScrumMaster?
Well, first I’d like to say what I’m not looking for:
- I’m not looking for someone who is strong in a functional area within the team. For example, if I’m staffing for a ScrumMaster in a team with a weak or non-existent Development Team Lead in it, I’m not looking for the SM to fill that role. Or an equivalent, PO, UX, BA, Testing, or any other role. If I have a skills gap or weakness in a team, I need to fill that with someone with those skills.
Tanner Wortham is a ScrumMaster and coach who I’ve quoted on this blog before. He recently wrote a blog post entitled: When Can a ScrumMaster Say No which I read with interest.
I’ve been sharing of late around the notion of more prescriptive coaching stances and, at least in my mind, this seeps into the role of ScrumMaster. So I wanted to hear what Tanner had to say.
Here’s a snippet from the article:
[…] Doing away with the sprint review simply ignores the problem. Help the team experiment with new ways to conduct the review but that align with the intent. Over time, they will find their solution. At no point did we have to say no. In fact, we should avoid it. I believe our responsibility is to understand and to guide. Rarely is it to deny.
Even so, I occasionally encountered two situations where I’ll say no as a Scrum Master:
In my classes I often liken an aspect of the ScrumMaster role to that of a sheepdog. That an important part of their role is protecting the team. Often the direction of this protection is assumed to be outward, for example, insulating the team from external interruptions.
In a recent newsletter (sent on September 22), Mike Cohn discussed this part of the role in more detail. He spoke to two areas of protection:
- From Management Dysfunction (external), and
- From Team Complacency (internal)
The thing that struck me in Mike’s post is the internal protection perspective, ie., protecting the team from “themselves”. It made me think about areas where a ScrumMaster can really help their teams in this area.
Let’s explore some specifics…
