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

Organization Follows Location

Different parts of the country may have different cultures and architectural styles.

I was once involved in planning a large project that was to be split between two locations. My organization was located in a new building in Colorado with blue carpet. The other half of the project was in New Jersey; their building had green carpet.When I presented our plan to my organization, I showed slides with different parts of the architecture colored blue or green, depending on where the development was to take place. The organization got the message immediately.

...a product must be developed in several different hallways, on different floors of a building, in different buildings or at different locations. This may owe to political reasons or to the need to have some development teams colocated with remote markets, or for reasons of standards or the distribution of physical facilities (e.g., the separation between different trading centers, or between a radio telescope site and a research university that uses its data), or even economic or trade issues that drive development to a different country.

There needs to be a degree of trust and camaraderie within an organization, since an organization is a decision-making body that must converge on and buy into joint decisions. Allegiance to an organization falls strongly along the lines of geographic distribution.

✥ ✥ ✥

It is important to assign tasks and roles insightfully across a geographically distributed work force.

Communication patterns between project members follows geographic distribution. Coupling between pieces of software must be sustained by analogous coupling between the people maintaining that software. People avoid communicating with people who work in other buildings, other towns, or overseas (see below). People in an organization usually work on related tasks, which suggests that they communicate frequently with each other.

Therefore:

The architectural partitioning should reflect the geographic partitioning, and vice versa. Architectural responsibilities should be assigned so decisions can be made (geographically) locally.

This is a variant of ConwaysLaw. Since the organization will follow the architecture, you want the organization, architecture, and geography to line up. Geographical considerations are often the most severe, and since architecture can be a strong lever for organization, it is a good tool to bring these three aspects into alignment.

One of the most significant characteristics of geographic differences is allegiance: people are naturally more loyal to local managers than to remote managers. This is even more extreme if a remote location is part of a company as a result of a merger or acquisition. If work is split between two locations where the work itself does not split cleanly, one or the other location must be in charge. And that naturally causes resentment on the part of the other location. Instead, try to make the work assignments as autonomous as practical; this instills trust.

✥ ✥ ✥

Sub-organizations that can be further split or organized by market or other criteria (see OrganizationFollowsMarket, WorkFlowsInward, and others). You still need someone to break logjams when consensus can't be reached, perhaps using ArchitectControlsProduct or PatronRole. If the organization is modularized along geographic boundaries, and the architecture is not then it will be impossible to apply ArchitectAlsoImplements: it's difficult for the architect at one location to oversee and contribute to the code at another.

Thomas Allen [BibRef-Allen1977 ] has found that social distance goes up rapidly with physical separation (see also "House Cluster" ([BibRef-Alexander1977 ], ff. 197) of Alexander). We have noted frequent cases of international collaboration (usually overseas) that strongly exhibit symptoms of this problem and which have had low prospects for success owing to just such separation. This is a crucial pattern that is often overlooked or dismissed out of consideration for political alliances or fashion (for example, outsourcing software development is very fashionable in management circles at this writing). Peter Bürgi's studies of geographically distributed organizations in AT&T bore out the importance of this pattern.

We have seen few geographically distributed organizations that exhibit positive team dynamics. There are exceptions, and there are rare occasions when this pattern does not apply. Steve Berczuk (then at MIT) notes: "... communications need not be poor between remote sites if the following items are true:

    1. The number of developers on a project, including all sites is small;

    2. Most of the communication is done via something like email (wide distribution and asynchronous communication--in [one case of his experience] ... more people were in the loop than if the primary means of communication had been hallway chats);

    3. The people involved have been together for some time so that they feel like they know each other (this can be as short as a kickoff meeting; see FaceToFaceBeforeWorkingRemotely);

    4. Folks aren't so burned out by "unnecessary" travel that they are willing and happy to travel when it is needed. In some situations [complete work split by location] is not possible because of the nature of the project, so we need a way to address the issue of remoteness." (Personal communication with Steve Berczuk, August, 1994.)

There are times when the market demands geographic distribution; see OrganizationFollowsMarket and [BibRef-Berczuk1996 ]. In these cases you need FaceToFaceBeforeWorkingRemotely .

As an organization grows, it may want to split geographically for a number of marketing and political reasons (DivideAndConquer ). The OTI corporation relates how it splits organizations geographically to keep reusable assets uncontaminated by each other.

That people be colocated within a building is probably more important to organizational effectiveness than to allocate offices as perks of seniority. Senior staff may have a need for larger or more secure offices than junior staff, but not for an office near the rest room or an office with a window.

See StandardsLinkingLocations as a technique supporting this organizational structure in the PeopleAndCodePatternLanguage.

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