Distributed Teams Can be Effective...Enough

Posted by Deborah Hartmann Preuss on May 24, 2006

Sections

Process & Practices

Topics

Teamwork ,

Collaboration ,

Agile ,

Agile Techniques

Tags

Offshoring ,

Distributed Teams

Scrum, like other Agile approaches, emphasises team co-location. So, shouldn't  Esther Derby, ScrumMaster, know better than to write about distributed teams? By way of answer: Scrum creator Ken Schwaber is also famous for saying "It depends".

One source frequently cited on the subject of "high bandwidth" interpersonal communication is Cockburn's communication effectiveness graph, which ranks "in person", "by phone" and email as providing ever decreasing effectiveness. This chart, contained in his seminal book Agile Software Development, may also be seen online in his article Characterizing People as Non-Linear, First-Order Components in Software Development

Even when they are aware of Cockburn's good advice, teams new to Agile often need to prove themselves before they can hope to challenge existing practices. Distributed teams are a reality in many organizations, and Agile teams, while acknowledging losses in effectiveness, are making them work. And, depending on the level of effectiveness sought, this may yield an acceptable level of improvement over previous processes.

Given these realities, and the challenges they pose, Esther notes "you can't just hope that communication will work." In this StickyMinds article, she offers Five Tactics to Compensate for Distance on Distributed Teams  .

Esther Derby is a recognized international trainer in retrospective facilitation, and is well known for helping teams grow to new levels of productivity, using tools that include project retrospectives and project assessments.

1. Back to top

   communication is important... not by quantity but by quality

   by Alex Popescu

   I have worked in distributed environments for a long time and I think I have noticed a somehow bad pattern. Almost all PMs recognized the importance of communication, and this was the good part. The bad part was that most of them never understood that it is the quality of the communication that matters and not the quantity. In my experience, I have taught that in fact for developers a too much communication is becoming counter-productive in fact (because you are starting to settle down too many meetings at too much inappropriate times for some of the team members, etc.).
   I think everybody agrees that PM and developers are seeing meetings/conf calls different. And the important point here is to learn together what is the best format for all of them. And while developers are requested to be maleable/agile, I haven't heard about many PMs doing/being the same.
   
   ./alex
   --
   .w( the_mindstorm )p.

   Reply

2. Back to top

   Re: communication is important... not by quantity but by quality

   by Dan Bunea

   Hi Alexandru,
   
   A few months ago, I noticed the same problem: quantity is not an improvement, but it actually decreases the effectiveness of communication so I wrote an article about the problem of communication, and about emerging ways to improve communication with the clients, with the code (test feedback) and inside the team: danbunea.blogspot.com/2005/11/problem-of-commun...
   
   Thanks,

   Reply

3. Back to top

   Re: communication is important... not by quantity but by quality

   by Alex Popescu

   Interesting post Dan. I am wondering if the meetings in front of the whiteboard are more appreciated because they tend to remain focused and not always divagating about completely unrelated topics as most of non-whiteboard meetings tend to go.
   Unfortunately, in highly distributed teams these meetings are quite impossible, and so meetings tend to become longer and less focused. To keep them focused, teams should agree to accept meetings only if a very specific agenda was published and accepted before.
   
   ./alex
   --
   .w( the_mindstorm )p.

   Reply

4. Back to top

   Re: communication is important... not by quantity but by quality

   by Dan Bunea

   :)
   
   I remember reading a few years ago, (I think in Cristopher Duncan's The Career Programmer: Guerilla tactics for an imperfect world) about not wating to participare in any meeting that didn;t have a very clear purpose and agenda, and that he considered that no meeting should be longer then 90 minutes. Probably one of the greatest advise I ever took. At the time, I was working in a company where meetings were like lunch: every day at least one, for 2-3 hours but at least lunch had a purpose. I refused to participate in meetings that did not have a clear purpose, and as soon as I saw someone going away from what we were discussing, I asked to go to the next point in the agenda. All participants in the meetings, noticed this and started embracing it, so the meetings became more focused and done only with a very clear goal.
   
   One of the best things in sincronizing with each other in a distributed team is a 15 minutes SCRUM daily meeting. Even if it done with Skype or on the phone, it is still much better then no meeting at all.
   
   Currentrly I am working on a project, that has developer in UK, Ireland and here (Romania). No daily meetings, in 2 weeks ended up with 4 User objects, mapping on the same database table, just to give you an example. One of the biggest failures of this project, is not lack of communication, but the refusal of one side to act on information obtained trough that communication. After all, I do remember one romanian antrepreneur in the US, speakign about elections: vote for those that have the ideas and the discipline to put them in practice, as only the ideas are absolutely useless. The same goes for communication.
   
   Thanks,

   Reply

• Older >