When I first encountered Scrum circa 2005, the role of a Scrum Master seemed pretty easy to understand: a person that spent 50 percent of their time doing story work and 50 percent of their time doing “Scrum Master” work (Larman, Craig. Agile and Iterative Development: A Manager’s Guide, 2003). Since that time, I’ve encountered a shift where folks labeling themselves as “Scrum Masters” are spending 100 percent of their time doing “Scrum Master” work and 0 percent of their time doing story work. I believe this is a shift that will ultimately lead to Scrum failing in nearly any environment, and the only way to fix this is to determine what makes an effective Scrum Master, and that is someone that comes from a technical background.
I believe the issues behind this phenomenon revolve around:
- A misunderstanding of what it takes to make a team self-organizing
- A failure to delineate the responsibly between a Scrum Master and a product owner
- The “mainstream” acceptance of Scrum and what it means to “waterfall” project managers
- A misguided opinion that a Scrum Master can “manage” more than one Scrum
And, nearly all of these issues are intertwined.
The solution to all of these issues is to identify the best candidates to run your Scrum team, and the best candidates are the folks that make good technical leads.
The Scrum Master can be considered as a facilitator, a servant leader, or, my personal favorite, the first among equals. The Scrum Master is the person in charge of guiding the team through the Scrum process, which means setting the team up for success and ensuring that success. A key part of understanding what success means is by understanding what folks are working on, understanding how they are working on it, and understanding the root of the issues they struggle with. All of that can only be achieved by speaking the language that the team best understands: code.
The Scrum Master also needs to ensure success “external” to the team, and the “external” deliverables a team has are releases, which are comprised of iterations, which are comprised of completed stories. So, the Scrum Master needs to be conversant in the language of the product owner: stories.
The only way to be conversant in the root of the “external” deliverables (stories) and the “language” of the team (code) is to actually participate in the exercise that the team is responsible for: completing stories by delivering quality code. To me, this means the qualities of an effective Scrum Master are:
- Removing impediments (obviously)
- Guarding the Scrum process (Scrum reviews)
- Helping the team understand what a “done” story is (iteration reviews)
- Ensuring solutions stay within the bounds of a Sprint but don’t sacrifice the future (design reviews)
- Guiding the team to deliver quality code (code reviews)
- Completing stories (story reviews)
Self organizing teams need guidance to figure out how to self organize and to self organize in a way that is productive for the organization. A team can’t be allowed to organize in any direction they want, since their primary purpose is delivering value for the organization through good code. The person guiding this process needs to speak the language of the team to ensure the business is getting what it needs (stories) delivered in an extensible way (code).
A Scrum Master needs to be able to converse in macro terms and micro terms. If you find folks that are only good at macro, they probably need to be steered into being Product Owners, and if you find folks that are only good at micro, they probably need to remain as team members. A good Scrum Master has to straddle both, or they risk losing touch with each side. And when that happens, they supply little more than a status collector. If you have a Scrum Master that is a status collector, you might as well bust out the Gantt charts and put on a life preserver, since your raft is headed back to the waterfalls.
For further information regarding Scrum and best agile practices, please visit the Scrum Alliance or visit the fairly comprehensive Wikipedia page (including references).