Mob Programming, eine Form des Problemlösens, erfreut sich an zunehmender Popularität. Jean-Claude Brantschen besuchte 2021 einen Workshop, wobei alle Übungen mit Mob Programming durchgeführt wurden. Wie diese Technik genau funktioniert und was es zu beachten gilt, liest du in diesem Blogpost.
Mob Programming wurde von Woody Zuill erfunden und erfreut sich in den letzten Jahren an zunehmender Popularität. Die Ausgangslage besteht darin, dass mehrere Personen (wir nennen sie mal A bis E) gemeinsam ein Problem lösen. Dabei sollen abwechselnd alle Personen involviert werden. Das Ganze wird in ein Setup und beliebig viele Iterationen aufgeteilt.
Setup mit initialer Rollenverteilung und Vorstellungsrunde
Zuerst wird die Reihenfolge und die Rollen (siehe weiter unten) auf die teilnehmenden Personen verteilt. Dies kann mit einer Liste oder mit Unterstützung eines Tools erfolgen. Als Beispiel eines Tools möchte ich Mobster erwähnen, das neben der Liste noch weitere Funktionalitäten (Timer, etc.) bietet. Danach müssen sich die Teilnehmenden darauf einigen, wie lange eine Iteration dauern soll. Über die Dauer der Iteration kann die Intensität gesteuert werden. Je kürzer die Dauer, desto intensiver. In unserem Workshop legten wir anfangs zehn Minuten fest. Als sich die Gruppe eingespielt hatte, verkürzten wir auf zwei Minuten.
Es gibt drei verschiedene Rollen, die dynamisch den einzelnen Personen zugeordnet werden:
• Writing: Diese Person ist ein „Driver“. Sie schreibt den Code.
• Talking: Diese Person ist ein „Navigator“. Sie sagt dem „Driver“/“Writer“, was sie/er schreiben soll.
• Next: Diese Person ist in der Warteposition und muss zu dieser Zeit noch nichts tun.
Die Aufsplittung auf „Driver“ und „Navigator“ basiert auf der Idee des „Strong Style Pairing“. Im klassischen Pair Programming schreibt oft die Person, die die Idee hatte, den Code nieder. Beim Mob Programming wird dies auf zwei Personen aufgeteilt. Die Person, die die Idee hat (Navigator), sagt einer anderen Person (Driver), was sie tun muss, um dessen Idee umzusetzen. Es sind also zwei Personen aktiv involviert und das Wissen wird breiter verteilt.
Beim Setup bekommen die ersten drei Personen auf der Liste eine Rolle.
- Person A bekommt die Rolle „Writing“.
- Person B bekommt die Rolle „Talking“.
- Person C hat die Rolle „Next“.
- Personen D und E haben aktuell keine Rollen.
Vorstellungsrunde
Jede Iteration startet mit einer kurzen Vorstellungsrunde. Jede Person, die eine aktuelle Rolle hat, stellt sich ganz kurz mit Namen und Rolle vor. Wichtig ist, dass die Reihenfolge der Rollen immer gleich ist: „Writer“, „Talking“, „Next“.
In unserem Beispiel sieht dies dann so aus:
- A sagt: Ich heisse A und ich schreibe.
- B sagt: Ich heisse B und ich rede.
- C sagt: Ich heisse C und ich bin die/der Nächste.
So weiss jedes Teammitglied, wie die Rollenverteilung aussieht und wann es selbst ein/e Rollenträger/in wird.
Iterationen und Rotationen
Wir starten mit der ersten Iteration und einer anschliessenden Rotation.
1 | Erste Iteration
Die Iteration besteht aus folgenden Schritten:
- Vorstellungsrunde
- Wir starten einen Timer mit der vorher definierten Dauer.
- Person B überlegt sich einen ersten Schritt zum Lösen des Problems und diktiert A, was sie aufschreiben soll. Wichtig dabei ist die strikte Trennung: B denkt und redet, A schreibt.
- Wenn der Timer abgelaufen ist, ist die Iteration fertig und es kommt zur ersten Rotation.
2 | Erste Rotation
Rotation heisst: Die Rollen werden um eine Position nach rechts verschoben.
- A hat keine aktive Rolle mehr.
- B hat die Rolle „Writing“, C „Talking“ und D ist „Next“.
3 | Weitere Iterationen
Es gibt nun beliebig viele weitere Iterationen. In jeder Iteration erfolgt derselbe Ablauf:
- Vorstellungsrunde
- Timer starten
- Der „Writer“ (Driver) hört auf den „Navigator“ und schreibt. Der „Navigator“ lässt seine Idee durch den „Driver“ umsetzten, indem er genaue Anweisungen gibt. „Next“ befindet sich in den Startlöchern.
- Wenn der Timer abläuft, gibt es eine weitere Rotation.
Zu beachten ist: Wenn die letzte Person die Rolle „Next“ hat und die Iteration beendet wurde, kommt es zu einer speziellen Rotation. Die erste Person in der Liste wird „Next“. Wir rotieren quasi wieder zum Anfang der Liste.
Nach den Iterationen ist dann das Problem gelöst oder die Zeit des Workshops abgelaufen. Auf jeden Fall haben wir eine Lösung oder zumindest einen Lösungsansatz, bei welchem das gesamte Team mitgearbeitet hat. Und das gesammelte Wissen ist breit über das gesamte Team gestreut.
Fazit
Zu Beginn war ich skeptisch, da ich einige Hürden sah:
- Iterationen sind nur wenige Minuten lang. Was kann ich in nur 10 Minuten erreichen?
- Zudem gibt es eine strikte Rollenteilung „eine Person redet und die Andere schreibt“. Dies führt dazu, dass keine Diskussionen entstehen. Ich war skeptisch, ob ohne Diskutieren und somit auch ohne Brainstorming Lösungen für die Probleme gefunden werden können.
- Alle arbeiten an einem Problem. Ich war unsicher, ob diese Vorgehensweise effizient ist, da es oft bereits zu zweit schwierig ist, an einem technischen Problem zu arbeiten.
Im Verlaufe des Workshops änderte sich jedoch meine Meinung stark.
Es ist definitiv nicht nur eine Spielerei. Es waren mit mir sechs Personen, die am Workshop teilnahmen. Ich empfand es als sehr intensiv. Mit sechs Personen geht die Rotation ziemlich schnell, was dazu führt, rasch wieder von der Rolle „Writing“ in der Rolle „Next“ zu sein. Dabei müssen die Teilnehmenden stets am Ball bleiben und dürfen den Überblick im Code sowie der aktuellen Rollenbelegung nicht verlieren. Durch das zügige Tempo entfallen zudem Detail-Diskussionen und Verzettelungen. Am Schluss hat die ganze Gruppe gemeinsam eine Lösung erarbeitet, was sehr zufriedenstellend war.
Ich finde es einen interessanten Ansatz, der sich gut für Dojos und Katas jeglicher Art eignet. Es gibt auch Firmen, die Mob Programming fest in ihren Entwickleralltag integriert haben, z.B. jede Woche eine Mob Programming Session von zwei Stunden.
Zum Schluss würde ich sagen: „Einfach mal ausprobieren!“
Weiterführende Links: