The Value of a ScrumMaster

I went to ScrumMaster training a few weeks into my first job in an Agile project management environment. I was brand new to the methodology, and throughout the training and after, I didn't really understand the value of the ScrumMaster. “What an easy gig,” I thought. Even a year into practicing the methodology (as a member of the team, not the ScrumMaster) this was my understanding of the responsibilities:

• Calendar: Schedule and start the Scrum ceremonies, and make sure everyone is attending and participating.

• JIRA: Update tickets and add story points during backlog refinement and create Sprints.

• Blocker Removal: Communicate blockers to the person who has the power to remove the blocker and follow up as needed.

• Scrum Coach: Make sure all of the ceremonies are happening.

Over the next year at Metal Toad, however, I realized that a highly performant Agile team (trusting, shared commitment to a common goal, no silos, happy and fulfilled team members) depends on a ScrumMaster who is committed to a different level of support. In the highly performant team, the ScrumMaster is paying attention to the internal and external dynamics that are influencing a team's productivity and mood.

One real world example of this is in the responsibility to remove blockers or impediments, as well as to identify them. Impediments or blockers are usually thought of as technical or client challenges — an API is down or we need to talk to someone on the client's team who is on vacation. These are common examples of items that could disrupt the flow of work and prevent a team from meeting its sprint commitment. As I took on the role of ScrumMaster, I realized that the number one impediment to our team completing its sprint commitment was actually operational interruptions.

Our business model requires us to be the industry technical experts on all things — and that requires that our developers share their expertise. Technical feedback is requested during most phases of the sales process and after nearly every client call. Traditionally, the request for knowledge can quickly become a confusing game of telephone where a client has asked someone to ask someone about something multiple times a day. For a developer, a day that started with the plan to complete two critical project priorities can quickly spiral into three different "quick questions" via Slack that turn into desk-side conversations.

As ScrumMaster, my role is to look at the whole system rather than just the individual interruptions and minor five-minute distractions — and I noticed some patterns. On the day level, these interruptions could manifest in team members working after hours just to do the work they intended to complete during the day. On the Sprint level, it could result in a missed Sprint commitment or a furious rush in the final two days to get all of the tickets done, cutting down on critical time needed for QA and Product Owner acceptance. On the project level, it could mean pushed timelines or difficult conversations about scope. Most importantly to me, for the team members it meant frustration and a sense of powerlessness in getting their work done. Considering all of those outcomes, the "just a five-minute interruption" became a much bigger deal and truly the definition of a blocker to a highly performant team.

Fortunately, along with identifying the issue, our self-organizing team could try out solutions to manage these interruptions. We asked that fly-in requests are communicated directly to the ScrumMaster to address the next morning in daily scrum, either directly by the requester or indirectly through the ScrumMaster. This gives the team the opportunity to quickly discuss the request and identify the person who has the most expertise and capacity to help out. This is an incredibly simple solution, but we still have to work at it every day. As ScrumMaster I am responsible for setting a standard of communication that allows our team to do their best work, and can never waver in my commitment to the team.

Reflecting on the trouble I had seeing value in the position of ScrumMaster, I think it was ultimately because the role is about micro-process improvements rather than broad sweeping changes. It’s easy to look past or disregard those small changes, but over time they add up to huge performance improvements for a team. An empowered and attentive ScrumMaster adds value in spades.