Back in 1998, when Scrum was published in a paper by Mark Beedle, Martin Devos, Yonat Sharon, Jeff Sutherland and Ken Schwaber, the Scrum Master was described as:
“The ScrumMaster is a team leader role responsible for resolving the Blocks
– SCRUM: An extension pattern language for hyperproductive software development (1998)”
Over two decades later, the role of the Scrum Master has evolved again and again. Schwaber and Sutherland highlight that they’re getting better and better at describing what Scrum, its roles, and what the framework as a whole is really about. The version published in 2020 is even smaller, less prescriptive, and makes some important clarifications about what the Scrum Master role truly is.
1. Myth: The Scrum Master removes impediments
Removing impediments isn’t one of a Scrum Master’s jobs. Actually taking on such a task robs Developers of being self-managing. A Scrum Master instead acts to cause impediments to be addressed, treated, and removed by:
- Helping Developers to problem solve and learn to fix the issue themselves.
- Supporting Developers to reach out to others, including other teams, subject matter experts, and even business stakeholders, to help them address and remove the issue that’s impacting them and stopping them from achieving the Sprint Goal.
- Escalating the issue to a manager empowered to change things when the issue is outside of the control of the team to influence.
2. Myth: The Scrum Master goes to Daily Scrum
The Daily Scrum is one of the most misunderstood events. It’s purpose revolves around empiricism: inspecting progress toward the Sprint Goal and adapting the Sprint Backlog so the plan for the next 24 hours is transparent to the whole team (and to stakeholders).
This event is compulsory for Developers, but it’s not an event for the Scrum Master to attend. They just have to make sure it happens and is effective.
For teams that are still learning how to be agile, they’ll benefit from the Scrum Master facilitating the event. But be warned, when the Scrum Master attends the event often turns into a status report to the Scrum Master. This is made worse when people use the “3 questions”: “what did you do yesterday”, “what are you going to do today”, “do you have any blockers”. These three questions were deliberately removed from the 2020 revision of the official Scrum Guide for this very reason.
3. Myth: The Scrum Master is responsible for Delivery
The Scrum Master started out as a manager role, driving the direction of the team and making decisions.
“How does the Scrum Master keep the team working at the highest possible level of productivity? The Scrum Master does this by making decisions and removing impediments. When decisions need to be made in the Daily Scrum, the Scrum Master is responsible for making the decisions immediately…”
— Schwaber, K (2003) Agile Software Development with Scrum
18 years later, with Schwaber and Sutherland publishing their single source of truth for Scrum – the Scrum Guide – it’s now very clear that the Scrum Master is only responsible for the effectiveness of Scrum.
If anything, the Product Owner is responsible for delivery given they’re accountable for the budget, optimising for business value, managing and ordering the Product Backlog, and release management.
4. Myth: The Scrum Master keeps the team’s board up to date
If Developers are self-managing, create the Sprint Backlog, and update it when the plan to achieve the Sprint Goal needs adjusting, then asking the Scrum Master to keep the board up-to-date makes no sense. Developers should keep their own work transparent by keeping the board up-to-date themselves. This is the same myth that perpetuates the idea that the Scrum Master, like a project manager, does the reporting.
5. Myth: Scrum Masters do the reporting
If the Product Owner is ultimately accountable for delivery, and Developers keep their own board up-to-date, then why do many people feel the Scrum Master has to do the reporting?
Usually, this happens as a byproduct of people being more used to Project Management practices. Simply put, if you’ve interpreted the Scrum Master to be an Agile Project Manager, Iteration Manager, or Delivery Manager, then it stands to reason that the Scrum Master does the project management reporting.
The only reporting a Scrum Master should really be involved with is reporting on the growth of the team’s agile capability maturity, and it’s impact on the enterprise: things like decreased time to market, improvements in quality, decreased costs, and improvements trends in productivity.
The Scrum Master Role
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. But, how do they do this effectively? Read the article and download our checklist for Scrum Masters.
1. True: The Scrum Master is a Management Role
The Scrum Master manages the use of the Scrum framework by the Scrum Team. They’re accountable for Scrum’s effectiveness. This means the self-management of Developers and Product Owners doesn’t mean free reign or complete autonomy to work how ever they want. The whole team is required to work within the guardrails of Scrum’s events, timeboxes, artefacts and commitments and it’s the Scrum Master that ensures it all works in a way that produces business value.
2. True: The Scrum Master is an agile coach
The Scrum Master role is an agile coach role. Scrum Masters don’t have legitimate power, the authority given to a manager to tell people what to do based on the organisation’s hierarchy. Scrum Masters use Expert Power and Referent Power to advise, teach, mentor, and coach people to use agile practices, patterns and frameworks so the whole team continuously improves.
The Scrum Master’s coaching responsibilities include helping people in the following ways:
3. True: The Scrum Master helps the organisation become more agile
Leading, training, and coaching the organisation in its Scrum adoption is part of a Scrum Master’s key responsibilities. This particular responsibility is not for the faint of heart. It takes years to learn how agile works beyond just one Scrum Team. Systems Thinking is a key asset for Scrum Master growth to tackle:
- Planning and advising agile implementations within the organisation.
- Helping employees and stakeholders understand and enact an empirical approach for complex work.
- Removing barriers between stakeholders and Scrum Teams.
4. True: Scrum Masters have to understand Scrum theory
Scrum theory is an important part of a Scrum Master’s knowledge. It helps provide the foundation understanding for:
- Why Scrum works and its relationship to empiricism. All Scrum’s events are about empiricism – inspecting one of three artefacts and then adapting. Reviewing progress toward the Sprint Goal, adapting the team’s plans for the next 24 hours to make sure it’s achieved, and making those plans transparent in the Sprint Backlog provides a superior level of transparency about the status of delivery of value compared to traditional reporting on tasks and percentage complete of milestones.
- How Scrum’s Sprints work to apply batch theory to large, complex initiatives. As the saying goes, you can only eat an elephant one bite at a time. Scrum reduces complexity by reducing the batch size. This means the risk profile of work goes down and transparency of actual progress goes up because each Sprint results in business value that is potentially ready to use.
- How to communicate why agile is very effective in dealing with complexity to stakeholders so they see the “what’s in it for me” factor. Seeing actual business value at the end of each and every Sprint increases trust in delivery. It also makes progress far more transparent than other ways of working. With a fixed team size, the amount of work that can be achieved each Sprint (which is a fixed about of time) becomes more easier to predict. That ultimately results in better ability of a team to tell stakeholders when they are likely to get the items they need.
If when asked about delivery status and timing of releases the Scrum Master says “oh, we’re agile, so we don’t know” or “you’ll get what you get”, it shows simply they don’t understand Scrum theory in the way they their role requires.
5. True: Being a Scrum Master isn’t one thing
A good Scrum Master knows how to support their whole Scrum Team (which includes the Product Owner). To do this, though, they have to build and develop a wide range of skills. While some Scrum Masters just stick to facilitating events and running meetings, great Scrum Masters learn a wide range of stances that are applied contingent on the context.
- Lean Leader: Promoting kaizen and life-long learning.
- Counsellor: Supporting people through empathy and active listening to help them to work through dysfunction.
- Teacher: Using traditional classroom styles of learning to create agile capability improvement in the whole team.
- Coach: Supporting the team to develop learning goals and drawing on the resources that will help them to help themselves to grow.
- Change agent: Developing formal pathways for continuous improvement for the team as well as the organisation.
- Mentor: Using personal experience, success and failures, to provide advice for the team to improve self-management and cross-functionality.
- Consultant: Creating and drawing on frameworks to help diagnose and solve complex problems.
- Facilitator: Supporting problem solving by others with structures for collaboration and empathy building without providing advice.
The role of Scrum Master has grown and evolved over the last 20 or so years. Sutherland and Schwaber, the creators of Scrum, have highlighted that they continue to learn how best to describe this enabling, leadership role that serves the organisation as well as teams.
To be a true champion of contemporary ways of working, a Scrum Master must also work to improve their knowledge of how Scrum is interpreted today. Continuous improvement of one’s own knowledge is key to this role’s ongoing success in enabling teams and whole organisations to do more with less, improve productivity, reduce costs, decrease risk, and improve an organisation’s ability to pivot.