Feature Development: Parallel Module Pattern

Overview

Each teammate owns an independent module or component. They build in parallel without interfering. An integrator ensures cross-module consistency.

Core principle: Conway's Law as a tool — structure the team to mirror the desired architecture.

Management theory: Conway's Law (team structure → system architecture), T-Shaped Skills (specialists who understand the whole), Belbin role coverage.

When to Use

• •New feature with 2+ independent components
• •Each component can be built and tested in isolation
• •Components have well-defined interfaces/contracts
• •Code ownership is clear (no two people editing same file)

Don't use when:

• •Components are tightly coupled
• •Interface contracts are undefined
• •Single module that can't be split

Team Composition

coordinator (lead, delegate mode recommended)
├── architect × 1          (designs interfaces, reviews contracts)
├── implementer × 2-3      (one per module)
├── reviewer × 1            (code quality + spec compliance)
└── integrator × 1          (optional: cross-module consistency)

Belbin coverage:

• •Thinking: architect (Plant) + reviewer (Monitor-Evaluator)
• •Action: implementers (Implementer)
• •People: coordinator (Coordinator) + integrator (Teamworker)

Sizing by feature scope:

The Process

Phase 1: Forming — Architecture & Contracts

Before spawning implementers:

1. •Coordinator or architect defines module boundaries
2. •Define interface contracts between modules (API signatures, data shapes)
3. •Create task list with dependencies
4. •Each module is a task assigned to one implementer

Critical: Interface contracts MUST be locked before implementation starts (Tuckman's Norming). Changing contracts mid-build invalidates parallel work.

Contract template:

Module A provides:
  - function doX(input: TypeA): TypeB
  - emits event "x-complete" with payload TypeC

Module B consumes:
  - calls A.doX() with [specific inputs]
  - listens for "x-complete"

Agreed data types: [shared types file]

Phase 2: Storming — Plan Review

• •Architect presents module split + contracts
• •Reviewer checks for gaps, ambiguities
• •Devil-advocate (or reviewer) challenges: "What if module A fails? What's the error contract?"
• •Iterate until contracts are solid

Phase 3: Performing — Parallel Implementation

Each implementer:

1. •Works only on their assigned module
2. •Follows the agreed interface contract
3. •Writes tests for their module in isolation
4. •Commits independently (no file conflicts)

File ownership rule: No two implementers touch the same file. If shared code is needed, the integrator or architect handles it.

Coordinator in delegate mode:

• •Does NOT implement anything
• •Tracks progress via task list
• •Unblocks stuck implementers
• •Routes cross-module questions to architect

Phase 4: Integration

Integrator (or coordinator):

1. •Verifies all modules implement their contracts
2. •Writes integration tests
3. •Checks cross-cutting concerns (error handling, logging, auth)
4. •Resolves any interface mismatches

Phase 5: Adjourning — Review & Reflect

• •Reviewer runs full review on integrated code
• •team-orchestrator:session-reflection captures learnings

Conway's Law: Team ↔ Architecture Mapping

Structure your team to produce the architecture you want:

Anti-pattern: Splitting by file instead of by feature. This produces files that "work" in isolation but features that don't cohere.

Common Mistakes

Integration

Pre-requisite: team-orchestrator:orchestrating-work routes here Post-requisite: team-orchestrator:session-reflection records learnings Related: superpowers:subagent-driven-development for single-session alternative