10 min read • Guide 835 of 877
Mob Programming Practices
One keyboard, whole team. GitScrum helps coordinate mob sessions and track their impact on quality and team capability.
Mob Programming Basics
How It Works
MOB PROGRAMMING EXPLAINED:
┌─────────────────────────────────────────────────────────────┐
│ │
│ THE SETUP: │
│ ────────── │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ │ │
│ │ LARGE SCREEN │ │
│ │ │ │
│ └───────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌────┐ ┌────┴────┐ ┌────┐ │
│ │ 🧑 │ │ 🧑💻 │ │ 🧑 │ │
│ │ │ │ DRIVER │ │ │ │
│ └────┘ └─────────┘ └────┘ │
│ Navigator Types Navigator │
│ only │
│ ┌────┐ ┌────┐ │
│ │ 🧑 │ │ 🧑 │ │
│ │ │ │ │ │
│ └────┘ └────┘ │
│ Navigator Navigator │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ROLES: │
│ ────── │
│ DRIVER: Types code, doesn't decide what to type │
│ NAVIGATORS: Direct the driver, discuss solutions │
│ │
│ "For an idea to get into the computer, it must go │
│ through someone else's hands." │
└─────────────────────────────────────────────────────────────┘
Session Structure
Running a Mob
MOB SESSION FLOW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SESSION STRUCTURE (2 hours): │
│ ──────────────────────────── │
│ │
│ 0:00 - 0:05 SETUP │
│ • Define goal for session │
│ • Ensure everyone can see screen │
│ • First driver at keyboard │
│ │
│ 0:05 - 0:50 MOB WORK (Block 1) │
│ • Rotate driver every 10-15 min │
│ • 3-4 rotations │
│ • Navigators guide work │
│ │
│ 0:50 - 1:00 BREAK │
│ • Stand, stretch, bio break │
│ • Quick sync on progress │
│ │
│ 1:00 - 1:50 MOB WORK (Block 2) │
│ • Continue rotating │
│ • 3-4 more rotations │
│ │
│ 1:50 - 2:00 WRAP UP │
│ • What did we accomplish? │
│ • What's left? │
│ • How did session work? │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TIMER: │
│ ────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🕐 Driver rotation: 12:00 ││
│ │ ││
│ │ Current driver: Alex ││
│ │ Next up: Jordan ││
│ │ ││
│ │ [Time visible to everyone] ││
│ │ [Strict rotation, no exceptions] ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
When to Mob
Best Use Cases
WHEN MOB PROGRAMMING SHINES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ HIGH VALUE CASES: │
│ ──────────────────── │
│ │
│ COMPLEX PROBLEMS: │
│ "This is too hard for one person" │
│ → Multiple perspectives find better solutions │
│ │
│ KNOWLEDGE TRANSFER: │
│ "Only Sam knows how this works" │
│ → Everyone learns by doing together │
│ │
│ ONBOARDING: │
│ "New team member joining" │
│ → Learn codebase, team practices, relationships │
│ │
│ CRITICAL CODE: │
│ "This absolutely cannot have bugs" │
│ → Multiple reviewers in real-time │
│ │
│ DESIGN DECISIONS: │
│ "We need to agree on architecture" │
│ → Build consensus while building │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ LESS EFFECTIVE FOR: │
│ ────────────────────── │
│ │
│ ROUTINE WORK: │
│ Simple, well-understood tasks │
│ → Solo work is more efficient │
│ │
│ PARALLEL TASKS: │
│ Independent work with no overlap │
│ → Split up and mob only on integration │
│ │
│ DEEP RESEARCH: │
│ Initial exploration phase │
│ → Research individually, mob on synthesis │
│ │
│ BALANCE: Not everything, not nothing │
│ Mob strategically, solo when appropriate │
└─────────────────────────────────────────────────────────────┘
Driver/Navigator
Role Dynamics
DRIVER AND NAVIGATOR ROLES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ THE DRIVER: │
│ ─────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RESPONSIBILITIES: ││
│ │ • Type what navigators direct ││
│ │ • Ask clarifying questions ││
│ │ • Stay focused on current task ││
│ │ ││
│ │ DON'T: ││
│ │ • Make decisions about what to type ││
│ │ • Go off on tangents ││
│ │ • Ignore navigator input ││
│ │ ││
│ │ THE DRIVER IS A "SMART KEYBOARD" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ THE NAVIGATORS: │
│ ─────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RESPONSIBILITIES: ││
│ │ • Think ahead about solution ││
│ │ • Direct driver clearly ││
│ │ • Discuss approaches among navigators ││
│ │ • Catch errors in real-time ││
│ │ ││
│ │ COMMUNICATION LEVELS: ││
│ │ ││
│ │ INTENT (high level): ││
│ │ "Let's add a method to validate the email" ││
│ │ ││
│ │ LOCATION (medium): ││
│ │ "In the User class, after the constructor" ││
│ │ ││
│ │ DETAILS (low level, when needed): ││
│ │ "Type: function validateEmail opening paren..." ││
│ │ ││
│ │ Start at intent level, get detailed if driver stuck ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ HEALTHY DYNAMICS: │
│ ───────────────── │
│ Everyone takes turns as driver │
│ Navigators discuss, driver implements │
│ Respectful disagreement is productive │
│ Quiet voices are drawn in │
└─────────────────────────────────────────────────────────────┘
Mob Challenges
Common Issues
OVERCOMING MOB CHALLENGES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CHALLENGE 1: DOMINANT PERSONALITY │
│ ───────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SYMPTOM: One person directing everything ││
│ │ ││
│ │ SOLUTIONS: ││
│ │ • Rotate "navigator lead" role ││
│ │ • Facilitator asks quiet people directly ││
│ │ • "What do others think before we proceed?" ││
│ │ • Written idea sharing when needed ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CHALLENGE 2: FEELS SLOW │
│ ──────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SYMPTOM: "I could do this faster alone" ││
│ │ ││
│ │ REALITY: ││
│ │ • Less rework (caught errors early) ││
│ │ • No code review delay ││
│ │ • Knowledge shared immediately ││
│ │ • Fewer bugs in production ││
│ │ ││
│ │ MEASURE: Total time to production, not just coding ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CHALLENGE 3: ENERGY DRAIN │
│ ───────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SYMPTOM: Team exhausted after mobbing ││
│ │ ││
│ │ SOLUTIONS: ││
│ │ • Regular breaks (every 45-60 min) ││
│ │ • Limit mob time (not all day) ││
│ │ • Comfortable room setup ││
│ │ • Mix mob and solo work ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CHALLENGE 4: REMOTE MOBBING │
│ ─────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TOOLS: ││
│ │ • VS Code Live Share ││
│ │ • mob.sh CLI tool ││
│ │ • Tuple/Pop for pairing ││
│ │ ││
│ │ TIPS: ││
│ │ • Cameras on (helps read the room) ││
│ │ • Good audio essential ││
│ │ • Clear hand-off rituals ││
│ │ • More frequent breaks ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Measuring Impact
Mob Effectiveness
TRACKING MOB RESULTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUALITY METRICS: │
│ ──────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ COMPARISON: Mob vs Solo Work ││
│ │ ││
│ │ METRIC MOB SOLO ││
│ │ ────── ─── ──── ││
│ │ Bugs found in review 0.5 2.3 ││
│ │ Bugs in production 0.2 1.1 ││
│ │ Rework rate 5% 18% ││
│ │ Time to production 3 days 5 days ││
│ │ ││
│ │ Mob code tends to be higher quality on first pass ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ KNOWLEDGE METRICS: │
│ ────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BEFORE MOB SESSIONS: ││
│ │ "Only 1 person can work on payment system" ││
│ │ ││
│ │ AFTER 4 WEEKS OF MOBBING: ││
│ │ "3 team members can work on payment system" ││
│ │ ││
│ │ Bus factor improved from 1 to 3 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TEAM HEALTH: │
│ ──────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Survey: "How well do you understand the codebase?" ││
│ │ ││
│ │ Before mobbing: 3.2/5 average ││
│ │ After 6 weeks: 4.3/5 average ││
│ │ ││
│ │ Survey: "How comfortable asking for help?" ││
│ │ ││
│ │ Before: 3.0/5 ││
│ │ After: 4.5/5 ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Getting Started
Introducing Mobbing
STARTING MOB PROGRAMMING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PHASE 1: EXPERIMENT (Week 1-2) │
│ ────────────────────────────── │
│ • Schedule 2-hour mob session │
│ • Pick a real but low-stakes problem │
│ • Explain roles before starting │
│ • Retro after session │
│ │
│ PHASE 2: REGULAR PRACTICE (Week 3-6) │
│ ──────────────────────────────────── │
│ • Weekly mob session (standing time) │
│ • Vary what you work on │
│ • Adjust timing/structure based on retros │
│ │
│ PHASE 3: INTEGRATE (Week 7+) │
│ ──────────────────────────── │
│ • Mob is a tool in your toolkit │
│ • Use strategically, not everything │
│ • Team decides when to mob │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FIRST SESSION CHECKLIST: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BEFORE: ││
│ │ ☐ Large screen everyone can see ││
│ │ ☐ Comfortable seating arrangement ││
│ │ ☐ Timer for rotations ││
│ │ ☐ Clear problem to solve ││
│ │ ☐ Everyone knows roles ││
│ │ ││
│ │ DURING: ││
│ │ ☐ Strict rotation timing ││
│ │ ☐ Everyone participates ││
│ │ ☐ Breaks every 45-60 min ││
│ │ ││
│ │ AFTER: ││
│ │ ☐ Quick retro (10 min) ││
│ │ ☐ What worked? ││
│ │ ☐ What to try differently? ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘