Sprint Meetings in Distributed Scrum

My current scrum team is distributed in three locations:

• Location A: developers only
• Location B: testers and the product owner
• Location C: testers, developers, and the scrum master

In this situation we have to deal with some lack of communication. Location A is in a different time zone, 5 hours away, which makes communication even more complicated. We can't use a simple task board everyone can easily work with on a daily basis. Electronic documents are used to substitute most sprint artifacts.

How do we succeed with all those sprint meetings we have to perform? Daily scrums, sprint review, product demonstration, sprint retrospective, sprint planning. These are quite hard to do with emails and phone calls only. In fact it simply is not possible to let the team improve by these means. (And please do not call it Scrum if you have to work that way.)

We use a video conferencing system to connect all three locations in all the meetings necessary. The team sits together in virtually one room, can see the other team members, and has direct communication with everyone. This is just great and after a few seconds you simply forget that the other people are far away.

To simulate the feeling of everyone standing in front of a task board, we use a remote desktop system with one master and two client connections. That way all participants are able to move the mouse, enter some information, and instantly see what other people do with the documents.

Today we had a really good distributed product demonstration for our product owner. The software system was hosted at location C, was presented by a developer of location A for our product owner sitting in location B. The product owner was impressed of the early feedback. As our testers already have done their job, the software was in a really good quality. So the product owner said something about "wonderfull" several times, which made the team proud of what they had achieved in the last two weeks. The product owner also gave suggestions and hints (in traditional tongue: "detailled requirements") so that the developers understood way more than a written requirement specification document ever could provide. I just love these short feedback cycles, the increasing team motivation, and the positive outcomes of Scrum!

Hint of the day: get video conferencing systems and remote desktop systems if you have to deal with distributed scrum meetings!

Book: Esther Derby, Diana Larsen - Agile Retrospectives

Everyone working with teams has to read this book!

Authors: Esther Derby, Diana Larsen
Title: Agile Retrospectives - Making Good Teams Great
http://bit.ly/cvoaH

Rating: highly recommended!

Esther Derby and Diana Larsen describe 38 activities for all stages of a retrospective meeting. These activities provide ways to improve the team work and to get better results of the retrospective. There are no rules when to choose which activity but you get a nice set of activities to select from. Goal: avoid boring routine by varying activities.

Retrospectives are one of the major keys to successful agile teams! This book helps to improve teams and so to improve the agile approach of a team.

Be aware of technical teams being focussed on hard skills rather than soft skills - this may be a problem to solve before introducing an activity working with feelings of team members and the expression of feelings. Tech staff often judges such things as psycho stuff. So what is the great thing about retrospectives? Even the 'psycho stuff' situations will improve as the team does.

Conclusion: read this book and try to vary your very next retrospective meeting.