Life in the mob

Unser Team bestand aus vier Personen. Wir arbeiteten agil zusammen, das heißt, alle zwei Wochen formulierten wir gemeinsam neue Ziele für unsere Sprints.
Hier ein kurzer Abriss über das "Leben im Mob" über mehrere Monate - tagein, tagaus. Wir verwendeten fast ausschließlich den "starken" Mob-Ansatz, bei dem der "Fahrer" an der Tastatur saß und die Gruppe als "Navigatoren" dem Fahrer sagte, was er zu tun hatte. Für die gemeinsame Nutzung von Bildschirmen verwendeten wir Microsoft Teams.

• mob ist eine großartige Möglichkeit, Wissen zwischen Kollegen auszutauschen und Arbeitsweisen zu etablieren: Programmierstil, bewährte Verfahren, Tools, IDE-Einstellungen, Git(Hub)-Arbeitsweisen, Bash-Hacks usw.
• Der Mob vereinfacht die Einarbeitung von Mitarbeitern - man kann sie ins kalte Wasser werfen und sie zwischen den Rollen als Fahrer/Navigator wechseln lassen :)
• das Team kann gemeinsame Setup-Probleme gemeinsam lösen, da jeder Dev-Themen lokal zum Laufen bringen muss: jeder Entwickler-Rechner muss auf ähnliche Weise funktionieren, um als Treiber teilnehmen zu können
  
  • Terraform, GCP, Java, SDKs etc.
  • Skripte müssen überall laufen, nicht nur in der CI/CD-Pipeline (Linux, Mac, Windows)

• es gibt keinen Druck, als Treiber aufzutreten
  
  • höre einfach auf das, was deine Navigatoren sagen
  • keine Notwendigkeit zu denken und zu tippen
  • weniger Druck auf den Treiber als in einem klassischen "Ich teile meinen Bildschirm und mache die ganze Arbeit"-Setup
  • Die Bereitschaft, die Rolle des Fahrers zu übernehmen, ist größer, insbesondere bei jüngeren Fahrern, da sie nicht vor der Gruppe "auftreten" müssen.

• Navigatoren müssen ihre Gedanken für alle, auch für den Fahrer, verständlich machen
  
  • damit alle leichter folgen können (und die zehnfachen Entwickler mit "schwarzem Gürtel" nicht wegrennen)

• das Team kann Fragen/Herausforderungen an Ort und Stellelösen und nicht erst später (lies: "wahrscheinlich nie")
• das Team entwickelt ein gemeinsames Gefühl für das Sprint-Ziel des Teams
• ein hoher "Bus-Faktor" entsteht - jeder weiß, was los ist und jeder kann im Falle eines plötzlichen Ausfalls einspringen
• es besteht kein Bedarf an zusätzlichen Sync-Meetings, da alle bereits auf dem Laufenden sind
• es sind keine Peer-Reviews erforderlich, da jeder Git-Commit von den Navigatoren mit einem 'reviewed-by' versehen wird
• Es ist einfacher, eine gemeinsame Basis für Code-Standards/-Stil, Architektur, CI/CD und Tests zu entwickeln, da die Teammitglieder ihre Meinungen sofort mit allen teilen können.
• es ist einfacher, seine (neuen) Kollegen kennenzulernen , wenn man ein Team von Grund auf neu aufbaut!

Tools, die wir verwenden:

• greenfield auf Google Cloud Platform (GCP)
• APIs mit zwei benachbarten Teams, derzeit asynchron; Nachrichtenaustausch über GCP Pub/Sub, später REST und UI-Integration in das große 'Lieferantenportal'
• Java, Spring Boot, Docker, Terraform, Github (Actions), CI/CD, Google Cloud Platform (Pub/Sub, Cloud Spanner), DevSecOps ('you build it, you run it').

Nach mehr als einem halben Jahr im Mob sind wir, wie gesagt, von dieser Form der Zusammenarbeit begeistert. Aber natürlich gibt es auch einige Herausforderungen, über die man sich im Klaren sein sollte, bevor man sich entschließt, diesen Programmieransatz auszuprobieren.

Unsere Herausforderungen in Kürze zusammengefasst:

• Verstecken" in der Meute: Es kann schwieriger sein, neue Teammitglieder einzuschätzen, da die Möglichkeit besteht, dass sie in der Meute "Deckung" suchen
• Potentiell hoher Leistungsdruck, wenn man sich dem Mob anschließt, insbesondere für Leute, die es gewohnt sind, allein zu arbeiten und ein "festes" Produkt zu liefern
• zu ausführliche Diskussionen - jemand muss moderieren und sich auf die Story und die Sprint-Ziele konzentrieren
• Es ist schwer, die Gruppe hinter sich zu lassen - ich arbeite in Teilzeit, also gibt es immer einen Punkt am Nachmittag, an dem ich sagen muss: "Wir sehen uns morgen".
• Es ist schwierig, Geschichten zu parallelisieren, da der Mob an einer Geschichte zur gleichen Zeit arbeitet.
• Das Leben im Mob kann manchmal hart und anstrengend sein - sich zu konzentrieren, zu diskutieren und gemeinsam zu programmieren kann und wird an den Kräften zehren
• es besteht die Gefahr, dass man Leute zurücklässt, die ihren Gedanken nicht folgen und sie nicht ausdrücken können
• man gewöhnt sich schnell daran, mit anderen zusammenzuarbeiten, was die Angst davor auslösen kann, alleine zu arbeiten und/oder Entscheidungen zu treffen, ohne Input oder Unterstützung durch die Gruppe
• Für jüngere Teammitglieder ist es schwieriger, Themen im Mob aktiv zu diskutieren.

Als wir mit dem Programmieren im Mob anfingen, hatte ich bereits einige Erfahrungen gesammelt. Ein halbes Jahr später sind wir jedoch viel schlauer und haben viel gelernt!

Unsere wichtigsten Learnings:

• Bevor man beginnt, sollte man eine klare Einführung in die Mob-Sitzungen geben und das "Warum" erklären
  
  • den Rahmen so gestalten, dass sich alle wohl fühlen
  • Gib jedem die Chance, Schwächen zu zeigen.
  • es gibt niemanden auf der Welt, der alles weiß, und niemand ist perfekt
  • Scheitern ist Teil des Geschäfts #failfast

• Stellt sicher, dass jeder in der Lage ist, den Bildschirm gemeinsam zu nutzen (ausreichende Internet-Bandbreite zu Hause, ausreichend gute Kamera, ruhiger Raum usw.)
• Wechselt häufig (15 Minuten) - wir verwenden den Cuckoo-Timer
• Erstellt einen eigenen MS Teams-Kanal für eure Mob-Sitzungen, z. B. mit dem Namen "Mob-Sitzungen / Anrufe Anrufe".

• eine Videositzung starten, an der alle teilnehmen können (Entwickler, Agile Master (AM), Product Owner (PO) usw.) und wissen, wo man sich befindet
• Gebt den Videositzungen lustige Namen :)

• AM und PO können an der Mob-Sitzung für die tägliche Besprechung teilnehmen
• Git-Commit-Nachricht mit 'reviewed-by:' Mob-Mitgliedern (Vorlage verwenden)