Part 1. History and Introduction

Chapter 1. An Overview of Patterns and Organizational Patterns

1.1 What are Patterns?

1.2 What are Pattern Languages?

1.3 Organizational Pattern Languages

1.3.1 The Structure of Social Systems

1.3.2 The Multiple Structures of Social Systems

1.3.3 Pattern Languages and Sequences

Chapter 2. How the Patterns Came to Us

2.1 Gathering Organizational Data

2.1.1 Introspection In and Analysis of Organizations

2.1.2 Shortcomings of State of the Art

2.1.3 The CRC-Card Methodology

2.1.4 Analyzing Roles and Relationships

2.2 Creating Sequences

2.2.1 시퀀스가 중요한 이유

이 책에 있는 패턴 언어 자체는 정적이다. 조직은 항상 변화하고 있으며, 변화하는 방식을 항상 예측할 수 있지는 않다.

역동(dynamics)은 어디에서 왔는가?

역동은 패턴의 적용에서 온다. 그리고 패턴을 적용하는 순서에서 온다. 그렇다면, 올바른 순서는 무엇인가? 누군가는 패턴 사이의 구조적 관계를 따른다고 추측할 수 있다. 하지만 항상 그렇게 작동하는 것은 아니다.

ChristopherAlexander 는 모든 시스템의 질서는 근본적으로 시스템을 구축하는데 사용되는 프로세스에 달려 있다고 믿는다. 이것이 근본적인 프로세스(fundamental process)가 중요한 이유이다. (/PIECEMEAL GROWTH 참조)

각 단계의 구조를 유지하고, 점차적으로 지역적인 대칭을 추가하는 것이 중요하며, 조직은 시간이 지남에 따라 펼쳐진다. 피드백을 통한 step-by-step 적응이다. 패턴 언어를 따르는 것만으로는 피드백을 처리하는 방법에 대한 단서가 제공되지 않는다. 이것이 바로 근본 프로세스가 존재하는 이유이다. 설계 프로세스에 완전한 자유를 부여하여 시스템의 가장 취약한 부분을 공격할 수 있다.

그러나, 근본 프로세스는, 반드시 구축되어야 하는 몇 가지 센터들을 예견할 수 있는, 경험에 기반을 둔 어떠한 종류의 인지적인 가이드 없이는, 휴먼 스케일로는 동작할 수 없다. 그것이 바로 패턴이다.: 필수적인 중심들이다.

펼쳐짐이 중요하다면, 펼쳐지는 순서를 어떻게 알 수 있는가? 순서(sequence)는 중요하다. 아마도 부드럽고 구조적인 펼쳐짐을 원할 것이다. '조직 설계'처럼 느껴서는 안된다.

따라서, 시퀀스가 하는 일은:

• 구조를 보존한다;
• 한 번에 한 가지 일을 계속한다;
• 각 단계에서 전체 조직을 고려한다;
• 수만번 반복될 수 있다.

시퀀스는 항상 전체 조직의 맥락에서, 예측할 수 없고, 피드백을 통해 다루어야 하는 상황으로 당신을 데려간다.

시퀀스는 생성(generativity)이 시작되는 곳이다.

2.2.2 우리의 시퀀스들

우리는 여기에 각 패턴 언어에 대한 시퀀스를 만들었다. 이러한 각 시퀀스는 각 패턴 언어에 대해 가정할 수 있는 수백만 개의 시퀀스 중 하나이다. 패턴 언어 그래프에는 의미 있는 경로가 많이 있다.

시퀀스는 스토리로서 펼쳐지고, 이것이 우리가 시퀀스를 제시하는 방법이다. 이러한 "스토리"는 그것들이 참조하는 패턴 집합에 대한 온전성 검사이다. 이 패턴들이 정말로 함께 속한다면, 우리는 패턴들을 타고 흐르는 "스토리"를 생각해낼 수 있어야 한다. (그리고 이것이 꼭 패턴을 통과하는 시간적인 흐름일 필요는 없다는 것을 기억하라) 패턴이 있는 곳에 잘 맞지 않거나, 그룹에 전혀 맞지 않는 패턴을 지적할 수 있다. 책의 이야기를 패턴이 함께 작동하는 방식을 설명하는데 사용할 수도 있다. 책에서 다음 순서를 보라.

• 프로젝트 관리에 대한 이야기 (4.1 프로젝트 관리 패턴 언어)
• 점진적 성장에 대한 이야기 (4.2 점진적 성장 패턴 언어)
• 조직 스타일에 대한 이야기 (5.1 조직 스타일 패턴 언어)
• 사람과 코드에 대한 이야기 (5.2 사람과 코드 패턴 언어)

이러한 시퀀스는 실제이다; 그것들은 우리의 경험에서 비롯되었으며, 우리는 패턴이 서로를 형성하는 풍부한 방식과, 언어가 살아남는 방식을 대표한다고 생각했다. 물론 각각의 케이스 스터디들은 그것을 위해 작성된 시퀀스를 가질 수도 있다. 각 시퀀스는 자체적으로 작은 언어를 형성하는 패턴을 선택한다. 이 언어는 조직의 문화를 설명한다.

2.3 History and Related Work

Chapter 3. How to Use This Book

3.1 Reading the Patterns

3.1.1 The Form

3.1.2 Understanding the Models Behind the Patterns

3.1.3 Stories and Pictures in the Patterns

3.1.4 Finding your Way

3.2 Applying the Patterns

3.2.1 Sequences

3.2.2 Which Patterns?

3.2.3 Human Concerns

3.3 Updating the Patterns

3.4 Who Should Use This Book?

Part 2. The Pattern Languages

Chapter 4. Organization Design Patterns

4.1 Project Management Pattern Language

• 4.1.1 /Community of Trust:

  • 인간 조직을 구축하고 있다면: 성장을 지속할 수 있을 만큼 깊은 수준에서 효과적인 의사 소통에 대한 신뢰와 존중의 기초를 가져야 한다.
  • If you are building any human organization, Then: you must have a foundation of trust and respect for effective communication at levels deep enough to sustain growth.

• 4.1.2 /Size the Schedule:

  • 일정이 너무 길면 개발자는 안주하게 된다; 그러나 너무 짧으면 과도한 부담이 된다. 따라서 일정을 맞추고 보상을 받고, 두 세트의 책을 보관하라.
  • If the schedule is too long, developers become complacent; but if it is too short, they become overtaxed. Therefore: reward meeting the schedule, and keep two sets of books.

• 4.1.3 /Get on With It:

  • 프로젝트를 시작하고 일부를 시작하기에 충분한 정보가 있는 경우: 프로젝트의 일부를 시작하기 전에 완전한 일정이 될 때까지 기다리지 말라.
  • If you are starting a project and have enough information to get started on parts of it, Then: don’t wait until you have a complete schedule before starting to do parts of the project.

• 4.1.4 /Named Stable Bases:

  • 안정성과 진보의 균형을 맞추고 싶다면: 사람들이 작업할 수 있는, 명명된 안정된 기반의 계층 구조를 만들라.
  • If you want to balance stability with progress, Then: have a hierarchy of named stable bases that people can work against.

• 4.1.5 /Incremental Integration:

  • 개발자가 변경사항을 게시하기 전에 테스트할 수 있도록 하려면: 개발자가 전체 제품 코드를 독립적으로 빌드하여 최신 베이스(최신의 명명된 안정 베이스가 아닌)로 테스트할 수 있도록 허용하라.
  • If you want developers to be able to test changes before publishing them, Then: allow developers to build the entire product code independently to allow testing with the very latest base (not the latest Named Stable Base).

• 4.1.6 /Private World:

  • 개발자를 변경의 영향으로부터 격리하려면: 개발자가 전체 빌드 환경을 포함하는 개인 작업 공간을 가지도록 허용하라.
  • If you want to isolate developers from the effects of changes, Then: allow developers to have private work spaces containing the entire build environment.

• 4.1.7 /Build Prototypes:

  • 초기에 획득한 요구사항을 테스트 없이 검증하기 어렵다면: 요구사항을 이해하는 것이 목적인 프로토타입을 만들라.
  • If early acquired requirements are difficult to validate without testing, Then: build a prototype, whose purpose is to understand requirements.

• 4.1.8 /Surrogate Customer

• 4.1.9 /Take No Small Slips:

  • 일정이 늦춰지고 추가 시간 자원이 필요하다면: 작고 예기치 못한 여러 지연들로 당신을 하찮게 만들어 죽음에 이르게 하는 대신, 하나의 크고 계획된 일정지연(slip)을 가져라.
  • If you are getting behind schedule and need additional time resources, Then: take one large planned slip instead of allowing yourself to nickel and dime yourself to death with small, unanticipated slips.

• 4.1.10 /Completion Headroom:

  • 일련의 중요한 일정들에 대해 작업이 진행중이라면: 가장 큰 작업의 완료 날짜와 중요한 배포 일자 사이에 /Completion Headroom이 있는지 확인하라.

  • If work is progressing against a set of hard dates, Then: make sure there is COMPLETION HEADROOM (4.1.10) between the completion dates of the largest task and the hard delivery dates.

• 4.1.11 /Work Split:

  • 문제에 너무 가까이에 있는 사람들이 "돼지 통" 문제나 선의의 문제로 문제를 확대하는 경우: 작업을 긴급 및 지연된 구성 요소로 나누고, 긴급한 작업에 개발 작업의 절반 미만이 투입되도록 하라.
  • If people too close to the problem are escalating their problems, either as a “pork barrel” issue or as something well-intentioned, Then: split work into an urgent and deferred component, with less than half of development work in the urgent half.

• 4.1.12 /Recommitment Meeting:

  • If: the schedule can’t be met with simple adjustments to the work queue and staffing, Then: assemble developers and interested managers to recommit to a new strategy based on doing the minimal amount of work to reach a satisfactory conclusion

• 4.1.13 /Work Queue:

  • If deliverables are ill-defined, you need to allow time to do everything. Therefore: produce a schedule with less output than you have input. Use the list of IMPLIED REQUIREMENTS (4.1.16) (really just names) as a starting point and order them into a likely implementation order favoring the more urgent or higher priority items.

• 4.1.14 /Informal Labor Plan:

  • If developers need to do the most important thing now, Then: let developers negotiate among themselves or “just figure out the right thing to do” as regards short term plans, instead of master planning.

• 4.1.15 /Development Episode:

  • If we overemphasize individual contributor skills, work suffers. Therefore: approach all development as a group activity as if no one had anything else to do.

• 4.1.16 /Implied Requirements:

  • If you need a way to nail down the functionality that needs to be covered, Then: make a list of functional areas and domains instead of breaking it down into traditional requirements.

• 4.1.17 /Developer Controls Process:

  • If you need to orchestrate the activities of a given location or feature, Then: put the Developer role in control of the succession of activities.

• 4.1.18 /Work Flows Inward:

  • If you want information to flow to the producing roles in an organization, Then: put the developer at the center and see that information flows toward the center, not from the center.

• 4.1.19 /Programming Episode:

  • If you need to split up work across time, Then: do the work in discrete episodes with mind share to commit to concrete deliverables.

• 4.1.20 /Someone Always Makes Progress:

  • If Distractions constantly interrupt your team’s progress, Then: whatever happens, ensure someone keeps moving toward your primary goal.

• 4.1.21 /Team per Task:

  • If a big diversion hits your team, Then: let a sub-team handle the diversion, the main team keeps going.

• 4.1.22 /Sacrifice One Person:

  • If a smaller diversion hits your team, Then: assign just one person to it until it gets handled.

• 4.1.23 /Day Care:

  • If your experts are spending all their time mentoring novices, Then: put one expert in charge of all the novices, let the others develop the system.

• 4.1.24 /Mercenary Analyst:

  • If you want to keep documentation from being a critical path roadblock for developers, Then: hire a MERCENARY ANALYST.

• 4.1.25 /Interrupts Unjam Blocking:

  • If you need to schedule urgent development activities according to some reasonable priority scheme, Then: use an interrupt scheme to keep individual problems from blocking the entire project.

• 4.1.26 /Don't Interrupt an Interrupt:

  • If you’re in the middle of handling an interrupt to keep the project from getting stuck, and a new urgent need arises, Then: continue handling the current issue before moving on to the new one.

4.2 Piecemeal Growth Pattern Language

• 4.2.1 /Community of Trust

• 4.2.2 /Size the Organization:

  • If an organization is too large, communications break down, and if it is too small, it can’t achieve its goals or easily overcome the difficulties of adding more people. Therefore: start projects with a critical mass of about 10 people.

• 4.2.3 /Phasing it in:

  • If you can’t always get the experts you need, Then: grow new experts from new hires.

• 4.2.4 /Apprenticeship:

  • If you have difficulty retaining expertise, Then: grow expertise internally from existing employees or even new hires.

• 4.2.5 /Solo Virtuoso:

  • If a project is intellectually small, then overstaffing it is a waste of time and money. Therefore: staff small projects with SOLO VIRTUOSOS.

• 4.2.6 /Engage Customers:

  • If you want to manage an incremental process that accommodates customer input, and if you want the customer to feel loved, Then: engage customers after Quality Assurance and project management are prepared to serve them.

• 4.2.7 /Surrogate Customer:

  • If you need answers from your customer, but no customer is available to answer your questions, Then: create a surrogate customer role in your organization to play advocate for the customer.

• 4.2.8 /Scenarios Define Problem:

  • If you want a good characterization of customer needs, Then: use scenarios to define the problem.

• 4.2.9 /Fire Walls:

  • If you want to keep your developers from being interrupted by extraneous influences and special interest groups, Then: impose a Fire Wall, such as a manager, who “keeps the pests away.”

• 4.2.10 /Gate Keeper:

  • If you need to keep from being inbred, Then: use a GATE KEEPER (4.2.10) role to tie together development with other projects, with research, and the outside world.

• 4.2.11 /Self Selecting Team:

  • If you appoint people to a team, it doesn’t come together as a team. But people with outside interests and who wish to joint a team make the best team members. Therefore: teams should be largely self-selecting with limited screening on the basis of track record and outside interests.

• 4.2.12 /Unity of Purpose:

  • If a team is beginning to work together, Then: make sure all members agree on the purpose of the team.

• 4.2.13 /Team Pride:

  • If a team needs to perform above and beyond the call of duty, Then: instill a well-grounded sense of elitism in its members.

• 4.2.14 /Skunk Works:

  • If a project innovates too much, then it increases its risk; yet there is a place for innovation. Therefore: give innovation an organizational space and time.

• 4.2.15 /Patron Role:

  • If you need to insulate Developers so DEVELOPER CONTROLS PROCESS (4.1.17) and provide some organizational inertia at the strategic level, Then: identify a patron to whom the project has access, who can champion the cause of the project.

• 4.2.16 /Diverse Groups:

  • If everyone has similar views, you have a good team, but too much normalization leaves important problem areas unaddressed. Therefore: assemble a diverse team, based on different experiences, cultures, and genders.

• 4.2.17 /Public Character:

  • If you need a catalyst to bring people together, Then: recognize some roles as PUBLIC CHARACTERS.

• 4.2.18 /Matron Role:

  • If your team needs ongoing care and feeding, Then: include a Matron in the team who will naturally take care of social needs of the team.

• 4.2.19 /Holistic Diversity:

  • If Development of a subsystem needs many skills, but people specialize, Then: create a single team from multiple specialties.

• 4.2.20 /Legend Role:

  • If a key person will leave the organization soon, Then: train a key replacement, and have them assume a role named after the key person.

• 4.2.21 /Wise Fool:

  • If critical issues do not get aired easily, Then: nurture a Wise Fool to say the things nobody else dares say.

• 4.2.22 /Domain Experties in Roles:

  • If you need to staff all roles, it’s difficult to determine how to match people to roles to optimize communication. Therefore: match people to roles based on domain expertise, and emphasize that people play those roles in the organization.

• 4.2.23 /Subsystem by Skill:

  • If you need to organize subsystems for the long haul, Then: divide them up by skills.

• 4.2.24 /Moderate Truck Number:

  • If you can’t eliminate having a single point of failure in allocating expertise to roles, Then: spread expertise as far as possible, but not more so.

• 4.2.25 /Compensate Success:

  • If enterprises are to succeed, they must reward the behaviors that portend for success; but, these behaviors are varied, and success is difficult to measure. Therefore: establish a spectrum of reward mechanisms that reward both teams and individuals.

• 4.2.26 /Failed Project Wake:

  • If people have put their hearts and souls into a project, only to have it canceled, Then: celebrate its demise; hold a “wake” for it.

• 4.2.27 /Don't Interrupt an Interrupt

• 4.2.28 /Developing in Pairs:

  • If you want to improve the effectiveness of individual developers, Then: have people develop in pairs.

• 4.2.29 /Engage Quality Assurance:

  • If developers can’t be counted on to test beyond what they already anticipate what might go wrong, Then: engage Quality Assurance as an important function.

• 4.2.30 /Application Design is Bounded by Test Design:

  • If you want to organize the interworking between test developers and software developers, Then: organize the process so APPLICATION DESIGN IS BOUNDED BY TEST DESIGN.

• 4.2.31 /Mercenary Analyst

• 4.2.32 /Group Validation:

  • If you want to avoid being blindsided in quality assurance, Then: ENGAGE CUSTOMERS (4.2.6) and DEVELOPING IN PAIRS (4.2.28) and others to validate the system.

Chapter 5. Organization Construction Patterns

5.1 Organizational Style Pattern Language

• 5.1.1 /Community of Trust

• 5.1.2 /Few Rules:

  • If your organization has high communication overhead and latency, Then: identify the roles in the organization, and keep the number of roles to sixteen or fewer.

• 5.1.3 /Producer Roles:

  • If your organization has too many roles, but does not know which to eliminate, Then: identify roles as Producers, Supporters, or Deadbeats; eliminate the Deadbeats, and combine some of the Supporters.

• 5.1.4 /Producers in the Middle:

  • If your developers are somewhat lost, Then: make sure the producer roles are at the center of all communication.

• 5.1.5 /Stable Roles:

  • If you have to deal with project disruptions, Then: keep people in their primary roles, and deal with disruptions as temporary tasks.

• 5.1.6 /Divide and Conquer:

  • If an organization is getting too large for communications to be effective any more, Then: try partitioning it along lines of mutual interest and coupling, forming a separate organization and process.

• 5.1.7 /Conway's Law:

  • If organization structuring concerns are torn between geography, expertise, politics, and other factors, Then: align the primary organizational structuring with the structure of the business domains, the structure that will be reflected in the product architecture.

• 5.1.8 /Organization Follows Location:

  • If you need to distribute work geographically, communications suffer, but you can limit the damage if work is partitionable. Therefore: organize work at locations so groups of people that work together are at the same location.

• 5.1.9 /Organization Follows Market:

  • If there is no clear organizational accountability to a market, Then: make some organization accountable for the market to assure that the market’s needs will be met.

• 5.1.10 /Face to Face Before Working Remotely:

  • If a project is divided geographically, Then: begin the project with a meeting of everyone in a single place.

• 5.1.11 /Form Follows Function:

  • If there is little specialization, and people don’t know where to turn for answers to technical questions, Then: Create domains of expertise called roles that cluster around artifacts or specialization.

• 5.1.12 /Shaping Circulation Realms:

  • If you need mechanisms to facilitate the communication structures necessary for good group formation, Then: shape circulation realms.

• 5.1.13 /Distribute Work Evenly:

  • If you want to optimize utilization of human resources, Then: alleviate hot spots of overload on specific groups and individuals in your organization by Distributing Work Evenly

• 5.1.14 /Responsibilities Engage:

  • If central roles are overloaded but you don’t want to take them out of the communication loop Then: intensify communication more among non-central roles to lighten the load on the central roles

• 5.1.15 /Hallway Chatter:

  • If developers tend to huddle around the organizational core or supporting roles are inadequately engaged with each other, Then: rearrange responsibilities in a way that encourages less isolation and more interworking among roles and people.

• 5.1.16 /Decouple Stages:

  • If stages are too interleaved for the good of some high-context development where phases can be separated to increase parallelism, Then: serialize process steps, with well-defined hand-offs between steps.

• 5.1.17 /Hub Spoke and Rim:

  • If you want to DECOUPLE STAGES in a high-context development process, Then: orchestrate the process with a hub role, and minimize coupling between other roles, in a hub-spoke-and-rim geometry.

• 5.1.18 /Move Responsibilities:

  • If you want to change coupling between roles (particularly if you want to decouple roles), Then: move responsibilities from one role to another.

• 5.1.19 /Upside Down Matrix Management:

  • If the right skills and resources don’t seem to be applied to a particular aspect of the work, Then: go beyond corporate structures to leverage teams in other organizations (customer, partners, other internal organizations)

• 5.1.20 /The Water Cooler:

  • If you need more communication between institutionalized organizations, Then: leave space for everyday human activities at the workplace that can provide more complete and informal communication

• 5.1.21 /Three to Seven Helpers oer Role:

  • If you want to even out communication, Then: at least try to limit communication to THREE TO SEVEN HELPERS PER ROLE, and to pull up the outliers to the same level of engagement.

• 5.1.22 /Coupling Decreases Latency:

  • If you need a high throughput development process, Then: increase coupling between roles to decrease latency.

• 5.1.23 /Standards Linking Locations

5.2 People and Code Pattern Language

• 5.2.1 /Community of Trust

• 5.2.2 /Conway's Law

• 5.2.3 /Architect Controls Product:

  • If a project has a long life, Then: use the architect to carry the vision forward and serve as the long-term keeper of architectural style.

• 5.2.4 /Architecture Team:

  • If you are building a system too large or complex to be thoroughly understood by a single individual, Then build a team that has both the responsibility and the power to create the architecture.

• 5.2.5 /Lock'em Up Together:

  • If your team is struggling to come up with an architecture, Then: isolate them physically for several days where they can work uninterrupted.

• 5.2.6 /Smoke Filled Room:

  • If you need to make a decision quickly and there are reasons to exclude others, Then: make the decision covertly so that the rationale remains private, though the decision will be publicized.

• 5.2.7 /Stand Up Meeting:

  • If there are pockets of misinformation or people out of the loop: Then: hold short daily meetings to socialize emerging developments.

• 5.2.8 /Deploy Along the Grain:

  • If reuse is suffering from fragmentation of responsibilities for an artifact, Then: give people dedicated, long term responsibility for a management piece of the system.

• 5.2.9 /Subsystem by Skill

• 5.2.10 /Architect Also Implements:

  • If an architect is on an ivory tower, they are out of touch; yet someone needs to take the big and long view and reconcile it with practice. Therefore: the architect is materially involved in day-to-day implementation.

• 5.2.11 /Generics and Specifics:

  • If you have many new people, Then: put the experienced people on generic parts of the work, and give specific assignments to the new people.

• 5.2.12 /Standards Linking Locations:

  • If you have geographically separated development, Then: use standards to link together parts of the architecture that cross geographic boundaries.

• 5.2.13 /Code Ownership:

  • If you need responsibility for code and want to build on DOMAIN EXPERTISE IN ROLES (4.2.22), Then: give various individuals responsibility for the overall quality of the code.

• 5.2.14 /Feature Assignment:

  • If you are trying to partition work in a large project, Then: make assignments of features to people.

• 5.2.15 /Variation Behind Interface:

  • If more than one person is developing software, then changes affect not only the code, but people as well. Therefore: create interfaces around predicted points of variation.

• 5.2.16 /Private Versioning:

  • If you want to enable incremental changes without publishing them, Then: set up a mechanism for developers to version code without checking it in to a public repository.

• 5.2.17 /Loose Interfaces:

  • If you need to develop systems rapidly in an environment where communication is less than optimal, Then: limit the number of explicit, static, interfaces. Use loose interfaces like callbacks.

• 5.2.18 /Subclass per Team:

  • If subsystem teams have different Design points, Then: where two subsystems collide in one class, assign them to different layers of the class hierarchy.

• 5.2.19 /Hierarchy of Factories:

  • If you have a creational system which creates different products specified by different groups, Then: set up factories in a hierarchical arrangement, where each knows about 1 level below only.

• 5.2.20 /Parser Builder:

  • If you need you create objects based on type information in an input stream, Then: use a parser builder which reads type information from the stream and builds the appropriate objects based on this information.

• 5.2.21 /Incremental Integration

• 5.2.22 /Private World

• 5.2.23 /Named Stable Bases

Part 3. Foundations and History

Chapter 6. Organizational Principles

6.1 Priming the Organization for Change

6.1.1 Dissonance Precedes Resolution

6.1.2. Team Burnout

6.1.3 Stability and Crisis Management

6.1.4 The Open Closed Principle of Teams

6.1.5 Team Building

6.1.6 Building on the Solid Core

6.2 Piecemeal Growth

6.2.1 The Foundamental Process

6.2.2 When do I apply these patterns?

6.2.3 Writing your own patterns

6.2.4 Master Planning and the Theory of Constraints

6.2.5 Communication and Organizational Learning

6.3 Some General Rules

6.3.1 Make Love not War

6.3.2 Organizational Patterns are Inspiration Rather than Prescription

6.3.3 It Depends on Your Role in Your Organization

6.3.4 It Depends on the Context of the Organization

6.3.5 Organizational Patterns are Used by Groups Rather than Individuals

6.3.6 People are Less Predictable than Code

6.3.7 The Role of Management

Chapter 7. Anthropological Foundations

7.1 Patterns in Anthropology

7.2 Beyond Process to Structure and Values

7.2.1 The Shortcomings of Process

7.2.2 Structure

7.2.3 Values: The Human Element

7.3 Roles and Communication

=== 7.4 Social Network Analysis

=== 7.5 Distilling the Patterns

7.5.1 CRC-Cards and Roles

7.5.2 Social Network Theory Foundations

7.5.3 Scatterplots are Patterns

Part 4. Case Studies

Chapter 8. Borland Quattro Pro for Windows

Chapter 9. A Hyperproductive Telecommunications Development Team

Part 5. Appendices

Chapter 10. Summary Patlets

10.1 Project Management Patlets

10.2 Piecemeal Growth Patlets

10.3 Organizational Style Patlets

10.4 People and Code Patlets

10.5 Patlets from Other Pattern Languages

• 10.5.1 /Arranging the Furniture

• 10.5.2 /Ad-Hoc Corrections

• 10.5.3 /All At Once

• 10.5.4 /Architecture Definition Team

• 10.5.5 /Balanced Team

• 10.5.6 /Business Process Model

• 10.5.7 /Clear The Fog

• 10.5.8 /Creator-Reviewer

• 10.5.9 /Demo Prep

• 10.5.10 /Designer are Our Friends

• 10.5.11 /Early and Regular Delivery

• 10.5.12 /Establish the Business Objectives

• 10.5.13 /Get Involved Early

• 10.5.14 /Gradual Stiffening

• 10.5.15 /Guru Does All

• 10.5.16 /Market Walk-through

• 10.5.17 /Master-Journeyman

• 10.5.18 /Micro Cosm

• 10.5.19 /Owner Per Deliverable

• 10.5.20 /Participating Audience

• 10.5.21 /Peace Maker

• 10.5.22 /Product Initiative

• 10.5.23 /Proto Types

• 10.5.24 /Query Objects

• 10.5.25 /Shared Clear Vision

• 10.5.26 /Shearing Layers

• 10.5.27 /Small Writing Team

• 10.5.28 /Skill Mix

• 10.5.29 /Work Allocation