Five Tips for Distributed Agile Teams

After many years of ranting to clients and classes about the problems with distributed Agile teams, I finally met a team at a small organization in Toronto that actually had a pretty good set-up for their distributed team.  But it wasn’t perfect.  Still, it inspired me to think seriously about how it would be possible to make it as good as possible.  The result is pretty good, but actually, I think it is more expensive than just getting everyone into a team room… oh well!

Actually, there are six tips here because my first tip is really about deciding to use distributed Agile teams…

Some in-house studies that I have been privy to have shown 2-1 or 3-1 productivity difference between good co-located teams and “good” virtual teams. Creating a true, high-performance virtual team is incredibly hard emotionally, incredibly time-consuming, and costs a lot in terms of tools and travel. If this is being done for convenience of the team members or for cost savings, it’s a bad idea. The only good reason to have distributed teams is if there is a compelling strategic reason that trumps the hit you will take financially and morale-wise. (That was tip “zero”.)

That said, it is worth trying is to create an environment as close as possible to what you would get with a co-located team. To do this, here are some things to try:

1. Set core hours (at least 3 contiguous) every day when everyone on the team, regardless of time zone, will be at work simultaneously. If you have globally distributed Agile teams, this will mean that some team members will have to make an ongoing personal sacrifice to be available. This sacrifice should be compensated financially. Avoid rotating the core hours in the misguided idea that it is better that everyone is uncomfortable some of the time vs. some being uncomfortable all of the time. It is much easier for a team member to get used to a consistent schedule and although initially there will be discomfort for some team members, they will (relatively speaking) get used to the new schedule.
2. During core hours, use a good video conferencing tool (e.g. Office Communicator), in an always-on state for all team members, to be in the same space at the same time. Cameras should be set up so that it is possible to see an individual’s facial expressions, yet also to allow that person to move around and still be in-view. The video conferencing tool should have good full-duplex audio so that no one ever gets cut off because someone else is louder.
3. During core hours, all team members agree to forego the use of headphones or anything else that would prevent them from instantly being aware of something happening with any of the other team members. Again, for some people this might be quite a sacrifice. The idea is that communication is paramount for Agile teams and anything that isolates one team member from another will hinder communication.
4. Have a live update task tracking tool that all team members use. Any task-switching should be visible on this tool either through a colour change, an audible cue, or a movement. So if I complete a task and start on a new one, everyone else should notice this immediately even if I do not actually say anything. The team members should get in the habit of using this tool even outside core hours.
5. Have a second (or third) monitor for every team member that is dedicated to the always-on communication tools (video conferencing, task tracking). These always-on tools should never be covered by anything else. All the real-time communication tools are useless if they are not constantly visible. If your team members currently have two monitors, then get them a third for these tools. There should never be any excuse for a team member to hide these tools.

Basically, these suggestions are designed to maximize the quality, bandwidth and minimize the latency of communication among the team members. If you have distributed Agile teams, and you try these things, please let me know how it works for you!

[This article was originally published on Agile Advice on 14-Apr-2011]

If you find this useful, please consider contributing with our
“Value for Value” model.