Mob Programming
Five people at one keyboard looks like waste to anyone who measures individual output. It turns out flow beats multitasking, and nothing spreads skills faster.
Overview
Mob programming puts the whole team on one problem at one computer, plugged into a large display. One person drives: hands on the keyboard, acting as a “smart input device.” Another navigates, deciding where the solution goes next. Everyone else watches, suggests, and waits for their turn. Roles rotate on a short timer, often every few minutes. Woody Zuill’s team at Hunter Industries made it famous, and Zuill now calls it software teaming.
The payoff is in what stops happening. No handoffs to break flow, no pull requests waiting a day for review, no knowledge stuck in one person’s head. A developer and a test engineer mobbing on test automation teach each other’s stack in an afternoon. In dojo work, mobbing is the default for the Do beat. It narrows the gap between novices and experts: drive when you’re unsure, navigate when you know the way. It’s also the fastest route we know to T-shaped teams.
Expect resistance. Mobbing goes against everything people have been taught about personal productivity, and “everyone’s watching me type” is a real fear. Give a team a few weeks before it decides, and give managers no veto based on a lack of research. After a session, close with a two-minute Fun, Done, Learn micro-retro.
Resources
- Woody Zuill and Kevin Meadows, “Software Teaming: A Mob Programming, Whole-Team Approach” (Independently published, 2022)
- Pair Programming — the two-person version
- Shifting Left to a T-shaped Team — mobbing to close a dev and test split
- Dojo Loop: Do — mobbing as the dojo’s daily driver