Scrum Master – Beyond the Basic Role

© 2012 William Patrick Swisher

The three standard roles of a Scrum Team are fairly well defined. The Product Owner represents the needs of the business, defines backlog items, is the single point of contact for questions, and ultimately accepts/rejects completed sprint work. The Developers select backlog items that can reasonably be done within the sprint and delivers the completed work. Lastly the Scrum Master ensures the team is working according to the Scrum methodology and assists the team in any way to clear impediments.

A good Scrum Master however, goes beyond the role as defined above, they have to  simultaneously be a part of the team and an impartial observer of how the team functions so that they can address disfunction when appropriate. The following sections expand on the basic role.

Facilitating Communication

The Scrum methodology has a set of rituals (meetings) that have very specific purposes. For example, the Sprint Planning meeting is all about the selection of sprint work, the Daily Standup is for coordination and issue resolution, the Sprint Review is for demonstrating completed work, and the Sprint Retrospective is for team self-evaluation and improvement. In each of these meetings the Scrum Master must play the standard facilitator role, making the sure the meeting starts and ends on time, that the purpose is clear and the participants stay on track. Additionally the Scrum Master needs to watch for communication failures and point them out so they can be corrected before the misunderstanding takes the team too far off course. For example:

Matching Topics

When two people appear to be conversing about the same topic there can be subtle differences in what they are saying or odd pauses as one party tries to clear the confusion in their minds. Scrum Masters should learn to recognize this pattern and bluntly ask if they are really talking about the same thing. Asking the members to reiterate the point of the conversation may reveal very different goals.

Mangled Message

When one person is sharing information with the group, the Scrum Master should look around the room for signs of confusion. Furrowed brows, slight tilts of the head, squinting are all signs that people aren’t getting the message. Interrupting, apologetically of course, and pointing out that people look confused will provide an opportunity for those team members who were confused to indicate they need further explanation.

Drifting Away

When some team members’ attention appears to be drifting because a speaker is not being clear or wandering around topics. The Scrum Master can interrupt and rephrase or simply “play dumb” and be the one person bold enough to say they don’t get it. People usually appreciate the clarification and it brings their attention back to the topic at hand.

Addressing Unspoken Needs

During the Daily Standup meeting each team member answers the three basic questions about what they did, will do, and any impediments.

For the last question, people tend to answer with real issues that are truly blocking them which of course is good but they also tend to skip potential issues or upcoming needs. This behavior is probably a natural part of our upbringing, where we shouldn’t alarm others unless something is real. In the case of being on a Scrum Team, where there’s a limited amount of time to complete work, this can be counterproductive. It’s far better for potential impediments or needs to be brought out into the open and addressed. Occasionally there may be some false positives, but when an unmentioned or potential impediment finally becomes real, the team has already lost time to address it. Scrum Masters should listen carefully for hints that a team member needs something or will need something soon and directly ask about it.

Guardian of Rituals and Artifacts

The Scrum Master may not be the most experienced person on the team, but their role focuses them on making sure the goals of the rituals are achieved:

  • Sprint Planning: The team assesses their capacity for the sprint, selects work that they can reasonably complete within the sprint, and comes to consensus on how they will execute the work.
  • Daily Standup: The team communicates, collaborates and identifies impediments through the answering of the three standard questions.
  • Sprint Review: The team demonstrates completed sprint work to the Product Owner who then accepts/rejects the work with any necessary explanations.
  • Sprint Retrospective: The team evaluates their performance across all aspects of working together and decides on improvements for the very next sprint.

They should also ensure that all artifacts are created and maintained to maximize team productivity:

  • Backlog Items: Do all Backlog Items have the necessary information for the Developers to execute the work? Are the user stories clear and meaningful? Do each of the acceptance criteria represent singular discrete requirements? Are clarifications by the Product Owner captured as updated acceptance criteria or easily referenced in documentation?
  • Product Backlog: Are the top backlog items in business priority order? Have the Developers seen the upcoming backlog items and given feedback and or effort estimated them? Is there a sufficient amount of backlog items for at least a couple of sprints ready for possible selection midway through the current sprint?
  • Sprint Backlog: Are updates to remaining hours being captured? Is the burndown chart being updated? Are any additions or team decisions regarding sprint work properly reflected?

When rituals and artifacts are well understood and consistently used properly, the team will be far more productive as they won’t have to deal with distractions.

Encouraging Adherence to Established Standards 

Along with the standards that make up the Scrum methodology, the team will need to follow the standards of the organization. The Scrum Master is in an ideal position to remind the team about coding or testing standards that may be forgotten as the team focuses on completing sprint work. Since they do not have authority over the team, their approach can be less confrontational and more helpful. For example, using a checklist for each product release and asking the team at opportune moments how they’re doing on one standard or another. This technique won’t be seen as controlling but as helpful, reminding the team when needed.

And, when established organizational standards don’t serve the team or their goals, or pose impediments, the Scrum Master can also help organize a reviews and updates of standards.

Playing Provocateur

We’ve all experienced that uncomfortable moment in a meeting where conversation stops and no one wants to breach the unresolved topic that’s on everyone’s mind. This is the proverbial “elephant in the room” and if the issue is somehow impeding the team’s progress or threatens to affect team performance, the Scrum Master should call it out in order to get resolution. Once the conversation starts, the Scrum Master can play the facilitator and manage the conversation towards a productive end.

During Sprint Retrospectives, breaching uncomfortable topics is an essential part of being the Scrum Master and finding a solution will help the team grow and accelerate their performance.

Maintaining Focus on Business Priorities

As sprint work is underway there will always be distractions that threaten to divert attention away from sprint work. These can come from the Product Owner or other stakeholder where they want some new issue explored or problem solved. Distractions can also come from the Developers themselves where they find a problem with the code or a way to improve it and want to spend the extra time completing the work.

It’s very easy for a team, especially those who like to solve problems and help, to take on new work. Unfortunately, doing so consumes sprint capacity and has the potential to block the completed of work specifically selected during Sprint Planning.

The Scrum Master should watch for the team starting to focus on anything but sprint work and bluntly ask if this new work is part of the sprint or not. If not, then the team should evaluate if they want to officially bring it into the sprint.

Conclusion

Ultimately, the Scrum Master is more than just a meeting facilitator and guardian of the Scrum rituals and artifacts. They should have the goal of mentoring and guiding the everyone towards being a high performance team.

Advertisements
This entry was posted in Scrum Master and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s