Mob Programming: Warum 5 Entwickler an einem Computer produktiver sein können

„Das ist doch Verschwendung! Fünf Leute für eine Aufgabe?"

Das ist die typische erste Reaktion auf Mob Programming. Und sie ist verständlich – aber falsch.

Mob Programming (auch Ensemble Programming) ist eine Praxis, bei der das ganze Team gemeinsam an einem Computer arbeitet. Und entgegen der Intuition ist es oft effizienter als jeder für sich.

Was ist Mob Programming?

Die Grundidee

TRADITIONELL:
5 Entwickler → 5 Computer → 5 Features parallel

MOB PROGRAMMING:
5 Entwickler → 1 Computer → 1 Feature gemeinsam

Die Rollen

DRIVER:
- Sitzt am Keyboard
- Tippt den Code
- Setzt um, was die Navigators sagen
- Denkt NICHT selbst über die Lösung nach

NAVIGATOR(S):
- Das restliche Team
- Denken über die Lösung nach
- Geben dem Driver Anweisungen
- Diskutieren Ansätze

ROTATION:
Alle X Minuten (typisch: 5-15) wechselt der Driver.
Jeder ist mal Driver, mal Navigator.

Der Flow

1. Das Team sitzt zusammen (physisch oder remote)
2. Ein Problem/Feature wird besprochen
3. Driver öffnet Editor
4. Navigators besprechen den Ansatz
5. Driver tippt, was ihm gesagt wird
6. Nach X Minuten: Rotation
7. Wiederholen bis fertig

Warum Mob Programming funktioniert

Das Effizienz-Paradox

INTUITION:
5 Entwickler parallel = 5x Throughput

REALITÄT:
5 Entwickler parallel =
- 5x Code mit Bugs
- 5x Code Reviews
- 5x Merge Conflicts
- 5x „Wie funktioniert das nochmal?"
- 5x Kontext-Wechsel

MOB PROGRAMMING:
1x Code, aber:
- Weniger Bugs (kollektives Review)
- Kein Review nötig (wurde live reviewed)
- Keine Merge Conflicts
- Geteiltes Wissen
- Fokussierte Arbeit

Die echten Vorteile

1. Continuous Code Review

TRADITIONELL:
Schreiben → PR erstellen → Warten → Review →
Kommentare → Änderungen → Nochmal Review → Merge

MOB:
Schreiben + Review gleichzeitig
→ Probleme sofort erkannt
→ Kein PR-Ping-Pong

2. Wissenstransfer

TRADITIONELL:
„Nur Maria kennt diesen Teil des Codes"
→ Single Point of Failure

MOB:
Alle haben den Code geschrieben
→ Alle verstehen ihn
→ Kein Wissensmonopol

3. Onboarding

TRADITIONELL:
Junior liest Doku, versucht, fragt, wartet, versucht wieder

MOB:
Junior ist dabei, sieht wie Seniors denken,
fragt in Echtzeit, lernt Kontext
→ Wochen gespart

4. Fokus

TRADITIONELL:
Slack, E-Mail, „Kurze Frage?", Meetings...
→ Ständige Unterbrechungen

MOB:
Das ganze Team ist im selben Kontext
→ Keine Unterbrechungen
→ Deep Work als Gruppe

5. Bessere Lösungen

„Zwei Köpfe sind besser als einer"
→ Fünf Köpfe sind noch besser

Verschiedene Perspektiven + Live-Diskussion
= Bessere Entscheidungen

Wann Mob Programming Sinn macht

Gute Anwendungsfälle

✓ KOMPLEXE PROBLEME
  - Niemand hat alleine die Lösung
  - Viel Unsicherheit
  - Architektur-Entscheidungen

✓ KRITISCHE FEATURES
  - Sicherheitsrelevant
  - Hohe Business-Impact
  - Wenig Fehlertoleranz

✓ WISSENSTRANSFER
  - Onboarding neuer Teammitglieder
  - Neues Team arbeitet an unbekannter Codebase
  - Rotation über Teams

✓ BUGS IN PRODUCTION
  - Schnelle Diagnose nötig
  - Alle Perspektiven helfen

✓ SPIKE / EXPLORATION
  - Neue Technologie evaluieren
  - Prototyping
  - Unklare Anforderungen erforschen

Weniger geeignet für

✗ ROUTINE-AUFGABEN
  - Gut verstanden
  - Wenig Diskussionsbedarf
  - Einzelperson schafft es schnell

✗ UNABHÄNGIGE TASKS
  - Keine Überschneidung
  - Parallelisierung sinnvoll

✗ SCHREIBEN VON DOKUMENTATION
  - Weniger Code, mehr Text
  - Einer schreibt meist effizienter

✗ WENN DAS TEAM ES NICHT WILL
  - Mob braucht Buy-in
  - Erzwungener Mob funktioniert nicht

Mob Programming einführen

Schritt 1: Klein anfangen

NICHT:
„Ab Montag machen wir alles im Mob."

BESSER:
„Lasst uns diese Woche einen Mob-Nachmittag
ausprobieren. Wir nehmen [komplexes Feature]."

WARUM:
- Niedrige Einstiegshürde
- Team kann es erleben
- Feedback sammeln

Schritt 2: Setup vorbereiten

Physisch:

- Großer Monitor (oder Projektor)
- Bequeme Tastatur/Maus
- Platz für alle
- Timer sichtbar
- Whiteboards für Nebennotizen

Remote:

- Screen Sharing (VS Code Live Share, Tuple, etc.)
- Video für alle
- Timer-Tool (Mobster, Mob Timer)
- Breakout-Möglichkeit für Side-Discussions

Schritt 3: Regeln etablieren

TYPISCHE MOB-REGELN:

1. Driver tippt nur, was Navigators sagen
2. Rotation alle X Minuten (Timer!)
3. Jeder ist mal Driver
4. Keine Laptops nebenbei
5. Pausen sind okay (Pomodoro-Style)
6. Fragen sind willkommen
7. Wir diskutieren, nicht streiten

Schritt 4: Erste Session moderieren

FACILITATOR-ROLLE:

- Timer managen
- Rotation ansagen
- Bei Diskussionen: Fokus halten
- Stille Teammitglieder einbeziehen
- Laute Teammitglieder bremsen
- Retro am Ende

Schritt 5: Iterieren

NACH DER ERSTEN SESSION:

- Was hat funktioniert?
- Was war schwierig?
- Was ändern wir nächstes Mal?

TYPISCHE ANPASSUNGEN:
- Rotationszeit anpassen
- Andere Regeln
- Andere Problemtypen

Tipps für effektives Mob Programming

Für den Driver

DOS:
- Nur tippen, was gesagt wird
- Nachfragen wenn unklar
- Laut denken: „Also ich schreibe jetzt..."

DON'TS:
- Vorpreschen ohne Anweisung
- Diskussion anfangen (du bist zum Tippen da)
- Eigene Ideen umsetzen ohne Team

Für Navigators

DOS:
- Laut denken
- Alle einbeziehen
- Konkrete Anweisungen geben
- Auf verschiedenen Ebenen navigieren:
  - High-Level: „Wir brauchen eine Funktion für X"
  - Low-Level: „Schreib const result = ..."

DON'TS:
- Dem Driver die Tastatur wegnehmen
- Zu vage sein („mach das irgendwie")
- Monologe halten
- Die Session dominieren

Für das Team

DOS:
- Timer respektieren
- Pausen nehmen (alle 90 min mindestens)
- Retros machen
- Geduld haben (es braucht Übung)

DON'TS:
- Nebenbei am Laptop arbeiten
- Eine Person dauerhaft dominieren lassen
- Stillere Mitglieder ignorieren
- Zu lange ohne Pause

Varianten

Mini-Mob (Pair+)

3 Personen statt ganzes Team.

WANN:
- Team zu groß (>6)
- Nicht alle müssen dabei sein
- Spezifisches Expertise-Set nötig

Async Mob (Remote)

Nicht alle gleichzeitig, aber am selben Code.

WIE:
- Einer arbeitet, andere schauen zu (async Recording)
- Kommentare/Reviews in Echtzeit
- Rotation über Zeitzonen

HERAUSFORDERUNG:
- Weniger Diskussion
- Mehr Koordination nötig

Mob Learning

Fokus auf Lernen, nicht Output.

BEISPIEL:
- Neue Technologie als Mob erkunden
- Dokumentation zusammen durcharbeiten
- Coding Katas im Mob

Häufige Einwände

„Das ist langsamer"

KURZFRISTIG:
Ja, 5 Personen an 1 Feature ist langsamer
als 5 Personen an 5 Features.

LANGFRISTIG:
- Weniger Bugs → Weniger Bugfixing
- Kein Review-Overhead
- Geteiltes Wissen → Weniger Blocken
- Bessere Entscheidungen → Weniger Refactoring

RECHNUNG:
Feature traditionell: 5 Tage Dev + 2 Tage Review + 1 Tag Bugfix
Feature Mob: 3 Tage gemeinsam + 0 Tage Rest

→ Oft schneller End-to-End

„Introvertierte leiden"

REALITÄT:
- Manche Introvertierte lieben Mob (strukturierte Interaktion)
- Andere finden es anstrengend

LÖSUNGEN:
- Nicht jede Aufgabe im Mob
- Pausen ermöglichen
- Verschiedene Rollen (Driver ist ruhiger)
- Hybrid: Mob für komplexes, Solo für einfaches

„Ist doch Pair Programming"

UNTERSCHIED:

PAIR PROGRAMMING:
- 2 Personen
- Driver + Navigator
- Oft längere Sessions

MOB PROGRAMMING:
- 3+ Personen
- Driver + mehrere Navigators
- Kürzere Rotationen
- Mehr Perspektiven
- Besserer Wissenstransfer

MOB = PAIR + SCALE

„Remote funktioniert das nicht"

REMOTE MOB IST ANDERS, ABER MÖGLICH:

TOOLS:
- VS Code Live Share
- Tuple / Pop
- Screen Sharing + Video
- Mob Timer Tools

HERAUSFORDERUNGEN:
- Mehr Disziplin nötig
- Gutes Audio wichtig
- Video hilft

TIPP:
Remote Mob ist sogar einfacher für Rotation
(Keyboard-Übergabe = Rechte weitergeben)

Mob Programming und Kultur

Was Mob über ein Team aussagt

WENN MOB FUNKTIONIERT:
- Team vertraut sich
- Offene Kommunikation
- Psychologische Sicherheit
- Lernbereitschaft

WENN MOB NICHT FUNKTIONIERT:
- Ego-Probleme
- Mangelndes Vertrauen
- Angst, Fehler zu machen
- Hierarchie-Denken

Mob als Team-Building

MOB PROGRAMMING FÖRDERT:

- Beziehungen (man lernt sich kennen)
- Geteiltes Ownership
- Respekt für verschiedene Denkweisen
- Gemeinsame Standards
- Team-Identität

→ MOB IST NICHT NUR EINE CODING-PRAXIS
→ ES IST EINE TEAM-PRAXIS

Fazit: Weniger alleine, mehr zusammen

Mob Programming ist nicht für jede Situation. Aber für komplexe Probleme, Wissenstransfer und Teamaufbau ist es ein mächtiges Tool.

Die Kernprinzipien:

1. Ein Problem, ein Team: Fokus statt Fragmentierung
2. Driver + Navigators: Klare Rollen, schnelle Rotation
3. Kontinuierliches Review: Qualität eingebaut, nicht nachträglich
4. Wissenstransfer: Alle lernen, niemand ist Flaschenhals
5. Ausprobieren: Klein anfangen, iterieren

Deine Challenge:

Identifiziere ein komplexes Feature oder einen hartnäckigen Bug. Plane einen 2-Stunden-Mob mit deinem Team. Beobachte, was passiert.

Vielleicht ist es ineffizient. Vielleicht ist es transformativ. Du wirst es nur wissen, wenn du es versuchst.

Du willst mehr über Team-Kollaboration lernen? Unser Guide zu Psychological Safety zeigt, wie du eine Kultur schaffst, in der Mob Programming funktioniert.