Scrum Teams are to be self-organizing. The process 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 in the modern workplace. Development Teams consisting of intelligent, creative individuals must have the freedom to self-organize. Indeed, self-organized teams are central to Scrum. But self-organization also brings problems. In particular, a team needs someone to oversee leadership, provide encouragement, and show the way to discipline. The team needs someone to keep them “honest.” A team occasionally needs an “official” face or spokesperson to the outside world – someone to go to when you want to communicate with the team, but don’t know who to go to. Without these functions being done, the team founders.

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. Teams often find someone to fill a role such as Project Management that makes things right to keep things functioning smoothly by patching each instance of recurring problems; however, such practices distance the team from owning their own problems and taking the initiative to solve them in the most satisfying way.


Select one person to be the ScrumMaster, who helps the team execute the Scrum process effectively, and to continuously improve. The ScrumMaster does this by taking an objective view of the Scrum team. The ScrumMaster takes responsibility for helping the team to continually become more effective.

✥      ✥      ✥

Ideally the Scrum Team selects the ScrumMaster. Selecting the ScrumMaster is often the team's first act of self-organization. In any case, the ScrumMaster serves at the pleasure of the team.

The ScrumMaster is a role that is very slightly separate from the rest of the Scrum Team. The person in this role provides leadership and encouragement, holds up the standards of discipline, protects the team, and facilitates communication as necessary. This is particularly important when team members may be unwilling or even unable to carry through on these. 

Although the ScrumMaster is slightly apart from the rest of the Scrum 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. Though the ScrumMaster role has overt responsibilities to the team, neither the team nor the ScrumMaster wield any direct power over each other. The ScrumMaster and the rest of the team should view each other as peers.

Note that the primary responsibilities of the ScrumMaster are 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 a good Scrum Team, the Development Team convenes its own Daily Scrum with or without the ScrumMaster. The team may invite the ScrumMaster to facilitate the Sprint Retrospective.

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 other patterns mentioned here.

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 they need to. But occasionally a single contact point is expedient, and the team should inspect and adapt in having the ScrumMaster fill that role. 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.

Good ScrumMasters rarely exist in the wild; you have to develop them. However, there are several desirable skills:

  • First and foremost, a person must want to be a ScrumMaster. The skills are different enough from developers' skills that many developers simply do not want the job.
  • As the leader of the Scrum process, the ScrumMaster must have deep knowledge of the Scrum process.
  • Strong people and communication skills are a must.
  • A ScrumMaster must be able to deal with many details.
  • The ScrumMaster must be able to analyze data and draw inferences. For example, the ScrumMaster collects data related to the team's velocity, and must analyze it to see what the team can do to increase velocity.
  • As a member of the team, the ScrumMaster needs technical expertise in order to understand the product under development. (Pointy-haired bosses need not apply.)

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. The job isn't to compensate from team lapses and shortcomings but to make them visible and support the team, working together with them to eliminate recurring problems.

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:

  • In the heat of the development battle, a 50% ScrumMaster commitment to development activities can easily balloon to 90%, and the ScrumMaster ends doing virtually nothing besides developing and facilitating meetings on request or as needed. You lose all the benefit of your ScrumMaster.
  • More subtly, it betrays and fosters an attitude that quality and team improvement are not as important as "just getting the product done."


  1. Occasionally during a seminar or meeting, the leader asks the audience to break into small groups to discuss a given topic, then report. These groups start out with everyone being uncomfortable, with nobody really wanting to step out and lead the discussion. Eventually, a discussion leader emerges (or is appointed/elected by the group.) This leader is generally the person who reports to the rest of the audience. Note the discomfort you feel until you have a “peer leader.”
  2. Academic departments often elect department chairs for a short term, and then the chair returns to the previous position of faculty member.
  3. In Scrum Teams, the ScrumMaster usually not only leads meetings, but makes sure they happen — developers often would rather be engaged in active development than attend meetings.
  4. The ScrumMaster generally collects project data and updates the ScrumBoard, thus providing Visible Status to the team (see Knight of the Mirrors, below.)

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:

  • The ScrumMaster keeps the team adhering to their Definition of Done by taking on the role of DoneMaster.
  • Sheepdog: Continually encourage the team follow its processes; watch for and correct deviations.
  • The ScrumMaster can become the Knight of the Mirrors, reflecting the team's behavior back to them so that they understand their strengths and weaknesses.
  • Coach: Challenge the team to improve, and give advice on how to improve.
  • Cheerleader: give the team encouragement and positive feedback.
  • Firewall: protect the team from unnecessary external distractions.
  • The ScrumMaster may also help the Product Owner become more effective, assuming the role of Product Owner Trainer.
There are also tactics the ScrumMaster can use as the occasion requires. They include the following:

Suggested possible additional ScrumMaster patterns:

  • Devil's Advocate  This is similar to Wise Fool. As such, anyone on the team can be a Devil's Advocate. I'd kind of hate to see a team always abdicating that role to the ScrumMaster.
  • Change Agent  The ScrumMaster is indeed a change agent. Nearly all of the sub-patterns listed above implicate the ScrumMaster as a Change Agent in a specific way; in particular, see Coach.