Study: Co-Located Teams vs. the Cubicle Farm

Posted by Deborah Hartmann Preuss on Oct 13, 2006

Sections

Process & Practices,

Architecture & Design

Topics

Offshoring ,

Teamwork ,

Stories & Case Studies ,

Business Models ,

Agile Techniques ,

Co-Located Teams ,

Statistics ,

Agile ,

Business ,

Distributed Team

New teams are always trying to figure out which of the basic Agile practices they can drop with impunity.  One that Agile coaches tend to stress as critical is co-location, but information to back this up has been largely anecdotal.  On the ScrumDevelopment list recently, Nicholas Cancelliere launched an interesting conversation by posting a link to this article [pdf], about a study comparing productivity gains in a "war room" style collaborative workspace versus a more traditional corporate cube-farm. 

The four authors, from University of Michigan and Rutgers University, reported, in a combination of case study and empirical evaluation, on research conducted at a Fortune 50 automobile company.  They ran a field study of six co-located teams, tracking their activity, attitudes, use of technology and productivity.  They compared their results with metrics collected on teams at the same company doing software development in the traditional office arrangement.  Since co-location does not work for every size of group, all projects were scoped to an estimated 4 months of work for a team of 6-8 people.  The writers admit that their study is "confounded" in that two variables were introduced: teams were co-located and scope was "timeboxed," which are two separate Agile strategies, though usually practiced together.  Most of the focus in this investigation was on the communication patterns of the individuals on the team.

So, what did they find?  Teams in these "war rooms" showed a doubling of productivity.  Factors identified as significant included: teams had easy access to each other for both coordination of their work and for learning, and the work artifacts they posted on the walls remained visible to all.

The original poster, Cancelliere, was looking for some advice for his own situation, and experienced practitioners like Pete Behrens, Ron Jeffries, Boris Gloger and others chimed in with ideas and experiences of their own. Here are some of the interesting hilights from the thread: (in approximately threaded order)

Ron Jeffries:

There needs to be provision for privacy, for calls about that disturbing rash, for example. Open rooms need to be inviting: windows and air and such are good for groups, not just high-status individuals.

I am strongly disinclined to force people to do anything, particularly not something that they might perceive as a loss in status. I'd be more inclined to make working in such a space be perceived as a privilege and a recognition that one is special...

aefager:

It just has to be as Ron says, "percieved as a privilege", rather than "percieved as a cheap alternative to cubicle walls"... When the server room and the call center have more elbow room than the development environment, it is not the kind of colocation that will benefit the company.

Jeffries:

I take your main point as being that with sufficient creativity, people can screw up even the best ideas. I fully agree.

Scrum Trainer, Pete Behrens:

I agree that any change this personal comes with both perceived and real loss that requires team ownership of the change and understanding of the benefits.

[Behrens goes on to tell how tries to create "safe" pilots that allow teams to explore co-location in an open environment to see results for themselves.] 

My findings, taken from survey feedback, show similar results to this study with respect to productivity, but also have shown an increase in software quality as well...  Our findings also showed that balancing individual's personal space with team space was critical. While a team-only space works for a short term, integrating personal space was required for maintaining for a longer period.

Practitioner and coach, Alex Pukinskis, whose team was considering a frequently-seen dilemma at that very moment:

We're wondering whether it makes sense to separate the teams physically. The different teams will probably be working on the same codebase - multiple teams drawing from the same backlog. I would love to hear suggestions about this; it seems tricky to decouple the teams entirely.

Various colleagues contributed ideas on this one... this list is a great place for both newbies and experienced practitioners to ask questions about applying Scrum in the real world.

As with all such interventions, common sense is a mandatory component of process change.  Behrens shared an example illustrating this:

In one case we moved a team 2 floors from their other related teams to create them a co-located space. While it increased the internal team's productivity and quality, it decreased the intra-team communication and cross-team dependencies were missed. Thus, it was determined that both inter- and intra-team co-location is important.

An interesting side note: the article writers quote a 1977 study which found that "A distance of 30 meters is equivalent to being truly remote" (Allen, T. J., 1977, see the article for the citation)  The researchers themselves deduced that "if we are to truly support remote teams, we should provide constant awareness and easy transitions in and out of spontaneous meetings."   Jeff Sutherland's SirsiDynix case study supports this, showing that even teams with significant off-shore components can achieve results comparable to a co-located team, if conscious and adequate compensation is made for the loss of high-bandwidth (face-to-face) communication.