Mob Programming

Mob Programming ist ein kollaborativer Ansatz der Softwareentwicklung, bei dem ein Team eine Aufgabe gleichzeitig, meist an einem Ort, an einem einzigen Computer bearbeitet. Gerne wird Mob Programming als Evolution des Pair Programmings deklariert, da sich nicht nur zwei, sondern alle verfügbaren Entwickler um die Lösung einer Aufgabe kümmern.

Für den englischen Begriff Mob gibt es zahlreiche Übersetzungen. Als Substantiv steht Mob für Pöbel, Meute, Mafia, Horde, Bande oder Haufen. Und das Verb steht to mob sth. bzw. to mob somebody für etwas umlagern bzw. jemanden umringen und jemanden belagern. Mob Programming ist aber nicht negativ konnotiert, es sollte eher als eingeschworener Haufen von Menschen verstanden werden, die gemeinsam ein Arbeitsgerät so lange belagern, bis sie als Team eine Aufgabe zufriedenstellend gelöst haben.

Die Rollen beim Mob Programming

Mob Programming kennt je nach Betrachtung zwischen zwei und sechs Rollen. In manchen Beschreibungen wird auch einfach von Aufgaben gesprochen, was besonders im agilen Kontext viel Sinn ergibt, denn Scrum als bekanntester Vertreter definiert auch keine expliziten Entwicklungsrollen. Rollen beim Mob Programming sind daher vor allem temporär, sie stehen auf keiner Visitenkarte und auch in keinem Lebenslauf.

Folgende zwei Rollen gibt es bei jedem Mob Programming:

• Driver
• Navigator

Der Driver ist derjenige, der vor dem Rechner sitzt und den Quellcode in den Computer tippt. Er setzt die Aussagen, Anforderungen, Ideen der anderen Teammitglieder um.

Die Navigatoren sind die Teammitglieder, die Ideen entwickeln, miteinander diskutieren und Vorschläge zur Lösung einer Aufgabe machen. Sie liefern den Input für den Driver.

Folgende vier zusätzliche Rollen kann es im Mob Programming geben:

• Designated Navigator
• Researcher
• Learner
• Timekeeper

Was soll der Driver umsetzen, wenn die Meinungen zur Lösung einer Entwicklungsaufgabe auseinandergehen? Soll er selbstständig eine Entscheidung treffen? Die Praxis zeigt, dass in solchen Situationen – oder auch bei der Arbeit mit größeren Gruppen – der Einsatz eines Designated Navigators Sinn ergibt. Dieser sammelt Vorschläge und Meinungen. Er moderiert, fragt nach und strukturiert Inhalte. Und bei Bedarf fordert er einzelne Teammitglieder auf, parallel zur Lösung der Aufgabe, Informationen zu sammeln und Aspekte in Erfahrung zu bringen. Ein Teammitglied, das eine solche Forschungsaufgabe übernimmt – in Scrum würde man von einer Spike Story sprechen – wird zu einem Researcher.

Teilnehmer, die zu einem konkreten Sachverhalt nichts beitragen können, sind die sogenannten Learner. Sie lernen aktiv durch Beobachtung, Zuhören und Nachfragen. Und last but not least kann es einen Timekeeper geben, der den Rollenwechsel von Driver, Designated Navigator und den anderen Teilnehmern initiiert. Meist sind Timekeeper und Designated Navigator eine Person.

Regeln beim Mob Programming

Die Regeln beim Mob Programming sind nicht in Stein gemeißelt. Es handelt sich um Good Practices, die jede Organisation für sich selbst entwickeln und anwenden, sowie auf Sinnhaftigkeit überprüfen muss. Hier finden Sie einige Regeln bzw. Empfehlungen zur Durchführung von Mob Programmings:

• Die Gruppe bestimmt gemeinsam einen Designated Navigator. Dieser fungiert als Moderator und erklärt den Teilnehmern das weitere Vorgehen. Sofern nicht im Vorfeld geklärt, wird die maximale Dauer der Session (bspw. einen halben oder einen ganzen Arbeitstag) und eine Timebox zum Wechseln der Rollen bestimmt. Darüber hinaus kann ein separater Timekeeper festgelegt werden.
• Der Timekeeper sorgt dafür, dass es bspw. alle 15 Minuten zu einem Rollenwechsel kommt, so dass jedes Teammitglied mindestens einmal Driver und einmal Designated Navigator wird.
• Meist liest man davon, dass der Driver der einzige ist, der einen Computer, ein Keyboard und eine Maus nutzt. Für die Researcher könnte es aber weitere Geräte (Computer, Tablet-PCs, Handys) geben.
• Der Computer des Drivers ist an einen Beamer oder einen sehr großen Monitor angeschlossen, so dass alle Teammitglieder leicht sehen können, was der Driver tippt.
• Alle Teilnehmer befinden sich idealerweise in einem Raum. Häufig wird dies als eine Voraussetzung für ein Mob Programming angesehen, wobei auch ein Remote Mob Programmings durchaus praktikabel sind.
• Idealerweise sollte man ein Aufgabe, bspw. ein Epic, ein Feature oder eine User Story, von Anfang bis Ende bearbeiten. Mob Programming unterscheidet sich in dieser Hinsicht nicht von anderen Ansätzen der Softwareentwicklung. Es geht darum, die Aufgabe zu verstehen, Akzeptanzkriterien zu definieren, Lösungswege zu finden und zu skizzieren, Code zu schreiben, die Implementierung zu testen, die Funktionen zu dokumentieren (wird gerne beim Mob Programming “vergessen”) und die Definition of Done zu beachten.

Beim Open Space Format gibt es das sogenannte Gesetz der beiden Füße. Es besagt, dass man jederzeit aus einer Session aussteigen kann, wenn man nichts beisteuern kann oder möchte, oder man nichts lernen kann. Die Meinungen variieren, ob dieses Gesetz auch bei einem Mob Programming angewandt werden sollte. Sicher ist jedoch, dass regelmäßige Pausen die Produktivität steigern.

Vorteile und Nachteile beim Mob Programming

Mob Programming bietet eine Reihe von Vorteilen wie bspw.

• eine gemeinsame Verantwortung für Entscheidungen.
• die Möglichkeit durch verschiedene Sichten und Erfahrungen voneinander zu lernen.
• die Möglichkeit, komplexe Aufgaben schrittweise im Team zu lösen.
• Transparenz und ein gemeinsames Verständnis der Codebasis.
• eine hohe Codequalität durch das “gemeinsame Kodieren”.
• die Förderung der Teambindung durch die gemeinsame Lösung einer Aufgabe.

Es gibt aber auch einen großen Nachteil beim Mob Programming:

• der hohe Aufwand zur Lösung einer Aufgabe.

Gerne wird empfohlen, Mob Programmings mit Teams bis zu ca. 8 Mitgliedern durchzuführen, theoretisch könnten es aber auch deutlich mehr Teilnehmer sein. Je mehr Teilnehmer es gibt, desto mehr Meinungen kann es geben. Je mehr Meinungen es zu einer Aufgabe gibt, desto mehr Diskussionen kann es geben. Je mehr Diskussionen es gibt, desto länger kann es dauern, bis es eine Einigung gibt. Oder anders ausgedrückt: auch wenn ein Großteil der Teilnehmer von dem Austausch lernt, Mob Programming muss nicht effizient sein.

Darüber hinaus gibt es auch noch einige andere Aspekte, die beachtet werden sollten:

• Ist der Driver lediglich ausführendes Organ oder darf er seine Vision umsetzen? Setzt der Driver seine Vision um, könnte es dann sehr ineffizient sein, wenn alle Navigatoren zu Zuschauern degradiert werden. Setzt er aber lediglich die Vorgaben um, dann bleibt seine Expertise möglicherweise auf der Strecke.
• Wie gelingt es, dass die Navigatoren den Driver nicht wie einen Anfänger oder einen Anfänger wie einen Experten behandeln? Dieses Problem wird tendenziell durch den Wechsel des Drivers befördert.
• Was passiert, wenn der Designated Navigator oder die Navigatoren versuchen, den Driver zu mikromanagen? Fördert das den Teamzusammenhalt? Wie kann sich der Driver dem entziehen?
• Was passiert, wenn ein Driver versucht, den Code eines anderen Drivers zu löschen? Ist das erlaubt oder generell verboten? Wären Abweichungen von der Regel möglich?
• Gerne wird auch gesagt, dass “externe” Mitarbeiter bzw. Rollen aus der Organisation an einem Mob Programming teilnehmen und sogar aktiv die Rollen des Drivers bzw. Designated Navigators können. Hier ist es wichtig, dass jede Organisation für sich, ein passendes Vorgehen festlegt. Ein Product Owner bspw. muss nicht programmieren können, warum sollte er also als Driver fungieren?
• Es empfiehlt sich trotz des Wechsels der Rollen regelmäßig Pausen einzuplanen.
• Und: es ist sinnvoll zum Ende eines Mob Programmings ein After Action Review bzw. eine kleine Retrospektive durchzuführen. Idealerweise lassen sich so Erkenntnisse verfestigen und die Zusammenarbeit bei der nächsten Session weiter verbessern.

Manchmal wird behauptet, durch ein Mob Programming könnten Technische Schulden vermieden oder zumindest reduziert werden. Sehen Sie das auch so?

Hinweise:

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

Wir suchen Softwareentwickler und Softwareentwicklerinnen. Haben Sie Lust, unser Team zu verstärken? Ob Sie als Berufseinsteiger die ersten Schritte machen, bereits einige Jahre Erfahrung mitbringen oder als Expertin tief im Code stecken – bei uns finden Sie genau die Herausforderung, die zu Ihnen passt!

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.