LockEmUpTogether
...you have an ArchitectureTeam to pull together the initial structure of the project, and need to get off top dead center and move toward production.
✥ ✥ ✥
A team of different people must come up with a single, coherent architecture.
A product needs a single architecture that is self-contained and consistent. But programmers have a (strong) tendency to work separately. Each person's design bears that person's unique signature; many people working on separate parts of an architecture will produce parts that do not necessarily work well together. Designs by committee usually look that way. You can allow a single person to create the architecture, but then not everybody will understand it (and follow it), and you are vulnerable to that person getting hit by a truck.
Therefore,
Gather everyone together to work out the architecture (or some other strategic issue). Put them all in the same room (literally.) Every person must commit to total participation until the architecture is complete enough that a clear picture has emerged.
There are two keys to this pattern. The first is that everyone must be physically together, in the spirit of FaceToFaceBeforeWorkingRemotely. This is necessary to ensure good communication at this critical time. Teleconferences are not sufficient.
The second key is that the architecture team must commit totally; the team members must be insulated from distractions and interrupts. In effect, a temporary organization is created for the architecture effort: previous responsibilities are suspended, and existing collaborations are broken for a time.
Both these keys are critical to provide continuity of ideas, so that the architecture can coalesce.
Note that like ArchitectureTeam, this work is only to create an initial architecture, resulting in a gross partitioning of the system.
✥ ✥ ✥
This pattern is superficially very similar to FaceToFaceBeforeWorkingRemotely, but they are essentially different, and both are vital. The purpose of FaceToFaceBeforeWorkingRemotely_ is the establishment of roles, allegiances, and building teams. The purpose of LockEmUpTogether is to hammer out technical issues. However, the two might happen at the same time.
This pattern works best when UnityOfPurpose is in effect, although the LockEmUpTogether patern can help achieve UnityOfPurpose.
Variants of LockEmUpTogether can bring teams together in other development phases, too. In Western Geco (a Schlumberger company) the development team sometimes spends days together in cramped quarters at their deployment site: a ship at sea. This experience inevitably helps team members to get to know each other better, and leads both to team binding and a binding between the team and its end-user constituency on the boat.
This approach also works well for other combinationss of constituencies: not only architects and coders, but architects and users, marketing folks and customers and end users, and so forth. This approach is central to Joint Application Development (JAD, [BibRef-Kendall2002], p. 132). See also ArchitectAlsoImplements.
PatronRole helps make this happen.
SmokeFilledRoom is a dark variant of this pattern.