The Case for a Technical ScrumMaster

11 February 2013

Jeff Meyer
Solution Design Group

When I first heard of the concept of Scrum nearly ten years ago, the role of the ScrumMaster seemed pretty easy to understand: a person who spent 50 percent of the time doing the same work as the team and 50 percent of the time enforcing the process. Since my initial foray into Scrum, I've encountered quite a shift; folks who fashion themselves ScrumMasters are spending all of their time "managing" a team (which they think is ScrumMaster work) and 0 percent of their time doing story work (i.e., delivering on the same functionality that the team is delivering). 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 ScrumMaster — and that, I think, is normally someone who 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 responsibility between a ScrumMaster and a product owner
  • The mainstream acceptance of Scrum and what it means to Waterfall project managers
  • A misguided opinion that a ScrumMaster can "manage" more than one Scrum

And nearly all of these issues are intertwined.

However, 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 who make good technical leads. (The product owner, also, needs a suitable level of consideration. . . .)

The ScrumMaster can be considered a facilitator, a servant leader, or — my personal favorite — the first among equals. The ScrumMaster 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 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 ScrumMaster 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 ScrumMaster 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 ScrumMaster are:

  • Removing impediments (obviously)
  • Guarding the Scrum process (Scrum reviews)
  • Helping the team understand what a "done" story is (iteration reviews)
  • Ensuring that 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 it wants, since its 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 ScrumMaster needs to be able to converse in macro terms and micro terms. If you find folks who are only good at macro, they probably need to be steered into being product owners. (I've found that the best product owners are strong business analysts who have also dabbled in project management. However, this role, like any in Scrum, needs to be filled by someone conversant in technology and not just in gathering requirements into a document.) And if you find folks who are only good at micro, they probably need to remain team members. A good ScrumMaster has to straddle both, or he risks losing touch with each side. When that happens, he supplies little more value than a status collector. If you have a ScrumMaster who 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.

Article Rating

Current rating: 4 (1 ratings)

Comments

Michael Tardiff, CSM,CSPO, 2/11/2013 2:09:58 AM
> The ScrumMaster can be considered a facilitator, a servant leader, or ΓÇö my personal favorite ΓÇö the first among equals.

I prefer to think of a ScrumMaster as the last among equals. The delivery team does the work needed to deliver value; a ScrumMaster helps the team by ensuing their impediments are removed, making work visible, telling the team's story to the team and everyone else, and by leaving space for the team to learn and improve.

+ Michael
Scott Cothrell, CSM,CSPO, 2/11/2013 11:57:25 AM
+1 Michael Tardiff's comment. I do agree that technical people make better ScrumMaster's; but I think they can serve multiple scrum teams (so long as they are not "managers").
Rui Miguel Ferreira, CSP,CSM, 2/12/2013 5:34:19 PM
If two teams have some related issues to deal, as technical as business related, i agree with Scott that the scrum master can serve more than one team. I think the maximum is two, otherwise he is playing more a role of Scrum Coach than a Scrum Master.

I also agree with Jeff with the technical background of the Scrum Master, i think this is mandatory when we want to put in practice Advanced Software Engineering Techniques, which become not optional when the team reaches a certain point of maturity and wants to climb higher mountains.
Nguyen Ngoc Hieu Thuan, CSM, 3/4/2013 6:28:15 PM
I'm not agree with the technical background of Scrum Master.

"A key part of understanding what success means is understanding what folks are working on, understanding how they are working on it, and understanding the root of the issues they struggle with." <-- Jeff: You are really a traditional project manager.

-1 for this article and +1 for Michael
Reid Lowery, CSM, 3/11/2013 11:45:17 AM
Have to agree with Michael and Scott's assessments. As a program manager (historically at Microsoft, but now freelance) I wasn't writing code, but facilitating the team, resolving impediments and enabling folks to be highly productive and engaged. As an Agile Coach these days, I see much the same and with success. so the assertion that they must be working on stories (writing code I assume?) is flawed, in my experience that is.

Reid
Scott Friend, CSM,CSPO, 5/6/2013 11:06:13 PM
I am late tossing my 2 cents in here, but I think that a technical scrum master has a greater challenge than a non-technical one. Specifically, I feel the most vulnerable statement was: "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)." I believe "how" to deliver is really the burden of the self-organizing development team (an ideal team will want to continuously improve their workmanship and effectiveness, therefore organically the better techniques should emerge - value of retrospectives). Also, I believe a scrum master with a development background may bring a bias to conflict resolution, because most people with a development background (I have found) tend to have strong emotions around technologies that they have worked with. However for the "greater good" these biases need to be set aside.

You must Login or Signup to comment.