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.