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.
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…
I think everyone has the sense that the ScrumMaster role is all about:
The team, the team, and the team
and that they spend all of their time working in groups, with…the team. Most of their effort is facilitating meetings, resolving impediments, and generally serving the well being of their team(s).
And all of that is true.
But I think there is a much more subtle persona to great ScrumMaster’s and it doesn’t directly involve the team or group. It’s actually one of the hidden aspects of Scrum Mastery and I want to explore it in this article.
What are you talking about you might be thinking?
I subscribe to Mike Cohn’s newsletter. As you would expect the value is always high and his posts usually make me think a bit about my own coaching experience and ongoing advice.
In a recent newsletter Mike adopted a position on a manager serving as a ScrumMaster that goes contrary to my experience. Here’s what he had to say:
When I first started doing Scrum, I was what we'd call today the team's ScrumMaster and product owner. But we didn't have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both.
I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.
I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP -- but I should not have been both at the same time to the same team.
I was watching an NHL game the other evening. The team was playing a hockey game without a goalie.
Apparently the team had decided that their goalie was too expensive. So they traded him away to another team.
Then the backup goalie was sick. And his equipment didn’t fit anyone on the team, so they decided to “go without”.
In a pre-game interview with the General Manager, he said that it was strictly a financial decision. They felt that the team could fill in the goalie role by sharing it amongst themselves.
If it worked out as he expected, then they might consider this change as a permanent part of their hockey team structure.
At the very end of the interview, he wondered –
What does a Goalie do anyway? For 90% of the game they’re idle. What a waste of money. Why not get the team to “pitch in” and fill that role? It just makes good sense…
There’s a trend in the agile community of influencing folks away from saying no, instead saying: “Yes, And…” as a means of connecting various conflicting points together. I wanted to use the same mechanism for the title of this article, because I think we need to start looking at the basic Scrum certifications in a different way, perhaps the same way we view Peanut Butter AND Jelly. Let me try and explain.
I’ve seen an incredibly alarming trend over the last 1-2-3+ years in my coaching. It involves whoever is teaching Certified ScrumMaster classes; whether they be from the Scrum Alliance, Scrum.org, or elsewhere.
I encounter quite a few organizations and many teams in my travels. Almost universally they are adopting Scrum and have a few to many CSM’s around to guide the transition.
But I’m finding that the “Scrum” that is being fostered and guided in these organizations leaves a lot to be desired. Often:
