I’m proposing a 80 minute talk with 10 minutes of questions at the end. The content of the talk will be primarily based on the following White paper which was published in October 2008. I will not be presenting the paper as-is. Learning from previous presentations, both internally at Microsoft and externally of similar material - p&p Summit 2008 & Agile Development Practices 2008 - suggest a different flow will work better.

While some elements of the content could be considered simply an experience report the material is more extensive then simply outlining what our teams did as it tries to give a framework for the challenges and means to address them. Our teams are simply used as an example of some of these things put into practice and the outcome.

This is not a vendor talk or a pitch for Microsoft’s tools. These are mentioned in the paper purely in the context of here’s what we’re currently using at patterns & practices. I mention other alternatives but do not talk about them in detail as we have no direct experience.

Presentation Outline

This is a rough outline. More detail of specific points can be found in the original white paper:

• Introduction (15 minutes)

  • Why do agile teams like to co-locate to minimize barriers to communication and trust
  • The reality of distributed agile
  • The makeup and distribution of patterns & practices teams

• The Challenges of distribution (15 minutes)

  • Communication and trust breakdown over geographical and temporal boundaries
  • Agile practices are self supporting - weakening one effects the others
  • Conway’s Law and how distribution can change your software - architecture can be affected by organizational structure

• Proven Practices (drilldown, 40 minutes)

  • Communication & Trust - maximizing communication and trust with a distributed team
  • Travel - Planning travel to get the most from it
  • Team Distribution - different strategies for team distribution
  • Distributing Work - the pitfalls of distributing work by component not feature
  • Coaching - distribution necessitates a renewed focus on coaching
  • Team Building - the increased cost of churning distributed teams
  • Tools for Distributed Teams - tools for reducing friction when distributed

• Do’s and Don’ts (5 minutes)

• Conclusions (5 minutes)

Example Nuggets

These are taken directly from the white paper.

Planning for travel

Being part of a distributed team at patterns & practices involves some travel. While it varies from team to team typical teams usually do the following:

Our teams have site visits from remote developers both at the start of the project and for one to two weeks out of every six while the project is in flight. Many teams try to incorporate some social activities for the team during these visits. Activities include both organized events—like a team dinner or game night—and opportunities for lots of informal time over lunch or coffee.

Teams also work together in Redmond at the end of the project for the last one or two iterations before final delivery. They also try to have a project retrospective and ship party before the team disperses.

Our testers either travel to Redmond for the duration of the project or work remotely from India. Remote test teams employ a team room representative approach to compensate for the large time zone difference (see Team Distribution). Our teams generally have at least two testers in the team room to compensate for the inability of the test team in India to visit Redmond. A senior Microsoft tester, a team room representative, and possibly one or more testers from India who are on site for the duration of the project.

How work is distributed

One of the challenges when the team distributes work is not to do so according to location. Doing this will have negative effects over time. The architecture will begin to reflect the team’s geographical distribution (according to Conway’s Law). Different locations will become over specialized in particular components. Ultimately both these effects will make user stories harder to complete within an iteration as different parts of the team have to complete specific pieces of work on a critical path to complete a given cross-component user story. This component based approach and its shortcomings are examined more fully by Larman and Voodexii and have even more significant downsides on large scale agile projects.

Distributed teams should continue to think about their work in the context of completing user stories not adding features to components. They need to consciously distribute tasks relating to a single story across the whole team, regardless of geography, and think in terms of user stories not system components. This is one of the most challenging areas for a distributed team as it requires the team to work closely across geographical boundaries but will to lead to consistent user experiences and reduce gaps in functionality that fall between components.

The white paper URL is: http://download.microsoft.com/download/4/4/a/44a2cebd-63fb-4379-898d-9cf24822c6cc/distributedagiledevelopmentatmicrosoftpatternsand_practices.pdf

(I tried to attach it but couldn’t figure out how)