| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions! Dokkio, a new product from the PBworks team, integrates and organizes your Drive, Dropbox, Box, Slack and Gmail files. Sign up for free.

View
 

Collocation Issue

Page history last edited by Joe Little 10 years, 9 months ago

In general, I believe that collocation is better.  AND, that agile and Scrum can be done when distributed.  But the data I know of and my personal experiences tell me that being collocated is quite valuable if it is possible.  And typically it is if we can convince the managers involved of its value.

 

See here for some discussion: http://groups.yahoo.com/group/scrumdevelopment/message/31404

 

See here for 2 articles on collocation: Agile Articles  The articles have "collocation" in the file name.

 

See this article:  http://www.sciencedaily.com/releases/2000/12/001206144705.htm

 

See this paper: http://www.commerce.uct.ac.za/Services/Temporary_Dumping_Ground/Files/The_Impact_of_Collocation_on_Team_Effectiveness.pdf

 

A few other comments:

* In my professional experience, we need to analyze each situation to determine whether a distributed team might be better.  See below for a simple approach to that analysis.

* It is MUCH better for a team to learn Agile collocated.  Travel expenses would have to be multiples of what they are currently for that to offset the benefit.

* A Scrum team can generally be pretty productive even if distributed.

* Some distributed teams can reach hyper-productivity.  Still, it is almost surely true that the likelihood of reaching hyperproductivity is much higher if collocated.

* The disadvantages of distributed are more intractable than those of collocation.  The disadvatages of collocation can be "solved" if the people are willing.

 

Vocab:

Distributed: Two pods (~4 each), each of which are collocated, that together form a real team.  One in Amsterdam and one in Mumbai, for example.  Distributed may or may not have time zone differences.

Dispersed: Each member of the team working in a different location (eg, at home). Time zone differences may or may not exist.

Collocation: My definition assumes a war room of reasonable size.  The studies suggest just having people sit within 30 meters of each other has a noticeable effect.

 

We will start another page on Distributed Teams, and associated best practices.

 

Email by Frabk Mauer 31 Jul 2008:

 

Hi Joe:

 
While I agree with your hypothesis that collocated teams are more productive than dispersed teams, I do not believe that they are twice as productive. My guess would be more 30-50% better. I do not have any data to actually support this. It is very difficult to come up with a meaningful productivity metric (LOC/hour does not cut it). Thus measuring it is very hard.
I also never have worked with a completely dispersed team. Usually, the teams I work with have multiple people at the same location (but multiple locations). 
 
One argument for dispersed teams might be morale: If team members can cut their commute substantially, their morale might improve (which often is a key to improve productivity). 
 
Even for distributed teams (multi-site teams), best practice is to bring them together at the start of the project and periodically so that social interactions are improved. Jim Herbsled studies this. There is also a conference on Global Software Engineering that has papers in this area.
 
I hope that helps,
 
Frank
 
Email from Jim Herbsleb 01 Aug 2008:
 
Hi Joe,
The most concrete result I'm familiar with is a study of software development projects at Lucent Technologies (I was one of the authors) where we looked at work units (basically, modification requests), and compared work units involving only 1 site and work units involving more than one site.  The work units that were multi-site took about 2.5 times as long than single-site work units.  We did a bunch of statistical analysis to rule out other explanations such as the thought that multi-site work items might be larger and therefore take longer, etc. We replicated the study on a completely different project and got essentially identical results.
The paper is here:
It doesn't involve agile teams -- these are fairly large projects using a more traditional spiral-type methodology.
If I think of other relevant studies, I'll pass them along.
Cheers,
Jim
 
Email from Jim Herbsleb 01 Aug 2008:
 
Single site just meant a single Lucent campus, each of which has multiple buildings.  Generally, though, for these projects, single site would mean same building, but I don't know if it is within Tom Allen's magic 30 meters.  Some campuses had cubicle farms, others had offices. None of them used team rooms.
Jim

 

Comments (0)

You don't have permission to comment on this page.