ScrumMaster - OLD VERSION
… 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.
Therefore:
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 StandUp 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:
First and foremost, a person must want to be a ScrumMaster. The skills are different enough from developers' skills that most developers simply do not want the job.
As the leader of the Scrum process, the ScrumMaster must have strong 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.
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 coding commitment can easily balloon to 90% or more, and the ScrumMaster ends up doing virtually nothing besides developing and running the stand-up meetings. 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 writing code."
✥ ✥ ✥
Examples:
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.”
Academic departments often elect department chairs for a short term, and then the chair returns to the previous position of faculty member.
In Scrum teams, the ScrumMaster usually not only leads meetings, but makes sure they happen -- developers often would rather code than attend meetings.
The ScrumMaster generally collects project data and updates the ScrumBoard, thus providing VisibleStatus 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 DefinitionOfDone 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:
Hide the Chicken (Break Eye Contact)
Oyatsu Jinja (Snack Shrine)
Four Minute Mile
Suggested possible additional ScrumMaster patterns:
Devil's Advocate (Comment: This is similar to WiseFool. As such, anyone on the team can be a Devil's Advocate. I'd kind of hate to see a team abdicating that role always to the ScrumMaster.)
Change Agent (Comment: the ScrumMaster is indeed a change agent. Nearly all of the sub-patterns listed above are the ScrumMaster as a Change Agent in a specific way. Coach is specifically a change agent role.)