Mob Programming Sessions | Team Coding Guide 2026
Run effective mob programming sessions with driver/navigator roles and rotation timers. GitScrum coordinates mob work for complex problems and onboarding.
9 min read
Mob programming brings the whole team together on complex problems. GitScrum helps coordinate mob sessions and track their outcomes.
Mob Programming Basics
What is Mobbing
MOB PROGRAMMING CONCEPT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRADITIONAL DEVELOPMENT: │
│ ───────────────────────── │
│ 4 developers → 4 different tasks → merge → review │
│ → conflicts → bugs → rework │
│ │
│ MOB PROGRAMMING: │
│ ───────────────── │
│ 4 developers → 1 task together → done right first time │
│ → no review needed → no knowledge silos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ THE MOB: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 👤 👤 👤 👤 ← Navigators (thinking, guiding) ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌───────┐ ││
│ │ │ ⌨️ │ ← Driver (typing only) ││
│ │ └───────┘ ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌───────────────────────────────────────┐ ││
│ │ │ BIG SCREEN │ ││
│ │ │ (everyone sees) │ ││
│ │ └───────────────────────────────────────┘ ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DRIVER: Types what navigators tell them │
│ NAVIGATORS: Think, discuss, direct the driver │
│ ROTATE: Driver changes every 5-10 minutes │
└─────────────────────────────────────────────────────────────┘
When to Mob
GOOD USES FOR MOBBING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BEST FOR: │
│ ───────── │
│ │
│ COMPLEX DESIGN DECISIONS: │
│ "How should we architect this feature?" │
│ Team reaches consensus while coding │
│ │
│ DIFFICULT BUGS: │
│ "No one can figure this out alone" │
│ Multiple perspectives help │
│ │
│ ESTABLISHING PATTERNS: │
│ "How will we do X across the codebase?" │
│ Everyone learns the pattern together │
│ │
│ ONBOARDING: │
│ "New person needs to learn our codebase" │
│ They observe and participate │
│ │
│ HIGH-STAKES CODE: │
│ "This is critical and risky" │
│ Collective ownership and review │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NOT GOOD FOR: │
│ ───────────── │
│ ❌ Simple, routine tasks │
│ ❌ Independent research │
│ ❌ When team is too large (max 5-6) │
│ ❌ All-day every day (exhausting) │
│ ❌ When quick feedback loops exist anyway │
└─────────────────────────────────────────────────────────────┘
Running a Mob Session
Session Structure
MOB SESSION STRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BEFORE (5-10 min): │
│ ────────────────── │
│ • Clear problem statement │
│ • Relevant context shared │
│ • Environment ready │
│ • Big screen / projector / shared screen │
│ │
│ DURING: │
│ ─────── │
│ • Rotate driver every 5-10 minutes │
│ • Navigators discuss approach │
│ • Driver types what mob agrees │
│ • Take breaks every 50-60 minutes │
│ │
│ AFTER (5-10 min): │
│ ───────────────── │
│ • Quick retrospective │
│ • Document decisions made │
│ • Identify follow-up work │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MOB SESSION TASK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MOB-001: Design payment processing flow ││
│ │ ││
│ │ PARTICIPANTS: @alex, @jordan, @pat, @sam, @taylor ││
│ │ DURATION: 3 hours (with breaks) ││
│ │ ││
│ │ PROBLEM: ││
│ │ Design and implement the new payment processing ││
│ │ flow with multiple providers and retry logic. ││
│ │ ││
│ │ GOAL: ││
│ │ Working implementation + team consensus on pattern ││
│ │ ││
│ │ SCHEDULE: ││
│ │ 9:00 - Context and problem review ││
│ │ 9:15 - Design discussion (whiteboard) ││
│ │ 9:45 - Start coding together ││
│ │ 10:45 - Break (10 min) ││
│ │ 10:55 - Continue coding ││
│ │ 11:45 - Wrap up, document decisions ││
│ │ ││
│ │ DRIVER ROTATION: Every 10 minutes ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Driver Rotation
ROTATION MECHANICS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIMER: │
│ ────── │
│ Set visible timer for 5-10 minutes │
│ When timer goes off, rotate driver │
│ No exceptions (keeps everyone engaged) │
│ │
│ ROTATION ORDER: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 10:00 10:10 10:20 10:30 10:40 ││
│ │ ───── ───── ───── ───── ───── ││
│ │ @alex → @jordan → @pat → @sam → @taylor → ││
│ │ ││
│ │ 10:50 11:00 11:10 ... ││
│ │ ───── ───── ───── ││
│ │ @alex → @jordan → ... ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DRIVER RULES: │
│ ───────────── │
│ • Type only what navigators tell you │
│ • Don't make decisions alone │
│ • Ask if unclear: "Where should I put this?" │
│ • Trust the mob │
│ │
│ NAVIGATOR RULES: │
│ ──────────────── │
│ • Give clear instructions │
│ • One voice at a time │
│ • Higher-level guidance (not character by character) │
│ • Discuss amongst yourselves first │
│ │
│ TIP: Use "strong-style" pairing │
│ "For an idea to go from your head to the computer, │
│ it must go through someone else's hands." │
└─────────────────────────────────────────────────────────────┘
Remote Mobbing
Virtual Setup
REMOTE MOB SETUP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TOOLS: │
│ ────── │
│ │
│ VS CODE LIVE SHARE: │
│ • Everyone can see and edit │
│ • Driver has cursor control │
│ • Shared terminal │
│ • Works great for mobbing │
│ │
│ VIDEO: │
│ • Cameras on (engagement) │
│ • Gallery view (see everyone) │
│ • Good audio (essential) │
│ │
│ TIMER: │
│ • mob.sh (open source mob timer) │
│ • cuckoo.team (web-based) │
│ • Simple phone timer │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REMOTE MOB FLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 1. Everyone joins video call ││
│ │ 2. Host starts VS Code Live Share ││
│ │ 3. All join the shared session ││
│ │ 4. Current driver has keyboard focus ││
│ │ 5. Timer runs for rotation ││
│ │ 6. On rotation, new driver takes focus ││
│ │ 7. Git handoff: mob.sh handles commits ││
│ │ ││
│ │ mob start → work → mob next → next driver ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIPS: │
│ ───── │
│ • Designate a facilitator │
│ • Shorter rotations (5 min) helps engagement │
│ • Take more breaks than in-person │
│ • Mute when not speaking (background noise) │
└─────────────────────────────────────────────────────────────┘
Making Mobbing Work
Facilitation
FACILITATING A MOB:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FACILITATOR RESPONSIBILITIES: │
│ ───────────────────────────── │
│ │
│ • Keep timer running │
│ • Call out rotations │
│ • Keep mob on topic │
│ • Ensure everyone participates │
│ • Call breaks │
│ • Manage disagreements │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ HANDLING CHALLENGES: │
│ │
│ SOMEONE DOMINATES: │
│ "Let's hear from others. @pat, what do you think?" │
│ "We've heard that perspective. Other ideas?" │
│ │
│ SOMEONE IS QUIET: │
│ "We haven't heard from @sam. Any thoughts?" │
│ Next driver rotation often helps │
│ │
│ DISAGREEMENT: │
│ "Let's try option A for 15 min, then reassess" │
│ "Can we do a quick experiment to see?" │
│ │
│ GOING OFF TRACK: │
│ "That's interesting, but let's park it" │
│ "How does this help solve our current problem?" │
│ │
│ DRIVER TYPING THEIR OWN IDEAS: │
│ "Remember, navigators direct. What does mob want?" │
│ Gentle reminder about strong-style │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ KEEP ENERGY UP: │
│ ───────────────── │
│ • Celebrate small wins │
│ • "Yes, and..." mindset │
│ • Regular breaks (every 50-60 min) │
│ • Snacks help (if in person) │
│ • End on time │
└─────────────────────────────────────────────────────────────┘
Measuring Value
Mob Outcomes
EVALUATING MOBBING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BENEFITS TO TRACK: │
│ ────────────────── │
│ │
│ IMMEDIATE: │
│ • Problem solved in session │
│ • Team aligned on approach │
│ • No review cycle needed │
│ • Fewer bugs in code │
│ │
│ LONGER TERM: │
│ • Knowledge spread across team │
│ • Patterns established │
│ • Better onboarding │
│ • Team cohesion │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MOB RETRO (End of session): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Quick check: ││
│ │ ││
│ │ ☐ Did we achieve our goal? ││
│ │ ☐ Did everyone contribute? ││
│ │ ☐ Was mobbing the right approach? ││
│ │ ☐ What would we do differently? ││
│ │ ││
│ │ LEARNINGS: ││
│ │ • Shorter rotations kept energy up ││
│ │ • Needed more context upfront ││
│ │ • Design discussion before coding helped ││
│ │ ││
│ │ NEXT TIME: ││
│ │ • 5 min rotations instead of 10 ││
│ │ • Prepare design beforehand ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ WHEN MOBBING ISN'T WORKING: │
│ ─────────────────────────── │
│ Signs: People disengaged, one person doing all thinking │
│ Fixes: Shorter rotations, better facilitation, smaller mob│
│ Maybe: Mobbing isn't right for this problem │
└─────────────────────────────────────────────────────────────┘