Search this site
Embedded Files
Scrum Pattern Group
  • Scrum PLoP
    • Scrum Tulip PLoP 2021 - Enkhuizen Netherlands
    • Scrum PLoP 2019
    • Scrum PLoP 2018, Quinta da Pacheca, Portugal
    • ScrumPLoP 2017, Quinta da Pacheca, Portugal
    • ScrumPLoP 2016, Porto, Portugal
    • ScrumPLoP 2015, Porto, Portugal
    • ScrumPLoP 2014, Helsingør, Denmark
    • ScrumPLoP 2013, Helsingør, Denmark
    • ScrumPLoP 2012, Helsingør, Denmark
    • ScrumPLoP 2011, Helsingør, Denmark
    • ScrumPLoP 2010, Stora Nyteboda, Sweden
  • Original Org Patterns Site
    • Organizational Patterns of Agile Software Development
      • Book Outline
        • Preface
        • History and Introduction
          • An Overview of Patterns and Organizational Patterns
          • What Are Patterns?
          • What Are Pattern Languages?
          • Organizational Pattern Languages
          • How the Patterns Came to Us
          • Gathering Organizational Data
          • Creating Sequences
          • History and Related Work
          • Introspection and Analysis of Organizations
          • Shortcomings of State of the Art
          • Analyzing Roles and Relationships
          • How to Use this Book
          • Reading the Patterns
          • Applying the Patterns
          • Updating the Patterns
          • Who Should Use This Book?
          • Size the Organization
          • The CRC-Card Methodology
        • The Pattern Languages
        • Organizational Design Patterns
          • Project Management Pattern Language
          • Community of Trust
          • Size the Schedule
          • Get On With It
          • Named Stable Bases
          • Incremental Integration
          • Private World
          • Build Prototypes
          • Take No Small Slips
          • Completion Headroom
          • Work Split
          • Recommitment Meeting
          • Work Queue
          • Informal Labor Plan
          • Development Episode
          • Implied Requirements
          • Developer Controls Process
          • Work Flows Inward
          • Programming Episode
          • Someone Always Makes Progress
          • Team per Task
          • Sacrifice One Person
          • Day Care
          • Mercenary Analyst
          • Interrupts Unjam Blocking
          • Don't Interrupt an Interrupt'
          • Piecemeal Growth Pattern Language
          • Size the Organization
          • Phasing It In
          • Apprenticeship
          • Solo Virtuoso
          • Engage Customers
          • Surrogate Customer
          • Scenarios Define Problem
          • Firewalls
          • Gatekeeper
          • Self-Selecting Team
          • Unity of Purpose
          • Team Pride
          • Skunkworks
          • Patron Role
          • Diverse Groups
          • Public Character
          • Matron Role
          • Holistic Diversity
          • Legend Role
          • Wise Fool
          • Domain Expertise in Roles
          • Subsystem by Skill
          • Moderate Truck Number
          • Compensate Success
          • Failed Project Wake
          • Developing in Pairs
          • Developing in Pairs
          • Engage Quality Assurance
          • Application Design is Bounded by Test Design
          • Group Validation
        • Organization Construction Patterns
          • Organizational Style Pattern Language
          • Few Roles
          • Producer Roles
          • Producers in the Middle
          • Stable Roles
          • Divide and Conquer
          • Conway's Law
          • Organization Follows Location
          • Organization Follows Market
          • Face-to-Face Before Working Remotely
          • Form Follows Function
          • Shaping Circulation Realms
          • Distribute Work Evenly
          • Responsibilities Engage
          • Hallway Chatter
          • Decouple Stages
          • Hub Spoke and Rim
          • Move Responsibilities
          • Upside-Down Matrix Management
          • The Water Cooler
          • Three to Seven Helpers per Role
          • Coupling Decreases Latency
          • People and Code Pattern Language
          • Architect Controls Product
          • Architecture Team
          • Lock 'Em Up Together
          • Smoke Filled Room
          • Stand Up Meeting
          • Deploy Along the Grain
          • Architect Also Implements
          • Generics and Specifics
          • Standards Linking Locations
          • Code Ownership
          • Feature Assignment
          • Variation Behind Interface
          • Private Versioning
          • Loose Interfaces
          • Subclass Per Team
          • Hierarchy of Factories
          • Parser Builder
        • Foundations and History
          • Organizational Principles
          • Priming the Organization for Change
          • Dissonance Precedes Resolution
          • Team Burnout
          • Stability and Crisis Management
          • The Open-Closed Principle of Teams
          • Team Building
          • Building on the Solid Core
          • Piecemeal Growth
          • Some General Rules
          • Make Love Not War
          • Organizational Patterns are Inspiration Rather Than Prescription
          • It Depends on Your Role in Your Organization
          • It Depends on the Context of the Organization
          • Organizational Patterns are Used by Groups Rather Than Individuals
          • People are Less Predictable than Code
          • The Role of Management
          • Anthropological Foundations
          • Patterns in Anthropology
          • Beyond Process to Structure and Values
          • Roles and Communication
          • Social Network Analysis
          • Distilling the Patterns
          • CRC Cards and Roles
          • Social Network Theory Foundations
          • Scatterplots and Patterns
        • Case Studies
          • Borland QuattroPro for Windows
          • A Hyperproductive Telecommunications Development Team
      • Appendices
        • Summary Patlets
        • Organization Book Patlets
        • Bibliography
        • Photo Credits
      • Mysteriously Missing
      • Supporting Pages
        • Common Pattern Language
        • Organizational Patterns
        • Diversity of Membership
  • Original Scrum Patterns Site Archive
    • Scrum as Organizational Patterns
    • Scrum Patterns Summary
    • Software Scrum Patterns
    • First-Level Scrum Patterns
  • The ScrumPLoP Mission
  • What is a PLoP?
Scrum Pattern Group

Hallway Chatter


One day a friend came into my office. She was pretty depressed about her project. She was in a test group, and their group was essentially shut off from the rest of the project. They didn't get timely information about what was happening; they didn't hear the latest project gossip. The only people they could talk to were each other. "I know what your problem is," I said. "You have schismogenesis." Her situation was the most striking example I had ever seen. She went on to other projects, so I didn't find out what ever happened with the organization. I suspect the problem wasn't fixed until the project was reorganized, or until a quality crisis forced them to involve the testers better.

...the organization has been established, and people have settled into their roles. This has led to uneven communication among the team members, and some members do not feel a part of the team.

✥ ✥ ✥

If people are left out of the main communication flow, they become dissatisfied, gripe among themselves, and may even leave the project. And by the way, they can't do their jobs as well.

When people become disengaged from communication networks, they can feelalienated from the community. They sometimes commiserate with others in the same situation, forming alliances with others who are equally distant from the center of the community. This phenomenon has been observed in certain aboriginal tribes, and was named "schmismogenesis." [Reference]


For any given role, there is a certain amount of information which is formally required for that role to be fulfilled. But this is usually insufficient for optimal efficiency; we tend to do better when we have contextual information as well as essential information.

But the hard thing is knowing what that additional information is. It's elusive: for example, a project might be officially on schedule, but the developers are murmuring among themselves that development isn't going so well. There is nothing concrete to put one's finger on, but something isn't quite right. This is important information if you are the tester waiting for delivery.

Therefore:

Move team members physically as close to each other as possible. Be sure that people with outer roles are located close to the central roles.


Thomas Allen [BibRef-Allen1977] gives guidelines for physical distance.

Of course, some projects, for various reasons, are split geographically. This can lead to exactly this problem unless OrganizationFollowsLocation and ConwaysLaw are followed.

Note that it is a misapplication of this pattern to apply it to only a subset of an organization responsible for a project. If for example, one clusters all the developers together in a "developer's ghetto", and forgets System Test or Marketing, you violate EngageQualityAssurance and EngageCustomers. And you actually create, rather than alleviate schismogenesis. In addition, communication with individuals outside the project is also important. Allen [BibRef-Allen1977] points out that the high performers had significantly more communication outside the project than low performers.

✥ ✥ ✥

The pattern complements DivideAndConquer both by encouraging symmetries within local groups, and establishing pathways between groups.

There are two complementary effects of this action. First, the people in the outer roles feel like they are a part of the project, and their morale improves. They are less likely to gripe about the project with other outsiders, because they are no longer outsiders. The second thing that happens is that they pick up more technical information through informal means, such as the chatter in the hallways, and they can do their jobs better. This secondary effect is the generative nature of this pattern: As communication improves, quality and time-to-market are improved, which tends to reduce the number of people needed for the project, which reduces communication overhead, which helps improve communication, and so on.

An organization consists of both roles and the people who fill those roles. Both must be considered. While most of the patterns in this language address one or the other, this pattern is unusual in that it bridges the two.

Copyright © 2026 The Scrum Patterns Group
Report abuse
Page details
Page updated
Report abuse