Mob Programming und Shared Everything

Mob Programming ist eine Methode, die wir exzessiv eingesetzt haben, um den Wissensaustausch im Team zu fördern, Entwickler-Skills zu schärfen und den Teamzusammenhalt zu erhöhen. Das mögen nicht unbedingt die Primärziele eures Unternehmens sein, aber sie tragen enorm dazu bei, eure eigentlichen Ziele erfolgreich zu erreichen. In diesem Artikel teilen wir mit euch die Ansätze, die wir nutzten, um Mob Programming machbar, effektiv und unterhaltsam zu machen.

„Shared Everything“

In einem unserer letzten Projekte haben wir Mob Programming eingeführt, um das Hauptziel „Wissensaustausch im Team“ zu erreichen. Wir wollten damit alle Entwickler auf das gleiche Niveau bringen, statt uns mit Titeln, Kategorisierungen und Spezialisierungen aufzuhalten. Das Ergebnis unserer kontinuierlichen Arbeit an einem „Shared Everything“-Mindset war, dass unser „Bus Factor“ sich an unsere Teamgröße annäherte.

Bus Factor?

In jedem Team findet man einzelne Personen, die ein Silo an spezifischem Wissen darstellen. Wissen, das essentiell für die Ergebnisse und die Performance des Teams entscheidend ist. Wenn eine solche Person nun das Team plötzlich verlässt, wird das gesamte Team darunter leiden.

Bild von Lai Man Nung, unsplash

Der Bus Factor eines Teams ist die Anzahl der Teammitglieder, die „von einem Bus überfahren werden müssen“, damit ein Team in ernste Schwierigkeiten kommt.

Somit ist der Bus Factor ein Indikator dafür, wie „gesund“ dein Team in Bezug auf Wissenstransfer und Skill-Sharing ist. Ein hoher Bus Factor deutet auf einen guten Wissenstransfer innerhalb des Teams hin.

Wie haben wir Mob Programming und Shared Everything etabliert?

Mob Programming – Ein Abenteuer

Remote Session – Bild von den Autoren

Während des besagten Projektes waren wir in der glücklichen Lage, DDD (Domain-driven Development), TDD (Test-driven Development), und, was wesentlicher war, Mob-Programming-Techniken zu verwenden.

Wir hatten einen holprigen Start. Mob Programming fühlte sich für uns total fremd an gegenüber der Art der Softwareentwicklung, die wir gewohnt waren. In täglichen Retrospektiven wurde das Gefühl von Verlangsamung beanstandet und man war relativ schnell frustriert, dass man nicht mehr wie gewohnt die Macht über das Keyboard und die damit verbundene Kontrolle hatte. Wir versuchten es, gaben es auf, starteten neu und hörten wieder auf.

Was wir damit sagen wollen, ist, dass wir am Anfang viel experimentierten. Während dieser Phase wurden wir durch den Guide von Maaret Pyhäjärvi inspiriert.

Wir begannen zu erkennen, dass Wissen im Team viel besser zu den einzelnen Teammitgliedern transferiert wurde und sich auch unsere Codequalität erhöhte.

Dennoch blieben die Herausforderungen bestehen. Wir waren auch zu Beginn an einem Punkt angekommen, an dem wir diese eigentlich gute Idee aufgeben wollten. Aber wir hatten dann einen sehr guten Workshop mit Woody Zuill . Dieser Workshop-Tag half uns enorm dabei, festzustellen, dass die Mob-Programming-Technik uns unterstützt, uns selbst als Menschen, aber auch als Team weiterzuentwickeln. Wir waren wieder enthusiastisch! Neben den vielen Tipps und Tricks, die Woody uns mitgab, war eines für uns entscheidend: die Daily Retrospektive. Eine tägliche Retro? Ja. Jeden Tag um ca. 16 h kamen wir für fünf Minuten zusammen. In dieser Retro geht es darum, dass jeder etwas sagt, was an diesem Tag gut gelaufen ist. Wir empfehlen euch, dafür einen Alarm einzurichten, um damit vertraut zu werden.

Eine weitere Herausforderung bei uns war, dass wir den Fokus auf Remote Mob Programming setzen mussten, da ein Teil unseres Teams über verschiedene Standorte verteilt war. Hierbei holten wir uns Inspiration aus dem Guide von Simon Harrer, Jochen Christ, und Martin Huber . Wir mussten einige Regeln etablieren, um Remote-Arbeit für uns erfolgreich zu machen.

Einige „Shared Everything“-Regeln

• Kamera immer an
  

  Bild von Aksa2011, pixabay

  Da das Team über verschiedene Standorte verteilt war, war es für uns besonders wichtig, die „Kamera immer an“-Regel zu forcieren. Das hilft allen Teammitgliedern, sich wie „Bürger erster Klasse“ zu fühlen. Es gibt, vor allem für die Remote-Mitglieder, ein besseres „Wir“-Gefühl. Zusätzlich hat es den Vorteil, dass bei Diskussionen und Meetings ein besseres Verständnis erzielt wird, weil man neben der Sprache so auch die Gestik der sprechenden Person mitbekommt. Das bringt uns zur nächsten Regel …

• 30-Sekunden-Regel
  

  Bild von Aron Visuals, unsplash

  Wenn jemand mehr als 30 Sekunden spricht und sich dabei außerhalb der Kamera befindet, kann jeder das Meeting unterbrechen, damit die Situation bereinigt werden kann.

  Da bei uns im primären Projektbüro jeder sein eigenes Notebook verwendete, war es sowieso Standard, dass jeder die ganze Zeit vor der Kamera war.

  In den Business-Meetings mit unseren Stakeholdern war jeder angehalten teilzunehmen, damit wir unsere „Shared-Everything“-Philosophie forcieren konnten. Es war entscheidend, unsere Einrichtung so anzupassen, dass alle Gäste im Raum von den Remote-Mitgliedern/-Teilnehmern deutlich gesehen werden konnten – ob es darum ging, die Körpersprache wahrzunehmen oder einfach nur zu wissen, wer genau spricht. Daher machte diese Regel auch einen Unterschied wie Tag und Nacht. Die zusätzlichen Personen wurden also vor Beginn des Meetings auf die vorhandenen Kameras (Notebooks) verteilt. Die Beteiligten haben in unserem Fall sehr gut mitgespielt.

• 10-Minuten-Regel
  

  Bild von Clem Onojeghuo, unsplash

  Bei der 10-Minuten-Regel geht es im Wesentlichen darum, dass jeder Teilnehmer ausreichend abgeholt ist. Falls einer der Beteiligten für mehr als zehn Minuten nichts sagte, wurde das Meeting kurz unterbrochen und derjenige sollte kurz den Stand zusammenfassen. Das klingt nach einer harten Regel, ja, aber für uns war es extrem wichtig, dass jeder alles mitbekam. Nur so konnten wir einen guten Wissenstransfer sicherstellen. Üblicherweise ist es ein Indikator, falls jemand eine Weile nichts zu sagen hat, dass derjenige den Faden der Konversation verloren hat.

• Brauchst du eine Pause? Nimm dir eine.
  

  Bild von Alex, unsplash

  Mob Programming braucht eine extrem hohe Fokussierung und Aufmerksamkeit von jedem. Hinzu kommt, dass Lernen schnell müde macht. Somit war es jedem in unserem Team erlaubt, eine Pause zu machen, wann immer eine benötigt wurde. Das Positive bei Mob Programming ist, dass man sehr schnell wieder auf dem Laufenden ist, wenn man aus einer Pause zurückkehrt. Wir haben verschiedene Pausenmodelle ausprobiert und sind am Ende bei der individuellen Pause geblieben. Das Einzige, was wir versucht haben zu synchronisieren, war die Mittagspause. Ansonsten konnte sich jeder eine individuelle Pause nehmen, sofern es nötig war. Die Person wurde dann einfach immer an das Ende der Mob-Programming-Liste gefügt und konnte sich somit eine Runde lang aufgleisen.

Bei Business-Meetings haben wir allerdings eine andere Pausenregelung angewandt. Wir haben hier die 45-Minuten-Regel verwendet. Also alle 45 Minuten eine kurze Pause. Das war besonders für unsere Remote-Teilnehmer sinnvoll, weil diese Meetings anstrengend sein können, wenn man nicht unbedingt in seiner Muttersprache folgen muss.

Die Regeln oben halfen uns während der Mob-Programming-Sessions sehr. Und Mob Programming half uns, das gesamte Wissen an jedes einzelne Teammitglied weiterzugeben. Jeder in unserem Team kannte also jede kleine Ecke unserer Anwendung und konnte an jedem Teil davon arbeiten.

Unsere Experimente

Wie wir bereits erwähnten, haben wir viel experimentiert. Experimente machen Spaß. So haben wir zum Beispiel verschiedene Ansätze für Mob Programming, die wir in „Dojos“ bei Woody Zuills Workshop gelernt haben, ausprobiert. Wir haben sie strict, soft und freestyle genannt:

• Strict
  
  Die strikte Art und Weise, Mob Programming durchzuführen, bedeutet, dass ausschließlich der Navigator reden darf. Der Rest darf nur zuschauen. Man darf nicht antworten, auch nicht auf direkt gestellte Fragen. Man kann sich vorstellen, dass das ziemlich schnell frustrierend sein kann. Vor allem, wenn man mit ansehen muss, wie der Navigator anfängt zu straucheln und einem nicht erlaubt ist, zu antworten oder Hinweise zu geben. Allerdings kann das überraschenderweise große Benefits mit sich bringen. Der Navigator zum Beispiel lernt laut zu denken, was wiederum der nächste Navigator aufgreifen kann. Dem Mob Fragen zu stellen ist eine effektive Methode der Kommunikation (auch wenn diese unbeantwortet bleiben)Auf der anderen Seite lernt der Mob, sich in Geduld zu üben und, was wir als wichtiger empfinden, dem Navigator Raum zu lassen, Dinge einfach auszuprobieren. Wenn man gelernt hat, mit diesen Frustrationen umzugehen, wird man merken, dass diese Art und Weise eine sehr friedvolle Technik ist. Keine Diskussionen, keine Argumente. Einfach programmieren und dabei versuchen, den anderen und dessen Gedankengang zu verstehen.
• Soft
  
  Diese Art ist ähnlich zur strikten Methode, mit dem Unterschied, dass der Mob reden darf, falls eine Frage vom Navigator gestellt wird. Man kann auf Fragen reagieren oder die Hand heben und warten, bis man an der Reihe ist, wenn man einen Hinweis oder eine Idee teilen möchte. Das erlaubt es, einem strauchelnden Teammitglied aktiv helfen zu können. Nichtsdestotrotz kann diese Technik in lange Diskussionen und den Freestyle-Modus abschweifen. Daher ist hier Vorsicht geboten.
• Freestyle
  
  Im Freestyle-Modus gibt es nur den Driver und alle anderen sind Navigatoren. Jeder darf frei Hinweise, Kommandos, Ideen äußern oder eine Diskussion starten. Wir haben gemerkt, dass es bei dieser Methode wichtig ist, Techniken anzuwenden, die Diskussionen reduzieren. Eine Möglichkeit ist es, die Idee eines Teammitglieds aufzugreifen und durchzuführen, egal ob sie gut oder schlecht endet, statt diese totzudiskutieren. Das Ergebnis kann überraschend sein!

Wir waren die meiste Zeit im Soft-Modus unterwegs, ein guter Kompromiss zwischen den anderen beiden Modi. Auch haben wir während des Tages immer mal wieder den Freestyle-Modus angewandt. Zudem haben wir uns einen Timeslot pro Tag (maximal eine Stunde) für den strikten Modus genommen, weil wir das Training für Geduld und Lösungsfindung sehr gut fanden.

Zudem haben wir viel mit der Mob-Programming-Rundenzeit experimentiert. Wir haben sehr kurze (2-3 min), mittlere (5-12 min) und lange (15-25 min) Rundenzeiten ausprobiert. Wir haben eine Zeit ausgewählt und 1-2 Runden Mob Programming durchgeführt. Wir haben festgestellt, dass bei den langen Zeiten sehr schnell der Fokus verloren wurde. Auch bei den zu kurzen Zeiten waren wir uns schnell einig, dass es nicht funktioniert, weil einfach zu wenig Zeit war, wenn man kurz nachdenken wollte oder man eine kleine Diskussion startete. Am Ende haben wir uns bei Zeiten zwischen 6-8 min eingependelt. Das war für uns genug Zeit, um etwas zu erreichen, aber auch, um mal eine kleine Diskussion zu führen.

Als hundertprozentiges Remote-Team mussten wir uns auch nebenbei noch eine Lösung suchen, um die Driver-Navigator-Wechselzeiten zu verbessern (Push des Codes zu einem dedizierten Git-Branch, Wechsel des Screensharings, etc.). Wir haben sie mittels Bash-Skripten und Disziplin auf ca. 30 Sekunden reduziert. Bei Timern unter 6 min ist das auch ein signifikanter Aspekt.

Auch haben wir verschiedene Driver-Navigator-Methoden ausprobiert. Viele Teams bleiben beim Navigator-Driver-Pattern. Wir haben nebenbei noch folgende Muster versucht:

• Navigator-Driver-Mob
  
  Der Navigator wird zum Driver, der Driver tritt dem Mob bei, und der Nächste aus dem Mob wird zum Navigator.
• Driver-Navigator-Mob
  
  Der Driver wird zum Navigator, der Navigator tritt dem Mob bei, und der Nächste aus dem Mob wird zum Driver.
• Driver-Mob-Navigator-Mob
  
  Der Driver und der Navigator treten dem Mob bei und die zwei Nächsten des Mobs werden zum Driver und zum Navigator.

Driver-Navigator-Mob wurde unser Standard, denn:

• Wenn jemand den Faden verlor, war hierbei die Chance groß, dass derjenige durch die Driver-Rolle wieder aufgegleist wird, bevor er zum Navigator wird.
• Während des Wechsels ist es von Vorteil, wenn der Driver aus dem Mob kommt, da er bereits die nötigen Dateien etc. öffnen kann, bevor es zum Wechsel kommt.

Aber wir fanden auch die anderen Muster interessant und zum Teil auch hilfreich. Haben wir schon erwähnt, dass wir es sehr mochten zu experimentieren?

Psychologische Sicherheit im Mob Programming

Die Forschung hat gezeigt, dass psychologische Sicherheit ein starker Prädiktor für die Teamleistung ist. Es ist ein angenehmes Gefühl, sagen zu können, was man denkt, und zu sein, wer man ist, ohne sich zu schämen oder Auswirkungen befürchten zu müssen. Die enge Zusammenarbeit hat uns geholfen, uns als Menschen zu verbinden. Selten gab es in unserem Team etwas wie den „Code eines anderen“, und jeder wusste und fühlte sich mit den Fähigkeiten und persönlichen Umständen des anderen wohl.

Es ist uns gelungen, uns mehrmals persönlich zu treffen und zusammenzuarbeiten – was sehr vorteilhaft ist. Sich live treffen, abends gemeinsam ein Bier trinken, die Familie des Kollegen kennen lernen – das sind Dinge, die ein Team stärken und vereinigen.

Die Ironie des Shared Everything und des Bus Factors

Die Verwendung des Mob-Programming-Ansatzes als Teil einer „Shared Everything“-Mentalität kann sehr vorteilhaft sein. Im Laufe des Projekts stellten wir fest, dass sich unser Bus Factor unserer Teamgröße angenähert hatte. Mit anderen Worten: Man hätte im Grunde das gesamte Team auflösen müssen, damit das Wissen und die Fähigkeiten aus dem Projekt verloren gehen. Das ist phänomenal.

Wir stellten auch eine hohe Zufriedenheit fest, die sich im Team verbreitete. Alle waren leidenschaftlich an den Experimenten und der Zusammenarbeit interessiert. Niemand fürchtete sich zu sagen: „Ich habe das nicht verstanden“, „Können wir das ändern?“ oder: „Wir sollten das mal so versuchen“.

Bild von Ryan Tang, unsplash

Ein hoher Busfaktor schützt das Team, falls die Leute es verlassen. Die Ironie dabei ist jedoch, dass, wenn ein „Shared-Everything“-Team gebildet wird, niemand das Team verlassen will. Wir hatten während dieses Projekts keine Fluktuation in unserem Team.

Trotz der wirklich interessanten Technologien und des kooperativen Kunden, der an dem Projekt beteiligt war, fasste ein Teammitglied am Ende des Projekts das Gefühl des Teams mit den Worten zusammen: „Ich bin wirklich traurig, dass dieses Projekt zu Ende geht. Nicht wirklich wegen der Projektarbeit, sondern weil ich das Team verliere.“