Mob-Programming: Effektive Entwicklung durch Zusammenarbeit

Zusammenarbeit und Teamwork sind bei Softwareentwicklungsprojekten von grundlegender Bedeutung. Während effektive Teamarbeit jedoch eine so wichtige Rolle spielt, können sich die traditionellen Ansätze der Softwareentwicklung unkollaborativ und distanziert anfühlen. Nach sechs Monaten als Teil eines Mob-Programming-Teams habe ich gelernt, dass Zusammenarbeit bei großen Softwareprojekten nicht nur einfach und effektiv sein kann, sondern auch Spaß macht und sich durchaus lohnt. In diesem Blog möchte ich über meine Erfahrungen mit Mob-Programming berichten, darüber, wie es einige der typischen Herausforderungen in unserem Team gelöst hat und über die Erkenntnisse, die unser Team auf diesem Weg gewonnen hat. 

Was ist Mob-Programming? 

Mob-Programming ist ein Softwareentwicklungsansatz, bei dem eine Gruppe bzw. ein „Mob“ von Entwicklern zusammenkommt, um gemeinsam ein Problem im Zusammenhang mit Software zu lösen. Viele Teams sind vielleicht mit der gängigen Praxis des Pair-Programming vertraut, bei dem zwei Entwickler gemeinsam an einem Problem arbeiten. Beim Mob-Programming geht die Zusammenarbeit noch einen Schritt weiter, indem drei oder mehr Personen an einem gemeinsamen Ziel arbeiten. Mob-Programming wurde erstmals durch den Entwickler und Agile-Guide Woody Zuill bekannt, der ab 2014 eine Reihe von einflussreichen Vorträgen über Mob-Programming und dessen Vorteile hielt. 

Zuill beschreibt die Grundidee der Mob-Programmierung als: 

“All the brilliant people working on the same thing, at the same time, in the same place and at the same computer.” 

Wie funktioniert Mob-Programming?

1. Die Rollen

Ähnlich wie beim Pair-Programming teilt sich das Team in die Rolle des Typist, also der Person, die den Code schreibt, und die Navigatoren, auch als Mob bezeichnet. In dieser Konstellation brainstormen die Navigatoren Ideen und diskutieren mögliche Lösungen. Die Aufgabe des Typist besteht darin, die Diskussionen der Gruppe zu verfolgen und ihre Vorschläge in Code umzusetzen. Dies erfordert eine präzise Kommunikation, wobei die Navigatoren sicherstellen müssen, dass sie ihre Ideen in einem Tempo und auf einer Abstraktionsebene teilen, dem der Typist folgen kann. 

2. Mob Rotationen

Nach einer bestimmten Zeit gibt der Typist seine Rolle auf und schließt sich dem Mob an. Gleichzeitig übernimmt einer der Navigatoren die Rolle des Typists. Das Rotieren der Rollen ist ein wesentlicher Bestandteil des Mob-Programmierungs-Workflows und erfolgt in der Regel nach einer festgelegten Zeitspanne. Durch diese Rotation wird ein hohes Engagement aller Mob-Mitglieder erreicht, da jedes Teammitglied irgendwann die Aufgabe hat, die Lösung zu programmieren. 

Vorteile von Mob-Programming

Als Mitglied eines Mob-Programmierungsteams konnte ich aus erster Hand erfahren, welche enormen Vorteile dieser kollaborative Ansatz in vielerlei Hinsicht bietet. Im Folgenden möchte ich einige dieser Vorteile näher erläutern und die Geheimnisse hinter dem Erfolg dieses Ansatzes aufzeigen! 

1. Code Qualität

Kontinuierlicher Workflow 

Das Programmieren im Mob bietet den entscheidenden Vorteil eines kontinuierlichen Workflows.  Die Beteiligung mehrerer Teammitglieder verringert die Wahrscheinlichkeit von Unterbrechungen oder Verzögerungen der Arbeit aufgrund individueller Abwesenheit. Sollte ein Teammitglied einmal nicht anwesend sein, können andere schnell einspringen und die Arbeit fortsetzen. Der kontinuierliche Arbeitsfluss hat insgesamt zu schnelleren Entwicklungszyklen beigetragen und hat sich außerdem positiv auf die Atmosphäre und Kultur innerhalb unseres Teams ausgewirkt. Da die Fertigstellung einer Aufgabe nicht von der An- oder Abwesenheit einer einzelnen Person abhängt, hat unser Team einen sehr entspannten Umgang mit persönlichen Terminen, Urlaub oder Krankheit gefunden. 

Kontinuierliche Code-Reviews 

In traditionellen Entwicklungsabläufen ist das Code-Review ein zeitaufwändiger Prozess, der nach Abschluss der Implementierung stattfindet. Beim Mob-Programming hingegen finden Code-Reviews natürlicherweise während des Zusammenarbeitsprozesses statt. Während das Team gemeinsam am Code arbeitet, findet kontinuierliches Peer-Review in Echtzeit statt. Dadurch entfällt die Notwendigkeit für traditionelle Code-Reviews, da der Code direkt während des Schreibens überprüft wird. 

Obwohl einige Bedenken zur Code-Qualität geäußert werden könnten, hat unsere Erfahrung das Gegenteil gezeigt. Obwohl wir nicht mehr auf Code-Reviews angewiesen sind, führt unser Team regelmäßig Refactorings durch. In diesen Sessions besprechen wir diverse Stellen in der Codebasis, diskutieren potenzielle Verbesserungen und setzen sie um, um eine qualitativ hochwertige Codebasis sicherzustellen. 

Hoher Truck-Faktor 

Der Begriff „Truck-Faktor“ beschreibt die Anzahl der Teammitglieder, die (metaphorisch) von einem Lastwagen erfasst werden müssen, damit ein Projekt einen schwerwiegenden Rückschlag erleidet. Da unser Team täglich zusammenarbeitet und somit Wissen verteilt, ist der Truck-Faktor unseres Teams äußerst hoher. Das Projekt ist somit äußerst resistent gegen unvorhergesehene Ereignisse und kann auch dann fortgesetzt werden, wenn ein Mitglied des Teams abwesend ist oder die Arbeit am Projekt nicht fortsetzen kann. 

2. Kommunikation

Reduzierter Kommunikations-Overhead 

Durch die gemeinsame Arbeit ist die Notwendigkeit separater Kommunikationskanäle wie E-Mail, Chat oder Meetings deutlich gesunken. Die direkte und unmittelbare Kommunikation innerhalb des Mobs erspart langwierige Klarstellungen und verringert so die Anzahl der Verwirrungen und Missverständnisse, die oft durch asynchrone Kommunikation entstehen. 

Kontinuierliches Lernen 

Eine der unmittelbaren Vorteile, die ich als Teil des Mobs gewonnen habe, war das dynamische Lernumfeld. Die Zusammenarbeit mit Kollegen an verschiedenen Aufgaben ermöglicht es uns, Fachwissen, Einblicke und Ideen auszutauschen. Hierdurch konnten wir unser Verständnis der Codebasis erweitert, neue Programmiertechniken erlernt und sind im Laufe der Zeit zu vielseitigeren Entwicklern geworden. 

Bessere Entscheidungsfindung 

Während der Implementierung ist es üblich, auf verschiedene Entscheidungen zu treffen. In der Regel sind diese Entscheidungen technischer Natur und ergeben sich, nachdem die Business-Logik definiert ist. Beispielsweise könnte man überlegen: 

• Soll diese Methode Teil von Service A sein, oder sollte ein neuer Service eingeführt werden? 

• Sollte eine neue Methode erstellen oder eine vorhandene Methode refactort werden? 

Oft existieren mehrere Lösungen, aber die passende zu finden, die am effizientesten, am intuitivsten oder schlichtweg konsistent mit der Codebasis ist, fällt schwer. Die Zusammenarbeit im Mob vereinfacht die Entscheidungsfindung und macht diese greifbarer. Angesichts einer schwierigen Situation können Teammitglieder sofort über mögliche Lösungen diskutieren.  Durch die Einbeziehung mehrerer Perspektiven kann das Team schneller eine bessere Lösung finden und dabei das Risiko von kostspieligen Fehlern oder dem Übersehen wichtiger Aspekte des Codes minimieren. Weiterhin hat dies dazu beigetragen, dass wir im Laufe der Zeit als Team einen prägnanten und einheitlichen Codestil entwickelt haben, der die Lesbarkeit und Konsistenz unserer Codebasis verbessert. 

3. Team

Soziale Verbindungen 

Die soziale Verbundenheit, die während dieser gemeinsamen Arbeitssitzungen entsteht, stärkt die Arbeitsbeziehungen, selbst wenn die Teammitglieder physisch voneinander getrennt sind. Insgesamt hat dieses Gefühl der Verbundenheit und Teamarbeit zu einer positiven Teamkultur beigetragen und das Gefühl der Isolation, das oft mit der Arbeit im Homeoffice verbunden ist, erheblich verringert. 

Einfaches Onboarding 

Anstatt sich ausschliesslich auf das Selbststudium oder separate Trainingseinheiten zu konzentrieren, konnten neue Teammitglieder konnten sich direkt in die Mob-Sitzungen stürzen. Durch die aktive Teilnahme und die Zusammenarbeit mit erfahreneren Kollegen konnten neue Teammitglieder den Kontext des Projekts, die Struktur der Codebasis und die Arbeitsnormen innerhalb des Teams schnell erfassen. Dank dieses direkten Lernansatzes gestaltet sich der Onboarding-Prozess effizient und angenehm, und einige der Frustrationen, die mit dem Eintritt in ein neues Team verbunden sind, konnten verringert werden. 

Remote Mob-Programming

Im Laufe meiner Recherchen überraschte mich die weit verbreitete Meinung, dass Mob-Programmierung nicht geeignet ist für verteilte Teams die hauptsächlich remote arbeiten. Viele Quellen behaupten, dass es sich am besten für die Arbeit vor Ort eignet, bei der alle Teammitglieder anwesend sind. Entgegen diesen Aussagen hat sich unsere Remote-Mob-Arbeit als äußerst effektiv erwiesen und meine Wahrnehmung von Remote-Arbeit grundlegend verändert. Im folgenden Abschnitt gehe ich auf die wichtigsten Aspekte unseres Remote Mobs ein. 

Kein fester Driver-Navigator Pattern

Im Rahmen der Mob-Programmings ist es üblich, dass der Navigator Lösungen vorschlägt, welche der Typist in Code umsetzt. Diese Muster ist auch als das Driver-Navigator Pattern bekannt. Für unser Team wurde schnell klar, dass wir uns dabei nicht strikt an dieses Muster halten wollen. 

Während unserer Zusammenarbeit stellten wir fest, dass es von Vorteil ist, wenn der Typist sich an Diskussionen beteiligt und seine Ideen während des implementierens einbringt. Dieser Ansatz vermeidet das Gefühl, von anderen „ferngesteuert“ zu werden, was oft frustrierend sein kann, vor allem in remoten Konstellationen. 

Die Kommunikation gewinnt mit diesem Ansatz zunehmend an Bedeutung. Da der Typist in der Lage ist, die Lösung während des Programmierens zu formulieren, ist es entscheidend, dass er seine Gedankengänge klar artikuliert, um sicherzustellen, dass sich alle Teammitglieder während der gesamten Mob-Sitzung einbezogen fühlen. Insofern sollte sich das Team angewöhnen, laut und offen zu denken und in einem angemessenen, leicht zu verfolgenden Tempo zu arbeiten. 

Das Virtual Office 

Woody Zuills Vision, dass alle Teammitglieder am selben Ort und an demselben Computer arbeiten, wurde vor der verbreiteten Praxis des Remote-Arbeitens entwickelt. Während es in einer Remote-Umgebung unmöglich ist, am selben Computer zu arbeiten, ist trotzdem möglich, an demselben (virtuellen) Ort zu arbeiten. Innerhalb unseres Teams nutzen wir ein „Virtual Office“, ein geteilter virtueller Raum, in dem sich das Team trifft und zusammenarbeitet. 

Das virtuelle Büro ist immer offen, und die Teilnehmer können von außen gesehen werden. Durch die Nutzung eines virtuellen gemeinsamen Raums wird der Kommunikationsaufwand bei der Organisation von Gruppengesprächen verringert. Darüber hinaus dient dieser Raum als natürlicher Treffpunkt für alle Teammitglieder. Wenn Teammitglieder nicht in einer Besprechung sind oder mit anderen Aufgaben beschäftigt sind, treffen sie sich alle im virtuellen Office. 

Die passende Rotation finden 

Es gibt keine allgemeingültige Antwort auf die Frage nach der optimalen Rotationsdauer innerhalb einer Mob-Session. Unser Team hat verschiedene Rotationszeiten zwischen 5, 10 und 15 Minuten ausprobiert, um herauszufinden, was für uns in verschiedenen Situationen am besten funktioniert. Dabei konnten wir zwei wichtige Aspekte herausfinden, die es zu berücksichtigen gilt:

1. Mob-Größe:

Die Größe der Gruppe spielt eine entscheidende Rolle bei der Bestimmung der idealen Rotationsdauer. In größeren Gruppen sind schnellere Rotationen in der Regel effektiver, da sie dazu beitragen, den Fokus aufrechtzuerhalten. Weiterhin, sorgen kürzere Rotationen dafür, dass jeder die Möglichkeit hat, als Typist aktiv mitzuwirken. 

2. Komplexität:

Die Komplexität der Aufgabe beeinflusst ebenfalls die Rotationszeiten. Im Falle weniger komplexer Aufgaben, die nur wenig Diskussionsbedarf erfordern, genügen oft kürzere Rotationen von 5 oder 10 Minuten. Im Allgemeinen konnten wir feststellen, dass kürzere Rotationen das Arbeitstempo des Teams erhöhen. Dagegen verlangsamen längere Rotationen von 15 Minuten oder mehr das Tempo und geben allen Beteiligten mehr Zeit, ihre Gedanken zu diskutieren. Dies ist im Falle von komplexeren Themen oft notwendig und sinnvoll. 

Was man beachten sollte 

Größe des Teams 

Bei der Implementierung von Mob-Programmierung ist die Teamgröße ein wesentlicher Faktor. Als Team, das aus 9 Entwicklern besteht, mussten wir häufig über die ideale Anzahl von Teilnehmern diskutieren und haben mit Mob-Größen von 3 bis 9 Personen in einer Sitzung sowie mit mehreren kleineren Mobs, die parallel arbeiten, experimentiert. Over time we have found our sweet spot at around 4 – 5 people. Im Laufe der Zeit haben wir unseren Sweet Spot bei etwa 4 – 5 Personen gefunden. Obwohl die Arbeit in sehr großen Gruppen möglich ist, wurde deutlich, dass der zusätzliche Nutzen der Zusammenarbeit bei Gruppen von mehr als 5-6 Personen nachlässt. Darüber hinaus neigen Diskussionen dazu, unübersichtlich zu werden, was dazu führt, dass die Beteiligung von Teilen des Teams nachlässt. Auch die Wartezeiten zwischen den Rotationen können in größere Gruppen recht lang werden. In einer Gruppe von 6 Personen, die sich alle 10 Minuten abwechseln, muss jede Person 50 Minuten warten, bis sie als Fahrer an der Reihe ist, was wiederum zu sinkendem Fokus führt. 

Ist Mob-Programmierung also ausschließlich für kleine Teams von bis zu 5 Personen geeignet? Unsere Lösung besteht, wie bereits angedeutet, darin, dass wir in erster Linie als zwei separate Mobs arbeiten. Jeder Mob arbeitet an separaten Aufgaben, die sich nicht überschneiden. Große Mobs bleiben für spezielle Aufgaben reserviert, z. B. für die Implementierung grundlegender Features, wovon das gesamte Team profitiert und wodurch sichergestellt wird, dass alle Teammitglieder ein fundiertes Verständnis der Kernfunktionen unserer Anwendung haben. Durch die Trennung in separate Mobs ist es uns gelungen, das Mob-Programming als unsere primäre Arbeitsmethode beizubehalten und gleichzeitig kleine und effiziente Sessions zu gewährleisten. 

Beschäftigung vs. Effektivität 

Bevor ich zum Schluss komme, möchte ich noch auf die Problematik der Effizienz eingehen. Ohne Zweifel lautet die häufigste Reaktion, die ich bei der Erklärung von Mob-Programming erhalte, „das kann nicht effizient sein“. Obwohl die Vorteile der Zusammenarbeit und des Wissensaustauschs allgemein anerkannt werden, fällt es vielen schwer, Mob-Programming als ernstzunehmende Alternative oder gar Verbesserung gegenüber der herkömmlichen Arbeitsweise zu sehen. Warum sollten sie auch nicht? Sicherlich werden 5 Personen, die an einer Aufgabe arbeiten, nicht so effektiv sein wie 5 Personen, die an separaten Aufgaben arbeiten, nicht wahr? Dieser Gedankengang scheint intuitiv, setzt aber fälschlicherweise Beschäftigung mit Effektivität gleich. Kurz gesagt, viele nehmen an, dass eine höhere Auslastung der vorhandenen Ressourcen zu mehr Fortschritt führt. Diese Annahme mag für einfache und repetitive Aufgaben zutreffen, die beispielsweise bei körperlicher Arbeit oft vorkommen. Für Wissensarbeit wie Software-Engineering trifft sie jedoch nicht zu. 

Ein einzelner Entwickler, der an einem Problem arbeitet, stößt mit größerer Wahrscheinlichkeit auf Probleme, muss seinen Code zum Review vorlegen und wird eher ein wichtiges Detail übersehen als eine Gruppe von Entwicklern. Dies verringert die Projektgeschwindigkeit, erfordert Kommunikationsumwege und verursacht somit Wartezeiten. Gleichzeitig entsteht die Gefahr, dass Silowissen aufgebaut wird. Der Fokus darf folglich nicht zu stark auf das Erreichen einer hohen Ressourceneffizienz gelegt werden, sondern auf das Erreichen einer hohen Flow-Effizienz, also auf die Zeit, die mit wertschöpfenden Aktivitäten verbracht wird. Betrachtet man die Flow-Effizienz, so wird Mob-Programmierung zu einem sehr viel sinnvolleren Ansatz. Weniger Wartezeit, mehr Wissenstransfer und mehr Zeit für aktive Wertschöpfung. 

Nicht für jeden geeignet 

Zum Abschluss dieses Artikels ist es wichtig, einige Einschränkungen von Mob-Programming zu benennen und anzuerkennen, dass es keine Universallösung ist. 

Nicht jede Aufgabe ist für Mob Programming geeignet. Aus unserer Erfahrung heraus konnten wir erkennen, dass Aufgaben, die wenig strukturiert sind, ein hohes Maß an Komplexität aufweisen und ein hohes Maß an Konzentration erfordern, sich nicht gut mit der ständigen Zusammenarbeit vereinbaren lassen. Insbesondere Mob-Rotationen wirken hierbei oft ungeeignet, vor allem bei sehr experimentierintensiven Aufgaben. 

Zudem muss berücksichtigt werden, dass Mob-Programming nicht für jeden geeignet ist. Manche Menschen empfinden es als überwältigend oder unangenehm, und manch anderer mag schlichtweg die ständige Arbeit in einer Gruppe nicht. Aus welchem Grund auch immer, es ist wichtig, individuelle Präferenzen zu respektieren. 

In diesem Sinne wählen wir eine pragmatische Haltung zur Mob-Programmierung und vermeiden starre Dogmen. Profitiert eine Aufgabe von der Zusammenarbeit, was bei den meisten der Fall ist, arbeiten wir als Mob. Wenn die Aufgabe viel Herumprobieren erfordert, wechseln wir zur Einzelarbeit oder zum Pairing. Gelegentlich kann es vorkommen, dass sich ein Teammitglied dafür entscheidet, allein zu arbeiten, da es sich in ein Problem vertiefen möchte oder einfach eine Verschnaufpause von der Gruppe braucht, und auch das ist völlig in Ordnung. Abschließend ist es wichtig, sich vor Augen zu halten, dass Mob-programming ein Werkzeug ist und als solches ein Mittel zum Zweck darstellt, nicht umgekehrt. 

Nehmen Sie Kontakt mit uns auf

---