Wenn das ganze Team den Mob schwingt

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 in dem sich jemand zu meiner großen Verwunderung sehr enthusiastisch über „Mobbing“ äußerte. Der Autor des Tweets versicherte, dass Mobbing sein Team weitergebracht hätte. Vielleicht war es der sensationslüsternde Teil in mir, der mich den Tweet anklicken ließ, um mehr zu verfahren. Vielleicht aber 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 Menschen und ganz besonders Informatiker immer noch schlecht darin sind, den Dingen Namen zu geben.

Aber genug zur Hintergrundgeschichte und statt dessen 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 darauf tippt, dass es sich um eine erweiterte Variante davon handelt, hat Recht.

Genau wie beim Pair Programming geht es im Grunde um eine etwas formalisiertere 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.

Der Gedanke ist natürlich nicht, dass die anderem dem sogenannten Driver einfach nur im Nacken sitzen und nerven.

Viel mehr geht es darum, die ganze Kompetenz des Teams zusammenzubringen und gemeinsam an einem Problem zu arbeiten. So könnten sich die Leute im Raum beispielsweise auf das „big picture“ konzentrieren, während der Driver die Details im Auge behält. In der Praxis wird die Rollenverteilung wohl nicht ganz so stringent sein, 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 dabei unter anderem bessere Ergebnissse aber vor allem soll man mithilfe des Mob Programming auch schneller Ergebnisse erzielen.

Macht das wirklich Sinn?

Ob das ganze wirklich Sinn macht oder nicht, lässt sich nicht so einfach beantworten.

Einerseits ist man praktisch auf anekdotische Erfahrungen wie denen im besagten Tweet angewiesen und auf der anderen Seite ist es sicherlich auch eine Frage des Maßstabs. Betrachtet man die Methode nur dann als erfolgreich, wenn sie besonders zeiteffizient ist, also kurzfristig oder zumindest über einen gut abschätzbaren Zeitraum eine Zeitersparnis bewirkt, wird man wahrscheinlich enttäuscht sein. Das hängt zum einen damit zusammen, dass die Produktivität schon beim Pair Programming erstmal um etwa 15% Prozent nachlässt und die Programmierung somit eben auch tatsächlich erst einmal teurer wird. Zum Anderen werden gewisse positive Effekte in der Praxis aber auch einfach gerne mal übersehen oder deren Bedeutung unterschätzt.

So weist dieselbe Studie zum Pair Programming etwa nach, dass sich das Pair Programming positiv auf die Qualität der Ergebnisse auswirkt, aber auch die Kommunikation im Team, Wissensverteilung und Skills verbessert und so letztlich auch zu einer geringeren Anzahl von Defekten und einem geringeren Risiko von Unterbesetzung beiträgt.

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 plötzlich gar nicht mehr so widersprüchlich, wenn man in Betracht zieht, dass die tatsächlich vergehende Zeit bis zur Erledigung einer Aufgabe nicht allein von der investierten Arbeitszeit sondern auch von anderen Faktoren abhängt (unter anderem ein Grund, weshalb wir in Planungen immer Puffer berücksichtigen und wieso Schätzungen so schwer sind).

Man denke zum Beispiel an die Zeit, die beim Warten drauf geht, 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 schon schwer, andere Personen von der Idee zu überzeugen, weil der höhere Zeitaufwand eine nicht zu unterschätzende Hürde darstellt und umso offensichtlich ist. Beim Pair Programming heißt es auch, dass die Effektivität unter anderem davon abhänge, dass die Wissensunterschiede zwischen Driver und seinem Partner nicht zu groß sind. Beim Mob Programmming mache ich mir dagegen Gedanken, ob und inwiefern hier der Groupthink-Effekt zum Tragen kommen könnte. Da sollte man wohl in jedem Fall ein Auge drauf haben.

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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen