Der Mob sieht mehr

Vor Kurzem habe ich von einer neuen Art des Programmierens gehört, die gerade im Kommen ist – Mob Programming (1). Euphorisch wie man als ScrumMaster nur sein kann, wenn man etwas Neues kennenlernt, wollte ich es sofort in meinem Team ausprobieren. Gesagt, getan.Also lud ich das gesamte Entwicklungsteam ein: „Liebes Team, lasst uns morgen gemeinsam frühstücken. Es gibt Mettbrötchen! Ach ja, und wir machen Mob Programming.“ Leicht verunsichert, was sich der ScrumMaster da wieder ausgedacht hat, ließ sich das Team nach kurzem Murren und Knurren auf das Experiment ein. Ich erklärte den Teammitgliedern, worum es dabei geht. Kurz zusammengefasst nämlich um

• ein Team,
• einen Computer,
• einen Raum und
• eine Aufgabe.

Es gibt einen Driver, der alle 15 Minuten auf freiwilliger Basis wechselt. Der Driver darf nicht reden und lediglich das programmieren, was ihm von den anderen Teamkollegen im Raum, den Navigatoren, gesagt wird. Jeder Gedanke muss erst formuliert werden, durch den Raum wandern, wo er zur Diskussion steht, und von einem anderen aufgenommen und umgesetzt werden. (2)

Ein erfolgreicher Versuch

Die Augen wurden größer, die Stirnen runzliger und ich konnte bereits das Fragezeichen über den Köpfen erkennen: Warum machen wir das überhaupt? Ich erklärte, dass durch diese Art des Peer Programmings das Code Review direkt im Programmieren enthalten sei. Sie sahen mich weiter skeptisch an. Außerdem wird gemeinsam schneller eine Lösung gefunden und es gibt schnelles Feedback zum Code. Der eine oder andere Mund öffnete sich langsam, zum: „Aber...“.Ich sprach schnell weiter und erklärte, dass wir hier die Möglichkeit haben, unseren eigenen Qualitätsansprüchen gerecht zu werden, wir unsere Definition of Done von Anfang an umsetzen können und wir durch so viele qualitätssichernde Augen kaum bis gar keine Fehler mehr produzieren werden. Die Münder schlossen sich wieder. Und außerdem werde damit der Wissenstransfer im Team sichergestellt und neu Gelerntes direkt in die Praxis umgesetzt. Jetzt nickten sie langsam.„Lasst es uns versuchen. Wenn es nicht passt, machen wir es nie wieder!“, versprach ich. Dieses Versprechen brauchten sie für ihre Einwilligung.Also machte ich die Teammitglieder noch mit den Spielregeln bekannt (3):

• Lass deine Teamkollegen ausreden!
• Sei respektvoll und offen gegenüber anderen Meinungen im Raum!
• Sei mutig und sprich deine Gedanken frei aus!
• Stelle Fragen und diskutiere mit!
• Nimm die Meinungen im Raum auf und gestalte sie weiter!
• Sei klar und strukturiert in deinen Aussagen!

Der Vormittag verging damit, dass sich das Team zwischen Code Review, Dojo und einem Frontaltraining, geführt von einem Teammitglied, ständig wechselnden Tasks und Zielstellungen langsam dem Flow näherte und nach dem Mittagessen schließlich genau das tat, was Mob Programming vorsieht: Das Team lieferte eine komplette User Story mit hoher Qualität in kurzer Zeit, inklusive einem Entwicklertest. Es war beeindruckend zu sehen, wie fokussiert alle gemeinsam arbeiteten und gar nicht mehr aufhören wollten, bevor die Story nicht fertig war.

Und jetzt jede Woche ein Mob

Bei einer kurzen Reflexion am nächsten Tag wurden neben kleineren organisatorischen Aspekten, die noch verbesserungswürdig waren (mehr Wasser trinken, sich selbst zu kurzen Pausen zwingen, Frischluft, maximal zwei Themen auf der Agenda) genau die positiven Erfahrungen genannt, die diese Art der Zusammenarbeit hervorrufen soll:

• Es gibt einen schnellen und guten Wissenstransfer.
• Das ganze Team kann bei dieser Story nun Support leisten, weil jeder genau weiß, wie es gemacht wurde und vor allem warum.
• Eine ganze User Story wird an einem halben Tag geliefert.
• Die Teammitglieder haben das Gefühl, das Produkt zu besitzen und sind bereit, Verantwortung dafür zu übernehmen.
• Mob Programming ist eine tolle Alternative zum normalen Alltag.

Und wer hätte es gedacht: Seither gab es bereits weitere Mob Programming Sessions. Das Team plant bereits für sich selbst jede Woche einen Mob-Programming-Tag ein, um gemeinsam an ein oder zwei User Storys zu arbeiten. Gerade komplexe Problemstellungen lassen sich in dieser Arbeitsweise schnell und effizient lösen, da man alle Argumente ohne umständliche Abstimmungsschleifen hören und nutzen kann .Einzelne Teammitglieder haben noch Vorurteile gegenüber der Methode (4), aber der Rest des Teams fordert es ein und das hat eine andere Wirkung als ein Zwang von außen. Es ist wie bei jeder anderen Methode des Agile Software Engineering: Nicht jeder kann sich damit identifizieren, deshalb behalten wir auch weiterhin das Prinzip der Freiwilligkeit im Team bei.Nichtsdestotrotz, das Ausprobieren lohnt sich! Aussagen wie „Lasst uns das am Donnerstag im Mob machen!“ oder „Können wir die Architekten zum Mob einladen?“ lassen jedes ScrumMaster-Herz höher schlagen.(1) Hunter Industries, A Day of Mobbing Wikipedia, Mob Programming (2) Mob Programming - A Whole Team Approach  (3) Zuill, Teaming  (4) Hammarberg, Mob programming - full team, full throttle