Tags
Business, collaboration, cooperation, Design, innovation, learning, pattern language, politics, science
Radical Collocation.
(This Pattern was initially inspired by a talk at CSCW 2000 — see reference — and the Socio-Technical Pattern Language Workshop at CSCW).
Author, reviewer and revision dates:
Created by John C. Thomas on 5th Sept., 2001.
Reviewed by <> on <>
Revised by JCT on Dec. 17, 2001, January 25, 2018.
Synonyms:
“Put the team in one room for the duration of the project”, “War rooms”
Abstract:
When small to medium teams of people need to solve a problem or design a novel solution and there are many highly interactive parts, it is useful for the people to work in one large room where people have easy access to each other and shared work objects can be easily viewed, modified, and referred to when necessary.
Problem:
Some problems are amenable to decomposition; that is, the overall problem can be broken down into a series of subproblems and when each of the subproblems is solved, the overall problem will be solved, possibly with slight modification to some of the sub-solutions. In other cases, especially problems that are relatively novel, complex, or “wicked”, such decomposition is not possible. In such cases, if a decomposition is attempted and each of the subproblems is solved, the resulting composition of sub-solutions will typically not be anything close to an overall solution. Under these circumstances, people working alone on their subproblem will become frustrated because all the progress they thought they had made will prove illusory. Morale will suffer. Management will become upset that the apparent progress has not been real and typically attempt a variety of counter-productive measures such as requiring more frequent reports and adding new personnel to meet a schedule.
Context:
In the design of complex systems with many interacting parts, it is often the case that understanding how best to “decompose” a problem cannot be determined ahead of time. Examples include complex software systems, especially where the overall system includes human-human and human-computer interaction, new machinery, novel nuclear power plant designs, complex military operations.
In such a context, handing out separate “assignments” to various individuals or small teams will at first seem to produce progress as each individual or small team carries out their assignment. Unfortunately, when an attempt is made to compose or integrate these sub-solutions into an overall solution, the result doesn’t work because of unanticipated interactions.
For instance, suppose that a software development team is designing an integrated office support package. Independently, various teams or individuals design various functions. Each of these may be well-designed in itself. However, the combination will be flawed on at least three counts. First, numerous functions will have been duplicated in separate modules. Second, some functionality that would have been useful for the whole package will not have been implemented at all because it would have been too much work for any one team. Third, the user experience will be scattered and inconsistent as separate designers make independent choices about what the user experience will be. In addition, it is quite likely that hard bugs will also be in the design due to the inconsistent treatment of data objects, deadlocks, infinite loops, etc.
There are two main general solutions common in the software development community. First, there may be an attempt to set “ground rules” or “style guides” that everyone is supposed to follow. These will help ameliorate the problem but cannot solve it entirely. Second, there may be overall project meetings where people report on progress or even do mutual design reviews. Again, this helps but even if problems are found and resolved, the resolution will re-quire considerable rework.
Forces:
*People are naturally gregarious.
*People can concentrate better on difficult mental tasks when it is quiet and when there are a minimum of interruptions.
*Some problems are amenable to decomposition into relatively independent sub-problems; others are not.
*Social cues can be used to guide the interruptibility of others.
*Having work-related shared artifacts that can be viewed and understood by others continually leads to productivity.
*Shuffling work artifacts in and out of view in a small space takes time.
*Space costs money and is therefore limited.
*A group will tend to develop useful social conventions when they are co-located.
*Noticing and resolving conflicts among sub-solutions early will result in minimizing rework.
*Noticing common problems and solving them collectively as soon as possible will result in maximum efficiency.
*Human performance often shows a “social facilitation” effect; that is, people perform better in the presence of others.
- The possibility of one person harming another and not doing so increases mutual trust.
- Shared experiences tend to increase mutual trust.
Solution:
When small to medium sized teams work on non-decomposable problems, it is useful for them to be radically co-located in one large room. This room should provide each person some private space and individual work tools (e.g., a computer, a drawing table) as well as numerous spaces for public display of large scale work artifacts (e.g., designs, work plans, diagrams, decisions, group rules, etc.).
Examples:
In the Manhattan Project, people from all over the country were relocated to a relatively remote and isolated area. There they had large workrooms to work on complex problems together.
Recently, automobile companies have empirically compared software work teams that were radically co-located with traditional software development and found the former to be significantly more productive. Interestingly, although before the experience, people thought that they would hate working in a single room, afterwards they said they preferred it.
Resulting Context:
Prior to the experiments at the auto companies, developers were afraid that they would be too distracted by noise and interruptions to get much work done. In fact, social cues can be read fairly well and a potential interrupter can gauge the time to interrupt. In radical co-location, a person might have to wait minutes or hours to resolve an issue by conversation and mutual problem solving. In traditional software development, they may have to wait for a weekly meeting or not discover a problem until integration testing. People working under conditions of radical co-location tend to develop common vocabulary and artifacts quickly and can easily and efficiently refer to these artifacts. Motivationally, it is also easier to see where the individual’s work fits into the larger whole. Having had many face to face interactions, the group now has more social capital.
Rationale:
In a complex problem solving process, it is most efficient to solve the most difficult constraints first. Similarly, the sooner potential design conflicts or potential design commonalities are discovered, the more efficient the global optimization. Social groups that work together can rely on subtle cues about whether to interrupt or not. Being alone in the office may seem more conducive to concentration but is still amenable to a knock on the door or a phone call; in this case, the per-son interrupting generally does not know the state of concentration of the person being interrupted. When we work separately, it is easy to imagine that others are “slacking off.” If we actually see all of our colleagues working, it tends to motivate us to work harder as well.
Related Patterns:
Conversational Support at the Boundaries.
Who Speaks for Wolf?
Known Uses:
War rooms, command centers, trials.
Metaphors:
The human body is mainly organized at one level into organs. These organs are generally completely co-located. Your brain cells are near other brain cells; spleen cells are near other spleen cells; bone cells are mainly near other brain cells. This is true in most (but not all) other species.
For many millennia, humans were hunter/gatherers. In some cases, our very distant ancestors may well have simply eaten “on the go” just as some of us still do off path-hugging berry bushes. But long ago, we gathered food, processed it, categorized it, re-shuffled it into various stews. All of these processes were typically done by a subgroup of the people. This co-work is at least one quite natural way to work.
Why is education arranged the way it is: into courses, lectures, topics, and so on? Why not just bombard kids with random facts from a computer? There are many reasons but one main one is that learning about a subject in a coherent way may help you see the larger coherence of the subject area.
Fable:
Once upon a time, there were three little lemur sisters and they each went to provide some shelter for themselves from the elements as well as protection from the ferocious leopards that roamed their forest. The first little lemur wanted her home to be as gigantic as possible. So, she fashioned some sticks and put them widely spaced over a large area. Unfortunately, the lemur had no trouble whatsoever going between these widely spaced sticks and he ate up the first little lemur.
The second little lemur, having learned from her sister’s unfortunate demise made a much, much tighter circle. In fact, her sticks were so tightly packed that she could not really lie down and sleep. After several days, she could stand it no longer so she went outside to hunt and sleep and was eaten by the roaming leopard.
The third little lemur, having learned from both of her two younger sisters’ untimely demises, instead struck a deal with the leopard. “You know,” said the lemur, “I can climb very high into the treetops. And from there, I can see for many miles around and advise you on your best direction for prey. In return, you don’t eat me. And, that would not be to your advantage anyway because then you’d have to revert to your old way of using guesswork to find prey.”
Instead of helping the leopard, the third little lemur used his high position to mislead the leopard and warn the prey through intermediaries. At last, the leopard grew quite weary and hungry and demanded to see the third little lemur about their deal.
“Sure, I’ll be right down!” The third little lemur had carried only a single stick up to his high nest. But he had sharpened with his teeth. She sprang upon the leopard jamming the spear deep into its soft underbelly.
The moral of the story is: if you combine the collective experiences of people with relevant knowledge and use creative problem solving, you’re likely to be able to solve any problem.
References:
Bos, N., Olson, J., Gergen, D., Olson, G. & Wright, Z. (2002) Effect of four computer-mediated communication channels on trust development, pp. 135-140. Proceedings of CHI 2002, New York: ACM.
Olson, G. & Olson, J. (2000) Distance matters. Human Computer Interaction. 15 (2,3), 139-178.
Teasley, S., Covi, L., Krishnan, M., & Olson, J. (2002). How does radical collocation help a team succeed? pp. 339-346. In Proceedings of CSCW 2000. New York: ACM.
petersironwood 