The Case for a Technical ScrumMaster

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.