Team Rooms Increase Productivity

Today, I saw two very interesting things.  First, Peter pointed out that Channel 9 has a tour of the new p&p space.  (I know that I have mentioned the space at least three times in the past, but I'm still excited about it.  I'm excited not only by what I am doing and the people I work with, but also where I work.) Second, Mitch Lacey forwarded me an article that he found, entitled How does radical collocation help a team succeed? .   This article describes some research looking into team dynamics and productivity in a team room.  Here are a few interesting quotes from the article:

  • "Teams  in  these  warrooms  showed  a  doubling  of productivity.”
  • “A distance of 30 meters is equivalent to  being  truly  remote”
  • “Our study of six teams that experienced radical collocation showed  that  in  this  setting  they  produced  remarkable productivity improvements.  Although the teammates were not looking forward to working in close quarters, over time they realized the benefits of having people at hand, both for coordination, problem solving and learning.  They adapted to the  distractions  of  radical  collocation,  both  by  removing themselves  to  nearby  hotelling  areas  when  they  needed privacy, and by zoning out, made possible because of the distance between people in the larger rooms.”

I thought this was great information.

Now, the Channel 9 post has a number of comments already.  One of these comments (by DigitalDud) laments the loss of privacy for developers and says "Considering developers are going to be spending most of their time debugging, I'd say some privacy and the ability to shut off distractions is going to be pretty important."  Very rarely do I spend time in the debugger.  The way we work in the p&p team leads to very little time stepping though code.  We practice test driven development and we work together (most of the time) by pairing.  Today, I spent 30-40 minutes working with one of the other guys on my team, Matias, troubleshooting an ugly problem.  We spent a total of about 2 minutes in the debugger validating a few assumptions, and the rest of the time making changes to our unit test fixture in a effort to isolate the problem to a simple, repeatable case.  If we had relied soley on the debugger to solve this problem, we would still be working on it.  But, to address the rest of DigitalDud's concern, if we need to tune out the rest of the team, we can use headphones, go grab one of the private "Focus" rooms that are available, or use someone's office.  Also, once you've worked in a team space, you develop mental and auditory filters that help a lot too.