Mob Programming
A whole-team development style where everyone works on the same problem at the same time on one screen — the extreme form of pair programming, used to crush complex problems and spread knowledge fast.
Definition
Mob Programming is a development style where the whole team — three to seven people — works on the same problem at the same time on the same screen. One person drives the keyboard; the rest navigate. The driver rotates every few minutes. It is the extreme expression of pair programming, originating with Woody Zuill's team at Hunter Industries in 2011.
Why It Matters
Knowledge transfer is instant; handoffs are eliminated; the highest-stakes decisions get the team's combined judgement in real time. Mob programming trades parallelism for throughput on the hard problems — and the trade often wins, because the hard problems were the ones serializing the team anyway.
How It Runs
- Driver–navigator rotation — typically 5–15 minutes per driver.
- One screen, one keyboard — physical or shared remote.
- The driver does not decide — they type what the navigators direct.
- The navigators do not type — they think out loud.
- Breaks are scheduled — mobbing is intense; sustained sessions need rest.
- Retrospect daily — the practice improves only with feedback.
Real-World IT Example
A core-banking team facing a notoriously complex regulatory rewrite tried mob programming after two failed sprints of split work. Five engineers mobbed for four hours each morning. The regulation, which the team had quoted at 5 weeks, completed in 11 working days with zero defects in QA. The team also onboarded a new engineer fully in two weeks — historically a 6-week ramp.
Real-World Construction Analogue
The closest construction analogue is a coordinated BIM coordination session where structural, mechanical, electrical, and architectural disciplines work the same model in the same room. Clash resolution that takes weeks asynchronously closes in a single day when the disciplines mob the model.
Key Takeaways
- Mob programming trades parallel work for higher throughput on the hard parts.
- Onboarding and knowledge transfer become almost free.
- The driver–navigator discipline is what separates mobbing from a meeting.
- It is most valuable on complex, ambiguous, or high-risk work.
Expert Tips
- Use a timer; rotation is the practice.
- Rotate the navigator's "primary voice" too; the loudest engineer should not lead permanently.
- Tooling matters — keystroke-shared IDEs reduce friction in remote mobs.
- Schedule mobbing for the hardest problems, not the routine ones.
- Mob with rituals: stand-up at start, retrospective at end, fixed-length sessions.
Common Mistakes
- Treating it as a meeting; the team must be coding.
- Letting the driver decide; they type, the navigators decide.
- Mobbing on routine work where parallelism would be faster.
- No rotation; one person becomes the permanent driver.
- Mobbing without breaks; the practice exhausts even strong teams.
- Skipping the daily retrospective on how the mob is working.
Practical Lessons Learned
- Mobbing accelerates onboarding more than any other practice.
- The team that mobs together aligns on standards without needing documents.
- Skeptical engineers often become the strongest advocates after two weeks.
Related Encyclopedia Entries
- Pair Programming
- Test-Driven Development
- Refactoring
- Continuous Integration
- Definition of Done
- Technical Debt
Related Research Articles, Case Studies & Tools
Frequently Asked Questions
Isn't mobbing a waste of engineer time?
Often the opposite — throughput on hard problems rises because handoffs disappear.How long can the team mob?
Four hours a day is sustainable; eight hours is not.Can mobbing be remote?
Yes — shared IDE and good audio matter more than the office.What size mob is right?
Three to seven engineers works best; larger groups drift into meeting dynamics, while two engineers is simply pair programming and loses the cross-pollination benefit.Does mobbing replace code review?
Largely yes — review happens live as code is written, though a lightweight async pass is still useful for security and compliance checks.Should every team mob?
Try it on hard problems first; teams whose work is parallel-friendly may not benefit.How do I introduce mobbing?
Volunteer-only one-day pilot, measure outcomes, share the result.What is a common misconception about Mob Programming?
That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.Which related encyclopedia entries should I read alongside Mob Programming?
Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.How does Dr. Hassan Eliwa's research treat Mob Programming?
Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Mob Programming is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.How is Mob Programming defined on PMMilestone Research & Insights?
A whole-team development style where everyone works on the same problem at the same time on one screen — the extreme form of pair programming, used to crush complex problems and spread knowledge fast. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.
People also ask
Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.
Which calculator on PMMilestone.org applies here?
The integrated EVM workbook covers most cost-schedule diagnostics. EVM Calculator ↗
Where is this in the glossary?
Quick-lookup definitions across 1,200+ PM terms. PM Glossary on PMMilestone.org ↗
Which learning track covers this end-to-end?
Structured tracks from beginner planner to programme controls director. Project Controls Academy ↗
Which book goes deeper than this entry?
Practitioner field handbooks with worked numerical examples. Books & Publications ↗
Related Entries
More in Agile
- Letter AAcceptance Criteria
The specific, testable conditions a deliverable must meet before the customer accepts it — the contract between a team and the person who will sign off the work.
- Letter BBacklog Refinement
The ongoing practice of clarifying, splitting, estimating, and ordering items on a product backlog so the team always has a healthy queue of ready work for upcoming sprints or releases.
- Letter BBurn-Down Chart
A time-series chart showing remaining work against time, used by agile teams to visualise sprint or release progress and forecast completion.
- Letter CContinuous Integration
The engineering practice of merging code changes into a shared mainline many times a day and verifying each merge with automated builds and tests.
- Letter CCumulative Flow Diagram
A stacked-area chart of work items in each stage over time — the single most informative chart in lean and Kanban flow management.
- Letter DDaily Stand-up
A short, focused, time-boxed daily meeting where the delivery team aligns on progress, plans the next 24 hours of work, and surfaces blockers.
Further reading on PMMilestone.org
Curated companion resources hosted on the flagship platform, PMMilestone.org.
- For practitioners who want to go deeper, the Learning Tracks.
- Engineers researching this topic typically continue with the Books & Publications.
- A practical companion to this entry is the EVM Calculator.
- Closely related on the flagship platform is the Schedule Health Checker.
- Useful alongside this article is the PMMilestone.org knowledge hub.