Mob Programming 2/3 - Can You Mob Without a Room?

At first, remote mob programming sounds like a contradiction. Same thing, same time, same space, same computer - how can a whole team share one computer if they’re not even in the same room?

That’s the question the authors of Remote Mob Programming set out to answer. Their experience shows that with the right habits and setup, a distributed mob can be just as effective - and sometimes even more flexible - than one sitting around a shared monitor.

What’s different when the mob is remote?

The basics don’t change: one Driver at the keyboard, several Navigators thinking ahead, rotations every few minutes, and a daily retro. But a few things become even more important online:

• Everyone remote: mixing some people in a room with others online creates information gaps. To keep things fair, the whole team needs to join remotely.
• Connection quality: laggy screen sharing breaks the flow. Good tools and stable audio matter.
• Staying engaged: without the cues of being physically present, it’s easier to drift off.

These challenges aren’t dealbreakers - they just mean a bit more care is needed.

How to make it work

From Remote Mob Programming, a few practices make a big difference:

• Start simple: screen sharing works fine at first. Later, try cloud IDEs or git handovers with WIP commits on temporary branches.
• Stick to rotations: 10 minutes per Driver is a good rhythm. Short, regular switches keep energy high.
• Cameras on: seeing each other helps with communication and builds trust.
• Good audio: clear sound, muting when not speaking, and avoiding cross-talk keeps things smooth.
• Facilitation: one person helps keep rotations moving, checks in with quieter voices, and reminds everyone to take breaks.
• Overlap in time: mobbing works best if everyone has a shared window of working hours.
• Meet in person too: at least once a month, get together on-site. Face-to-face time strengthens cohesion and makes remote sessions feel more natural.

Why do this remotely?

All the benefits of in-person mobbing are still there: faster learning, quick decisions, breaking down silos. Going remote adds a few more:

• Inclusivity: you don’t need to be in the same office. Everyone can take part equally.
• Resilience: work continues smoothly even when people travel or offices are closed.
• Broader input: it’s easier to involve testers, designers, or ops engineers from other locations for a session.

Common pitfalls (and fixes)

• Tiredness from long calls → Keep sessions short (around 90 minutes) and take breaks.
• Tech hiccups → Always agree on a fallback tool.
• Unclear roles → Explain the difference between Driver and Navigator before you start.
• Overuse → Save mobbing for complex work where shared context is crucial.

Closing

Remote mob programming isn’t second-best. Done right, it gives teams all the benefits of mobbing, plus the reach and flexibility of working across locations.

If you’d like to experiment too: run one 90-minute remote mob this week. Keep everyone remote, rotate every 10 minutes, use screen sharing or git handovers, and finish with a short retro. Then compare the outcome to your usual way of working.

Next up, I’ll explore how these principles carry over into work beyond programming - from design sessions to incident reviews and onboarding.