Do you remember the game ‘telephone’ that you might have played as a kid?  Someone starts with a message that they whisper into the ear of the person next to them, then that person whispers as much as they can remember of that same message to the next person in line, and so on until the last person repeats what she hears.  The message at the end of this ‘telephone line’ is often quite different from what the first person originally started with.  Now take that same concept and spread it across three offices on three separate continents with three distinct native languages.  That gives you a picture of what our daily scrums can be like.

Each morning when our team gathers for scrum, we aren’t all in the same room.  This is because we have offices and development partners in Europe, the US, and Latin America.  There are great benefits from this situation, including the opportunity to draw on a global talent pool and the chance for some team members to get started on tasks hours before others arrive at work.  From my perspective in our Philadelphia-area office, we have scrums about an hour after I get to work; but for other members of the development team these meetings happen midday or early in the morning.

These benefits come along with two challenges we have to sort through: communication and coordination.  One of the twelve key principles behind the Agile Manifesto is this: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  We are fortunate to have the technological capabilities to function this way (generally) even with a geographically dispersed team.  Our daily scrums involve video conferencing and screen sharing, our frequent code reviews and user acceptance reviews use the same technology, and we converse regularly over the phone when we need to talk across our different offices.  We also make regular visits to the teams in other countries to further strengthen our abilities to communicate well with each other.

Our daily scrums also focus on our “Agile Board” which provides a graphic indication of every defect and user story that we are working on in a given sprint.  We track the daily progress of these issues during the sprint, coordinate the efforts of testers and coders around addressing these tickets, and gage our overall sprint progress as a team by looking together at this board every morning.  This is, by the way, the same board we constructed together during our sprint planning and so we are coordinating our daily work around the set of goals we established at the start.

This doesn’t always work smoothly of course.  When you combine complicated software development, complex underlying financial concepts, and exacting end user needs all on top of a globally dispersed team with different native languages you will stumble.  In fact I’ll write about an example we encountered today in a post later this week.  But the Agile process allows us to roll with these curve balls (to mix my metaphors), to learn from our mistakes, and to continue working on our communication and coordination.

Of course, the need for strong communication across the team and the importance of coordinating the work of people involved in different aspects of solving a problem is not unique to my sprint team.  Folks working together in the same office – even folks who sit next to each other – can get tripped up here as easily as the diverse members of a globally distributed development team.  In fact, I have found that the obvious need we have to concentrate on communication and coordination means that we pay extra attention to these matters, and thereby I think we avoid pitfalls that collocated teams can get trapped in.  We consciously devote energy to strengthening the ways we work and talk together because we know we have to attend to this.  This is more than just an abstract principle of Agile development; thinking about our communication and coordination is a very practical reality.  In my experience, remembering this makes us a stronger and more effective development team.  Of course, in truth it’s not that simple.