Tag Archives: distributed teams

Distributed Teams and Agile Development

On a project I’m experiencing how difficult it is to work with a geographical distributed team. We rely on web-conferencing and just finding a free meeting room at any time, with a projector, to discuss open issues is not easy.

On the one hand bringing people together in one pace is costly because of travel expenses. On the other hand there is nothing like face-to-face communication that is hard to mimic even with the latest communication technology. It is not easy to find the correct balance between travel expenses and communication efficiency.

I was just wondering what agile development has to say about geographical distributed teams, when I ran into a Pattern & Practices document of Microsoft:
Distributed Agile Development at Microsoft patterns & practices. There are no chocking new things in the document but I give you some personal highlights in the case you?l don’t have the time to go through the whole document.

Collocated vs. Distributed teams
One of the best practices of Scrums says your team should have high-bandwidth communication. This is one of the forces to collocate them in one “team-room”.

The force that distributes teams geographical is globalization. Global markets mean that your workforce has become distributes over the world during mergers and acquisitions. Talent has become global as well. You might need the input in your project of one expert located in the other end of the world. Like I said above, you?l want to reduce the costs of bringing the team together.

Challenges

  • How to achieve optimal communication?
  • What to do with teams in different time zones?
  • How to avoid artifacts are affected?

    Conway’s Law says the artifacts will reflect the organizational structure that produced it.

Optimal Communication
Minimize the overhead of setting up meetings across locations. This means that your teams should, very early in the project, get used to the conference technologies to avoid any hesitation in using them. Getting the team in the habit of using the technology and making communication one of their duties is key.

Different communication technologies are available but shouldn’t be that high-tech. A phone with a headset might do! Other options are electronic sharing of documents in web conferences (MS SharedView), video or phone conferences. Instant messaging or webcams might suffice as well.

Get your team acquainted to avoid us’s vs. them’s discussions. You should bring your team together once and while to build a social fabric. Avoid the team members to change too often. Every release at least half of the team members in one location shouldstay the same!

Optimal communication is supported by the right tools. For example Teams System supports electronic scrum boards to be shared by the whole team. Good tools should adhere the natural flow of work.

Different time zones
In the case you?l have teams working in non-overlapping timezone’s, there will be communication black-outs. The strategy is to have team members working late or start early to create at least one common moment that someone in both sides is available.

Give those persons a store-and-forward role in the communication: gather information from the other site forward it to the team-members at his site and forward the information from the team-members of his site to the other site.

Some pitfalls:

  • Functionally focused distribution: testers in site A and developer at site B can result in knowledge silos.
  • Asymmetric distribution: 1 person in site A and n persons in site B can result in losing the ability of keeping the one person up-to-speed with information.

Distribution of work
Force the teams to think in the context of the results meaning in use cases or stories. Avoid that work is functionally distributed over sites. For example one site implementing only the data access related component and another site doing the user interface controls. This can be done by appointing stories to a site and not individual tasks from the stories.

Do and don’ts

  • Do: provide technology for high bandwidth communication
  • Don’t: change the team too often
  • Do: bring the team together
  • Dont: functionally distribute the work
  • Do: provide tools that can make the team work together as they would do if located in one room
  • Don’t: forget remote members
  • Do: improve the team practices to encompass the geographic distribution by gather possible improvements from retrospectives and coaching the agile practices