One of the tenets that agile pro­po­nents often tout as the best of the best is the team room. A team room is a cen­tral­ized loca­tion where the entire team works. Typ­i­cally, there are tons of white­boards around, a big space and the con­cept of per­sonal space is thrown out the win­dow if there hap­pens to be one nearby. The sup­posed ben­e­fits come from the high band­width com­mu­ni­ca­tion that a sit­u­a­tion like this fos­ters. No more does a team mem­ber have to wait to have his ques­tion answered via email or IM. He can just tap any­one on the shoul­der (or just stand up and announce his prob­lem) and presto, prob­lem solved by who­ever knows the answer.

There are about 40 things wrong with this sce­nario that seem to be typ­i­cally glossed over by the pro­po­nents of team rooms. The first, but cer­tainly 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 Man­i­festo. Pretty sure it’s not in Lean any­where. This site says pow­er­ful com­mu­ni­ca­tion is one of the seven core prin­ci­ples of agile man­age­ment and makes a huge gen­er­al­iza­tion that “The sin­gle most effec­tive means to com­mu­ni­cate pow­er­fully, is to put all the team in a room together where they can do their work, every day for the major­ity of the work time” but pro­vides no links or stud­ies to back up this rather extreme asser­tion. Over­all, hav­ing the team in a team room is at best, accord­ing to the links to the vari­ants of agile above, a minor bonus, not even impor­tant enough to write into the rules.

The sec­ond way that a team room is just wrong is the effect that noise and inter­rup­tion have on task com­ple­tion, specif­i­cally cog­ni­tive tasks like pro­gram­ming. Google “Effects of noise on task com­ple­tion” or “Effects of inter­rup­tions on task com­ple­tion” and take your pick of psy­cho­log­i­cal and soci­o­log­i­cal stud­ies of this on human per­for­mance. They are so preva­lent that you can even find free ones which is say­ing some­thing in the field of psy­cho­log­i­cal research. Even when you find one that sup­ports crazy ideas like “rad­i­cal colo­ca­tion” which I wrote about here, you find that the study involved quiet places where pro­gram­mers could go to actu­ally do, you know, REAL work. There just isn’t any evi­dence out there that team rooms actu­ally improve the code. There is anec­do­tal evi­dence that they improve the process that leads to the code but there is a MOUNTAIN of evi­dence that when the code has to be writ­ten, noise and inter­rup­tions lead to longer task com­ple­tion, greater num­bers of errors/bugs and higher frustration/annoyance by the subjects.

The third and final rea­son why team rooms suck is the fact that 50% of the time teams spend in the room involve non-work related issues rang­ing from dis­cus­sions of the hot chick in HR with the short skirt, dis­cus­sions 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 peo­ple 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 inter­rupt some­one, it is dif­fi­cult to not be interrupted.

All of this is brought on by this post (I’m sorry to keep pick­ing on Ken but he and I seem to have VASTLY dif­fer­ent ideas of how agile works. He’s far more expe­ri­enced than I am so I’m prob­a­bly wrong on every count but until I get some hard evi­dence of it, I’m going to keep spout­ing off). In it, he exam­ines the noise effect on teams and what that means for task com­ple­tion. His num­bers are

    Nor­mal 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 talk­ing about porn (ok I made that up but where else are the 65 hours going to go?)

One thing this analy­sis leaves aside is the fact that it took you 50% more time to do work that now con­tains a prob­a­ble fac­tor of 5 more bugs. Which means some­one has to find the bugs and fix the bugs. You took more time to write crap­pier code which surely can’t be looked favor­ably upon by agile pro­po­nents. On top of that, there is some evi­dence that you spend more time mod­i­fy­ing exist­ing code than you do on new code by a fac­tor of 10. Even if you believe that you wrote the same qual­ity of code in the 15 hours inter­rupted that you did in the 10 unin­ter­rupted, you’re going to spend 50 more hours mod­i­fy­ing it and debug­ging it. Like every­thing in life, you can’t just look at the pro side of things.

I don’t doubt that team rooms can work. The prob­lem is, they fail far more often than they suc­ceed for the same rea­son teams doing scrum fail far more than they suc­ceed. If you don’t imple­ment a team room or scrum per­fectly, they fail to deliver on the goods. If they aren’t imple­mented with a chance for quiet con­cen­tra­tion sep­a­rate from the team, if they don’t involve meta-XP rules like code stan­dards, pair pro­gram­ming, or con­tin­u­ous inte­gra­tion, they just aren’t going to do what you think they do. Just throw­ing a bunch of peo­ple in the same room together doesn’t do what you think it does. Like putting lip­stick on a pig, it’s a not a pret­tier pic­ture and you only stand to annoy the pig.

Fur­ther read­ing (as if you made it this far):
Hold­ing A Pro­gram In One’s Head
Atten­tion and Sex
Human Task Switches Con­sid­ered Harmful