Does a Scrum Master have to be a techie?

 

Recently I wrote an article about the potential for a Scrum Master to take on additional roles. While I was teaching a class this week, one of my learners voiced a concern about Scrum Masters who didn't possess deep technical knowledge of the product solution. He felt that without this expertise a Scrum Master would run into difficulties in building credibility with the Development Team. He also believed that a Scrum Master lacking this knowledge might not know enough to ask the right questions when trying to understand specific technical risks or impediments and hence wouldn't be effective in clearing hurdles from the team's path.

Having been posed similar questions in the past with regards to project managers, I believe the answer is consistent for both roles. Some technical knowledge is necessary, but given a choice between a technically savvy Scrum Master who isn't an effective servant-leader and one who has some technical competency but does a much better job of improving interactions within and outside of the team to enhance value delivery, I'll always pick the latter.

To keep myself honest, I decided to double-check my views against The Scrum Guide™. The only activity listed for the Scrum Master role which could be interpreted as requiring technical competency is listed in the Scrum Master's service to the Development Team: "Helping the Development Team to create high-value products". I take this as meaning that a Scrum Master has sufficient competency to encourage technical excellence but isn't necessarily challenging specific technical decisions or contributing directly to solution design or development.

A few years back I'd written an article covering the pros and cons of a project manager being a technical subject matter expert. The same risks apply to a Scrum Master such as the potential for the Scrum Master making assumptions based on their past hands-on experience or the likelihood of their butting heads with team members when they disagree on specific technical matters.

As with all Scrum Team members, I would encourage Scrum Masters to become generalizing specialists and if they possess the capability and capacity to help the team achieve sprint goals, they should, but making this a default expectation of the role suggests that the supporting organization is not able to form a "whole" Development Team. Quoting The Scrum Guide™ again, "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment".

Servant-leadership is a lifelong journey of self-discovery and personal development. Let's not divert focus from that critical path by requiring Scrum Masters to also develop deep technical expertise.