Alistair Cockburn once stated that Scrum is a mirror, and that organizations need to look into the Scrum mirror no matter how difficult it may be.

I would take that a step further and say that the ScrumMaster is the mirror for the team.

A team often unintentionally falls back into situations in which they’ve previously committed to improving.

For example, let’s say that in the last iteration retrospective the team decided that they need to expand the ownership of each story. The last iteration was a success, yet it seemed as though they were not collaborating effectively. Each user story had one developer doing most, if not all of the assigned tasks.

As a ScrumMaster, you also notice that early on in this iteration there continues to be very little or no overlap in story and task ownership.

It is your duty to speak up (in a non-critical way) and remind the team that they’ve committed to improving this aspect of their software development process. Take a minute and ask them if they’d like to switch stories for the day, pair on tasks, or otherwise find a way to solve this recurring dilemma. In a fashion, you are reflecting back to them their current behavior so they can reason out how to improve.

This is the ScrumMaster essentially acting as a mirror for the team.

Now take the ScrumMaster out of the room, and spread the team around the globe.

Instead of addressing this situation as it happens, a Distributed ScrumMaster would need to look for specific behavior on a virtual scrum board or pick up on it over video / phone chat during a Daily Stand Up. Depending on your unique Distributed Scrum setup, this would most likely not be a quick feedback loop. A Distributed Scrum team with little or no overlapping hours would put the ScrumMaster in a situation where the events may have happened a day ago. In my opinion this is one of the reasons Distributed Scrum teams inspect and adapt more slowly than Collocated Scrum teams.

I’ve found that it can be difficult enough to serve as a mirror for the team when you are literally in the same room. Doing this on a distributed scale requires a ScrumMaster with keen observation skills, patience, and a belief in magic.