Volunteer Scrum Master Handbook

I have to disclose upfront that I am more of an Agile guy than a Scrum guy. Which is to say I feel more at home discussing Agile in general than Scrum in particular. (I’m not even sure how to capitalize it–SCRUM or scrum?)

Over the years I’ve made my peace with Scrum and as I dig into it’s theory and history I find I have few real arguments with the brainchild of Schwaber and Sutherland. My arguments are not with Scrum but with Professional Scrum Masters.

Over past 19 years that Agile/Scrum have reshaped the process of software development many of the traditional roles of software engineering have drastically changed or simply gone away. Technical Writers, Business Analysts, and non-coding Development Managers aren’t needed much by self-organizing teams that talk directly to Product Owners and write up their backlogs on sticky notes. But the one big role that Agile/Scrum has made obsolete is the hard nosed, battle tested, two fisted, lock jawed, steely eyed, organization shaking, cat herding Project Manager.

Back in the day it was the Project Manager who got things done. The good engineers were taught to be sheep and good senior managers were turned into putty by the power of the Project Manager. Microsoft’s variety of Project Manager, the TPM, is still a legend in the industry. It was Windows Vista epic failure and not Agile/Scrum that finally dethroned the TPM.

So when an organization finally buys in to Agile/Scrum where do the people who filled the roles of the waterfall process go? Product Managers became Product Owners. Development Managers who could code became team members or even team leads. Spec writers and Business Analysts moved on. Often Project Manager became Scrum Masters–If the non-coding Dev Managers didn’t beat them to it first.

It is where I got my first bad taste of Scrum: Project Managers turned Scrum Masters who were still doing Project Management. These pseudo-Scrum Masters were the ones with the Microsoft Project plans detailing every sprint from here to release. They demanded status explained in non-technical terms during the daily standup. They stuffed the sprint backlog too tightly (or sandbagged it) and argued with Product Owners over priority. What a mess! It was all Bagile and Fragile.

At least with the non-coding Dev Managers who become Scrum Masters the social graces were respected and they generally stayed out of the way (lest a technical question come their way).

To combat the pseudo-Scrum Master I like to use the role of the Volunteer Scrum Master (VSM). This is just one of the team members (either a coder or a tester) who plays the role of part time Scrum Master. It’s a volunteer and rotating position which can be filled by anybody but the Product Owner. Most of the time the VSM writes code or tests. When the need arises the VSM laces up his boots and does Scrum Master things: Calls for help to scare away any chickens, reminds everyone to follow the process, and let’s me or the full time Scrum Master know that those servers need to be updated by Ops. The VMS removes impediments to the success of the sprint by communication not coercion.

It’s not a glamourous job. There’s no extra pay. There is no authority. You don’t get to wear a uniform or the keys to the executive washroom.

While the job of a VSM is simple and straight forward it can be hard for a new recruit to know where the Scrum Master job starts and ends. So I ask each VSM to think of his part time job as a journalistic one. Observe what is going in the scrum. Take notes. Report findings to the full time Scrum Master or one of the Engineering Directors.

Note: Team members should be responsible for managing themselves. A Scrum Master is not Mom or Dad or a Police Officer. The best way to remove impediments is to communicate them to someone who can address them.

Let’s review how the VCM fits into the role of the Scrum Master…

Responsibility

Pro Scrum Master

Volunteer Scrum Master

The Scrum Master is not the leader of the team

In Theory

Yes

The Scrum Master teaches the process

Yes

Has to learn it first

The Scrum Master has no authority and may not make commitments

That’s idea but…

Definitely yes

The Scrum Master surrenders control to the Product Owner

Hopefully

100% Yes

The Scrum Master is an enforcer of rules

Sure

Nope

The Scrum Master sets up the meetings

If she has time

Nah, set up your own meetings!

The Scrum Master maintains the backlog and updates the Scrum board

Busy work

All team members should pitch in

The Scrum Master explains to management what the team is doing

Bad idea (It’s the Product Owner’s Job!)

Wouldn’t bother

The Scrum Master acts as a buffer

When there is no other option

Dials 911

As you can see the Pro Scrum Master has to be careful. As the Scrum canon defines her job there is some inherent contradiction with the job of Product Owner and even some chicken-like (i.e., management) responsibilities. The VMS has no such ambiguities. He’s just passing through–his sense of self-worth isn’t caught up with the role.

Using VSM enables an organization to limit the number of Pro Scrum Masters, minimize political struggle, and help the team members learn the game of Scrum (the best way to learn is to volunteer).

4 replies on “Volunteer Scrum Master Handbook”

Interesting idea about the VSM… I actually ask anyone to speak up any time the rules we agreed upon during the last retrospective are not followed (I guess that makes anyone who cares to be a VSM). As a Scrum Master I know that the team is ready and successful if I leave for a week-long vacation in a middle of a Sprint and when I am back there are no fire-drills waiting for me, the burn-down chart looks good enough and external impediments were resolved by the team talking to another team. That is a great feeling.
BTW would love to hear your thoughts about end of Sprint demos and retrospective meetings.

Thanks for the comments Vlad. The VSM doesn’t replace the Pro Scrum Master. The fact that you can go on vacation without disaster means you’ve been growing some VSMs of your own 🙂

I’m still observing the effectiveness of the retrospectives and demos. They seem to have a tremendously positive effect but I have some concerns. I often see a lot of therapy but little true utilization of the ideas generated in these meetings. Maybe we’re doing something wrong. I mean it’s been good, but not great.

Thanks John. My “vacation” is getting a little bit too long 🙂 On the matter on retro and demo, I am a strong believer that those are very important parts of the agile process.
The demos cover a lot if done right: confirmation of the user-story readiness by wider audience, support and sales training and even new backlog items ideas. This is where I would not spare any time, as the payback is tremendous and gives the bigger collective the sense of ownership and pride.
The retro discussion, I consider to be a great team-building tool, with this simple, honest conversation about failures and team’s ideas of “even better team”. I would’ve made those Sprint-end celebrations; they should be VERY private (team only) and informal (beer and pizza help there a lot). The role the Sheppard dog is to take notes on how to convert the “pigs” into “happy cows” and enjoy the evolution in the front of his eyes!