The organization

The Scrum Master

The Scrum Master has no authority over the team, and yet Scrum makes it an accountability in its own right. Five patterns from A Scrum Book describe the work: helping everyone understand Scrum, stepping back so that the team takes charge of its daily meeting, shaking it out of complacency, removing a "hero" who overshadows the others and getting support for the Scrum Master too.

A meeting where everyone looks at the same person

Every morning at 9:15, the six developers who maintain the billing software of a public water utility gather standing in front of their board. Sandrine, a former project manager, has been their Scrum Master for two months. She holds a notebook.

Karim speaks while looking at her: "Yesterday I finished the calculation for estimated meter readings. Today I'm moving on to corrective invoices." Sandrine nods and takes notes. Julie goes next: "I'm still stuck on the meter import. Sandrine, what should I do?" The other five wait for Sandrine's answer.

One morning, Sandrine stands behind Julie instead of facing her. Julie turns around, hesitates, then ends up speaking to her colleagues. The following week Sandrine does not come, and tells the team that this meeting belongs to them. The first two days are laborious. On the third, Karim says to Julie: "I wrote the meter import last year. Let's look at it together after the meeting."

The ScrumMaster pattern: someone who watches how the team works

A Scrum Book (2019) describes Scrum as a set of patterns, each of which sets out a recurring problem, the forces at play and a solution drawn from experience. The ScrumMaster pattern (a scrum being the rugby formation), which the book writes as a single word, carries two stars: the authors believe a Scrum team will end up needing it.

The problem. The Product Owner (the person who orders what needs to be built) looks after the market, and the Developers look after the techniques for building. Neither has the job of examining how they work together. Yet neither the team nor the organization benefits from Scrum without understanding and applying its principles.

The forces. It is hard to see a problem you are part of, and a detached eye helps to spot it. Roles, meetings and lists are only the visible part of Scrum, and the principles behind them are often ignored. A healthy team also needs work that nobody asks for, such as removing an impediment or settling a disagreement. When that work falls to managers, they bring a relationship of control with them. Finally, everyone looks at their own objective and loses sight of the process: a few tests are skipped, the Product Owner interrupts the work "just this once", and the team gets used to it. The book sums up the situation by saying that Scrum has two products, the deliverable and the team, and that what belongs to everyone ends up belonging to no one.

The solution. The team gets a Scrum Master who guides the Product Owner, the Developers and the organization in understanding Scrum, its principles and its values. The Scrum Master defends the process, helps remove impediments and explains the principles at stake so that the team finds its own solution. The Scrum Master has no authority over the Developers or the Product Owner. The book lists the activities: observing and asking questions, facilitating, teaching, intervening and, the most important according to the authors, actively refraining from acting. Every time the Scrum Master solves a problem in the team's place, the team loses a chance to learn.

The book gives the example of a Product Owner who has not ordered the list. Rather than demanding it, the Scrum Master asks which of two items matters more, given what only the Product Owner knows about finances and users. The authors add that the team ideally chooses its Scrum Master and can replace them if they do not help it progress. They doubt that one person can be half-time Scrum Master and half-time developer, because that person would lose their detachment.

What the 2020 Scrum Guide says

In the Scrum Guide by Ken Schwaber and Jeff Sutherland (2020 edition), the Scrum Master is accountable for two things: establishing Scrum as the Guide defines it, and the effectiveness of the Scrum Team, the whole team. The Guide states that "Scrum Masters are true leaders who serve the Scrum Team and the larger organization", where the 2017 edition spoke of a "servant-leader". It details this service to the team (coaching it toward self-management, causing impediments to be removed, making sure events take place and stay within their timebox), to the Product Owner and to the organization.

Three differences are worth noting. The book gives the Scrum Master a direct power, that of removing a team member, which the Guide does not mention. The book wants the team to choose its Scrum Master, and the Guide says nothing about this. Finally, the 2020 Guide accepts that the Scrum Master may work on items in the Sprint (the fixed-length working period, one month at most), in which case they take part in the daily meeting as a Developer, whereas the book is wary of combining the two.

ScrumMaster Incognito: stepping back during the Daily Scrum

The Daily Scrum is the fifteen-minute daily meeting where the Developers examine their progress and adjust their plan. The opening scene illustrates the ScrumMaster Incognito pattern. It carries one star: the authors see in it the core of a good solution, without claiming it is the only one.

The problem. During the Daily Scrum, the Developers address the Scrum Master instead of talking to one another, and they wait for an instruction or approval before acting. They have taken ownership neither of the meeting nor of the team's work.

The forces. The Developers are best placed to replan their work, but giving a status report is less risky than making a decision. The habit often comes from an earlier relationship with a project manager. People also prefer to talk to someone they are sure is listening, that is, to the person who insisted on organizing the meeting.

The solution. The Scrum Master, as guardian of the process, makes sure the team takes charge of the meeting. The Scrum Master can become invisible, by standing behind the person who keeps reporting to them or by quietly leaving the room, and can also explain to the team why this ownership matters. Their presence is not required. If they attend, they take part in the planning only when asked, and without steering the Developers' choice. The 2020 Guide points the same way: in it, the Daily Scrum is an event for the Developers.

Two interventions when the team stalls

Refraining from acting is the rule, and the book describes two situations where the Scrum Master must, on the contrary, step in.

Pop the Happy Bubble: bursting the bubble of complacency

The Pop the Happy Bubble pattern carries no star: the authors consider it useful and acknowledge that other solutions exist.

The problem. A team that has made progress can become satisfied with its improvements. The remaining dysfunctions then persist, as if a bubble shielded it from unpleasant information.

The forces. The first success, for example finally delivering something, makes the next obstacles look trivial. Retrospectives (the meetings where the team examines how it works) turn into self-congratulation, then disappear. The team attributes its failures to exceptional events or outside causes. In a close-knit group, nobody wants a painful conversation. And the bubble is transparent and cannot be seen from the inside.

The solution. Someone shakes the team by showing it significant weaknesses, backed by data, then builds an improvement plan with it. The Scrum Master is well placed to do this, because they see the whole picture and take no part in decisions about building the product. The book asks them to say "we" rather than "you", and to prefer questions to imposed solutions. If the Scrum Master is inside the bubble too, the eye of another team's Scrum Master can pierce it.

The authors do not hide the risks. Some members will experience the intervention as unjustified pressure, motivation may drop and people may leave the team.

Remove the Shade: when a hero casts a shadow

The problem in the Remove the Shade pattern (one star) is this: the team puts off important decisions and work until a particularly skilled member is available.

The forces. The organization always calls on this person when something is urgent, since they will have the last word anyway. The others give up on difficult tasks. The hero, like a parent in a hurry, finds it simpler to do things than to teach the others. The hero produces a lot, but colleagues stay in the shade and stop progressing, while the hero risks burnout.

The solution. The Scrum Master removes the hero from the team so that the others can grow, as flowers get light after a tall tree falls, and the organization finds another use for the hero's talents. The authors admit the decision is hard: management may oppose it, the hero may feel demoted and output drops while the team takes over. They report the case of a Danish company where a team's velocity (the amount of work finished per Sprint) doubled after the departure of a member who got through five times as much work as the others. This is a testimony, not a controlled measurement. The book also offers a lighter version: the hero gives up the work they excel at and limits themselves to advising, often in a pair.

Scrum (Master) Coach: the Scrum Master gets help

The problem in the Scrum (Master) Coach pattern (one star) fits in a sentence: the Scrum Master is sometimes the source of the team's difficulties, or is not up to the job, or simply wants to improve.

The forces. Many Scrum Masters are beginners, and the role has many facets. The most experienced fall back into their routines. By living alongside certain impediments, the Scrum Master ends up finding them normal.

The solution. The Scrum Master regularly seeks opportunities for reflection with a coach or a sparring partner. This can be another Scrum Master in the organization or someone from outside, provided they have enough distance from the situation. They need not be an expert in the subject, because a good question sometimes unblocks more than an answer. The coach may observe the team but does not intervene with it. The book points out a side effect: a new behavior, such as active listening, first seems insincere to those who knew the old one, and it takes time to become natural.

Limits and pitfalls

The most frequent drift is the project manager in disguise. The Scrum Master hands out tasks, collects progress reports and reports to management, as Sandrine did at first.

The opposite drift reduces the role to secretarial work: booking rooms, keeping the tracking tool up to date and writing minutes. "Doing nothing" can also serve as an excuse for passivity, whereas the book speaks of active restraint, preceded by observation and followed by questions.

The two intervention patterns should be handled with care. Removing a person from a team is a weighty decision, which the Scrum Guide does not entrust to the Scrum Master and which, in most organizations, belongs to line management and employment law. The book itself asks you to try support first. Bursting the bubble, for its part, can hurt if the data are missing or the tone is accusing.

Finally, the usefulness of a full-time Scrum Master is debated, and the available research does not settle the question. These patterns describe what practitioners have seen work. The article Criticism and the state of the evidence returns to this point and to the certification market.