Working Together in Real Time: Pair, Mob, Shadowing and Swarming

Pair programming, mob, shadowing, swarming: the four ways of working together in real time, their variants, their pitfalls, and how to choose the one that fits your situation.

In the guide to collaboration modes, we set out a rule: tacit knowledge travels only through contact. Synchronous modes are therefore irreplaceable — but they come at a cost, and that cost is scary. “Two people on a single task means halving productivity.” This article proves the opposite and details the four main ways of working together in real time, with their variants and their pitfalls.

I. Why synchronous work is irreplaceable  

An expert diagnosing an outage isn’t following a procedure: they eliminate hypotheses at a speed they couldn’t even describe themselves. Ask them to write down their method and they’ll hand you an impoverished list. That knowledge — the order in which you look at things, what triggers a suspicion — exists only in action.

That is the whole point of synchronous modes: they don’t transmit content, they expose a reasoning as it unfolds. Watching someone hesitate, backtrack, rule out a lead: that’s where tacit knowledge passes.

As for the cost, it’s almost always miscalculated. People compare the time spent writing the code, when they should count the whole: the code review that becomes unnecessary, the back-and-forth avoided, the bugs not introduced, the colleague trained along the way. Working in pairs doesn’t double the cost of a feature — it shifts part of the effort upstream, where it’s cheapest.

II. Pair programming  

Two people, one keyboard. It’s the baseline mode, and the most flexible.

The classic setup rests on two roles:

• The driver holds the keyboard and focuses on the immediate move: writing code that works.
• The navigator keeps the big picture: the direction, the forgotten cases, the consistency with the rest.

The golden rule is regular rotation. Without it, one becomes an operator and the other a spectator — and the transfer stops. A switch every ten to fifteen minutes is enough to keep both brains engaged.

Three variants are worth knowing:

• Ping-pong pairing — pairing in the TDD style: A writes a failing test, B writes the code that makes it pass, then B writes the next test, and so on. It’s the best way to pass on testing discipline, because it’s practiced rather than explained.
• Strong-style pairing — formulated by Llewellyn Falco: “for an idea to go from your head to the computer, it must go through someone else’s hands.” The one who knows speaks, the one who learns types. Counterintuitive, but formidably effective when the experience gap is wide: the novice can’t stay passive.
• Promiscuous pairing — frequent rotation of pairs within the team (Arlo Belshee). Knowledge stops circulating between two people and starts irrigating the whole group.

III. Mob programming  

The whole team, one problem, one screen. What Woody Zuill popularized under the name mob programming (also called ensemble programming).

The format resembles pairing, at group scale: one person at the keyboard, the others thinking and guiding, with a timed rotation of the driver — often every five to ten minutes. The timer isn’t a gimmick: it prevents anyone from monopolizing the keyboard and ensures everyone goes through the physical act.

When to use it. The mob isn’t made for mass production. It excels at:

• the start of a project or a module, when conventions are being set;
• an architecture decision that commits everyone;
• a critical system that too few people know;
• the arrival of several new hires at once.

On these subjects, it does in a morning what weeks of documentation and reviews wouldn’t: it aligns the whole team at once.

Its real cost is lower than it seems, because it absorbs activities you pay for elsewhere: no more code review to do, no more alignment meeting, no more context handoff. It remains tiring, though — more on that in section VII.

IV. Shadowing  

Shadowing is the simplest mode, and probably the most underused. It unfolds in two stages:

1. Shadowing — the apprentice observes the expert at work, without stepping in. They watch an on-call shift, a diagnosis, a deployment. The expert narrates what they do and, above all, why they do it.
2. Reverse shadowing — the roles swap. The apprentice acts, the expert observes without taking back control, and steps in only if there’s a real risk.

That second stage is the one almost always skipped, and yet it’s the only one that proves the transfer happened. Observing gives the illusion of knowing; doing reveals what you don’t know yet.

Shadowing shines especially for operational knowledge — incidents, ops procedures, rare gestures — that you don’t practice often enough to acquire any other way.

V. Swarming  

Swarming is the convergence of the whole team on a single blocking item. The difference from the mob lies in its trigger: the mob is a chosen way of working, swarming is a reaction to a situation.

You use it when:

• a task blocks the whole chain and prevents the rest from moving;
• an incident calls for several eyes in parallel;
• a piece of work has dragged on too long in a single person’s hands.

Its knowledge-transfer virtue is a side effect — but a powerful one: by leaning on a subject together, the team discovers an area of the system that few mastered. It’s often during a swarm that you realize how much a component rested on a single head.

VI. Which mode for which situation?  

Last row included: not everything deserves to be done together. Synchronous work is reserved for what’s new, critical, or poorly shared.

VII. Pitfalls to avoid  

• The passive pair. If the navigator is looking at their phone, you’re paying two people for one person’s work. Regular rotation is the cure.
• The permanent mob. The mob is intense; running it all day, every day, exhausts the team. Many work in sessions of two to three hours, a few times a week.
• The expert who grabs the keyboard back. In reverse shadowing as in pairing, it’s the reflex that kills the transfer: you save ten minutes and lose the learning. Let the other make mistakes — that’s the price of knowledge.
• The absence of rotation. Always the same two people pairing means a bus factor of 2 instead of 1. Progress, but not a solution.
• Synchronous work without trust. These modes expose you: you make mistakes in front of others. Without psychological safety, no one takes the keyboard, and the practice becomes theater.
• Improvised remote work. Remotely, these modes work very well — provided you equip the sharing (collaborative editing, smooth screen sharing) and keep the camera on. A remote pair without a face becomes a monologue.

Conclusion  

Pair, mob, shadowing, swarming: four ways of putting several brains on the same problem at the same moment, and four ways of passing on what no document will retain. They don’t compete — a mature team combines them according to context, and reserves them for what truly deserves them.

Above all, remember this: these modes don’t cost time, they shift it. The time you invest in working together today, you won’t pay tomorrow in endless reviews, in bugs, or in the departure of an expert who takes everything with them.

Useful links  

• Mob Programming — Woody Zuill
  The blog of the person who popularized the mob: principles, format, and field experience with the practice in a team.

• Llewellyn’s Strong-Style Pairing
  The original article on “strong-style” pairing: the idea must go through the other person’s hands, with the practical rules to apply it.

• On Pair Programming — Martin Fowler (Böckeler & Siessegger)
  A complete overview of pairing: styles, benefits, common difficulties, and advice for practicing it remotely.

• Industrial Logic — Articles & papers
  Industrial Logic’s library of articles on agile practices, including pair programming and pair rotation.