Sorry for another rant, but I am getting annoyed at what the ScrumMaster role has been watered down to all too often. I want to see the mastery put back into the role as its name suggests.
The title ScrumMaster is indicative of what the role should be: a person that has a mastery of the Scrum framework. Which I translate into a deep understanding of Scrum and how to implement and apply it. The word “master” indicates a master of one's craft and not a master of other people. Given that this is the intention of the role and the responsibilities associated with it, here are the predominant smells and anti-patterns that I am seeing applied to this role and finally what I would like to see more of in the role.
This is the most common anti-pattern I've seen, where the SM becomes a team administrator. I think it comes mostly from companies that are still thinking waterfall and waterfall Project Management.
The Event Scheduler
Yes, scheduling events is part of the role, but just having the event doesn't mean you are doing Scrum. You need to be getting value out each event, too. And that requires mastery, which the ScrumMaster can demonstrate by ensuring that the goals of the scheduled event are met and that participants did, in fact, get value from it. For example, the goal of the sprint review meetings is to inspect and adapt. If you are having a demo and retrospective meeting each boundary, is there any adaptation going on or are you just checking the scrum check box to say that the meeting happened?
The Tool Administrator
"Wow, this tool will make us Agile! If we do everything the tool is capable of and keep it up to date, we will be Agile!" The SM who misinterprets this as their sole role updates the tool each day with hours burned. Yes, keeping track of the Sprint progress is part of Scrum but nowhere does it say that it is the job of the ScrumMaster. Ongoing maintenance does not fall into the category of removing impediments. It falls into creating work for yourself. Beware of busy work.
As an aside, I'd advise to ditch the tool at the team level if at all you can and use a physical board instead. But that’s a broader topic for another day…
The Status Taker
Teams that use stand-ups to give status updates to the ScrumMaster are not self-organizing. You give status to all your team members and not just the SM. If you as the ScrumMaster find yourself taking status, stop it. That’s not what stand-up is for. If a stakeholder wants to know what the "status" of the current project is, they should be able to get this from the Product Owner. (And if the PO doesn't know how to do this, I know some excellent coaches who can help).
The ScrumMaster is not there to tell the team what to do. They are there to guide and lead them—from the back, in most cases. That is why they call it a “servant-leader” position. The delivery team should want you around for support and guidance, but they shouldn’t be afraid of you in any way. You are not responsible for the project - the whole team are. Encourage them to take responsibility for and ownership of its success. If you’re the ScrumMaster , you are only there to grease the wheels in whatever way you can - whilst not being a wheel yourself or the driver. Leave the driving to the Product Owner.
The Training Wheels ScrumMaster
This happens when a company decides to transition to Agile and they realize that they need a person to fill the ScrumMaster role. So they pick someone from the team or elsewhere in the company to take on that role. And often that someone does not have a mastery of Scrum. Mastery comes from extensive experience, which you probably don’t have if you were chosen by your higher-ups because we had to choose someone from the team.
If you find yourself in this position, then get help. Study, read, join a local meetup, get a consulting firm in. There are classic Scrum pitfalls and pain points in a transition that you need to be ready to handle and probably aren’t yet.
I'm always surprised when I hear Agile coaches say that the ScrumMaster role is not a coaching role. I understand what they mean. They are saying that, in an enterprise Agile transition, you need more mastery in Scrum and Agile than what you had at just the team level. Whilst that is true, it is not true to say that a ScrumMaster should not be a Scrum coach to their team and to the organizational elements that their team interacts with. As an Agile coach, you really shouldn't be spending time coaching ScrumMasters and their teams on Scrum.
Behaviours I'd expect from A Master ScrumMaster
Work your way out of the job
A Scrum team by definition is self-organized. Your goal is to get them to a place of total self-reliance. Act as if you were trying train the team in everything you know to be able to do all of the activities required to be effective at Scrum as a team without you. They should get to the point of not needing you at every stand-up and be able to self-facilitate retrospectives, for instance.
Be a thought leader
Can you display your mastership? Why not write a blog or talk at conference? At least attend a conference or two and a local Scrum group to mingle with peers. Keep learning. If you can’t be a thought leader, at least attempt to be a thought follower.
Humility is important for the servant part of the position. Being a master shouldn't make you an ass.
Know your trade and the tools of your trade
The Scrum guide defines Scrum. If you find yourself uncertain or in a disagreement about Scrum with someone, this simple document is the first place to go. As a "master", you should know the contents of this document. There are a few other things you should know as a master: the history of Scrum, why it's called Scrum, how it compares to other Agile delivery processes. Being thus informed, you’ll understand Scrum better, not to mention be on the way to being a better ScrumMaster while you’re at it.
Have a strong synergy with the Product Owner
The relationship between the ScrumMaster and the Product Owner needs to be good for the team to be effective, especially if you have a newbie Product Owner. You are not always going to be able to work effectively with everyone. If you find that a ScrumMaster can't get on with their Product Owner, I would suggest that you switch one or the other out until you do find a synergy. Don't take it too personally if you don't have chemistry with this counterpart on your team. You can't expect to like or be liked by everyone.