Mob Programming

Purpose

Mob Programming (ensemble programming) puts the entire team around one screen. One person drives (types), the rest navigate (think and direct). It eliminates hand-offs, spreads knowledge, and produces high-quality code with built-in review.

At a glance

How to run

1. Setup (5 min) — Choose the task. Set up one computer with the codebase, projector or screen share, and a timer.
2. Assign first driver (1 min) — The driver only types what the navigators tell them. They do not make design decisions.
3. Navigate and code (rotation cycles) — Navigators discuss the approach and tell the driver what to type. Use strong-style pairing: "For an idea to go from your head into the computer, it must go through someone else's hands."
4. Rotate driver (every 10–15 min) — Timer rings, the driver becomes a navigator, the next person takes the keyboard.
5. Break (every 60 min) — Take a 10-minute break. Mob sessions are cognitively intense.
6. Debrief (10 min) — What did we learn? What worked? What should we change next time?

Materials needed

• One workstation with codebase set up
• Projector or large screen (or screen share for remote)
• Rotation timer (Mobster, mob.sh, or a simple kitchen timer)
• Comfortable seating for the whole team

Pitfalls & common mistakes

• Driver goes solo — The driver must only implement what the navigators say. If they go rogue, gently redirect.
• One person dominates navigation — Encourage everyone to contribute. Use round-robin for navigation turns if needed.
• Sessions too long without breaks — Fatigue kills the quality advantage. Break every hour.
• Choosing trivial tasks — Mob programming shines on complex, ambiguous tasks. Do not mob on boilerplate.

Inclusion & accessibility

• Ensure the screen is large enough and font size is readable for everyone.
• For remote mobs, use a tool that transfers control smoothly.
• Encourage all navigators to speak, including those less experienced.
• Consider using a designated facilitator to manage turn-taking if the team is large.

Variations

• Pair programming — Two people instead of the whole team.
• Mob with a facilitator — A non-coding facilitator manages rotations and energy.
• Remote mob — Use VS Code Live Share, Tuple, or similar for seamless remote driver rotation.
• Randori — Coding dojo style: audience can swap in as driver.

When NOT to use this

• For simple, well-understood tasks that one person can handle quickly.
• If team members are strongly opposed — mob programming requires buy-in to be effective.
• If the team is larger than 7 — split into two mobs.

Source & further reading

• Zuill, W. (2014). "Mob Programming — A Whole Team Approach." mobprogramming.org
• Zuill, W. & Meadows, K. (2016). *Mob Programming Guidebook*.