InfoQ

News

Do Dedicated Team Rooms Make for More Productive Teams?

Posted by Ben Hughes on Dec 06, 2007 11:42 AM

Community
Agile
Topics
Agile in the Enterprise
Tags
Co-Located Teams
In the article posted in Science Daily, University of Michigan researchers found that teams working in a 'War Room' shared environment were up to twice as productive as those in a  non-colocated environment:
Teams of workers that labored together for several months in specially designed "war rooms" were twice as productive as their counterparts working in traditional office arrangements...
This sparked a Lean-Agile-Scrum thread discussion,some for and some against the concept. Jay Vandewark commented:
...one-room locations do have drawbacks and I believe that one-room locations are the weakest practice advocated by agilists.
However Ron Jeffries' viewpoint differs - stating:
My bottom line, though, is that I have observed the team room effect:
  • on my own teams;
  • on other people's teams;
  • in the literature;
and it is substantial enough to make me believe that it is by far one of the strongest of the Agile practices, not the weakest. Still needs to be tempered by other considerations, but it would be very unwise to dismiss it, in my opinion.
Are InfoQ readers thoughts on 'War Rooms'? Are they neccessary for a team that already buzzes? Indeed do InfoQ readers have any ideas about the layout of a room that fosters greater productivity? Take a look at the thread and post your comments below or on the thread.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Obstacles to war rooms by Bruce Rennie Posted Dec 6, 2007 2:11 PM
Turn it round, does separating a team make it more productive? by Frank Carver Posted Dec 6, 2007 3:16 PM
Re: Turn it round, does separating a team make it more productive? by Geoffrey Wiseman Posted Dec 19, 2007 2:51 PM
Context is everything by Deborah Hartmann Posted Dec 7, 2007 6:05 AM
War Room - blagh. by Adron Hall Posted Dec 11, 2007 6:35 PM
  1. Back to top

    Obstacles to war rooms

    Dec 6, 2007 2:11 PM by Bruce Rennie

    Besides the resistance of many developers, I found there are actually other significant obstacles to war rooms. I once asked my boss why we couldn't tear down our cubicles and build a nice, common war room environment. She responded that she'd be delighted to do so but: - Cubicles are actually pretty cheap, apparently. - Setting up a war room can actually cost more than cubicles for the same number of people, if you factor in buying extra whiteboards, re-arranging the environment, knocking down walls, etc. - Many offices just aren't war-room friendly. Still, I think one of the things that makes war rooms attractive is the simple fact that your company actually cares enough about your productivity to invest in your environment. It doesn't matter if you don't believe that war rooms are more productive, it's the mere fact that the company isn't stuffing you into a cubicle because "it's easier". I would say the same about a company that tailored hardware, tools, whatever, to a particular team. So, perhaps teams with war rooms succeed because they work in companies that support them rather than try to make them comply with accountant-driven ideas of the perfect work environment??

  2. This sort of question always seems strange to me. I have worked in software development for several different companies, of wildly differing sizes, since graduating in 1986. I have always worked with the development team (and often with non-development staff) in the same room. I've only ever seen "cubicles" in Dilbert. It just seems so much like common sense that working near to the people you are working with makes everything easier. So I have to ask, can anyone give any reasons why separating a team might make it more productive?

  3. Back to top

    Context is everything

    Dec 7, 2007 6:05 AM by Deborah Hartmann

    One reply to the original paper was:

    Even here at the U-M, many of the conversations that I have observed in shared offices are not work-related. I feel very strongly that the bullpen or war room would be a terrible work environment. In addition to the frequent distraction of non-work-related conversations, many people feel the need to play radios during business hours. Often, head phones are not adequate to insulate people who want to work in a quiet atmosphere. On a humanitarian basis, I urge these researchers to reconsider what they are advocating. Their next step should be to interview people who have worked in both war rooms and private offices or cubicles. I will be very surprised if they don’t find a strong worker preference for a private and quiet work space.
    Of course, Ron's comments would be in the context of XP. And XP is a set of patterns that work together synergistically. None of those patterns provide a place for unrelated work being done in the team room, imo. And those patterns usually also provide for space for private work, when needed. Experienced teams might have "team norms" as a pattern and "team turns cellphones off 10-4" and "have unrelated conversations outside" could be norms for one team, "no radios" could be agreed upon by another, if it's affecting one or more people's productivity. That is to say, the "continuous improvement" pattern (retrospectives, feedback) should allow for creating a better workspace, not just better software, since people create software and need to be treated well.

  4. Back to top

    War Room - blagh.

    Dec 11, 2007 6:35 PM by Adron Hall

    Having a war room isn't all that particularly helpful without XP. XP is the key... or more simply, a good team to start with. If you have a war room and a bad team that can't communicate it won't make a damn difference in the world to productivity. So any consideration of war rooms is really only practical if your team is very XP - or as I like to say, good friends. In that sense, I've seen teams work just as well in a bar, at a coffee shop, in a war room, separated in cubes, sitting at home 400+ miles apart. To summarize, the key isn't the war room, it is the team and the ability to communicate instantly. THAT is what does or does not make an environment helpful. Personally I like two environments... war rooms and at home. All others IMHO are kinda "meh".

  5. Sure - Joel Spolsky regularly argues that concentration is an important factor in software development, and that putting a software developer in any environment that reduces concentration is a bad idea, so he argues for individual offices.

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.