So what is going on? Paradoxically, we went through evidence in favor of isolation and individual offices, based on the principle that developers should be able to concentrate as much as possible, and then we switched to evidence in favor of collocation and shared spaces, based on the contrasting principle that developers should be able to coordinate as much as possible. Is one piece of evidence wrong?

Thinking in terms of work patterns might give us a clue to this puzzle. According to Tesluk et al., team workflow can be categorized in several levels, depending on the kinds of interaction that the team’s members need to engage in [Tesluk et al. 1997]. They offer the following classification:

Of course, this taxonomy is just an abstraction; it is unlikely that teams will fall strictly on only one category. Generally speaking, however, software projects tend to fall in the last two levels, although the exact slot for any one team depends on the specific processes and practices that it uses. There are very few software projects for which the pooled workflow or the sequential workflow patterns are feasible. (Pure waterfalls, which do not allow backtracking to the previous stages of the project, would be an example of sequential workflow.) But the reciprocal workflow pattern adjusts closely to real-life waterfall and spiral project life cycles, whereas the intensive workflow pattern matches Agile strategies much better.

This is important because, to the best of our knowledge, the need to coordinate on the spot is particularly present in teams with more intensive workflow patterns. In a comprehensive literature review, Beal et al. conclude that group cohesion and performance are strongly correlated for teams with complex workflow dynamics, but not necessarily for teams with a straightforward and simple workflow [Beal 2003].

Think about your last software project. Did the team members have a clear idea of the requirements and of what they needed to do individually? Did they know exactly who to go to in order to extract the information they needed? Did they have a clear picture of how their pieces matched with those of their teammates? Was there a repository of information that they could access to answer their questions, and was it useful? If so, workflow was more sequential, and there were fewer coordination demands in the team. If not, workflow was more intensive, and there were more coordination demands.

Here is an alternative way to look at this. Imagine you are part of a hypothetical project that does not have any clear requirements, just a broad idea of what the system should do. There is no clear end point either, just a commitment to keep delivering functionality to the clients as often as possible. Furthermore, you and your teammates don’t know each other very well; you have not worked together for an extended period before, and you are not familiar with everybody’s strengths and weaknesses. Now imagine the team members locking themselves away in their own private offices, in an environment that discourages all but the most essential interruptions. How could you get anything done in this setting?

Picture now the opposite case: the team has a pretty clear idea of what it needs to do, there is a comprehensive, beautifully crafted specification, everyone’s responsibilities are precisely delimited, and, thanks to careful planning, integration will probably not be a headache. If only you and your teammates could concentrate individually on your own tasks for a few hours a day, the project would proceed perfectly, but you are sitting in a large communal space where you’re interrupted and distracted all the time. How could you get anything done in this setting?

Unfortunately, research still has not provided a clear guideline to making a choice in the particular case of software development teams. The most we can get from the evidence so far is that both the Doors that Close and the Communal Workshop layouts can be beneficial if they are in agreement with the practices and the workstyle of the team. If you are committed to an intensive workflow (or if your context demands it), you should allow for intensive coordination, and if you prefer sequential or reciprocal workflows, you should enable developers to concentrate and depend on each other only through the necessary interfaces.