Mob Programming – key issues it can solve, benefits, and learnings

futurice.com · article · 2022-08-08 source ↗ Reader 🖥️

DORA & Engineering Metrics Lean & Toyota Way Pair & Mob Programming Psychological Safety Pull Requests & Async Code Review Trunk-Based & Continuous Delivery

Asynchronous, feature-branch-and-pull-request software development ('soloing') generates Lean process waste — delays, queues, defects, big batches, overproduction, and rework — because it structurally separates writing code from reviewing it; mob programming (the whole team working synchronously on one task at a time) eliminates this waste by collapsing the hand-off entirely, and on one real six-month engagement its benefits (faster flow, continuous review, shared knowledge, trunk-based delivery, psychological safety) outweighed the new problems it introduced (remote-tooling friction, flow-state overwork, loose-specification discomfort).

practical · narrative — A first-person practitioner case study: a Futurice consultant recounts six months of adopting mob/ensemble programming on one client project, framed through Lean 'muda' (process waste) categories, and honestly reports both the problems solved and the new problems that emerged. Argues for the practice via lived experience plus Lean/Theory-of-Constraints theory, not controlled evidence.

Structure

Part	Role
Diagnosis: the conventional scatter-gather / feature-branch / pull-request model as a source of six named Lean wastes (delays, queues, defects, big batches, overproduction, rework)	problem statement
Introducing mob programming as the structural fix (eliminates the hand-off that creates each waste), plus common misconceptions rebutted	proposed solution + definitional clarification
The author's own project's prior pain (long feedback loops, knowledge gaps, no team cohesion) that motivated trying mob programming	case-study motivation
What was gained, organized as six 'Less X, More Y' sections: less queues/more efficiency, less technical debt/more refactoring, less knowledge gaps/more transfer, less passive meetings/more collaboration, less branching/more integrating (trunk-based development), less blaming/more psychological safety	evidence of benefit
What was lost / new problems: remote code/communication tooling friction, flow-state overwork, loose-specification discomfort, third-party library research, slow CI/CD pipelines	honest counter-evidence / limitation
Conclusion via Theory of Constraints (Ackoff's systems quote, 'any improvement not at the constraint is an illusion')	theoretical synthesis

Key terms

Soloing
The author's term for the conventional practice of developers each working their own feature-branch tasks in isolation and integrating via pull request later — treated as the default, largely unquestioned status quo that mob programming replaces.
The six Lean wastes (delays, queues, defects, big batches, overproduction, rework)
A specific mapping of Lean/muda categories onto the asynchronous pull-request workflow: delay from context-switching to review, queues from WIP piling up while waiting for review, defects from reviewers lacking authoring context, big batches from late integration, overproduction from speculative features, and rework from review ping-pong.
Mob / ensemble programming (Zuill's definition)
'All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer' — operationally, pair programming extended to three or more people, with a Driver who types and Navigators who direct, rotating roles on a short timer (the team settled on ~10 minutes, also experimenting with TDD ping-pong rotation).

Propositions

explicitCode review conducted asynchronously, days after the code was authored, forces the reviewer to reconstruct context the author already had, which both slows review and increases the risk that logical defects pass unnoticed while reviewers fixate on surface style issues.conf: high
explicitA developer forced to context-switch between authoring their own task and reviewing someone else's reduces team throughput and inflates lead time beyond what was estimated.conf: high
explicitTeams that react to rising production-defect rates by adding more quality gates, rather than addressing delay/queue/batch-size root causes, do not fix the underlying problem and can make it worse by growing batch sizes further (the 'big batches catch-22').conf: high
explicitLimiting work-in-progress to exactly one task, by having the whole team work on it simultaneously, eliminates the need to hand work off for review at all, because inspection is immediate and continuous rather than a separate, queued step.conf: high
supportsFour Eyes Without Pull Requests · p8 — Both describe the same pattern — continuous/pairing-based review fitting trunk-based, small-batch, frequent-integration delivery better than long-lived branches and batched PR review — the Futurice piece supplies a concrete, first-person case study of exactly this claim.
explicitCode review is inherently a synchronous, face-to-face activity, and most advice for optimizing asynchronous code review fails because it doesn't recognize this.conf: high
explicitOn this team, mob programming reduced queues and context-switching to the point where developers are never interrupted to review others' code, because review happens instantly as code is written rather than being requested afterward.conf: high
explicitMob programming does not eliminate the need for refactoring or produce flawless code on the first pass — it shifts the team's relationship to refactoring from something requiring permission to something done as an unquestioned professional duty, applied continuously.conf: high
explicitContinuous shared presence on the same codebase eliminated the team's knowledge-gap problem: any member could take time off without stalling the work, because the whole team, not any one person, holds the project's design knowledge.conf: high
explicitSwitching from long-running feature branches to trunk-based development (a shared development branch with daily merges to mainline, pull requests retained only to trigger release pipelines) was both enabled by and necessary for mob programming's continuous-integration benefits.conf: high
supportsSoftware Teaming: A Mob Programming, Whole-Team Approach · p13 — Futurice's 'continuous review as an inherent side effect of working together' is the same claim Zuill and Meadows generalize: continuous real-time review drives both quality and shared ownership, as an inherent side effect of the whole team working together rather than a scheduled step.
explicitWhen the whole team collectively owns a decision and its consequences, no individual needs to personally defend a mistaken decision after the fact, which reduces blame and increases psychological safety even when real failures occur (e.g. a misunderstood requirement that delayed a release).conf: high
supportsSoftware Teaming: A Mob Programming, Whole-Team Approach · p16 — Futurice's observation that collective ownership removes the need to personally defend a decision after a failure is a concrete instance of the book's general claim that shared decision-ownership removes the incentive to defend a decision post-hoc.
implicitPassive-aggressive remarks that re-individualize ownership (e.g. 'this is Joe's code, ask him') can still erode psychological safety even inside an otherwise collectively-owned, blame-light team — collective ownership is a practice that must be actively maintained, not a state achieved once and preserved automatically.conf: medium
explicitIntense flow states during mob programming sessions have a real cost (exhaustion, working too late, attention from non-driving members wandering off) that requires deliberate countermeasures — scheduled breaks, muted notifications, explicit per-session goals — rather than being treated as an unambiguous good.conf: high
implicitLoosely specified acceptance criteria produce unproductive-feeling debate time in a mob, but that discomfort is partly an illusion caused by utilization-focused guilt (feeling bad for not visibly producing), not a true sign of wasted effort, since learning time is real value.conf: medium
implicitMob programming surfaces previously hidden constraints (slow CI/CD pipelines, unfriendly third-party libraries, remote-tooling limitations) that soloing had kept invisible because no one was waiting on them synchronously; this is evidence the constraint moved, not that mob programming created new waste from nothing.conf: medium
explicitPer Theory of Constraints, any local improvement that isn't applied at the actual system bottleneck is illusory — most attempts to fix asynchronous code review (better PR tooling, more reviewers, bigger batches with less frequent release) fail for this reason, because none of them address the real constraint of hand-off-induced queueing.conf: high
extendsSoftware Teaming in the Age of AI with James Herr and Woody Zuill · p4 — Futurice's finding that mob programming's whole value proposition depends on eliminating hand-off-induced queueing anticipates, in a pre-AI context, exactly the queueing problem Zuill/Herr later identify with AI agents themselves (waiting on the agent to finish) — the same lean-queueing diagnosis applied to a new kind of bottleneck.

Arguments

Mob programming is structurally superior to the soloing/feature-branch/pull-request model for this team's context, because it removes the hand-off that is the root cause of delays, queues, defects, big batches, overproduction, and rework, rather than mitigating any one of those symptoms individually. strength: medium

Explicit premises:

Each of the six named wastes traces back to the same structural feature: work is handed off from author to reviewer at a later point in time
Limiting WIP to one task removes the hand-off entirely rather than optimizing it
Code review is inherently synchronous/contextual, so delaying it (as PR review does) degrades its effectiveness

Implicit premises:

A single team's six-month experience generalizes at least loosely beyond this one project's specific domain, team composition, and client constraints
The new problems introduced by mob programming (flow overwork, tooling friction) are second-order and manageable, while the problems it solves are first-order and structural

Inferences:

If the hand-off is the actual root cause, then any practice that reintroduces asynchronous hand-offs at scale (e.g. large distributed teams, or AI agents generating code faster than a mob can absorb it) would be expected to reintroduce the same wastes in a new form — a question this article doesn't explore but which the corpus's later AI-era mob-programming material (Zuill/Herr) takes up directly.

Narratives

The team completed a highly productive-feeling week shipping task after task, then discovered during client-side testing that they had misunderstood the requirements and had to postpone the release — and the team's response was to collectively 'point fingers at ourselves' rather than blame an individual.
→ Shows (rather than argues) that collective ownership changes a team's emotional/social response to real failure, and also implicitly supports the point that velocity-only measurement ('running at full speed in the wrong direction') is an insufficient signal of value delivered.
One mob session ran for several hours straight on a hard problem without anyone noticing to take a break, leaving the author too exhausted afterward to enjoy free time — prompting the team to agree explicit rules about watching the clock and taking hourly breaks.
→ Grounds the claim that flow-state intensity in mob programming is a real cost requiring deliberate countermeasures, not merely a theoretical caveat.

Questions addressed

✅ What specifically about the conventional feature-branch/pull-request workflow causes slow delivery and quality problems, beyond vague complaints about 'too many meetings' or 'slow reviews'?
A six-category Lean-waste breakdown (delays, queues, defects, big batches, overproduction, rework), each traced to the structural hand-off between authoring and reviewing.
✅ Does adopting mob programming actually solve these problems in practice, or only in theory?
Yes, on this one six-month engagement, across each of the six named benefit areas — though the author is explicit this is one team's lived experience, not a controlled study.
⭕ Does mob programming's cost structure (remote tooling friction, flow-state overwork risk, loose-specification discomfort, exposure of previously-hidden bottlenecks like slow CI/CD) outweigh its benefits for teams with different constraints (e.g. fully distributed, highly specialized domains, or very large teams)?

Gaps

incompleteThe case study is a single team's self-reported, uncontrolled six-month experience (explicitly framed via the author's 'Just Sharing' disclaimer), with no comparison team, no defect-rate or cycle-time measurements before/after, and no discussion of what made this particular domain (unfamiliar, NDA-restricted data science/device programming) more or less favorable to mob programming than a typical project.
Read next: See extract-software-teaming-a-mob-programming-whole-team for Zuill and Meadows's book-length treatment with cited pair-programming defect-rate studies (Williams & Erdogmus; Rico et al.) that this article's claims echo without citing.
incompleteThe article never addresses what happens to the mob-programming model when the volume of code being produced per unit time grows beyond what a human driver can type or a human mob can continuously review — a scenario that didn't exist when soloing was the baseline being critiqued but that AI coding agents create directly.
Read next: See extract-software-teaming-age-of-ai-zuill-herr for Zuill's own later account of how ensemble/mob discipline changes once AI handles the typing and introduces a new kind of agent-queueing to eliminate.

Closes gaps elsewhere

GitHub Brings Stacked Pull Requests to Public Preview · g4 — This article is a concrete, lived case study of exactly the alternative the stacked-PR article never weighs: moving from batched asynchronous PR review to continuous, pairing/mob-based review (trunk-based development, instant in-the-moment review) dissolved the throughput/quality trade-off for this team rather than trading it for a different batch size.