It is, however, a perfectly valid question. My response to the accusatory stares and occasional guffaws begins with a description of what constitutes a living, breathing product team. In the software industry we have deluded ourselves for decades that a group of individuals who just happen to be working on the same project constitutes a “team.” Therein lies the essence of the problem: building actual product teams is hard work, harder than almost anyone who takes on the role of ScrumMaster for the first time can imagine.
The first problem I encounter as a coach is that most organizations lack a person with the correct skill set to be a successful ScrumMaster out of the gate. I always try to steer clients away from the idea of appointing a ScrumMaster at all, preferring that they ask for a volunteer – after I have described in detail what the role requires. Barring the self-organizing solution, I encourage clients not to appoint a technical lead, architect, or functional manager as ScrumMaster. The first two sets of people are usually interested in the technical aspects of the work only and would find the duties of the ScrumMaster role an unwelcome distraction. Functional managers typically find it particularly difficult to wrap their heads around the servant-leader concept, especially if they are accustomed to issuing detailed instructions to the people inside their functional silo. Functional managers generally also find it difficult to adapt to the idea of cross-functional product teams, seeing such a development as either against nature or as a direct threat to their own positions. Finally, even if a functional manager is completely on-board with Agile values and principles and Scrum practices, the authority relationship that exists may prevent team members from dealing with their manager/ScrumMaster properly. It is difficult as a team member, for example, to express concerns in a Retrospective about the ScrumMaster’s handling of the role when that same person is your functional manager.
None of this is to say that technical leads, architects, or functional managers are always unsuited to the role of ScrumMaster; it is simply a more difficult adjustment at best and an unwanted distraction at worst. My advice always comes back to self-organization. Sometimes the best ScrumMaster is the person on the team who doesn’t have the most advanced technical skills. Since a large portion of the ScrumMaster’s duties revolve around being a Scrum champion and coach, so-called soft skills are much more important to the role than sheer technical prowess. When everyone realizes fully just how thankless and even dangerous (in the corporate/professional sense) the role of ScrumMaster can be, only those individuals who are really interested will volunteer.
My friend and colleague Jeff McKenna often says that the most applicable training he ever received in preparation for being a ScrumMaster was his extensive coursework in family counseling. While this statement initially generates laughter, whether genuine or of the nervous variety, it gets the point across unambiguously. A product team is very much like a family, with the major exception that most or all of the members of a team can choose to join a different team if things get too difficult. For the most part, however, teams have to work through the inevitable rough patches if they are ever to achieve high levels of performance. Remember, the Tuckman Model ends with Performing, but only after passing through the Forming, Storming, and Norming stages.
So what are the essential skills and characteristics of a good ScrumMaster? How about starting with this list, which is neither complete nor exhaustive:
- Able to listen rather than talk
- Has the courage to take on organizational and cultural impediments
- Comfortable when team members talk about personal issues that affect their work
- Encourages team members to express how they’re feeling about the work, Scrum, their teammates, etc.
- Understands and supports collaboration
- Supports – to the point of demanding – self-management and self-organization
- Tenaciously protects the team from distractions and outside interference
- Dedicated to learning tools and techniques to foster team development
- Understands that it’s about the team, not the ScrumMaster
All for now.