9 min read • Guide 795 of 877
Mob Programming Sessions
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 │
└─────────────────────────────────────────────────────────────┘