Remote Mob Programming bei INNOQ

Joshua Töpfer

Dr. Simon Harrer

Niko Will

Andreas Wissel

Martin Huber

Daniel Westheide

Vera Peuntinger

Tina Schönborn

Jochen Christ

Franziska Dessart

This article is also available in English

Der Begriff “Mob Programming” wurde von Woody Zuill folgendermaßen definiert: alle im Team arbeiten an der gleichen Sache, zur gleichen Zeit, am gleichen Ort und am gleichen Computer. Remote Mob Programming nutzt anstatt eines Meeting-Raums den virtuellen Zoom Raum und anstatt eines Computers den geteilten Bildschirm. Das Team arbeitet bei dieser Methode intensiv zusammen.

Bei INNOQ nutzen einige Teams diese Methode erfolgreich in Kundenprojekten, teilweise sogar schon seit über zwei Jahren. Dabei ist die Themenseite www.remotemobprogramming.org entstanden und ein INNOQ Podcast zu dem Thema. Für diesen Artikel haben wir vier Teams aus drei unterschiedlichen Branchen gefragt, wie ihre Erfahrungen mit dieser besonderen Arbeitsmethodik sind und waren. Viel Spaß beim Lesen!

Team Pluto, Branche e-Commerce

Wie ist euer Team aufgebaut?

Zu Anfangs waren wir 3 Developer von INNOQ und hatten einen externen Product Owner. Bei der langen Projektzeit hat der Kunde sowohl den Product Owner internalisiert als auch eigene Developer eingestellt. Zu Spitzenzeiten waren wir mit 4 Developer von INNOQ und 3 vom Kunden unterwegs. Mittlerweile sind nur noch 2 Developer von INNOQ im Projekt.

Wie habt ihr Remote Mob Programming eingeführt?

Beim Projekt Kick-off beim Kunden vor Ort haben wir drei INNOQ Developer begonnen, den ersten Service gemeinsam zu entwickeln, um ein gemeinsames und einheitliches Verständnis für die weiteren Services zu schaffen. Danach sind alle zurück in ihr Homeoffice und es fühlte sich einfach richtig an, weiter gemeinsam zusammenzuarbeiten. Und so blieb es dann auch.

Was hat es euch für Vorteile gebracht?

Unsere große Angst war es, im Homeoffice zu vereinsamen. Diese Sorge hat sich mit dieser Methode aber komplett in Luft aufgelöst, im Gegenteil, wir verspüren ein sehr starkes Teamgefühl - vermutlich sogar stärker als würde man vor Ort in einem Team ohne Mob Programming zusammen arbeiten.

Aber vielleicht noch ein weiterer Grund: Ein Developer im Team wurde Vater und musste wegen der Corona-Krise immer mal wieder während der Arbeitszeit auf seine Tochter aufpassen und diese auf dem Arm herumtragen. Dank Remote Mob Programming war das kein Problem, denn der Developer konnte einfach weiterhin in der Zoom Videokonferenz den geteilten Bildschirm sehen und in der Diskussion beitragen, getippt haben die anderen aus dem Team für ihn.

Welche Herausforderungen sind euch begegnet und wie seid ihr damit umgegangen?

Wir haben anfangs im Rausch des Mob Programming Flows zu wenig Pausen gemacht und unser Team an den Rand der Erschöpfung gebracht. Das war eine harte Erfahrung, und danach haben wir sehr auf das Einhalten von Pausen geachtet.

Es gab eine Zeit, als unser Team mit 7 Developer sehr groß war. Zu groß für einen Mob. Wir haben viel herumexperimentiert, und sind dann letztlich zu folgender Lösung gekommen: am Anfang des Tages teilen wir das Team mittels Zufallsgenerator in zwei Sub-Teams auf. Das erste Sub-Team erledigt die nächsten und wichtigsten Stories während das zweite Sub-Team alles andere erledigt und damit das erste Sub-Team vor Störungen bewahrt. Es war nicht immer optimal, und wir hatten plötzlich viel höheren Abstimmungsbedarf, aber es funktionierte gut genug.

Was sagt der Kunde dazu?

Der Product Owner ist sehr zufrieden. Auch die Developer des Kunden sind es. Hierzu eine kleine Anekdote. INNOQ hatte mal wieder ein Team-Event und für ein paar Tage waren die Developer des Kunden unter sich im Büro des Kunden vor Ort. Und obwohl alle nun vor Ort waren haben diese beschlossen, weiterhin Remote Mob Programming zu nutzen.

Würdet ihr die Arbeitsweise weiterempfehlen?

Ja. Wir wollen nicht mehr anders arbeiten.

Team Saturn, Branche Pharma

Wie ist euer Team aufgebaut?

Unser Team besteht aus einem INNOQ Frontend Developer und zwei Frontend Developer des Kunden. Unser Product Owner und Scrum Master wird vom Kunden gestellt. Das Team arbeitet komplett remote.

Wie habt ihr Remote Mob Programming eingeführt?

Wir haben Remote Mob Programming mehrfach bei uns im Team ausprobiert. Das erste Mal war ziemlich chaotisch, aber letztlich ziemlich erhellend, weil es schlechte Kommunikation im Team aufgedeckt hat. Mit viel Coaching um die Teamkommunikation zu verbessern und mit dem Argument “dies/jenes wäre mit Remote Mob Programming nicht passiert” konnten alle überzeugt werden, die Methode noch einige weitere Male auszuprobieren. Jetzt arbeiten wir ausschließlich mit Remote Mob Programming.

Was hat es euch für Vorteile gebracht?

Die größte Veränderung für uns war letztlich der drastisch geringere Abstimmungsbedarf. Dailys sind entfallen, Entscheidungen werden Ad-hoc getroffen, anstatt dass dedizierte Termine dafür benötigt werden, und alle wissen jederzeit, woran gearbeitet wird. Das Verrückte dabei ist, dass, obwohl sich Remote Mob Programming erstmal langsam, zeitintensiv und ein bisschen unproduktiv anfühlt man insgesamt eigentlich Zeit spart. Das hat uns immer wieder beeindruckt.

Welche Herausforderungen sind euch begegnet und wie seid ihr damit umgegangen?

Wir mussten zuerst die Kommunikation im Team verbessern, denn bei dieser Arbeitsweise arbeitet man so intensiv zusammen, dass man Konflikte nicht einfach ignorieren kann. Das haben wir mit viel Coaching erfolgreich in den Griff bekommen. Ansonsten hatten wir allgemein ein paar Startschwierigkeiten, da wenig Vorwissen vorhanden war. Dafür gibt es aber ja jetzt den Workshop ‘The Remote Mob Programming Experience’. ;-)

Ach ja, schlechtes Mikro und Video den ganzen Tag lang geht an die Substanz. Investitionen in gute Hardware zahlt sich hier besonders aus!

Was sagt der Kunde dazu?

Gute Idee! Die Qualität des Softwareprodukts erhöht sich stark und die Leute arbeiten besser und produktiver zusammen – sagt der Product Owner des Kunden.

Würdet ihr die Arbeitsweise weiterempfehlen?

Bei manchen Tätigkeiten passt es nicht, insbesondere wenn man intensiv nachdenken muss oder es einem nicht so gut geht. Ansonsten ist das schon die Variante unserer Wahl.

Team Mars, Branche Pharma

Wie ist euer Team aufgebaut?

Unser Team besteht aus 3 Backend Developer von INNOQ, die über ganz Deutschland verteilt sind. Unser Product Owner und Scrum Master wird vom Kunden gestellt. Da wir aktuell noch als Feature Team arbeiten, holen wir uns ab und zu einen Frontend Developer in den Mob, um auch die Arbeiten im Frontend mit guter Qualität erledigen zu können.

Wie habt ihr Remote Mob Programming eingeführt?

Zu Beginn des Projekts haben wir uns virtuell zusammengesetzt und darüber gesprochen, wie wir uns die Arbeitsweise vorstellen könnten. Da wir drei aus unterschiedlichen Gegenden kommen und auch unterschiedliche INNOQ-Büros als unsere Standorte betrachten, stand die verteilte Zusammenarbeit von Beginn an außer Frage. Aus anderen INNOQ Teams haben wir viel Gutes über Remote Mob Programming gehört und einige von uns haben bereits erste positive Erfahrungen mit Remote Pairing und zeitweisem Mob Programming gesammelt. Außerdem haben wir es als Chance gesehen, die unterschiedlichen Wissensstände im Team so am produktivsten einzusetzen.

Dass zu der Zeit das Coronavirus auch in Deutschland schon sein Unwesen getrieben hat, hat sicherlich zur Akzeptanz beim Kunden beigetragen.

Was hat es euch für Vorteile gebracht?

Ein sehr großer und wichtiger Vorteil ist der Wissenstransfer, der automatisch stattfindet. Jedes Projektmitglied ist Experte auf einem oder mehreren Gebieten, welche sich in unserer Konstellation tatsächlich kaum überschneiden. Im täglichen Doing bekommt man so auf ganz natürliche Weise eine sehr praxisorientierte Wissensvermittlung. Der jeweilige Wissensträger muss sein Wissen verbalisieren und wird natürlich auch von den anderen gechallenged und hinterfragt.

Drei Augenpaare sehen mehr als eins. ;) Kleine Fehler, die so gut wie jedem Developer gelegentlich passieren, können manchmal recht lange aufhalten. Durch das instantane Review des geschriebenen Codes oder der Arbeitsweise werden Fehler bereits frühzeitig entdeckt und können eliminiert werden. Das spart in der Praxis jede Menge Zeit.

Bei der Arbeit stößt man auch häufig auf Probleme, bei denen man sich für einen Lösungsweg entscheiden muss. Wenn man an solchen Punkten zu dritt die möglichen Lösungen abwägt und auch die Probleme der jeweiligen Ideen erörtert, ist die Wahrscheinlichkeit deutlich geringer, sich aufgrund von fehlendem Hintergrundwissen für die falsche Umsetzung zu entscheiden.

Auch größere architektonische Entscheidungen lassen sich so schneller und besser fällen. Gemeinsam wird ein Architecture Decision Record ausgearbeitet, in dem die möglichen Optionen betrachtet und mit Vor- und Nachteilen aufgelistet werden. Nachfolgend kann direkt die Entscheidung gefasst werden, da alle die an der Entscheidung beteiligt sein sollten, durch die Arbeitsweise als Mob bereits eingebunden sind. Die getroffene Entscheidung wird noch im Architecture Decision Record dokumentiert und schon kann mit der Umsetzung begonnen werden.

Dass man in verteilten Teams mit wenig realer sozialer Interaktion so mehr das Gefühl der Teamzugehörigkeit und des Vertrauens schafft, hilft auch auf der zwischenmenschlichen Ebene.

Welche Herausforderungen sind euch begegnet und wie seid ihr damit umgegangen?

Das ständige Zusammenarbeiten erfordert viel Konzentration und kostet viel Energie. Gerade anfangs dauerte es eine Weile, bis wir das realisiert und uns bewusst Pausen eingebaut haben. Auch das Einführen einer ausgedehnten, zweistündigen Mittagspause hat uns zusätzlich geholfen.

Eine weitere Herausforderung ist die hohe Koppelung zwischen den Anwendungen des Kunden. So kommt es immer wieder vor, dass wir als Team Änderungen an einer Anwendung eines anderen Teams vornehmen müssen. Alle Änderungen die wir dort vornehmen, sprechen wir vorher mit dem Team ab und erwarten auch im Nachgang ein Code Review. Das kostet leider sehr viel Zeit und führt zu Kontextwechseln. Diese Herausforderung wird aktuell im Projekt angegangen, so haben wir durch ein Event Storming Bounded Contexts identifiziert und sind nun dabei, die Anwendungen neu zu schneiden, um Features möglichst aus einer Anwendung heraus liefern zu können. Das führt dazu, dass unsere Features nur noch Änderungen an unserem Code nach sich ziehen. Die Arbeit im Mob sollte so noch produktiver werden.

Durch die Arbeit von Zuhause sehen wir leider nicht, wenn unser Product Owner an seinem Schreibtisch und gerade nicht in einem Meeting ist. Das erschwert es uns, wichtige Fragen an den Product Owner zu stellen. Man kann natürlich versuchen, ihn anzurufen, ob das jedoch erfolgreich ist, weiß man nicht. Daher haben wir uns darauf geeinigt, zu Beginn unseres Arbeitstages einen 15 Minuten Slot einzuplanen, in dem der PO uns zur Verfügung steht. Wenn wir Themen haben schreiben wir unserem Product Owner eine Nachricht und er kommt einfach in unseren virtuellen Raum. Ebenso wird dieser Zeitslot auch genutzt, wenn der Product Owner gerne einen Zwischenstand von uns hätte.

Was sagt der Kunde dazu?

Unser Kunde findet Remote Mob Programming sehr gut, da sich die Leute zwingend austauschen und so keine Wissenssilos entstehen können. Codereviews haben des Öfteren zu starker Frustration geführt. Seien es konzeptuelle Fehler, die erst relativ spät gefunden wurden oder auch einfach nur die Wartezeit, bis das Review erfolgt ist. Dies gehört nun der Vergangenheit an, da bereits bei der Entwicklung alle Teamkollegen beteiligt sind und so ungewisse Punkte frühzeitig entdeckt und geklärt werden können.

Würdet Ihr die Arbeitsweise weiterempfehlen?

Ja! 🙂

Team Jupiter, Branche Online-Marktplatz

Wie ist euer Team aufgebaut?

Unser gesamtes Team bestand aus drei Backend Developer sowie einem Frontend Developer und einem Product Owner. Der Frontend Developer hat überwiegend alleine gearbeitet, während die drei Backend Developer zusammen im Mob gearbeitet haben.

Wie habt ihr Remote Mob Programming eingeführt?

Anfangs haben wir darüber diskutiert, in welchem Modus wir arbeiten wollen. Der Service war recht überschaubar, sodass man ohnehin nicht gut parallel daran arbeiten konnte. Da wir mit Kotlin eine neue Technologie eingesetzt hatten, war es uns außerdem wichtig, das Wissen im Team zu verteilen. Deshalb haben wir uns dafür entschieden, im Mob zu arbeiten. Dies geschah die ersten sechs Monate in Präsenz im Berliner Büro. Erst durch den Lockdown wurden wir dazu gezwungen, das Mob Programming remote durchzuführen.

Was hat es euch für Vorteile gebracht?

Ein großer Vorteil, der sich schnell bemerkbar gemacht hat, war die bessere Wissensverteilung in unserem Team. Dadurch dass wir fast permanent im Mob gearbeitet haben, konnten in der Code-Basis des neuen Service gar nicht erst Wissensinseln entstehen. Darüber hinaus war es deutlich einfacher, gemeinsam kleine und große Architekturentscheidungen zu treffen, da alle Beteiligten den gleichen Wissensstand hatten. Dies führte dann auch dazu, dass die getroffenen Architekturentscheidungen durchdachter und passender waren als von den Teammitgliedern einzeln hätten getroffen werden können.

Ein weiterer Effekt, der sich bemerkbar machte, war, dass fachliche Lücken und Unklarheiten schneller erkannt und entsprechend abgeklärt wurden. Arbeitet man alleine, übersieht man diese unserer Erfahrung nach häufig zu Beginn und stößt erst spät während der Entwicklung darauf, wenn man schon lange in die falsche Richtung gelaufen ist.

Durch die ständige Arbeit zusammen im Mob hat sich zudem schnell ein gemeinsamer Code-Stil entwickelt, da niemand im Alleingang seine persönlichen Vorlieben durchdrücken konnte. Dies hat es natürlich einfacher gemacht, sich in unserer Codebasis zurechtzufinden, auch wenn man eine Zeit lang abwesend war, etwa wegen Krankheit oder Urlaub. Generell hat die Arbeit im Mob dazu geführt, dass unser Code einfacher zu lesen und zu warten war — der Mob war schlicht eine direktere und strengere Qualitätskontrolle, als es ein Code-Review im Pull-Request-Modell in der Regel ist. Das lag auch daran, dass das Feedback sofort kam, und nicht erst, wenn das Feature bereits fertig implementiert war.

Durch den Wegfall von Code-Reviews konnten wir Features außerdem schneller umsetzen und in Produktion bringen. Es gab keine Wartezeiten auf das Code-Review und keine Mergekonflikte — und natürlich auch kein Context Switching, wenn jemand zwischen der Entwicklung eines Features und dem Review eines ganz anderen Features hin und her wechseln musste.

Zwar waren Teile des Mobs zu unterschiedlichen Tagen wegen Teilzeit nicht anwesend, aber mindestens eine Person war an jeweils aufeinander folgenden Tagen konstant dabei und konnte so das Wissen von dem, was am letzten Tag gemacht wurde, weiter tragen. Auch bei Urlauben oder anderen Abwesenheiten entfielen durch die gemeinsame Arbeit im Mob lange Übergaben.

Als wir das Projekt verlassen haben, haben wir im übrigen auch zur Übergabe Mob Programming verwendet. Dazu haben wir einen großen Mob gebildet aus unserem Subteam und einigen Leuten aus dem Team, das unsere Services übernehmen sollte. Dabei haben wir bei der Rolle des Typist konsequent ausgesetzt. Nach und nach konnten wir uns auch immer mehr zurückhalten, was Vorschläge zur Umsetzung angeht, bis das andere Team schließlich in der Lage war, Features komplett ohne unsere Unterstützung umzusetzen. Das andere Team war von dieser Vorgehensweise genauso begeistert wie wir. Es hat sich gezeigt, dass die Vorteile, die Mob Programming bei der Wissensverteilung bietet, sich auch bei der Übergabe an ein anderes Team als sehr nützlich erweisen.

Welche Herausforderungen sind euch begegnet und wie seid ihr damit umgegangen?

In der Phase, in der wir vor Ort im Büro gearbeitet haben, war es nicht immer leicht, die anderen Anwesenden im Großraumbüro nicht zu stören. Zwar hatten wir Zugriff auf einen separaten Meetingraum mit großem Bildschirm, dieser stand uns aber nicht immer zur Verfügung. Zudem machte uns das unterschiedliche Keyboard-Layout auf den verschiedenen Rechnern Schwierigkeiten, da wir keinen dedizierten Mob-Rechner zur Verfügung hatten.

Als wir dann remote gearbeitet haben, war unser Git Handover nicht besonders effizient. Der Hauptgrund war, dass das VPN des Kunden die Übertragung unserer Video-Calls und der Bildschirmübertragung so verlangsamt hat, dass wir uns gezwungen sahen, ausschließlich zum Pushen mit dem VPN zu verbinden — ein großer Overhead, bei dem auch für die entsprechende Person immer der Video-Call unterbrochen wurde.

Was sagt der Kunde dazu?

Der Kunde hatte kein Interesse an Micromanagement und hat uns deshalb keine Vorgaben gemacht. Stattdessen standen stets die Ergebnisse im Vordergrund. Was zählte war, dass wir unsere Features rechtzeitig umsetzen — und das in dieser Konstellation stets wunderbar funktioniert.

Unser Product Owner konnte seine Zweifel schnell überwinden. In einer Retrospektive hat er sich dann auch sehr positiv geäußert über die schnelle Geschwindigkeit, in der Features umgesetzt und in Produktion gebracht wurden. Ebenfalls angetan war er davon, dass er immer mindestens eine Person hatte, die ihm zu sämtlichen Themen des neuen Services Auskunft geben konnte.

Würdet ihr die Arbeitsweise weiterempfehlen?

Grundsätzlich ist Mob Programming für uns bisher die beste aller Arbeitsweisen, und wir wünschen uns, nur noch in diesem Modus zu arbeiten. Natürlich ist dies nur dann sinnvoll, wenn alle Beteiligten eine ähnliche Einstellung zum Mob Programming haben. Tendenziell würden wir zwar lieber in Präsenz Mob Programming machen, das Remote Mob Programming hat sich für uns aber ebenfalls bewährt. In Zukunft würden wir dann allerdings wohl konsequent das mob-Tool einsetzen, um schnellere Handovers hinzubekommen.

Remote Mob Programming erleben

Interesse an Remote Mob Programming bekommen? INNOQ bietet einen Workshop namens Remote Mob Programming erleben an um an einem Tag die Methode bei einer realistischen Fallstudie kennen zu lernen – und Spaß macht es auch, versprochen.