Search this site
Embedded Files
Published Patterns
  • Home
  • A Vision
  • Book Outline
    • Acknowledgments
    • Beedle Dedication
    • Beyond the Core
    • Composing Your Own Pattern Language
    • Confidence Star Summary
    • Dedications
    • History of the Patterns
    • Introduction
    • Patlets
    • Pattern Name Aliases
    • Picture Credits
    • Preface
    • Product Organization Pattern Language
    • Product Organization Pattern Language
    • Product Owner’s Note
    • The Core Patterns in Brief
    • The Future of the Patterns
    • Value Stream Pattern Language
  • External Patterns
    • Apprenticeship
    • Code Ownership
    • Community of Trust
    • Compensate Success
    • Completion Headroom
    • Day Care
    • Developer Controls Process
    • Developing in Pairs
    • Distribute Work Evenly
    • Do Food
    • Domain Expertise in Roles
    • Don’t Interrupt an Interrupt
    • Eat Your Own Dog Food
    • Engage Quality Assurance
    • Face-to-Face Before Working Remotely
    • Failed Project Wake
    • Firewall
    • Gatekeeper
    • Informal Labor Plan
    • Interrupts Unjam Blocking
    • Matron Role
    • Moderate Truck Number
    • Named Stable Bases
    • Organization Follows Market
    • Patron Role
    • Producer Roles
    • Programming Episodes
    • Recommitment Meeting
    • Sacrifice One Person
    • Self-Selecting Team
    • Size the Organization
    • Smoke-Filled Room
    • Solo Virtuoso
    • Someone Always Makes Progress
    • Stand-Up Meeting
    • Surrogate Customer
    • Take No Small Slips
    • Team per Task
    • Team Pride
    • The Water Cooler
    • Unity of Purpose
    • Wise Fool
    • Work Flows Inward
  • Product Organization Pattern Language
    • A Scaling Sequence
    • A Sequence Of Scaling
    • Birds of a Feather
    • Chief Product Owner
    • Conway's Law
    • Development Partnership
    • Development Team
      • Autonomous Team
      • Collocated Team
      • Cross-Functional Team
      • Developer-Ordered Work Plan
      • Distribute Work Evenly
      • Fertile Soil
      • Oyatsu Jinja
      • Remove the Shade
      • Self-Organizing Team
      • Small Teams
      • Stable Teams
      • Swarming: One-Piece Continuous Flow
      • Team Pulse
      • Team Sprint
    • Domain Expertise in Roles
    • Emergency Procedure
    • Illegitimus Non Interruptus
    • Improvement Community
    • Kaizen and Kaikaku
    • Kaizen Pulse
    • Leading Team
    • MetaScrum
    • Mitosis
    • Norms of Conduct
    • Organizational Sprint Pulse
    • Pop the Happy Bubble
    • Product Owner
    • Product Owner Team
    • Product Pride
    • Scrum of Scrums
    • Scrum Team
    • ScrumMaster
    • Scrumming the Scrum
    • Small Red Phone
    • Sprint Pulse
    • The Mist
  • Scrum Core Pattern Language
    • Backlog Grooming Meeting
    • Backlog Refinement Meeting
    • Daily Scrum
    • Development Team
    • Product Backlog
    • Product Owner
    • Scrum Team
    • ScrumMaster
    • Sprint
    • Sprint Backlog
    • Sprint Burndown
    • Sprint Planning Meeting
    • Sprint Retrospective
    • Sprint Review
  • Sequences
    • A Project Language of Highly Effective Teams
    • Product Backlog Sequence
    • Product Organization Sequence
    • Project Languages
    • Value Stream Sequence
    • Your Own Pattern Language
  • Unlinked Patterns
    • Impediment List
    • Involve the Managers
    • Involve the Managers - Redux
  • Value Stream
    • Daily Clean Code
    • Definition of Done
    • Estimation Points
      • Accountable Estimates
      • Pigs Estimate
      • Updated Velocity
      • Yesterday's Weather
    • Fixed Work
    • Good Housekeeping
    • Greatest Value
    • Information Radiator
      • Scrum Board
      • Sprint Burndown Chart
    • Notes on Velocity
    • Product Backlog
      • Aggregate Velocity
      • Change for Free
      • Definition of Ready
      • Enabling Specification
      • Estimation Range
      • Fixed-Date PBI
      • Granularity Gradient
      • High Value First
      • Money For Nothing
      • Product Backlog Item
      • Rechunked PBIs
      • Refined Product Backlog
      • ROI-Ordered Backlog
      • Specialized Velocities
      • Vacation PBI
      • Value and ROI
    • Product Roadmap
    • Product Wake
    • Production Episode
    • Regular Product Increment
    • Release Plan
      • Product Roadmap
      • Release Range
      • Release Staging Layers
    • Responsive Deployment
    • Rhythms: Patterns of Time
    • Running Average Velocity
    • Set-Based Design
    • Small Items
    • Sprint
      • Daily Scrum
        • ScrumMaster Incognito
      • Follow the Moon
      • Sprint Retrospective
      • Stop the Line
    • Sprint Backlog
      • Burndown Chart
      • Dependencies First
      • Developer-Ordered Work Plan
      • Small Items
      • Sprint Backlog Item
    • Sprint Goal
    • Sprint Planning
    • Sprint Review
    • Team Sprint
    • The Spirit of the Game
    • Value Areas
    • Value Stream Fork
    • Visible Status
    • Vision
    • Whack the Mole
  • Organizational Patterns of Agile Software Development
    • BookOutline
      • Appendices
        • Bibliography
        • ParkingLot
        • PhotoCredits
        • SummaryPatlets
      • CaseStudies
        • AHyperproductiveTelecommunicationsDevelopmentTeam
        • BorlandQuattroProForWindows
      • FoundationsAndHistory
        • AnthropologicalFoundations
          • BeyondProcessToStructureAndValues
          • DistillingThePatterns
          • PatternsInAnthropology
          • RolesAndCommunication
          • RolesAndCommunications
          • SocialNetworkAnalysis
          • CRCCardsAndRoles
          • ScatterplotsAndPatterns
          • SocialNetworkTheoryFoundations
        • OrganizationalPrinciples
          • PiecemealGrowth
          • PrimingTheOrganizationForChange
          • SomeGeneralRules
          • BuildingOnTheSolidCore
          • DissonancePrecedesResolution
          • ItDependsOnTheContextOfTheOrganization
          • ItDependsOnYourRoleInYourOrganization
          • MakeLoveNotWar
          • OrganizationalPatternsAreInspirationRatherThanPrescription
          • OrganizationalPatternsAreUsedByGroupsRatherThanIndividuals
          • PeopleAreLessPredictableThanCode
          • StabilityAndCrisisManagement
          • TeamBuilding
          • TeamBurnout
          • TheOpenClosedPrincipleOfTeams
          • TheRoleOfManagement
      • HistoryAndIntroduction
        • HowThePatternsCameToUs
          • CreatingSequences
          • GatheringOrganizationalData
          • HistoryAndRelatedWork
          • AnalyzingRolesAndRelationships
          • IntrospectionAndAnalysisOfOrganizations
          • IntrospectionInAndAnalysisOfOrganizations
          • ShortcomingsOfStateOfTheArt
          • TheCRC-CardMethodology
        • HowToUseThisBook
          • ApplyingThePatterns
          • ReadingThePatterns
          • UpdatingThePatterns
          • WhoShouldUseThisBook
      • PreFace
      • ThePatternLanguages
        • OrganizationConstructionPatterns
          • OrganizationalStylePatternLanguage
          • PeopleAndCodePatternLanguage
          • ArchitectAlsoImplements
          • ArchitectControlsProduct
          • ArchitectureTeam
          • CodeOwnership
          • ConwaysLaw
          • CouplingDecreasesLatency
          • DeCoupleStages
          • DeployAlongTheGrain
          • DistributeWorkEvenly
          • DivideAndConquer
          • FaceToFaceBeforeWorkingRemotely
          • FeatureAssignment
          • FewRoles
          • FormFollowsFunction
          • FunctionOwnerAndComponentOwner
          • GenericsAndSpecifics
          • HallwayChatter
          • HierarchyOfFactories
          • HubSpokeAndRim
          • LockEmUpTogether
          • LooseInterfaces
          • MoveResponsibilities
          • OrganizationFollowsLocation
          • OrganizationFollowsMarket
          • ParserBuilder
          • PrivateVersioning
          • ProducerRoles
          • ProducersInTheMiddle
          • ResponsibilitiesEngage
          • ShapingCirculationRealms
          • SmokeFilledRoom
          • StableRoles
          • StandardsLinkingLocations
          • StandUpMeeting
          • SubclassPerTeam
          • TheWaterCooler
          • ThreeToSevenHelpersPerRole
          • UpsideDownMatrixManagement
          • VariationBehindInterface
        • OrganizationDesignPatterns
          • PiecemealGrowthPatternLanguage
          • ProjectManagementPatternLanguage
          • ApplicationDesignIsBoundedByTestDesign
          • ApprenticeShip
          • BuildPrototypes
          • CommunityOfTrust
          • CompensateSuccess
          • CompletionHeadroom
          • DayCare
          • DeveloperControlsProcess
          • DevelopingInPairs
          • DevelopmentEpisode
          • DiverseGroups
          • DomainExpertiseInRoles
          • DontInterruptAnInterrupt
          • EngageCustomers
          • EngageQualityAssurance
          • FailedProjectWake
          • FireWalls
          • GateKeeper
          • GetOnWithIt
          • GroupValidation
          • HolisticDiversity
          • ImpliedRequirements
          • IncrementalIntegration
          • InformalLaborPlan
          • InterruptsUnjamBlocking
          • LegendRole
          • MatronRole
          • MercenaryAnalyst
          • ModerateTruckNumber
          • NamedStableBases
          • PatronRole
          • PhasingItIn
          • PrivateWorld
          • ProgrammingEpisode
          • PublicCharacter
          • RecommitmentMeeting
          • SacrificeOnePerson
          • ScenariosDefineProblem
          • SelfSelectingTeam
          • SizeTheOrganization
          • SizeTheSchedule
          • SkunkWorks
          • SoloVirtuoso
          • SomeoneAlwaysMakesProgress
          • SubsystemBySkill
          • SurrogateCustomer
          • TakeNoSmallSlips
          • TeamPerTask
          • TeamPride
          • UnityOfPurpose
          • WiseFool
          • WorkFlowsInward
          • WorkQueue
          • WorkSplit
    • CommonPatternLanguage
    • DiversityOfMembership
    • IndentationHint
    • OrganizationalPatterns
    • SkillMix
    • StartingPoints
    • TheCatalyst
    • ThoughtsWeaver
    • WorkAllocation
    • HistoryAndIntroduction
      • AnOverviewOfPatternsAndOrganizationalPatterns
        • OrganizationalPatternLanguages
        • WhatArePatternLanguages
        • WhatArePatterns
Published Patterns

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.

Report abuse
Page details
Page updated
Report abuse
OSZAR »