Scrum Masters: What Makes a Good One?
Yes, that’s right. I am writing a blog post today about Scrum and Scrum Masters.
No, I haven’t lost my mind.
I just realized that out of everything I’ve written about Agile and Scrum, I never talked about what makes a good Scrum Master.
I’ve both been a Scrum Master and I’ve worked on a team with Scrum Masters and from both of those experiences I can tell you that there is much confusion about this particular role on a Scrum or Agile team.
Even the name Scrum Master has confusion around it, is it ScrumMaster or Scrum Master—you can tell, I prefer the latter.
So, let’s talk about why Scrum Masters exist in a Scrum team and what they actually should be doing.
Scrum Masters! What are they good for?
On some teams, unfortunately, it is absolutely nothing.
But, it doesn’t have to be that way. A Scrum Master actually serves a really important role on a properly functioning Scrum Team. (They bring the donuts or bagels in every morning, so the team can get actual work done.)
Ok, I am just kidding about that last part, but in reality it isn’t all that far from the truth. Let me explain.
A Scrum Master really is supposed to be the person who clears the path for the team so they can run as close to full speed as possible. The Scrum Master is sort of like the pit crew for a race car driver.
Without a Scrum Master, a Scrum team is slowed down by impediments which inevitably come up in any development project. It takes time and distracts the team to deal with these impediments, so the whole cadence of the team slows down unless someone external to the development process is moving the boulders out of the way.
So, really, the most important job of the Scrum Master is to remove impediments which may hamper a Scrum team from progressing on backlogs and getting their work done.
This isn’t the same thing as managing a project, because the Scrum Master isn’t deciding how and when things should be done. Instead, the Scrum Master is part of the team and the team as a whole is taking accountability for managing the project.
The Scrum Master also has the role of being the master of the Scrum process—hence the name. This is a tough spot to be in, but is a very important role that many teams neglect. The rules of Scrum are important to a successful Scrum team. One of the reasons why I started to write off Scrum as a process was simply because it was so difficult to get anyone to actually enforce the rules.
This is the job of the Scrum Master; he carries the big Scrum stick and he beats people over the head with it when they step out of line. He doesn’t do this because he is a big power-hungry bully. No, instead, he does this because he knows that the only way the team is going to produce their best work and not waste time arguing over process is if they all follow the process that was agreed upon from the start.
Scrum is intended to be more than just a way to develop software or organize teams, it is also a process that clearly defines what will happen, when it will happen and who will do what.
The Scrum Master is one of the most important roles on the team
It may seem, based on my previous description, that the role of a Scrum Master isn’t all that important to the overall performance of the team, but that is far from the truth.
In reality, the velocity of a team is more influenced by the Scrum Master than any other member of the team—with the exception of that lazy developer that breaks the build all the time and constantly falls asleep at meetings.
Even though the Scrum Master does not have direct control over the management of the team, the Scrum Master’s ability to both remove impediments and enforce the Scrum framework directly affects the team’s ability to get s!@# done.
A poor Scrum Master will let the team flounder and let outside influence distract the team from their work.
A poor Scrum Master will either be too timid or not care enough to force the team to obey the rules of Scrum, causing the whole platoon to go scampering off whatever direction they choose, rifles firing randomly in all directions.
I like to think of the Scrum Master as a guide who takes the team over rough terrain and shows them how to get water from tree leaves on their journey. Sure, the team could manage to bushwhack their way through the jungle without a guide, but it would take them a whole hell of a lot longer to do so—and they’d be much more likely to get eaten by a lion.
So, what should Scrum Masters actually do?
The answer is whatever needs to be done.
You know those gangster movies where some mob boss has a guy they call “the cleaner?” The guy that comes into a sticky situation and can hide a dead body, bribe the right cops, or just make someone disappear? If mobsters were following Scrum, that guy would be the Scrum Master.
The Scrum Master should be part of the team, but not part of the team. The Scrum Master should attend the standup meetings actively trying to spot impediments—especially the ones that aren’t mentioned by the team members, but exist beneath the surface of a problem.
The Scrum Master should ensure that all the Scrum meetings and processes flow smoothly. He should make sure that standups are being used for their correct purpose. He should encourage the team to hold each other accountable and he, himself, should hold the team accountable to what they promised to deliver.
The Scrum Master should be the guy (or gal), who makes things happen. He should know the right people to talk to and know how to get things done. The team should focus on the work, the Scrum Master should focus on the politics. If the team is dealing with politics the Scrum Master has failed.
Most of all, the Scrum Master should be willing to lay it all on the line—to take the hits for the team. Even though the Scrum Master doesn’t control the team and get to boss them around, they are his team and his alone. A good Scrum Master isn’t afraid to take full responsibility for the actions and performance of the team and step in the way of that bullet and take one in the chest if he has to.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)