Team Rooms Aren’t That Agile

One of the tenets that agile proponents often tout as the best of the best is the team room. A team room is a centralized location where the entire team works. Typically, there are tons of whiteboards around, a big space and the concept of personal space is thrown out the window if there happens to be one nearby. The supposed benefits come from the high bandwidth communication that a situation like this fosters. No more does a team member have to wait to have his question answered via email or IM. He can just tap anyone on the shoulder (or just stand up and announce his problem) and presto, problem solved by whoever knows the answer.

There are about 40 things wrong with this scenario that seem to be typically glossed over by the proponents of team rooms. The first, but certainly not the worst, is that it seems to be a myth that this is an agile tenet. It’s not found in Scrum. It’s not on the XP Rules page. I don’t see it in the Agile Manifesto. Pretty sure it’s not in Lean anywhere. This site says powerful communication is one of the seven core principles of agile management and makes a huge generalization that “The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time” but provides no links or studies to back up this rather extreme assertion. Overall, having the team in a team room is at best, according to the links to the variants of agile above, a minor bonus, not even important enough to write into the rules.

The second way that a team room is just wrong is the effect that noise and interruption have on task completion, specifically cognitive tasks like programming. Google “Effects of noise on task completion” or “Effects of interruptions on task completion” and take your pick of psychological and sociological studies of this on human performance. They are so prevalent that you can even find free ones which is saying something in the field of psychological research. Even when you find one that supports crazy ideas like “radical colocation” which I wrote about here, you find that the study involved quiet places where programmers could go to actually do, you know, REAL work. There just isn’t any evidence out there that team rooms actually improve the code. There is anecdotal evidence that they improve the process that leads to the code but there is a MOUNTAIN of evidence that when the code has to be written, noise and interruptions lead to longer task completion, greater numbers of errors/bugs and higher frustration/annoyance by the subjects.

The third and final reason why team rooms suck is the fact that 50% of the time teams spend in the room involve non-work related issues ranging from discussions of the hot chick in HR with the short skirt, discussions about guns/football/basketball/your mother and who to blame for the awful stench after the team went to Abuelo’s for lunch. Put 5 people in a room together and you don’t get 8 hours of work out of them. You get about 4 if you’re lucky because the other four are spent doing non-work related things. It’s just human nature. It’s also the nature of the beast because when it is easy to interrupt someone, it is difficult to not be interrupted.

All of this is brought on by this post (I’m sorry to keep picking on Ken but he and I seem to have VASTLY different ideas of how agile works. He’s far more experienced than I am so I’m probably wrong on every count but until I get some hard evidence of it, I’m going to keep spouting off). In it, he examines the noise effect on teams and what that means for task completion. His numbers are

Normal Project
• 90 hours spent in lag time (based on an unlinked study)
• 10 hours spent on real work

Project with a team room
• 15 hours spent on real work (the real work takes 50% more time in a noisy environment)
• 20 hours of lag time
• 65 hours talking about porn (ok I made that up but where else are the 65 hours going to go?)

One thing this analysis leaves aside is the fact that it took you 50% more time to do work that now contains a probable factor of 5 more bugs. Which means someone has to find the bugs and fix the bugs. You took more time to write crappier code which surely can’t be looked favorably upon by agile proponents. On top of that, there is some evidence that you spend more time modifying existing code than you do on new code by a factor of 10. Even if you believe that you wrote the same quality of code in the 15 hours interrupted that you did in the 10 uninterrupted, you’re going to spend 50 more hours modifying it and debugging it. Like everything in life, you can’t just look at the pro side of things.

I don’t doubt that team rooms can work. The problem is, they fail far more often than they succeed for the same reason teams doing scrum fail far more than they succeed. If you don’t implement a team room or scrum perfectly, they fail to deliver on the goods. If they aren’t implemented with a chance for quiet concentration separate from the team, if they don’t involve meta-XP rules like code standards, pair programming, or continuous integration, they just aren’t going to do what you think they do. Just throwing a bunch of people in the same room together doesn’t do what you think it does. Like putting lipstick on a pig, it’s a not a prettier picture and you only stand to annoy the pig.

Further reading (as if you made it this far):
Holding A Program In One’s Head
Attention and Sex
Human Task Switches Considered Harmful