Remote Mob Programming: Gemeinsam virtuell coden

Warum wir Remote Mob Programming begonnen haben

Software im Homeoffice zu entwickeln ist bequem. Aber es macht auch einsam. Vor zwei Monaten haben wir deshalb angefangen, mit Remote Mob Programming zu arbeiten. In unserem Team bearbeiten wir – drei Kollegen und ich – für unseren Kunden sämtliche Features und Bugs gemeinsam. Nach dem Motto: einer tippt, die anderen denken. Inzwischen hat ein weiteres Team nachgezogen. Warum wir diese Methode so gut finden? Das erzähle ich euch

Remote Mob… – was? Wie geht das?

Wir starten um 8 Uhr morgens via Zoom in einem Online-Raum. Reihum arbeiten wir in 10 Minuten-Intervallen. Eine Person – der Typist – gibt seinen Bildschirm frei und macht im Prinzip das, was ihm die anderen Entwickler sagen. Nach 10 Minuten übernimmt der Nächste. Wenn Jeder zweimal an der Reihe war, schieben wir eine kurze Kaffeepause ein. Danach geht es weiter, mit entsprechenden Pausen natürlich. Wir sind ganzen Tag mit eingeschalteter Webcam und Mikro im Online-Raum präsent. Die Kolleg:innen aus dem Unternehmen unseres Kunden können jederzeit vorbeikommen. Im Prinzip ist es so, als würden wir alle in einem Büro sitzen.

Gibt es Vorteile, die die Kund:innen direkt spüren?

Viele! Im Wesentlichen sind es diese:

Schnellere Time-to-Market: Weil wir uns auf ein Feature fokussieren, wird dieses schneller fertig gestellt und in Produktion genommen, als wenn wir parallel mehrere entwickeln, die mehrere Code Reviews und Test-Schleifen durchlaufen müssen.
"Learning with the mob" – schnelleres Onboarding von neuen Kolleg:innen: Spitzen lassen sich besser abdecken, weil ein neues Teammitglied sofort produktiv wird, denn es lernt von den anderen Mitgliedern.
Bessere Planbarkeit – die Velocity wird belastbarer: Ein/eine Kund:in kann genauer planen, wann er/sie mit der Produktivsetzung eines Features rechnen kann. Die Summe der durch das Team machbaren Story Points ist durch die gemeinschaftliche Entwicklung höher, da alle ihr Wissen teilen.
Weniger Abhängigkeit von einzelnen Entwickler:innen: Ein Feature hängt nicht an den Fähigkeiten eines einzelnen Entwickelnden. Es entstehen keine Wisseninseln. Know-how-Lücken werden geschlossen. Zudem ist die Fertigstellung eines Features nicht abhängig von der Verfügbarkeit einzelner Personen (Urlaub! Tätigkeiten außerhalb des Projekts!).
Zusätzliche Meetings werden überflüssig, weil die Abstimmung laufend stattfindet. Zuvor hatten wir jeden Tag 15 Minuten Daily und einmal pro Woche ein einstündiges Entwickler:innen-Meeting, in dem technische Details besprochen wurden. Aufsummiert waren das circa 9 Stunden Meeting pro Woche, die jetzt wegfallen!
Kurze Wege: Dadurch, dass wir ständig im "Remote Office" präsent sind, kann Jeder jederzeit dazu kommen. Man muss nicht bis zum nächsten Meeting warten!

Playmobilfiguren als Programmierer:innen

Wie ist unser Team darauf gekommen, diese Methode anzuwenden?

Vor zwei Jahren habe ich einen Podcast gehört, in dem ein Team davon berichtete, wie begeistert es von dieser Methode ist. Schon damals habe ich das Thema sehr interessant gefunden, aber noch nicht vorangetrieben.

Manchmal muss man eben zu seinem Glück gezwungen werden! Aufgrund der Corona-Pandemie arbeiten wir bereits seit Mitte 2020 ausschließlich aus dem Homeoffice. Je länger die Pandemie dauert, desto weniger wurde der Austausch zwischen uns. Anfang 2021 sagten wir, dass sich etwas ändern muss. Und da kam RMP ins Spiel: Wir haben ein, zwei Bücher gelesen und losgelegt.

Ist Remote Mob Programming ganz neu?

Mob Programming ist eine Weiterentwicklung des Pair-Programming und kommt aus dem Extreme Programming, das wohl um 2003 entstanden ist. MP wird Anfang der 2000er erstmals erwähnt und ist somit also nicht wirklich neu. Es hat auch bei der HEC schon stattgefunden, aber eher für einen festgelegten Zeitraum oder spezifische Aufgaben.

RMP hat sich dagegen erst in den letzten Jahren verbreitet. Der Grund ist wahrscheinlich, dass sich Remote Arbeit mehr etabliert hat. Das war vor 10 bis 20 Jahren aufgrund technischer Hürden schwierig oder von Firmen nicht so recht gewünscht. Darüber hinaus waren viele Tools nicht so ausgereift wie heute. Jetzt ist das Thema – nicht zuletzt wegen Corona – immer mehr im Kommen.

Was haben die Teams davon?

Das Team profitiert ebenso wie die Kunden davon, dass Wissensinseln aufgelöst werden, die Velocity belastbarer wird und es mehr Zeit gibt, weil Meetings wegfallen. Positiv ist außerdem:

Das soziale Miteinander im Team wird stark gefördert und bietet Austausch für die Einzelkämpfer:innen im Homeoffice.
Stärkung der Teamverantwortlichkeit: Im Vergleich zum üblichen Modus, in dem sich jeder in erster Linie für die eigenen Features verantwortlich fühlt, ist beim Mob Programming jeder an jedem Feature beteiligt.
Code Reviews werden überflüssig. Da alle Entwickler beteiligt sind, ergibt sich das Code Review quasi direkt bei der Entwicklung. Das spart Zeit und beschleunigt die Time-to-Market.
Keine Merge-Konflikte mehr, weil parallel an mehreren Features gearbeitet wird. Das erspart uns eine Menge Zeit und Frust!
Features werden schneller fertig. Getreu dem Motto “Stop starting, start finishing” wird immer nur ein Feature zur Zeit entwickelt. Mit dem nächsten wird erst begonnen, wenn das vorherige von Entwicklungsseite her fertig gestellt wurde. Das Team arbeitet disziplinierter an der Umsetzung und verliert sich nicht so schnell in Details. Stoßen wir auf zusätzliche Aspekte, wird ein gesondertes Ticket erstellt.
Dailies werden überflüssig. Wir wissen ja ohnehin, wo wir stehen und wo Probleme liegen! Statt Dailies schreiben wir am Tagesende in einem gemeinsamen Teams-Channel, was wir geschafft haben und wo es eventuell noch Probleme gibt. Somit ist auch der Kunde immer informiert!

Sollten auch andere Entwicklungsteams RMP nutzen?

Einen Versuch ist es auf jeden Fall wert! Aber die Rahmenbedingungen müssen stimmen:

Teamstärke 3 bis 4 EntwicklerInnen – weniger ist kein Mob, mehr ist ineffektiv.
Alle müssen remote tätig sein – zwei im Büro, zwei Remote ist nicht sinnvoll, weil dann die Kommunikation ungleich ist.
Zeitliche Abstimmung – wenn der eine um 6 Uhr, der andere erst um 10 Uhr anfängt, dann funktioniert das nicht.
Last but not least: Kundenzustimmung – RMP kann auf den ersten Blick ineffektiv wirken, ist es aber definitiv nicht. Dennoch muss man das Vorgehen erklären können.

Also, alles gut?

Natürlich gibt es bei viel Licht auch Schatten. So reduziert sich die Zeit automatisch, die jeder Einzelne mit dem Coding beschäftigt ist. Manchmal ist es auch etwas schwierig, Dinge verbal zu beschreiben. Dann würde es vielleicht schneller gehen, wenn man sie selbst codieren könnte. Hier empfiehlt sich die Verwendung eines Online Whiteboards um Sachverhalte visuell darstellen zu können.

Es benötigt durchaus Disziplin, auch bei einfachen Themen am Ball zu bleiben und sich nicht mental auszuklinken. Darüber hinaus muss man seine Arbeitsweise an die des Teams anpassen und sich beispielsweise auf halbwegs einheitliche Arbeitszeiten einigen.

Mein Fazit nach zwei Monaten Remote Mob Programming:
Die Vorteile überwiegen die Nachteile deutlich, insbesondere in der jetzigen Homeoffice-Situation. Es macht einfach wieder richtig Spaß zusammenzuarbeiten, statt alleine Probleme zu wälzen. Ich möchte mir eine Rückkehr zum Einzelkämpfer-Dasein nicht mehr vorstellen!

Der Autor

Björn Seebeck ist seit 2006 bei der HEC tätig und hat in dieser Zeit viele Projekte als Softwareentwickler umgesetzt. Sein Schwerpunkt ist Softwarearchitektur sowie Infrastrukturthemen. Privat ist er viel mit dem Mountainbike unterwegs und fiebert mit den Fischtown Pinguins in der Eisarena mit.

Wer RMP im Projekt ausprobieren möchte, dem hilft Björn gerne bei den ersten Schritten!

Weitere Infos zum Thema findet Ihr online hier https://www.remotemobprogramming.org/ oder als Buch https://pragprog.com/titles/mpmob/code-with-the-wisdom-of-the-crowd/ .