Author, reviewer and revision dates:
Synonyms:
Abstract:
Problem:
Context:
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 subsolutions into an overall solution, the result doesn’t work because of unanticipated interactions.
For instance, suppose that a software development team is designing an inte-grated office support package. Independently, various teams or individuals de-sign various functions. Each of these may be well-designed in itself. However, the combination will be flawed on at least three counts. First, numerous func-tions will have been duplicated in separate modules. Second, some functionality that would have been useful for the whole package will not have been imple-mented 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 design-ers make independent choices about what the user experience will be. In addi-tion, it is quite likely that hard bugs will also be in the design due to the inconsis-tent 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 meet-ings 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:
Solution:
Examples:
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 be-fore the experience, people thought that they would hate working in a single room, afterwards they said they preferred it.
Resulting Context:
Rationale:
Related Patterns:
Known Uses:
References:
ź Olson and Olson
ź Biography of the Manhattan project
ź Other examples?
Created by John C. Thomas on 5th Sept., 2001
Reviewed by <
Revised by JCT on Dec. 17, 2001
“Put the team in one room for the duration of the project”, “War rooms”
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 refered to when necessary.
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 subsolutions.
In other cases, especially problems that are relatively novel, complex, or “wicked”, such decomposition is not possible. If a decomposition is attempted and each of the subproblems is solved, the resulting composition of subsolutions will 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.
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.
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 interruptability of others.
Having work-related shared artifacts that can be viewed and understood by oth-ers 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 subsolutions early will result in minimiz-ing 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 per-form better in the presence of others.
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 com-puter, 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.).
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.
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 guage 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 tradi-tional 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 arti-facts. Motivationally, it is also easier to see where the individual’s work fits into the larger whole.
In a complex problem solving process, it is most efficient to solve the most diffi-cult 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 inter-rupt 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.
Conversational Support at the Boundaries.
Who Speaks for Wolf?