I was sitting around and thinking about my experiences with distributed agile software development.  I've run a number of projects like this and have had a few challenges to deal with, and thought they were worthwhile writing down.

First, perhaps a definition for distributed agile development.  One of the principles of agile development is to have high bandwidth communications between members of the team.  This isn't necessarily bandwidth in the sense of Internet speed, but in having direct face to fact communications.  Once this direct communications is removed, you then have a distributed agile project.  This can be that some people are on another floor, another building, or state, or country; just that they are not instantly available for face to face interaction.  And this includes all participants in the process.

When distributing agile development, and therefore reducing the bandwidth of communications, you must then realize through communications theory (Shannon's law I believe) that the amount of processing to understand a message must increase.  In a sense, you must either start compressing the content of the communication, and / or increasing the effort to understand the communications.

The issue that then begs to be addressed is that how does the processing increases to handle the restriction in bandwidth?

To control this, you must get up front (as soon as possible):

• High trust / agreed SOW.
• Understanding of where the business value is.
• Agreement to collaborate frequently
• Set up means of collaboration
• Understanding that it is still an iterative process that assumes no specs but frequent changes
• Having the ability to access to subject matter experts

A lot of this can be solved by a kick off meeting that addresses these issues through:

• Discuss the scope
• business outcomes
• Get the team together
• Agree on how to break down communications barriers

This type of get together can range from a few days to a couple of months.  It's great to get everyone together as they will be able to begin to understand each other personally, and from that they can understand who they are dealing with when having communications challenges.

This can be very important in facilitating as remote communications will now feel more like they are face to face, making the communications seem much more personal.

It is also useful to rotate people through the sites.  This helps to facilitate keeping personal bonds tied, as well as in helping all members understand the culture of the other members (since this is often global in nature).

Another important thing is to be able to empower the team.  The team as a whole must be able to make their own decisions.  This will tie into having a vision for the work.  Often this can be set by a CEO explaining the vision (or other visionary).  I've found this to be very useful as it has allowed the team to understand where it is that needs to go.  By having the CEO of a remote partnership get buy in to the process, and selling that to his employees that are a remote part of your team, they will respond much better.

I've also found it useful to still hold daily stand up meetings to integrate the distributed members of the team.  I'd often have a daily stand up in the morning with my immediate team members, but also conference call in members of a remote team (say in Europe).  But, I'd also have a standup late in the day with the team, but with other members of the team in India (which late in the US day is their early morning).

The purpose of these meetings is just like that of every other standup: keep the teams tracking on the immediate goals of the project, and also work to identify any communications or technical issues while going around the horn.  And also make sure that you keep this meeting rolling.  Identify issues in the meeting, don't try to solve them.  Take the things identified offline into other meetings between the specific people needed to solve them.

Also, as a project manager (or Scrum Master, ...), use these times to also facilitate more interaction between the members of the distributed teams.  Basically, this comes down to being able to coach the team members to being up issues, and then to lead them into offline communications.  This is also particularly facilitate if you have co-located team members, as a member of the remote team being local can facilitate your understanding of what is being said from afar.

I've only scratched the surface so far.  I'll surely write some more on this inthe future.