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

Hub Spoke And Rim

...you have a design and implementation process in a well-understood domain, and want to implement the principles of DeCoupleStages. The organization is mature and the process well-understood; it is fairly well optimized and has good partitioning in the spirit of DivideAndConquer. Mature development organizations have well-defined development stages — such as requirements acquisition, design, and coding. 

✥ ✥ ✥

Some processes can almost be automated, but still require a degree of human intervention and coordination. This is particularly true for highly detailed processes. 

For example, even if a process is mature enough to have well-delineated development phases, it may need additional mechanisms to integrate these stages and coordinate the interactions between them. 

Process stages should be decoupled to reduce the communication associated with hand offs and promote independence between stages. Such independence creates opportunities for parallelism and increased throughput. Yet independence generally hampers information flow. 

Therefore: 

Link each role to a central role that orchestrates process activities, with the activities taking place serially. The hub plays a simple coordination and management function to ensure all steps are completed successfully, while the work is done in the rim. The "rim" carries the hand off and its associated information between roles. The "spokes" provide the link to the central coordinating agent, and are lighter links of communication than between the "rim" roles. 

This organization, a front-end process for a large development project, exhibits HubSpokeAndRim: 

The process supports sales and marketing activities and is highly responsive. 

The hub role should be encouraged to avoid micro-managing, particularly with respect to the mechanisms individual rim roles use in achieving their tasks. The hub role should scrutinize deadlines and schedules and should be in close enough contact with the rim roles to facilitate hand offs from role to role if necessary, and to communicate the state changes to other parts of the project as necessary. In this sense, the hub role can also act as a natural FireWall for the rim roles. 

✥ ✥ ✥

The rim roles still maintain a good modicum of autonomy; each can focus on its own domain-specific task. There need not be any essential domain coupling between the roles on the rim; the only coupling is with respect to sequencing. The hub can coordinate that coupling and can optimize it (juggle priorities, give different projects or customers different priority) to meet project priorities. The hub is a management role rather than a development role--a controller or sequencer. The hub role holds things together and ensures that progress ensues from state to state. Here, we want to ensure progress in the process; compare with the design pattern SomeoneAlwaysMakesProgress. HubSpokeAndRim is an implementation pattern that achieves the intent of SomeoneAlwaysMakesProgress in a limited context. 

Prof. Aaron Gelman (Northwestern University) notes that in the contemporary airline market, the hub pattern contributes to congestion. Many airlines are acquiring small planes that can take small numbers of passengers directly between end destinations, acting as "hub busters" and relieving such congestion. The analog is a concern for over-application of this pattern. (WBBM Radio News, Chicago, IL, Sep. 30, 2000) 

The organization must be wary of the central role becoming a bottleneck, and address such bottlenecks with other patterns (e.g., MoveResponsibilities). 

This configuration has higher latency than a highly coupled process, but it is likely to be able to support higher throughput (see CouplingDecreasesLatency). However, it cannot easily support essentially creative processes that are common to design, coding, and testing. In the creative process of design, communication is more important than sequencing, since a repeatable sequence is unlikely to be found in such a creative process. 

In a less mature domain, it is more appropriate to apply DeveloperControlsProcess as the alternative. Most domains in fact lack the maturity for HubSpokeAndRim to be appropriate. 

Parallelism can be re-introduced if the central role pipelines activities become a bottleneck.

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