InfoQ

News

Distributed Teams Can be Effective...Enough

Posted by Deborah Hartmann on May 24, 2006 09:20 PM

Community
Agile
Topics
Collaboration,
Agile Techniques,
Teamwork
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.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

4 comments

Reply

communication is important... not by quantity but by quality by Alex Popescu Posted May 25, 2006 3:56 AM
Re: communication is important... not by quantity but by quality by Dan Bunea Posted May 25, 2006 4:55 AM
Re: communication is important... not by quantity but by quality by Alex Popescu Posted May 25, 2006 5:49 AM
Re: communication is important... not by quantity but by quality by Dan Bunea Posted May 25, 2006 7:01 AM
  1. 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.

  2. 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: http://danbunea.blogspot.com/2005/11/problem-of-communication.html Thanks,

  3. 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.

  4. :) 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,

Exclusive Content

Rationalizing the Presentation Tier

Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.