Pair and Mob Programming: A Practical Guide
How pair and mob programming work, the driver and navigator roles, when collaborative programming helps, tips for remote sessions, and answers to common objections.
The Agile Coach · Last reviewed October 21, 2026 · 5 min read
Picture two developers sharing one keyboard, or a whole team gathered around a single screen. To people used to the image of the lone programmer, this can look inefficient. Yet many teams deliberately work this way, at least some of the time, and report better code, faster learning and fewer handoffs.
Pair programming and mob programming are the two best-known forms of this collaborative style. Both are rooted in agile practice, and both are often misunderstood by people who have only heard about them secondhand.
This guide explains how each works, the roles involved, when they tend to help, how to do them remotely, and how to think about the objections teams commonly raise.
Pair Programming Basics
Pair programming means two people working together on the same task, at the same time, on one shared view of the code. A 2020 article on Martin Fowler's site by Birgitta Böckeler and Nina Siessegger notes that the term became widespread after Kent Beck described it in his writing on Extreme Programming in the late 1990s.
The classic structure uses two roles. The driver has the keyboard and focuses on the immediate step, talking through what they are doing. The navigator thinks at a higher level, watching for problems, considering the next steps and keeping the bigger picture in mind. Pairs switch roles frequently.
Variations on Pairing
The same article describes several styles, each suited to different situations:
- Driver and navigator: the classic split between tactical and strategic thinking.
- Ping-pong: one person writes a failing test, the other makes it pass, then they swap, which fits naturally with test-driven development.
- Strong-style pairing: often used when an experienced person pairs with a newer one, following the rule, attributed to Llewellyn Falco, that "for an idea to go from your head into the computer it MUST go through someone else's hands."
- Pair development: applying the same collaboration to research, planning or documentation, not only coding.
Mob Programming Basics
Mob programming extends the idea to a whole team, or a large part of one. In a 2012 post, Woody Zuill described it as all the brilliant people working on the same thing, at the same time, in the same space, and on the same computer. Zuill helped popularize the practice, including through an experience report at the Agile2014 conference. The phrase itself appeared earlier, in a piece by Moses Hohman and Andrew Slocum in the 2002 book Extreme Programming Perspectives.
Some practitioners prefer other names, such as ensemble programming, partly because "mob" can sound chaotic or hostile. Zuill's own website now describes his workshops as Software Teaming. The practice is the same whichever name a team uses.
In Zuill's description, one person drives at the keyboard while the others navigate, and ideas flow from the navigators' words through the driver's hands. The driver rotates on a timer; his team used 15 minutes, so everyone takes regular turns.
A hypothetical mob session might start with the team agreeing on a goal for the morning, such as fixing a stubborn bug, then setting a timer and a rotation order. Everyone sees the same screen, questions are answered on the spot, and decisions are made together, so there is little need for handoffs or follow-up meetings afterward.
When These Practices Help
Collaborative programming is not meant for every task. Teams tend to find it most valuable in situations like these:
- Complex or risky changes where a second set of eyes prevents costly mistakes.
- Onboarding new team members, who learn the system and team habits much faster.
- Spreading knowledge so that no single person is the only one who understands a critical area.
- Tackling problems with many unknowns, where discussion leads to better solutions.
- Reducing waiting, since work reviewed as it is written needs less separate review afterward.
Böckeler and Siessegger also highlight a quieter benefit: pairing acts as continuous code review. Instead of a finished change waiting in a queue for someone to read it later, a second person has already understood and questioned it as it was written. That suits continuous integration, where small changes are merged often and long waits for separate review would slow everything down.
Böckeler and Siessegger also note situations where pairing may add less, such as straightforward, repetitive tasks, and suggest that newer developers sometimes benefit from solo time to build confidence in solving problems independently.
Remote Pairing and Mobbing
Distributed teams pair and mob successfully, but they need good setups. Useful habits include using video along with screen sharing so participants can see each other's reactions, using tools that let more than one person control the code, keeping a shared online whiteboard for sketching ideas, and rotating who hosts the session so no one is stuck with a laggy connection. For mobs, a visible rotation timer and clear handoffs keep everyone involved.
Common Objections
The most common objection is cost: if two people work on one task, surely output halves. Advocates respond that typing is rarely the bottleneck in software work. Thinking, understanding, waiting for reviews and fixing defects take far more time, and collaboration can reduce those. Böckeler and Siessegger are candid that evidence from studies is limited and suggest teams try pairing and judge whether it works for them, rather than relying on claims either way.
Other objections are about people, and they deserve respect. Pairing is intense and tiring, so sessions need breaks and should not fill every hour. Some people need quiet time to think, and introverted team members may find constant collaboration draining. Differences in experience or seniority create power dynamics that can make one person dominate. Openly discussing these issues, agreeing on working agreements, and rotating partners helps.
A sensible approach is to treat pairing and mobbing as tools. A hypothetical team might mob for an hour when starting a tricky feature, pair on the riskiest parts, and work solo on routine tasks, then review the balance in its retrospectives.
Key takeaways
- Pair programming puts two people on one task with driver and navigator roles that switch often.
- Mob programming, also called ensemble programming or software teaming, involves the whole team at one screen with a rotating driver.
- These practices help most with complex work, onboarding and spreading knowledge.
- Remote sessions work well with good tools, video and clear rotation.
- Take objections seriously, use breaks and rotation, and let the team judge results from experience.
Sources
Spotted something out of date? Let us know.