(I originally posted this on my MSDN blog.)
I recently took on the role of ScrumMaster for a newly-formed team that’s new to agile project management. We’ve had several interesting discussions about various topics that commonly come up when a team is adopting Scrum so I thought I’d share them here.
Now, I know, Scrum is so 2007, right? But I’ve been writing about it recently and have several more posts in mind for the near future because I firmly believe in the principle of “write what you know”. This is what I’m doing right now so you get to hear about it. And anyway, although the alpha geeks may roll their eyes at such an outdated topic, there are still large swathes of the software development industry where people are just now looking around and asking, “So, what’s up with this Scrum whatchamacallit thingy?” So hopefully this will still be of use to some of you.
So what’s this ScrumMaster thing all about? Sounds important. I mean, you can get certified for it and everything. The ScrumMaster must be a bigshot project manager, right? Well, no. The ScrumMaster role is important but it’s a very different kind of important than most people assume when they first hear the word.
Here’s what I wrote to my team on the subject:
The term “ScrumMaster” is really a misnomer because there’s really nothing “master” about it. The role is mostly about being the team’s secretary and conscience in regard to anything having to do with the Scrum process. It’s not a management role; it’s a facilitator role. In fact it’s best if the role is not filled by an actual manager.
As the ScrumMaster you can expect me to:
- Clarify the intent and purpose of the Scrum process when anyone has questions.
- Facilitate the collaborative team decision-making process as we figure out what process rules we want to have.
- Loudly remind people to follow the process rules once we’ve agreed on them.
- Identify roadblocks that are hampering team productivity.
- Enlist the aid of people who can remove those roadblocks.
As the ScrumMaster I will not:
- Be responsible for budgeting, resource allocation, or project planning.
- Unilaterally make process rules.
- Be a substitute for Dev leads, PMs, and PM leads.
The ideal Scrum team is supposed to be self-organizing, self-directed, and self-motivated. The ScrumMaster role exists to help out when the team loses its way, but an experienced and healthy Scrum team doesn’t have much need for a ScrumMaster because everyone knows how things should work and the team is able to function on its own without help. The ultimate goal of the ScrumMaster is to work himself or herself out of a job.
To this I would add that it’s important that a ScrumMaster has a good understanding of the Scrum practices, but it’s even more important that the ScrumMaster deeply understands the principles and philosophies behind the practices and why certain things are the way they are. When the team has a difficult decision to make, the ScrumMaster’s job is not to make the decision but rather to lay out the options and articulate the principles that are at stake and how each option will hinder or aid those principles. Then let the team decide. They may choose something that the ScrumMaster doesn’t particularly agree with. That’s ok; let the team run with it for awhile and see if it works. If it works, then great! And if not, then it’s a growth opportunity for all concerned and all the team members have a personal ownership stake in finding a better solution.
SaintGimp 