… Scrum teams are to be self-organizing. The process of of self-organizing includes determining certain key roles and responsibilities within the team.
✥ ✥ ✥
A self-organizing team cannot objectively see itself, and thus has difficulty improving, identifying problems, and even maintaining velocity and quality.
Traditionally, development projects have been run in a top-down command and control mode, but it has not worked well. Development teams consisting of highly intelligent, creative individuals must have the freedom to organize their own selves. Indeed, self-organized teams are central to Scrum. But self-organization also brings problems. In particular, a team needs some sort of leadership/encouragement/discipline enforcer. The team needs someone to keep them “honest.” A team also needs an “official” face to the outside world – someone to go to when you want to communicate with the team, but don’t know who to go to. A team occasionally needs a single spokesperson. Without these functions being done, the team founders (not “flounders” – this isn’t a fish!)
However, within a completely egalitarian team, these types of activities do not work well. People are reluctant to pick them up, because it feels like you are kind of breaking the egalitarianism. People feel uncomfortable doing these things, and don’t like to volunteer to do them – it isn’t because of a lack of commitment or a lack of recognition that the task is important, it’s just a natural product of a self-organizing egalitarian team.
Select one person named the ScrumMaster to help the team execute the Scrum process most effectively and continuously improve. The ScrumMaster does this by taking an objective view of the team from the team ("above" the team). The ScrumMaster takes responsibility for helping the team to become more effective.
✥ ✥ ✥
Selecting the ScrumMaster is often the team's first act of self-organization.
The ScrumMaster is a role that is very slightly separate from the rest of the team. The person in this role does the leadership/encouragement/discipline/protection/communication things which are necessary, but that team members might be unwilling or even unable to do.
Although the ScrumMaster is slightly apart from the rest of the team, the ScrumMaster must be considered by all to be a full member of the team. The ScrumMaster is a member of the team first, and the ScrumMaster second. In other words, both the ScrumMaster and the team must not let the "view above" in any hinder their open and supportive relationship with each other. The ScrumMaster and the rest of the team should view each other as peers.
Ideally, the ScrumMaster is selected by the team. In any case, the ScrumMaster serves at the pleasure of the team.
Note that the primary responsibility of the ScrumMaster is to support and improve the team. However in many teams, the most visible activity of the ScrumMaster is running the Daily Scrum meetings and other meetings, and this may give the false idea that ScrumMasters just run meetings and deal with administrivia. It is important that the ScrumMaster and the entire team recognize the larger, more important role of the ScrumMaster.
In the pattern, Producer Roles, Coplien and Harrison explain that team members typically are either "producers" (people who directly contribute to the ROI of the organization), or "supporters" (people who help the producers do their jobs). The ScrumMaster is the quintessential supporter: everything the ScrumMaster does should focus on helping the rest of the team (who are typically all producers) be effective. There are many ways the ScrumMaster can do this, and the most important are described in the sub-patterns.
The ScrumMaster is sometimes the face of the team to the rest of the world. However, in no way does it mean that the ScrumMaster is the communication channel for the team. On the contrary, team members should communicate freely and frequently with anybody the need to. But occasionally a single point is needed (but be careful not to let it become a habit!) In addition, the ScrumMaster can help protect the team against unwanted distractions (see Firewall.)
Where should the ScrumMaster come from? Ideally, the ScrumMaster comes from within the team, but the team may have nobody who is willing or capable. In that case, the ScrumMaster will of course come from outside. Thus there is danger of a lack of Community of Trust — trust will have to be established. Note that managers should not appoint a ScrumMaster for the team. Managers may propose a possible ScrumMaster, but the team decides whether to accept the person. Note also that for an inexperienced team, it is useful to select a highly experienced ScrumMaster (see some other patterns.)
Good ScrumMasters don't naturally exist in the wild; you have to develop them. However, there are several desirable skills:
Many of the skills are the same as those used for traditional project management. However, there is a danger in bringing in a traditional project manager as your ScrumMaster: they may fall back into old habits, and Scrum is very different from traditional project management.
Should ScrumMasters also have development responsibilities? This can be quite tempting, especially if it appears that the ScrumMaster doesn't have enough ScrumMaster duties to keep him/herself fully occupied. However, avoid it for a couple of reasons:
Once a team has a ScrumMaster, the ScrumMaster can help the team by using the following patterns, as appropriate. ScrumMasters should become familiar with all these sub-patterns, which describe the major roles the ScrumMaster plays:
There are also tactics the ScrumMaster can use as the occasion requires. They include the following:
Suggested possible additional ScrumMaster patterns: