Als wir uns von einem Kollegen auf einem Development Day erklären ließen, was Mob Programming ist – mehr als zwei Entwickler arbeiten gemeinsam am selben Computer am selben Stück Code – haben wir erstmal den Kopf geschüttelt. Unfug! Zeit- und Ressourcen-Verschwendung! Allein schon die Idee klingt merkwürdig! Punkt!
Damit war das Thema erledigt. Fast zumindest. Denn dann haben wir es einfach probiert.
Alle lieben Pair Programming
Wir mögen Pair Programming. Man nehme sich eine Aufgabe. Einer aus dem Pair – der Pilot – schnappt sich die Tastatur und legt los und spricht dabei darüber, was er gerade tut. Der andere – seines Zeichens Navigator – sitzt daneben und gibt den einen oder anderen Hinweis. Nach ein paar Minuten, oder wenn eine Methode oder ein Test fertiggestellt ist, wechseln die Partner die Rollen. Der andere schreibt und erklärt. Der eine gibt Tipps. Bis zum nächsten Wechsel. Und so weiter.
Nach der gemeinsamen Session wissen zwei Kollegen, wie die Aufgabe erledigt wurde. Die Lösung ist potenziell besser und in kürzerer Zeit entstanden als wenn sich nur einer der beiden um die Entwicklung gekümmert hätte. Und der entstandene Code hat durch das Vier-Augen-Prinzip wahrscheinlich auch eine gute Qualität. Der Wermutstropfen[1] – zumindest für die Management-Fraktion – ist, dass die Zeit von zwei Kollegen in dieselbe Aufgabe geflossen ist.
Pair Programming im Team?
Was zu zweit funktioniert, kann zu dritt oder zu viert auf keinen Fall funktionieren. Die Tastatur kann nur eine Person benutzen. Geben dann zwei/drei Navigatoren Tipps und streiten darüber, wer recht hat? Da kann der Pilot ja einfach weitertippen.
So ähnlich ist es bei uns gewesen. Wir waren zu dritt und wollten eine Aufgabe, an der bisher nur ein Kollege gearbeitet hatte, auch für die anderen Kollegen transparent machen und uns so die Möglichkeit geben, die Aufgabe verteilt zu Ende zu bringen. Diskutiert haben wir alle drei und waren mit der Lösung und der Methode – Mob Programming – am Ende auch zufrieden.
Was wir nicht beherzigt hatten, war, dass im Mob der Pilot eigentlich nur die Schreibkraft (Typist) ist und er das tippen soll, was die Kollegen im vorsagen. So werden eine zu große Meinungsvielfalt und zu lange Diskussionen vermieden. Die vielen Navigatoren gibt es ebenfalls nicht, sondern nur den Rest des Mob.
Besteht der Mob aus mehr als drei Personen, diskutiert der aktuelle Typist nicht mit, sondern setzt das um, was ihm der Rest des Mob souffliert. Bei drei Personen funktioniert das nicht! Wenn der Typist nur schreibt, haben wir Pair Programming erweitert um eine Schreibkraft. Don’t!
Wie beginnen?
Man nehme:
- Ein sinnvolles Thema: Ein Kata war aus unserer Sicht ungeeignet, weil er zum einen potenziell sehr kurz gewesen wäre und kein echter Problembezug zwischen Mob und Kata bestanden hätte.
- Einen Termin: Ein oder zwei Zeit-Slots von mehreren Stunden, in der das gestellte Thema vorangebracht werden kann.
- Einen Startschuss: Einfach das Ziel umreißen und die notwendigen Schritte kurz skizzieren.
Und los geht es. Irgendwann wird die Session unterbrochen und eine Pause gemacht. Und am Ende der zweiten Session wird gemeinsam entschieden, ob ihr
- weit genug gekommen seid,
- eine gute Lösung gefunden habt,
- eventuell Restarbeiten außerhalb des Mobs erledigen werden können.
Eine Reflexion darüber, was gut/schlecht lief und was beim nächsten mal besser gemacht werden kann, wird ebenfalls nicht schaden.
Nach sechs Mobbing Sessions
Nach den ersten Sessions haben wir gelernt, dass Mobbing für uns bedarfsorientiert gut funktioniert. Als Default-Arbeitsmodell kam es für uns nicht in Frage. Wir haben die Sessions oft zweigeteilt, z.B. vor und nach der Mittagspause, und sind damit gut gefahren. Die allgemeine Erschöpfung hielt sich in Grenzen.
Wir haben immer etwas voneinander gelernt und uns zum Beispiel methodisch einander angenähert. Feste Regeln zum Rollenwechsel zwischen Typist und Rest des Mob gab es nicht und waren auch nicht notwendig. Entscheidungen in der Gruppe wiederum waren notwendig und die Entscheidungsfindung manchmal anstrengend. Dennoch fühlte sich jede Mobbing Session und ihr jeweiliges Ergebnis am Ende gut an.
Eine generelle Entscheidung zu einem anschließenden Review haben wir nicht getroffen. Manchmal gab es eine manchmal nicht – irgendwie bedarfsorientiert.
Wäre da nicht die Ressourcen-Frage
Wie überzeuge ich meinen Manager, dass es sich lohnt, mit mehreren Kollegen an der selben Aufgabe zu arbeiten? Dafür gibt es genau ein schlagendes Argument: Speed!
Wer in einem Umfeld arbeitet, in dem die schnelle Bereitstellung von Features das Maß der Dinge ist, sollte sich mit Mob Programming zumindest auseinandersetzen.
Bei wem Geschwindigkeit kein triftiges Argument ist, sondern eine optimale Ressourcen-Auslastung wichtiges Kriterium ist, kann eventuell mit gleichmäßiger Wissensverteilung, Ausbildung weniger erfahrenerer Kollegen, höherer Code-Qualität, Schwarmintelligenz und Risikominimierung[2] punkten.
Mit Schwarmintelligenz ist die Qualität der zu erwartenden Lösung gemeint, die im Team erzielt in der Regel besser ist als bei Einzelkämpfern oder bei Paaren.
Unter Umständen ist Remote Mobbing – z.B. im Home Office – eine erstrebenswerte Alternative zu ständiger Reisetätigkeit zum Kunden.
Ein großer Mob heißt nicht zwingend hohe Geschwindigkeit. Je mehr Kollegen beteiligt sind, desto mehr Kommunikation findet statt und desto mehr Meinungen/Sichtweisen müssen adressiert werden. Eine Mob-Größe von drei bis maximal fünf Personen erscheint uns optimal. Ist der Mob größer, sinkt die Geschwindigkeit. Wer‘s nicht glaubt, probiere es aus!
Remote Mob Programming
Eines unserer Nachbar-Teams hat den Mobbing-Ansatz noch etwas weitergetrieben und eine Zeit lang Remote Mobbing praktiziert. Es gab eine kritische Projektphase, in der die entfernt voneinander sitzenden sechs Team-Mitglieder gemeinsam Remote arbeiten mussten. Dabei spielten die Locations der Kollegen – Krakau, Cottbus und Chemnitz – eine entscheidende Rolle.
Das Team arbeitete mehrere Tage am Stück an ihren Problemen: Einer tippte, die anderen diskutierten. Im Team hatte man sich darauf festgelegt, dass immer mindestens drei Team-Mitglieder online sein und als Mob arbeiten sollten. Die anderen hatten die Freiheit, sich für andere Aktivitäten ein paar Stunden auszuklinken.
Damit Remote Mob Programming funktioniert, müssen folgende Rahmenbedingungen erfüllt sein:
- Stabiler Videodienst
- Gute Netzwerkbandbreite
- Es muss möglich sein, die Steuerung an einen/alle Kollegen zu übergeben (z.B. mit ZOOM, WHEREBY, etc.).
- Die Benutzung der gleichen IDE hilft; das verwendete Betriebssystem war z.B. bei der Übergabe der Steuerung (fast) egal, weil die Tastaturkürzel zwischen z.B. MacOs und Windows für die gleiche IDE in der Regel ähnlich sind.
Eine Empfehlung für Remote Mob Programming ist, bei einem physischen Handover an einen Kollegen an seinem Rechner ebenfalls ein Git-Handover zu machen – also den aktuellen Code einzuchecken und die Build-Pipeline laufen zu lassen. Den entstehenden Zeitversatz sollte man ruhig in Kauf nehmen.
Aus dem Team kam ebenfalls die Empfehlung, Design Sessions bzw. Architecture Stories generell als Remote Mobbing Session durchzuführen – es lohnt sich.
Das Fazit zum Remote Mob Programming aus dem Team war: Guter Fortschritt, hohe Qualität und kein Bedarf, nach Abschluss einer Funktionalität einen Code Review durchzuführen.
Es gibt Teams, für die ist Remote Mob Programming das Default-Arbeitsmodell (innoq Podcast). Auch andere Spielarten wie Remote Mob Testing klingen spannend.
Flow – Der Mob schläft nie
Pair Programming ist schon bei einzelnen Sessions intensiv und anstrengend. Beide Partner diskutieren ständig, sind hoch konzentriert und lassen kein Auge vom Bildschirm. Wer das mal einen ganzen Tag gemacht hat und nicht gewohnt ist, will sich am Ende des Tages vielleicht nur noch ausruhen.
Eine Mob Programming Session ist ebenfalls intensiv. Aber gefühlt weniger intensiv als Pair Programming. Dafür gibt es eine Reihe von Gründen. Wenn der Rest des Mob aus mehreren Personen besteht, kann eine Person dem Typist diktieren, eine andere Person kann eben mal ein Detailproblem googeln. Die dritte Person lehnt sich kurz zurück und schaut nur zu? Kein Problem.
Einer aus dem Mob braucht eine kurze Pause? Ebenfalls kein Problem. Der verbleibende Mob bleibt am Ball. Oder es muss jemand ein kurzes Telefonat führen oder gar zum Meeting? Beim Pair Programming wäre jetzt Schluss. Beim Mob Programming können die verbleibenden Personen die Aufgabe weiterführen. Ist das Meeting vorbei oder das Telefonat zu Ende, kann sich der Rückkehrer vom Mob kurz „aufgleisen“ lassen und sollte nach kurzer Zeit inhaltlich wieder dabei sein.
Wie zu Beginn bereits kurz erwähnt, bietet es sich an, die Aufgabenverteilung nicht stur über einen längeren Zeitraum beizubehalten, sondern in relativ kurzen Abständen einmal durch zu wechseln. Das kann nach einer gelösten Teilaufgabe, einer bestimmten Anzahl an vergangenen Minuten oder frei nach Gefühl geschehen, wobei wir letzteres bevorzugten, um sich nicht zu stark von Regeln einschränken zu lassen.
Besonders für Berufsanfänger und Junior-Entwickler bietet diese Abwechslung einen hohen Lernfaktor, da Theorie und Praxis auf eine kurzweilige Art und Weise vermittelt werden – ohne dabei einen Teil zu dominant werden zu lassen. Denn lang bevor so etwas wie Langeweile aufkommen kann, hat man schon wieder eine andere Rolle. Des Weiteren bekommt man ziemlich exklusive Einblicke in den Arbeitsrhythmus der erfahreneren Kollegen, denn wann sonst schaut man ihnen so detailliert bei der Lösung einer Aufgabe über die Schulter? Selbst wenn man nur kleinere Tipps und Kniffe – wie beispielsweise bislang unbekannte IDE-Shortcuts – aus einer Session mitnimmt: gerade beim Einstieg in den Development-Alltag ist jede lehrreiche Erfahrung wertvoll.
Natürlich braucht auch der Mob insgesamt ausreichend Pausen: gern mit Fokus auf andere Themen um dann erholt die Arbeit im Mob und die Geschwindigkeit wieder aufzunehmen. Aber losgelöst von den Pausen ist ein Mob durchaus produktiver als ein Pair oder Einzelkämpfer. Produktiver heißt nach unserer Erfahrung nicht tatsächlich schneller. Ähnlich wie beim Pair Programming ist die Lösung nicht nur gefühlt besser, der Code hat eine höhere Qualität. Nachgelagerte Aufwände zur Qualitätssicherung sind geringer. Und das Wissen über die gelöste Aufgabe ist in jedem Fall besser verteilt als beim Einzelkämpfer oder beim Pair. Man sollte allerdings nicht in die Falle tappen und glauben, ein zusätzliches Review entfällt automatisch. Denn auch sechs oder mehr Augen können im Eifer des Gefechts Fehler übersehen, die einem etwas losgelöst und nach zwei Tagen “drüber schlafen” sofort auffallen.
Diskussionen müssen in den meisten Fällen time-boxed werden – sonst geht zu viel Zeit verloren, und die Qualität der Lösung wird auch nicht besser.
Wer mit Störungen von außerhalb des Mob zu kämpfen hat, kann einen Batman einsetzen. Der Batman ist der Scrum Master des Mob. Sein Job ist es, Störungen vom Mob fernzuhalten. Will jemand auf Ressourcen aus dem Mob zugreifen, kann er dies nur über den Batman tun. Die Batman-Rolle soll dabei im Mob mindestens täglich wechseln. Gleichzeitig muss außerhalb des Mob klar sein, wer aktuell die Batman-Rolle hat, um den Mob nicht unnötig zu stören. Und: Der Batman darf an dem Tag nicht Typist des Mob sein, sonst wird der Flow zusätzlich gestört.
Der Mobbing Space
Ein Mob braucht genug Platz zum Arbeiten. Ein normaler Büro-Arbeitsplatz ist dafür eher nicht geeignet, weil daran selten mehr als zwei Personen bequem Platz haben. Das Bilden einer zweiten Reihe ist keine Option.
Beim Mobbing ist Ruhe – für alle außerhalb des Mob – unbedingt notwendig. Wenn drei oder vier oder mehr Leute lautstark diskutieren, darf der Rest der Organisation nicht darunter leiden. Wer einen Meeting-Raum hijacken kann und das Setting im Meeting-Raum zu allem Überfluss noch zum Mob Programming passt, greift besser schnell zu.
Wenn der Mob umziehen muss, weil ein Meeting-Raum von anderen belegt ist, stört das den Flow. Versucht das zu vermeiden, indem ihr gebuchte Räume tauscht.
Der bzw. die Monitore sollen so groß wie möglich sein. So. Groß. Wie. Möglich. Nicht so groß wie nötig. Hat euer Mobbing Space einen 65 Zoll Fernseher, wird das nicht schaden. Im Idealfall befindet sich in eurem Raum ein fester Arbeitsplatz mit eingerichteten IDE und Netzwerkverbindungen, so dass ihr auf alle relevanten Ressourcen direkt zugreifen könnt, ohne eure eigenen Notebooks mit euch herumtragen zu müssen.
Zum Abschluss – Was noch übrig bleibt
Ein paar letzte Punkte lassen sich schwer in das bisher Beschriebene einordnen.
Versucht den Mob konstant zu halten. Ein wechselndes Mob-Team durchlebt denselben Team-Findungs-Prozess wie z.B. ein Scrum-Team. Ändert sich die Mob-Zusammensetzung, ändert sich die Dynamik im Mob und ihr verliert unter Umständen Geschwindigkeit.
Erlegt euch beim Mob Programming keine Regeln auf, die euch nicht helfen oder schlimmstenfalls sogar ausbremsen (Review, Typist diskutiert nicht mit, unsinniger Prozess etc.). Tut was euch am meisten hilft, und trennt euch von solchen Regel-Hindernissen. Mob Programmierung ist eher ein loses Konzept als ein streng reglementiertes Vorgehen – und das ist auch gut so!
[1] Gerüchteweise mögen Software-Entwickler keinen Wermut.
[2] Truck-Factor, siehe https://deacademic.com/dic.nsf/dewiki/1414528
