„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:
- Ein Problem, ein Team: Fokus statt Fragmentierung
- Driver + Navigators: Klare Rollen, schnelle Rotation
- Kontinuierliches Review: Qualität eingebaut, nicht nachträglich
- Wissenstransfer: Alle lernen, niemand ist Flaschenhals
- 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.
