Mobbing
Home/ Mob Programming
Team Practice Remote Work Agile

Mob Programming

How remote mob programming improved our software delivery — a practical, first-hand account from delivering production software across time zones, with patterns, roles, and lessons that actually work.

First-Hand Account

"How Remote Mobbing Improved Software Delivery"

At first, it was unknown territory — a remote developer like me exploring the world of consultancy for overseas clients. I was part of a team working remotely from South Africa for a client in the Netherlands, developing code in a well-calculated project timeline that needed to yield great results in a very short lifecycle. We had to come up with a plan to achieve great code and great testing, and the only way to achieve both was to test mob programming.

At first it was uneasy. We split up to tackle sprint tasks as a team and quickly realised after one sprint that it was very unproductive when we paired up in mobs with more than two to three people.

So the conclusion was that it was most productive in groups of two to three — working on one task together. We were all on a joined Microsoft Teams "mob session" for 8+ hours a day with half-hour breaks. We could easily see how the Driver (sharing screen and typing) was being navigated by the Navigator and how a Third Eye caught missed implementations. It put the Driver on the spot to make good decisions in real time.

From the practical example: it took us only a couple of sprints to get so far ahead on the project schedule that our team was split to go help other teams that were behind. We advanced from backend API all the way through to Angular frontend — together, at pace.

Myth Busted

"Mobbing is not two or three people doing one man's work — it is a workforce completing tasks with quality control on the fly, which is hard to achieve in the agile world."

Mob Programming Session
2-3
Optimal mob size
8h
Daily sessions
1-2
Sprints to sync
Roles

The Three Mob Roles

Each role has a distinct responsibility. Rotate roles every task so everyone builds each skill.

Driver

Hands on Keyboard

The person sharing their screen and typing the code. The Driver executes the intent of the Navigator. This separation forces clear communication and reduces ego-driven coding.

Key Rule

Never be the Driver for more than one task in a row. Rotate to grow the whole team.

Navigator

Guides Direction

Directs the Driver at a higher level — what to implement, which approach to take, what test to write next. Thinks ahead while the Driver focuses on immediate typing. This is where senior developer impact multiplies.

Key Rule

Speak in intent ("create a method that validates the email") not in keystrokes.

Third Eye

Quality Watchdog

Optional but powerful. Watches overall code quality, catches missed test cases, spots potential bugs, suggests refactors, and can onboard to the codebase in real time. Great for training junior developers.

Key Rule

Speak up immediately when you spot a bug or missing edge case — don't wait for code review.

Analysis

Advantages & Disadvantages

Based on real-world experience — not theoretical. These are patterns observed over multiple project sprints.

Advantages

  • Better quality code delivered in shorter time — quality control happens live, not in review.
  • Teams of 2-3 are the productivity sweet spot — each member stays engaged and contributing.
  • Problems are solved constantly and instantly — no Slack thread waits while someone is blocked.
  • Refactoring happens sooner, speeding up delivery after a short initial ramp-up period.
  • Team members bond more deeply — shared ownership of every line of code.
  • Knowledge transfer is continuous — no more "only one person knows this module."
  • The whole team stays in sync at all times — stand-ups become much shorter.
  • Team members become better automated testers — TDD thinking is contagious in a mob.
  • Architects and leads can drop into a mob session and instantly help when needed.
  • No handover needed when someone leaves — the knowledge lives in the whole team.

Disadvantages & Watch-outs

  • Never have more than 3 people in a mob — productivity drops and someone always goes passive.
  • Mobbing exposes individual weaknesses — manage this with psychological safety and a growth mindset.
  • Conflicts must be resolved on the spot — there's no room to avoid disagreements in a mob.
  • Cultural and workplace politics surface quickly — requires a mature, respectful team culture.
  • Onboarding a new member slows current sprint delivery — but it pays off by sprint 2.
  • Never assign the same Driver to every task — rotate to avoid bottlenecks and resentment.
  • Introvert developers may find 8-hour mob sessions exhausting — schedule recovery time and solo tasks.
Best Practices

Running Great Mob Sessions

1
Pick one clear task per session

Decide which Story Board task to complete before opening the meeting. No scope creep mid-session.

2
Assign roles before starting

Assign Driver, Navigator, and optionally Third Eye at the start. Never let it be ambiguous. Rotate for every task.

3
Discuss, refactor, improve constantly

Review code as it is written. Surface simpler approaches immediately. The mob's strength is real-time code review without bureaucracy.

4
TDD as a shared rhythm

Red to Green to Refactor. Write the failing test first together, then implement. The Navigator keeps the TDD rhythm.

5
Take short, regular breaks

30-minute lunch, 10-minute breaks every 90 minutes. Respect the cognitive load and the team will stay sharp all day.

6
Most importantly — have fun

Mob sessions should be energising, not draining. Celebrate wins together — everyone owns that success equally.

Remote Tools

Remote Mob Setup

Remote mobbing requires the right tooling to feel as natural as sitting together. These are the tools we used effectively across South Africa and the Netherlands.

Microsoft Teams

Persistent meeting rooms for mob sessions. Screen share for the Driver, breakout rooms for parallel mobs.

VS Live Share

Real-time collaborative editing in VS Code. Navigator can place cursor to point — not just describe in words.

Azure Boards

Shared sprint board visible to the whole mob. Move cards during the session so everyone sees progress.

mob.sh / Mobster

CLI or desktop timer for automated Driver rotation. Removes the "who goes next?" discussion entirely.

Remote Mob Pro Tip

Use a dedicated always-on mob meeting link. Keep cameras on. The social presence is what makes remote mob work — don't let it devolve into a silent screen share.