Von Fackeln und Forken – wie der Mob remote zusammenkommt

Die aktuelle Situation verlangt von uns, im Home-Office zu arbeiten. Dadurch fehlt vielen Teams der direkte persönliche Kontakt; im Alltag kommt es bei uns zum Beispiel sehr häufig vor, dass ein Teammitglied in den Raum hinein ruft, wie ein Problem zu lösen wäre. Schon alleine das verbale Auseinandersetzen mit dem Problem führt häufig zur Lösung.

Damit wir nicht bald alle nur noch mit unseren Gummienten reden, möchte ich hier eine mögliche Lösung aufzeigen. Denn es gilt: Entwicklerteams können auch remote hervorragend zusammenarbeiten.

Was ist Mob Programming?

Mob Programming ist als Softwareentwicklungsansatz definiert, bei dem das gesamte Team zur selben Zeit an derselben Sache im selben Raum am selben Computer arbeitet.

Das funktioniert so ähnlich wie Pair Programming, bei dem sich zwei Entwickler gleichzeitig um dasselbe Problem kümmern. Dabei gibt es immer einen sogenannten Driver, der an der Tastatur sitzt und den Code eingibt und einen Navigator, der die Denkarbeit übernimmt und ansagt, was zu tippen ist. Nach einem bestimmten Zeitraum wechseln die beiden die Rolle.

Beim Mob Programming gibt es ebenfalls einen Driver der tippt, aber alle anderen Beteiligten sind gleichzeitig Navigator und bestimmen gemeinsam, wie der Code gestaltet sein soll. 

„Alle anderen Beteiligten“ meint an dieser Stelle wirklich alle im Team, sogar der PO und auch der Kunde können hinzugenommen werden. 

Das Mob Programming ist übrigens nicht nur auf das Schreiben von Code begrenzt; es können auch User Stories und Anforderungen definiert werden. Darüber hinaus kann designed, getestet oder auch Software deployed werden.

Die Vorteile von Mob Programming

Das gemeinsame Entwickeln im Mob bietet einige Vorzüge. Das Wissen über die Codebasis und das Projekt verteilt sich besser im Team und Silowissen wird so vorgebeugt. In der modernen Softwareentwicklung kommt diesem Punkt eine große Bedeutung zu, löst es doch das Problem vom Wissensvakuum im Falle von Urlaub, Krankheit oder Kündigung.

Die Umsetzung der einzelnen Tickets erfolgt sehr viel schneller, und auch auch komplexere Tickets werden im Team einfacher gelöst, da mit gemeinsamen Wissen und Erfahrungsschatz daran gearbeitet wird.

Außerdem wird auch noch ein anderer Stelle kostbare Zeit eingespart: Ein separates Code Review kann entfallen, da sich bereits mehrere Personen mit diesem Problem beschäftigt und gemeinsam die für sie beste Lösung gefunden haben. Bei kleinen Teams kann sogar das Daily entfallen, da bereits jeder darüber informiert ist, woran der jeweils andere arbeitet und mit welchen Problemen man aktuell zu kämpfen hat.

Neue Teammitglieder profitieren dabei vom geballten Wissen des Teams, denn sie werden unmittelbar an die aktuellen Problemstellen des Projektes herangeführt und können daneben mit ihrer eigenen Erfahrung zur Lösung beitragen. Darüber hinaus werden auftretende Fragen sofort beantwortet, wodurch ein besseres Miteinander entsteht und neue Teammitglieder nicht einsam vor sich hin arbeiten, sondern direkt mit einbezogen werden – gerade in Zeiten von „Social Distancing“ ist das immens wichtig.

Nicht verachten sollte man zu Beginn jedoch, dass das Team noch einmal gemeinsam plant, wie das Ticket genau umzusetzen ist. Dabei werden auch die letzten Verständnisfragen geklärt.

Die Vorteile in Stichpunkten zusammen gefasst

• Wissen verteilt sich besser.
• Umsetzung der Tickets erfolgt schneller. Komplexere Tickets werden schneller fertig.
• Separates Code Review kann entfallen. Daily kann entfallen.
• Onboarding neuer Teammitglieder erfolgt schneller.
• Kontakt zum Team wird trotz Corona bzw. Remote-Arbeit intensiviert.
• Gemeinsame Planung, wie das Ticket umzusetzen ist.

Wie funktioniert das Ganze denn jetzt Remote?

Damit die Session geregelt und produktiv verläuft, sollten einige Regeln beachtet werden. Zuerst müssen alle Teilnehmer remote teilnehmen. Dafür eignet sich ein Videokonferenz-Tool der Wahl, sei es Google Meet, Microsoft Teams oder Zoom. Unser Team hat mit Whereby gute Erfahrungen gemacht, denn es erlaubt das gleichzeitige Teilen mehrerer verschiedener Bildschirme.

Wenn einige Teile des Teams zusammen in einem Raum und die anderen Mitglieder separat in ihren Home-Offices sitzen, kommt es zu asymmetrischer Kommunikation. Das bedeutet, dass die Kollegen, die in einem Raum sitzen, untereinander anfangen zu kommunizieren, ohne dass die Remote-Teilnehmer davon Kenntnis haben. Dadurch hat der asymmetrisch kommunizierende Teil des Teams mehr Informationen als der Andere. Ein wichtiger Aspekt beim Mob Programming ist jedoch, dass das Wissen an alle verteilt wird.

Die Durchführung

Benachrichtigungen sollten aus- und das Handy stumm geschaltet werden. E-Mail, Twitter, Slack – all das lenkt ab und sollte für die Zeit der Session pausiert werden, denn für ein produktives Arbeiten ist der Fokus aller Beteiligten notwendig.

Der Code sollte nur via Screen Sharing geteilt werden. Kollaborative IDEs verleiten die Teilnehmer dazu, an anderer Stelle zu programmieren oder, wenn sie ungeduldig sind, schnell ihre eigene Lösung einzubauen und nicht dem Driver zu folgen.

Auch sollte das Team klein gehalten werden, etwa vier bis fünf Teilnehmer maximal, denn bei größeren Gruppen tendieren die einzelnen Mitglieder dazu, den Fokus zu verlieren. Sollte das Projektteam aus sehr viel mehr Mitgliedern bestehen, werden mehrere Mob-Gruppen gebildet, die alle in ihrem eigenen Videokanal ein eigenes Problem angehen. In diesem Fall wird ein separates Daily benötigt, damit sich die Teams untereinander synchronisieren können.

Der Driver sollte etwa alle 10-15 Minuten gewechselt werden, damit jedes Teammitglied alle 30-50 Minuten die Rolle des Drivers einnehmen kann. Wer gerade kein Driver ist, ist Navigator und trägt mit seinem Wissen zur Lösung des Problems bei. Die Rolle des Drivers erlaubt es, sich für ein paar Minuten mental auszuruhen, da man nur auf Anweisung wartet.

Ganz wichtig ist darüber hinaus, dass eine Entscheidung, die von der Gruppe getroffen wurde, schwerer wiegt als eine Entscheidung, die von einem Individuum getroffen wurde. Die Gruppe trägt die gemeinsame Lösung, nicht der Einzelne.

Zuletzt möchte ich noch betonen, dass regelmäßige Pausen ebenfalls wichtig sind, um konzentriert zu bleiben. Es empfiehlt sich daher, eine kurze Pause von 5-10 Minuten einzulegen, nachdem alle Beteiligten einmal Driver waren oder spätestens nach 1 Stunde.

Hier alle Regeln in Stichpunkten kurz zusammengefasst

• Alle Teilnehmer müssen remote sein (wenn Teile des Teams zusammen in einem Raum sind, bilden sich mehrere Kommunikationskanäle).
• Benachrichtigungen ausschalten (E-Mail, Twitter, Slack, … das lenkt ab)
• Nur via Screenshare ausführen, nicht über kollaborative IDEs
• Team klein halten (max. 4-5 Teilnehmer)
• Jedes Teammitglied sollte etwa alle 30 – 50 Minuten die Rolle des Drivers einnehmen
• Driver etwa alle 10 bis 15 Minuten wechseln
• Gruppenentscheidung > Individualentscheidung
• Pause etwa alle Stunde oder nachdem alle Beteiligten einmal Driver waren

Die Schattenseiten

Wie bei allem anderen auch, gibt es natürlich auch hier einige Nachteile, die ich nicht verschweigen möchte.

Das einzelne Teammitglied verliert natürlich etwas Flexibilität in seiner individuellen Arbeitszeitgestaltung, da für das Mob Programming natürlich feste Zeiten existieren sollten. Um dem etwas entgegen zu wirken, können Kernzeiten definiert werden; beispielsweise von 09:00 Uhr bis 15:00 Uhr.

Hin und wieder haben einzelne Teammitglieder natürlich auch andere Termine, die sie wahrnehmen müssen. Das sollte den Rest des Teams jedoch nicht davon abhalten, trotzdem weiter zu mobben. Bei uns gilt: wer da ist, ist da und macht mit; wer keine Zeit hat, geht einfach und kommt gegebenenfalls später wieder.

Ein weiterer Punkt ist, dass in kleineren Teams nicht gleichzeitig an mehreren Tickets gearbeitet wird. Das sollte jedoch die Tatsache wieder wettmachen, dass das Code Review entfallen kann, im Allgemeinen eine bessere Codequalität erreicht wird und das Wissen innerhalb des Teams deutlich breiter verteilt ist.

Und du?

Ich hoffe, ich konnte dir hier eine wunderbare Teammethode näher bringen. An dieser Stelle würde mich interessieren, ob du bereits mit Mob Programming zu tun hattest. Wenn ja, so freue ich mich auf deine Erfahrungen oder Fragen in den Kommentaren.