InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

MS Experience Yields Distributed Agile "Dos and Don'ts"

Posted by Chris Sims on Nov 03, 2008

Sections
Process & Practices,
Architecture & Design
Topics
Collaboration ,
Agile ,
Stories & Case Studies
Tags
Distributed Teams ,
Microsoft ,
Antipatterns

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.

  • This article is part of a featured topic series on Agile

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.