Communication problem with Distributed teams

Question

Hi,

There is usually a lot of scope for bad/ miscommunication between geographically distributed teams.

Any suggestion for tools which makes the communication clear and well documented in an easily formatted and accessible manner?

Answer 1

We're using Basecamp to share information and work on timelines, todo lists. It's limited but does just enough to be useful. we're also using Hudson for CI, if you're not all in the same place having some kind of automated build/test is pretty much essential.

In the past I've tried using SharePoint for information sharing, and it's been a little too clunky to be useful. Sharing documents and calendars is not the same as a collaboration space. I've also used Lotus Notes many years ago and it had the same failings.

Another approach we've tried has been a straight wiki - that was better than nothing, but needed more discipline to keep upto date, it also doesn't handle tasks lists, hence the move to basecamp.

Answer 2

I had three teams in different time zones for about 7 years, totalling up to 100 people. It can work very well.

I found a development wiki to be very helpful, it encouraged articulation and sharing, even when remote. Some people liked online chat/IM type interaction and it was very useful when a couple of people were working on closely related things in different locations. Not everyone works well like that.

Video conferencing and shared white boards was a complete waste of time and nobody ended up using it after a great deal of expense. However, it was an obvious first step so we did it on the presumption that it would be good.

However, the real lesson I learned - and re-learned later when I outsourced work to India - was that there are two fundamental things which you have to get right. If you don't you have no chance of succeeding:

1. Get the whole team together at the start of the project. The quality of communication is much better when people have met. Without that there is so much room for misunderstanding that the cost of doing it is insignificant. The biggest positive is that people can hear and see someone in their head when they are reading a terse email, or on the end of a conference call or under pressure or disagreeing. Without having seen who the person is and how they operate it is just too easy to get the wrong idea about them. That then severley damages productivity and team spirit.

2. Strong local management. The really unsuccessful remote teams I had were always characterised by not having a strong local leader. It is really important that the local manager has authority commensurate with his/her responsibility. If there is too much central control the team will feel disenfranchised and split and be hard to manage. If there is too little contact they will go their own way, which is almost worse. It has to be done just right and the person in charge has to be completely reliable and trusted. They also need to have an open enough relationship that they can give the central manager a feel for the unspoken things happening in the team. Very often small local arguments can really affect how a team performs - especially if the argument breaks out between remote teams. Having someone who will identify and flag those is key to success. Having someone who can then resolve them is even better. You need to get those people together and in each others' locations too so they have a level of relationship which means they can work together and represent the other teams to their team.

Lastly it is important that you provide a means for them to all get together socially periodically. We would have everyone in one place once a year, put them up in a hotel, have a mini-conference so they could share their bright ideas and basically get them all drunk or do something else fun which has nothing to do with work. It really helped them gel and form relationships which they could take back to their working world.

So, fundamentally I don't think good remote team interaction is about tools, it is a human thing and you have to get the social infrastructure sorted out or the technical infrastructure doesn't matter.

HTH and good luck. I really enjoyed having a varied collection of people from different cultures and backgrounds working effectively rond the clock. It was a huge challenge to make it work but when it did it was awesome.

Answer 3

I also work as part of a geographically separated team. One element that has been key to our success has been ease of informal communications.

The two tools that have been useful for this are the chat clients that are part of Skype and Gmail.

The biggest problem facing us was a sense of disconnection from each other. One person would make progress, but other people wouldn't necessarily know about it. Small questions would go unresolved. Employees who worked alone tended to feel isolated and unmotivated.

By using chat as opposed to frequent calling, each team member was able to stay in constant contact with other team members in a non-obtrusive and productive way.

The key here is that it became extremely easy to stay in contact -- just leave a chat window open all the time with one's co-workers (in gmail for example).

Other technologies that are even slightly slower to use were much less effective and required programmers to stop work to participate.

One of the benefits of Gmail chat is that the chat transcripts are saved with the e-mail messages and can easily be archived and referred to.

Answer 4

Use mandatory IRC for basic day-to-day communication. It has a very low threshold for participation, and everyone is always included in the conversion. With mail and skype and such, distribution of knowledge will be much harder, since most people will not participate, or only talk to the ones they like. And half the team will never look at the development wiki. IRC creates an informal atmosphere, making room for the constant casual conversation which helps smooth out the wrinkles that distribution of teams create.

Also, IRC is free, open, easy to setup, etc.

I agree with this answer, except that I think gmail or skype chat is too much overhead to use.

Answer 5

Try Redmine. I worked for a long time on a project where the main company was in the US, with managers in Austraila, programmers in Austria, Czech Republic and here I am with a small team in The Philippines. Beyond a deep hatred for daylight savings time, I grew quite fond of Redmine in the last few months.

Also, getting to know Asterisk won't hurt :)

Answer 6

Here is what we are doing to handle geographically distributed teams (China and Canada):

• Make sure that the same processes are used worldwide
• Centralize continuous integration system and SCM
• Conduct a weekly meeting where you review the week achievements, week challenges, and future plan. Have the development managers and product manager participate
• Implement scrum and run daily scrum of scrums
• Identify the bottlenecks and make sure that a person with enough authority resides in both offices
• Meet from time to time (every quarter or so)
• Train people to describe their problem precisely
• Pick up the phone if the problem is not resolved after to mail exhanges
• Escalate to manager if the problem is not solved quickly
• Trust the other office