Making Software

Work Patterns

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:

Pooled workflow

Involves tasks that aggregate individual performances to the group level. No interactions or exchanges between group members are required in this pattern.

Sequential workflow

Describes tasks that move from one member of the team to another but not in a back-and-forth manner.

Reciprocal workflow

Similar to sequential workflow in that work flows only from one member to another, but the flow is now bidirectional.

Intensive workflow

Work has the opportunity to flow between all members of the group, and the entire group must collaborate to accomplish the task.

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 ...