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.