MS Experience Yields Distributed Agile "Dos and Don'ts"
Ade Miller , development manager for Microsoft’s patterns & practices group, has published a paper on distributed agile development, highlighting the challenges of trying to do distributed agile development, along with recommendations for addressing these challenges based primarily on the experiences of teams within the Patterns and Practices group at Microsoft.
Microsoft’s patterns & practices group has been following an agile, distributed development approach for the past five years. During this time teams within the group have experimented extensively with different approaches to best address the challenges of distributed agile development. This paper outlines the challenges faced by geographically distributed agile teams and details some proven practices to address these issues and build successful distributed teams.
The paper starts and ends with warnings that a distributed team is likely to be less effective and more dysfunctional that one that is colocated, and thus a recommendation to prefer colocation to distribution whenever possible. It then goes on to identify areas that the patterns and practices group has focused on, in order to make their distributed teams as effective as possible. The article includes this list of Dos and Don'ts, based on their experience:
Do work to maximize the available communication bandwidth available to your team. Provide communications tools—like conference phone, Web cams, and hands free headsets—for your team and help them adapt their existing practices to distribution.
Don’t continually reorganize your teams for each new project. Building teams takes time, building distributed teams takes even longer. Maximize your investments in team building by minimizing churn on teams.
Do plan to travel, especially at the project’s pivotal points. Bring everyone together for the first couple of iterations, periodically during the project, and right before final release.
Don’t distribute the work by system components, focus on user stories. Avoid organizing distributed teams by function—for example, the offshore test team. Both these approaches create knowledge silos within the team.
Do provide tools to augment or replace those that only work within a team room—like a work item tracking system to replace sticky notes on whiteboards.
Don’t let remote team members be forgotten in team meetings. Pair them up with a buddy and try putting everyone on the same footing by having all members call into conference calls at least occasionally.
Do evolve the team’s practices as they identify better ways to deal with the challenges of geographic dispersion. Frequent retrospectives are the key to getting a team to consider how to improve.
Don’t forget to include everyone in frequent team retrospectives to identify what does and does not work for the team.
Do focus on coaching. Make sure everyone understands why agile practices need to be adapted for distributed development.
Are you working on a distributed agile team? Leave a comment and share some of the challenges you face and some of the ways that you are addressing them.