In diesem Artikel geht es um das Mob Programming: eine aufs Team erweiterte Version des Pair Programming. Der Artikel beleuchtet, was es damit auf sich hat und ob das wirklich sinnvoll ist oder nur Zeit kostet.
Vor kurzem stieß ich bei Twitter auf einen Tweet, der mich irritierte. Da äußerte sich jemand doch tatsächlich recht enthusiastisch über „Mobbing“! Der Autor versicherte, dass Mobbing sein Team weitergebracht hätte. Vielleicht verleitete mich der sensationslüsterne Teil in mir, den Tweet anzuklicken. Vielleicht auch nur die Hoffnung, dass sich dahinter eine etwas ungünstige Bezeichnung für irgendetwas völlig Anderes verbarg. So war es dann zum Glück auch.
Mit einiger Erleichterung stellte ich zweierlei fest: dass es nicht um die Ernennung von Teamschlägern oder ähnlich bösartiges geht und dass wir Informatiker immer noch schlecht darin sind, den Dingen Namen zu geben.
Aber genug zur Hintergrundgeschichte und stattdessen zum Thema dieses Blog-Artikels: das Mob Programming.
Was hat es mit dem Mob Programming auf sich?
Wer das Pair Programming schon kennt und nun beim Mob Programming eine erweiterte Variante davon vermutet, hat recht.
Genau wie beim Pair Programming geht es im Grunde um eine formalisierte Variante des einfach mal zusammen an etwas Arbeitens. Also: einer sitzt am Keyboard und der Rest gibt gute Ratschläge, während der Bildschirminhalt zum Beispiel mit einem Beamer an die Wand geworfen wird.
Die Anderen sollen dem sogenannten Driver natürlich nicht einfach nur im Nacken sitzen und nerven. Viel mehr geht es darum, die ganze Kompetenz des Teams zusammenzubringen, gemeinsam an einem Problem zu arbeiten und von unterschiedlichen Blickwinkeln zu profitieren.
So könnten sich die Leute im Raum beispielsweise auf das „Big Picture“ konzentrieren, während der Driver die Details im Auge behält. Vielleicht ist die Rollenverteilung nicht ganz so stringent, aber der springende Punkt ist der: ein und dasselbe Problem könnte gleichzeitig von verschiedenen Seiten betrachtet werden.
Wie schon beim Pair Programming erhofft man sich vom Mob Programming bessere Ergebnisse, aber man soll damit auch schneller Ergebnisse erzielen.
Macht das wirklich Sinn?
Gar nicht so einfach zu beantworten.
Einerseits ist man praktisch auf anekdotische Erfahrungen wie denen im besagten Tweet angewiesen. Andererseits ist es sicherlich auch eine Frage des Maßstabs. Betrachtet man die Methode nur dann als erfolgreich, wenn sie besonders zeiteffizient ist, wird man wahrscheinlich enttäuscht. Denn schon beim Pair Programming lässt die Produktivität erstmal um etwa 15 % Prozent nach. Aber: gewisse positive Effekte werden in der Praxis aber auch einfach gerne mal übersehen oder deren Bedeutung unterschätzt.
So weist eine Studie zum Pair Programming etwa nach, dass sich das Pair Programming positiv auf die Qualität der Ergebnisse auswirkt. Zusätzlich verbessert es die Kommunikation im Team und Wissensverteilung, führt so letztlich auch zu einer geringeren Anzahl von Defekten und senkt die Risiken von Unterbesetzung.
Verringerte Lead Time
Im Codebetter-Blog wirft Marcus Hammarberg noch einen ganz anderen interessanten Gedanken ein: möglicherweise sei es nicht effizient, dafür senke es die tatsächliche Lead Time.
Die Lead-Time gibt die Zeit von Auftragsannahme bis zur Erledigung an und so mag das zunächst widersprüchlich klingen. Weniger effizient mit Zeit umgehen und doch schneller liefern? Das erscheint nicht mehr so widersprüchlich, wenn man in Betracht zieht, dass noch andere Faktoren beeinflussen, wie viel Zeit bis zur Erledigung vergeht.
Man denke zum Beispiel an die Wartezeit, wenn man seine Arbeit von einem Kollegen reviewen lassen möchte und der gerade was anderes macht.
Gelingt es einem, die richtigen Leute in einen Raum zu bringen und diese gemeinsam an einem Thema arbeiten zu lassen, dann lassen sich die sonst so unvermeidlichen Wartezeiten einfach umgehen. Möglicherweise erzielt man so Flow (um es mal ganz DevOps-mäßig auszudrücken) und stellt in ein paar Tagen ein Ergebnis auf die Beine, für das man sonst Wochen gebraucht hätte.
Das wäre doch mal was, oder?
Ob das in der Praxis dann wirklich so funktioniert, kann ich nicht sagen: ich hab mit dem Mob Programming noch keine praktischen Erfahrungen gesammelt.
Beim Pair Programming war es in der Vergangenheit schwer, andere Personen von der Idee zu überzeugen, weil der höhere Zeitaufwand eine nicht zu unterschätzende Hürde darstellt. Zudem soll die Effektivität unter anderem davon abhängen, dass die Wissensunterschiede zwischen Driver und seinem Partner nicht zu groß sind. Beim Mob Programmming mache ich mir dagegen Gedanken, ob hier der Groupthink-Effekt zum Tragen kommen könnte.
Letztlich ist es aber wie bei vielen Ideen: wenn man wissen will, ob es einem was bringt, muss man ihnen eine Chance geben und sie ausprobieren.
Post mortem