Skills / Engineering-practices

Mob Programming

All the brilliant minds working on the same thing, at the same time, in the same space, and at the same computer.

Mob Programming is a whole-team software development practice where the entire team works on one task at a time at a single shared workstation. Pioneered by Woody Zuill at Hunter Industries in 2012, it replaces handoffs, isolated code ownership, and async code reviews with continuous collaboration through defined Driver, Navigator, and Mob roles and timed rotation. The result is shared knowledge, zero bus factor, and code that the whole team understands from the first line.

By Woody Zuill  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisMob Programming

Input

“We have a senior engineer who's the only one who understands our payment integration. She's going on parental leave in 6 weeks and we're in a bit of…”

Diagnosis

Welcome.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

All the brilliant minds, one screen — eliminate silos by working together, always

Mob Programming structures the entire development team around a single shared workstation with three rotating roles: the Driver types exactly what the Navigator directs and does not self-direct; the Navigator provides the highest-level direction they can articulate; and the Mob (everyone else) contributes ideas, looks up documentation, and prepares for their next turn. Rotation happens on a fixed timer — typically 4–15 minutes — so every team member cycles through the Driver seat. The enforcing principle is Strong-Style Pairing: 'For an idea to go from your head into the computer it MUST go through someone else's hands,' which eliminates silent lone-wolf work by forcing all thinking to be verbalized. Zuill's Turn Up the Good philosophy guides retrospectives: rather than cataloguing failures, teams identify what's working and amplify it deliberately.

The problem

Most teams accumulate knowledge silos without noticing: one engineer owns the payment service, another is the only person who understands the data pipeline, and the bus factor for critical systems is one. Code reviews become rubber-stamp rituals because reviewers lack context, and onboarding new team members takes months because knowledge lives in individual heads, not in shared understanding built together.

The solution

A mob programming coach helps your team design, run, and sustain mob sessions — so that every line of code is written with the whole team's intelligence, knowledge silos become structurally impossible, and new team members are productive within days because they mobbed on real work from day one.

You bring

Your team's size, roles, and current tech stack
Specific collaboration pain points — silos, bus factor risks, onboarding delays
Whether you're setting up in-person or remote
Your team's level of readiness or resistance to trying mob programming

You get

A first-session setup guide: room or virtual layout, tooling recommendations, timer intervals
Driver, Navigator, and Mob role cards with specific behavioral dos and don'ts
A rotation schedule calibrated to your team size and session length
A post-session retrospective guide using the Turn Up the Good principle

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your senior engineer is the only person who can touch the payment service without risk. The auth system is a black box owned by one developer who's perpetually in meetings. Your last sprint review revealed that three team members couldn't explain what the other three were building. Code reviews take two days because reviewers lack the context to evaluate logic — they check style and move on.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Mob Programming

“After four weeks of targeted mob sessions, three engineers can navigate the payment service confidently. Your senior engineer's parental leave caused zero incidents — Priya had been the Driver on every payment story and understood the system deeply before the handoff. Code review lag has disappeared because every line of code was reviewed continuously as it was written, by the whole team, in the room.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Mob ProgrammingClaude

Mob Programming

Welcome. I'm your Mob Programming coach, grounded in Woody Zuill's whole-team approach. Before we build anything, let me ask: what's driving your interest in mob programming right now? Knowledge silos? A bus-factor crisis? A new team that needs to gel fast? Knowing the specific pain helps us design your first session around what will matter most.

We have a senior engineer who's the only one who understands our payment integration. She's going on parental leave in 6 weeks and we're in a bit of a panic.

That's a classic bus-factor crisis — and mob programming is one of the fastest ways to spread that knowledge. Here's the Zuill approach: don't schedule knowledge-transfer meetings. Instead, have your senior engineer be the Navigator for the next 6 weeks while someone else Drives. Under Strong-Style Pairing, every idea she has about the payment system must go through someone else's hands — which forces her to verbalize the tacit knowledge she'd normally just implement silently. The rest of the mob looks up docs, asks clarifying questions, and absorbs context in real time. Who on your team is the best candidate to be the first Driver on payment work?

Probably our mid-level engineer, Priya. She's worked adjacent to payments but has never owned any of it. How long should the rotation be?

For a knowledge-transfer mob like this, I'd recommend 10-minute rotations — long enough for the Driver to settle into a rhythm, short enough that everyone cycles through at least twice in a 90-minute session. With a team of five, that's 10 minutes driving, then 40 minutes in the Mob before you're back at the keyboard. One key rule: when Priya is Driving, your senior engineer navigates at the highest level of abstraction she can manage — not 'type this code,' but 'we need to validate the webhook signature before we touch the payload.' The Driver figures out the implementation. That gap between instruction and execution is where Priya's understanding deepens fastest.

What if our senior engineer just takes over? She's very hands-on and tends to grab the keyboard when things get confusing.

That's the most common failure mode in early mob sessions — Zuill calls it mob domination by a single voice. The fix is structural, not personal: when it's not her turn to Drive, she physically steps away from the keyboard. In remote sessions, that means she does not have screen-share controls. You can also designate a Facilitator role for the first few sessions — someone whose only job is to enforce the rotation timer and gently redirect if the Navigator starts implementing instead of directing. The rule is blunt: if you're not the Driver, your hands are not on the keyboard. Do you want me to build role cards with an explicit Navigator constraint tailored for senior engineers who are used to being the implementer?

Yes — and can you add a retrospective format we can run at the end of each session?

Absolutely. Here's what I'll produce for you: (1) Role cards for Driver, Navigator, and Mob member — each with behavioral dos and don'ts, plus a specific note for the Navigator role about directing rather than implementing; (2) A first-session runbook with a 10-minute rotation schedule for five people over 90 minutes, including remote tooling recommendations; and (3) A Turn Up the Good retrospective template — three questions: What worked that we should do more of next session? What single change would make the next session better? What did we learn about the payment system that we didn't know before? Shall I start with the role cards, or would you rather lead with the runbook so you can share it with the team today?

Reply to Mob Programming…

What the skill is doing

01Role Card Design

02First Session Runbook

03Rotation Schedule Builder

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

MPMob Programmingtyping…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

We have a senior engineer who's the only one who understands our payment integration. She's going on parental leave in 6 weeks and we're in a bit of a…9:14✓✓

I'm your Mob Programming coach, grounded in Woody Zuill's whole-team approach.9:14

Before we build anything, let me ask: what's driving your interest in mob programming right now?9:15

A new team that needs to gel fast?9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Role Card Design

Generates clear, concrete behavioral cards for each mob role — Driver, Navigator, and Mob member. Each card includes specific dos and don'ts so team members know exactly what to do when their turn arrives, reducing the awkward hesitation and role confusion that derails early sessions.

◦ MethodBased on Zuill's strict role separation: the Driver acts as 'an intelligent input device' that does not self-direct, while the Navigator operates at 'the highest level of abstraction they can manage' — a distinction that must be made explicit for teams new to the practice.

CapabilityC-02

First Session Runbook

Produces a tailored checklist for running your first (or improved) mob session — covering physical room layout, shared display setup, virtual tooling recommendations (VS Code Live Share, Tuple, Miro), timer configuration, and the opening ritual to align the mob on the day's goal.

◦ MethodReflects Zuill's single-workstation constraint (one screen, one keyboard) as a structural forcing function: real-time shared context rather than async handoffs is the whole mechanism by which knowledge spreading and continuous code review become possible.

CapabilityC-03

Rotation Schedule Builder

Calculates rotation intervals and sequence for your specific team size and session length, ensuring every team member cycles through the Driver role equitably without disrupting flow or leaving anyone in the Mob for too long.

◦ MethodImplements Zuill's timed rotation system (typically 4–15 minutes) alongside the Strong-Style Pairing constraint — every idea must pass through someone else's hands, which requires everyone to cycle through the Driver role regularly rather than leaving the keyboard to experts.

CapabilityC-04

Turn Up the Good Retrospective

Guides post-session retrospectives using Zuill's lean principle: rather than cataloguing what went wrong, the team identifies what worked and makes explicit plans to do more of it in the next session — building momentum instead of managing dysfunction.

◦ MethodDirectly implements Zuill's 'Turn Up the Good' philosophy — a deliberate alternative to traditional retrospective formats focused on problems, borrowed from lean thinking: amplify what generates value rather than spending energy eliminating what doesn't.

CapabilityC-05

Mob Adoption Proposal

Drafts a structured proposal for leadership or skeptical stakeholders — covering the business case (reduced bus factor, faster onboarding, eliminated PR review lag, continuous quality), a suggested pilot design, and measurable success criteria.

◦ MethodAddresses the organizational adoption challenge Zuill identifies: mob programming requires cultural willingness to experiment, and teams need credible language to get buy-in from managers who see 'five engineers on one problem' as waste rather than as the elimination of coordination overhead.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

Driver / Navigator / Mob Role Cards

One card per role with specific behavioral guidelines, common anti-patterns to avoid, and cues for when to speak up or defer — ready to print, share digitally, or post in a virtual collaboration space at session start.

OutputD-02

First Mob Session Runbook

A step-by-step guide from room or virtual setup to session close: equipment checklist, tooling links, timer recommendations, rotation order, and an opening ritual to align the mob on the session goal.

OutputD-03

Turn Up the Good Retrospective Template

A structured post-session reflection format that captures what worked, what to amplify in the next session, and experiments the team wants to try — grounded in Zuill's lean amplification philosophy rather than problem-deficit framing.

OutputD-04

Bus Factor Risk Map

A team knowledge map identifying which systems or domains have single-owner concentration risk, used to prioritize which work to mob on first for maximum knowledge-spreading impact before a critical deadline or departure.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Woody Zuill

Woody Zuill is the originator of Mob Programming, developed while leading a software team at Hunter Industries in 2012–2013. He co-authored 'Mob Programming: A Whole Team Approach' (2021) with Kevin Meadows and delivered the influential Agile 2014 conference talk that brought the practice to international attention. Zuill has spent decades as an Agile coach and software developer teaching teams to collaborate more deeply through shared work.

Status · Inspired by Woody Zuill’s work — not yet claimed. Are you Woody Zuill?

Primary sourceS-01

Mob Programming: A Whole Team Approach

by Woody Zuill

Originator of Mob Programming; co-author of 'Mob Programming: A Whole Team Approach' (2021, with Kevin Meadows); keynote speaker at Agile 2014 and international conferences; founder of mobprogramming.org community.

Read the original ↗

Citationmobprogramming.org

In the build queue

Be first to run it.

Mob Programming is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchMy team has a serious bus-factor problem — one engineer owns our most critical service and she's leaving in 6 weeks. I want to use mob programming to transfer that knowledge fast. Can you design our first session, including role cards, a rotation schedule for 5 people, and a remote setup guide?