Agile Zone is brought to you in partnership with:

David has enjoyed success using agile and lean techniques at several companies near Washington DC and San Francisco. He joined his first startup in 1999, and helped scale it to a 13 million dollar acquisition in 2006. He now brings entrepreneurial thinking into large organizations so that disruptive innovation can emerge. David is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

A Mirror for the Team

07.30.2010
| 1808 views |
  • submit to reddit
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.

References
Published at DZone with permission of David Bland, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: