The Scrum Master in Practice

What the Scrum Master is accountable for

The Scrum Team has three accountabilities. The Scrum Guide (2020) gives the Scrum Master two things to be accountable for: establishing Scrum as defined in the guide, by helping everyone in and around the team understand Scrum theory and practice; and the Scrum Team's effectiveness, by enabling the team to improve its practices within the Scrum framework.

Notice what is not on the list: delivering features on time, managing the plan, writing the backlog, or deciding who does which task. Delivery belongs to the whole Scrum Team; the backlog to the Product Owner; the plan for the Sprint to the Developers. The Scrum Master's product is a team that works well and keeps getting better.

The examples follow the Portal team at Kestrel Energy, which builds the customer portal and app. Lars de Boer is the Scrum Master, Isabel Santos the Product Owner, and Ravi Kumar, Sofia Lindqvist, Kwame Asante, Priya Shah and Bram Peeters are the Developers.

Whom the Scrum Master serves

The guide lists ways in which the Scrum Master serves three groups. In our own words:

The Scrum Team

• Helping team members learn to organize their own work and to work across skills, so the team depends less on one expert or on a manager.
• Keeping the team's attention on creating valuable Increments that meet the Definition of Done.
• Making sure obstacles that slow the team down get removed, by the team itself wherever possible.
• Making sure every Scrum event happens, is worth the time spent on it and ends within its timebox.

The Product Owner

• Suggesting ways to formulate a good Product Goal and to keep the Product Backlog in order.
• Showing the team why short, unambiguous Product Backlog items are worth the effort.
• Introducing empirical product planning, which means planning from evidence and adjusting often, because the work is complex.
• Bringing stakeholders and the team together whenever that is asked for or needed.

At Kestrel, Lars showed Isabel how a burn-up chart and a simple forecast from the team's throughput can replace the fixed dates her stakeholders used to ask for (see Estimation and Forecasting).

The organization

• Guiding the organization as it adopts Scrum, through leadership, training and coaching.
• Helping plan how Scrum is introduced, and giving advice along the way.
• Helping employees and stakeholders see why complex work calls for an empirical approach, and how to apply it.
• Breaking down walls between stakeholders and Scrum Teams so they can work together directly.

Working with management is a large part of this. Managers in an organization that adopts Scrum often worry about losing control. A Scrum Master helps them find a useful role: setting direction, removing organizational obstacles, growing people's skills and creating the conditions for self-managing teams, instead of assigning tasks inside the Sprint. It helps to give managers what they actually need, such as transparency about progress and risks, through the Sprint Review and the Product Backlog rather than through extra status reports.

True leaders who serve

The 2020 Scrum Guide says that Scrum Masters are "true leaders who serve the Scrum Team and the larger organization". Earlier editions used the term "servant-leader". The change in wording stresses that the Scrum Master really leads, by example, by teaching and by changing the system around the team, and is not a helper who only fetches coffee and books rooms.

Both phrasings go back to servant leadership, a leadership philosophy described by Robert K. Greenleaf in his 1970 essay The Servant as Leader: a leader's first task is to serve, by helping the people around them grow, become more capable and more autonomous. Authority comes from earning trust, not from a position in the organization chart.

Stances

Barry Overeem's whitepaper The 8 Stances of a Scrum Master (2017, published via Scrum.org) describes eight stances: servant leader, coach, facilitator, teacher, mentor, manager, impediment remover and change agent. A stance is a position a Scrum Master takes depending on what the situation needs. The stances are not in the Scrum Guide, but they give useful language:

Part of the skill is choosing the right stance. A team that does not yet know how a Sprint Retrospective works needs a teacher; a team that keeps raising the same problem in its retrospectives may need a coach who asks why nothing changes.

Coaching

Taking a coaching stance means helping people find their own answers instead of giving them a solution: the Scrum Master asks open questions, listens, reflects back what they hear and lets the person or team decide. It is slower than telling, but the team learns, owns the solution and needs the Scrum Master less next time. Useful coaching questions:

• "What would you like to be different by the end of the Sprint?"
• "What have you already tried? What happened?"
• "What is within your control here?"
• "What would make this a good Sprint Goal for our customers?"
• "If this problem were solved, how would you notice?"
• "What is the smallest experiment we could run next Sprint?"

Coaching is not always right. When the team is about to break the Definition of Done to hit a date, or when someone is treated disrespectfully, the Scrum Master speaks up directly.

Facilitating events

Facilitation is helping a group reach its goal in a meeting or workshop by guiding the process, such as the structure, timing and participation, while staying neutral about the content. A good facilitator makes sure quiet people are heard, the conversation stays on purpose and decisions are made explicit.

The Scrum Master ensures that all Scrum events take place, are positive and productive and stay within their timebox. That does not mean the Scrum Master has to lead every event. As the team matures, Developers often facilitate their own Sprint Planning or refinement, and the Scrum Master steps in only when it helps.

A Daily Scrum where everyone reports to the Scrum Master is a sign of trouble. Lars noticed the team looking at him while they talked, so he started standing at the back of the room, and later stopped coming most days. The conversation turned toward the board and each other.

Working agreements

A working agreement is a short set of rules a team agrees on about how its members work together: meeting habits, communication, code review, how to disagree. The team writes and changes it itself, often in a Sprint Retrospective; the Scrum Master facilitates but does not impose it. Working agreements are a common practice and not part of the Scrum Guide.

We, the Portal team, agree that:

1. The Daily Scrum starts at 09:15 sharp, also when people are missing.
2. Focus time from 13:00 to 15:00: no meetings, chat on "do not disturb".
3. Every pull request gets a first review within four working hours.
4. We do not start a new item while one of ours waits for review.
5. Disagreement goes in the open, to the person, not around them.
6. Production incidents beat Sprint work; we tell Isabel the same day.
7. We review this agreement in every second Retrospective.

Impediments

An impediment is anything that blocks or slows the Scrum Team's progress toward its goals and that the team cannot easily solve on its own: a missing test environment, a slow approval process, a dependency on another team, a key person pulled away for other work. A technical problem the Developers can fix with their own skills, such as a failing build, is normally just work, not an impediment.

The guide's wording is precise: the Scrum Master serves the team by causing the removal of impediments. That leaves room for two approaches, and a good Scrum Master uses both:

• Removing it. Some impediments sit outside the team's reach, such as a security policy that requires a two-week manual approval for every release. Lars works with Sanne de Vries, the portal's service owner, and the owners of the change enablement practice to agree on a standard change for low-risk portal releases (see change enablement).
• Teaching the team to remove it. When Kwame says "we are waiting for the billing team's API", Lars's first question is "who could you talk to today?", not "I will chase them". Next time, Kwame goes himself.

Making impediments visible is half the work: a column or marker on the team's board, a short list reviewed every Sprint, and honesty in the Sprint Review about what slows the team down.

Common traps

More patterns that go wrong, such as Zombie Scrum and Dark Scrum, are on Agile Tools and Anti-Patterns.

A day in the life

No two days look the same, but this is a realistic Wednesday for Lars in the second week of a Sprint:

Notice what is missing: Lars does not assign tasks, does not write Product Backlog items and does not report hours. Most of his day is spent on the system around the team.