When I first received my ScrumMaster certification, I regularly asked the senior ScrumMasters I worked with what I was supposed to do, besides facilitate Scrum events, enforce Scrum rules, and remove impediments. I tried to be a good ScrumMaster and worked with multiple teams, so I stayed busy, but I had heard that great ScrumMasters could only handle one team at a time. I didn’t understand what could take up that much time. As I gained more experience as a ScrumMaster I began reviewing and reflecting on what the Scrum Guide says versus what that looks like in the real world.
The Scrum Guide provides a list of ways that the ScrumMaster serves the Product Owner, but it is not exhaustive. The list includes helping the Scrum Team understand what the goals, scope, and product domain are. It encourages effective Backlog management, which includes arranging the Backlog to maximize value and the need for “clear and concise” Product Backlog items. Added to that is understanding empirical product planning, practicing agility, and finally facilitating Scrum events “as requested or needed.” Notice that it is NOT the primary job of the ScrumMaster to facilitate ALL meetings.
ScrumMasters help ensure that the Product Backlog reflects the Product Owner’s latest release plan, prioritized by value and transparent to all Stakeholders. They help confirm it contains the latest Stakeholder requests, including the ones that were discussed in the last Sprint Review. They work with the PO and Development Team to ensure it isn’t bloated with items that are no longer valid or valuable. They also work with the PO and Development team to review the backlog items and ensure that time and energy are focused on the items at the top (that they are ready for the next Sprint) rather than items that are farther down the list because spending too much time refining items 4 or 5 Sprints away is wasteful in an empirical process. They also make sure the Product Owner doesn’t neglect Technical Debt and refactoring, which are critical to maintaining a robust architecture. ScrumMasters facilitate the (sometimes) difficult discussions around trade-offs between the Development Team’s desired work items vs. the Product Owners priorities. Ultimately the Product Owner decides, but the Team needs to be a part of the decision making process. ScrumMasters make sure those conversations take place.
The Scrum Guide also lists how ScrumMasters serve the Development Team. They coach the team to self-organize, be cross-functional, and create high-value products. No surprise that ScrumMasters also remove impediments to the team’s progress and facilitate Scrum events (as requested or needed). They also coach the team on interacting with the non-Scrum parts of the organization.
One of the most important roles of ScrumMasters is to establish a safe space for the Development Team to truly become a team. Teams celebrate successes, challenge one another to new heights, and hold each other accountable when things go sideways. The teams should strive for transparency, and have the courage to express their opinions and concerns to the group, even when they are in conflict with everyone else. The ScrumMasters are there to help them realize those efforts. In short, ScrumMasters press the team to discuss issues that are uncomfortable in order to continuously improve both the quality and quantity of work getting done.
ScrumMasters help the team keep their work transparent by ensuring the task board is continuously updated, along with the Burndown Chart, impediments list, Yesterday’s Weather, backlog management tools, etc. Transparency helps reduce risk by showing everyone, both internal and external to the team, exactly what is happening in each sprint. ScrumMasters also encourage the team toward continuous design and refactoring. Constant feedback loops through test automation and continuous integration are also critical to success.
ScrumMasters serve the Organization through Agile evangelism, planning and coaching Scrum adoption, along with helping everyone understand how an empirical product development approach can be highly effective, when well executed. That includes being plugged in enough and understanding the overall direction of the business to answer the questions that haven’t been asked yet and provide insights on strategic next steps. The Transparency discussed earlier allows ScrumMasters to have difficult conversations with the organization’s leaders about potentially negative impacts their decisions can have on team continuity, productivity, morale, etc.
Strong communication channels are also well maintained between different Scrum Teams and the organization at large, as the teams go about delivering value, quantified in dollars, lost opportunities (whether customer related or time to market), or lost quality.
ScrumMasters also work on organizational impediments and encourage the organization to allow teams to experiment, for example, by implementing pair (or mob) programming. The ScrumMaster may be the only agile person management/leadership has ever interacted with, so they need to remember that they are an ambassador for the agile mindset, and they need to show the business the value Scrum has to offer as a framework.
Perhaps the most important thing ScrumMasters have to do is grow. Their personal growth will help the Product Owner, the Development Team, and the Organization improve. Take time to read books, articles, and blogs. Go to Meetups (especially right now while they are being conducted virtually), and interact with ScrumMasters / Agile Coaches from other organizations. Being the best ScrumMaster you can be is indeed a full time job.
Esse quam videri,