The ScrumMaster Role

(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:

  1. Clarify the intent and purpose of the Scrum process when anyone has questions.
  2. Facilitate the collaborative team decision-making process as we figure out what process rules we want to have.
  3. Loudly remind people to follow the process rules once we’ve agreed on them.
  4. Identify roadblocks that are hampering team productivity.
  5. Enlist the aid of people who can remove those roadblocks.

As the ScrumMaster I will not:

  1. Be responsible for budgeting, resource allocation, or project planning.
  2. Unilaterally make process rules.
  3. 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.

Guest Post: Blink and Subconscious Messaging

(I originally posted this on my MSDN blog.)

My colleague Robert Hanz wrote an excellent piece for an internal email list and I liked it so much I asked him if I could post a copy of it.  Apparently Herb Sutter liked it too!  Thanks, Robert!

I was reading Blink last night, and one of the things it mentioned is how subconscious signals can significantly impact conscious activity.  For instance, one experiment took jumbled, semi-random words and had the subjects arrange them into sentences.  After they finished these, they would need to go down to the hall and speak to a person at an office to sign out of the test.  But the test wasn’t the actual sentences – mixed in with the words to form sentences were one of two sets of words.  One set had a lot of words regarding patience and cooperation, while the other had words regarding belligerence and impatience.  The test was to see the behavior of the student when the person they needed to talk to was engaged in a conversation and was unable to help them.

The group that had the belligerent words waited, on average, about 5 minutes before interrupting the conversation.  The group with the patient wordset waited indefinitely.  The test was designed to end after I believe 10 minutes of waiting – not a single “patient” subject ever interrupted the conversation.

Reading this, one of the things that came to mind was some of the different messaging used by waterfall projects vs. agile projects, and how often we hear them.


  • “Bug” (used for just about anything that needs to be done by a developer)
  • “Priority one”
  • “Due by”
  • “Stabilization”

(this in addition to the frequently long list of “bugs” that confronts developers every day)


  • “User story”
  • “Customer value”
  • “Velocity”

(in addition, the list of work to be done is usually scoped to be possible within a single week)

When I thought about the differences in words, I was really struck by how different the messaging was.  In the waterfall case, the message was overwhelmingly negative – it focused on failures, urgency, and almost a sense of distrust.  It seemed that the language seemed to be geared around ways that individuals messed up, and how everything is an emergency that must be dealt with immediately.  And, if you think about it, in a waterfall culture there is typically no frequent reward or messaging of success – the best you can typically hope for (for much of the cycle) is to avoid failure.  And the idea that you’re actually producing value is very much removed from the language.

On the other hand, the agile language itself focuses on results, not failures.  Stories are typically “done” or “not done,” and while bugs are certainly tracked, at a high level that’s usually just a statement that the story is “not done.”  Combine this with sprint reviews (where the team shows what they’ve accomplished), and the overall message becomes very much focused on the successes of the team, rather than the failures.  Progress is measured by value added, not by failures avoided.  Even something as low-level as TDD consistently gives its practitioners a frequent message of success with the “green bar.”

While I certainly believe that agile development has many advantages in terms of reducing iteration time and tightening feedback loops, among other things, is it possible that something as simple as the shift in language is also a significant part of the effectiveness?  That by priming individuals with messages of success and value, rather than messages of failure, morale and productivity can be boosted?

I strongly agree with Robert that the agile language tends to lead directly to morale and productivity boosts.  You are what you eat, or in this case, you are what you talk about.  Agile practices encourage you to talk about the things that matter.