Meine Projekt-Engineer- und Architektenkolleg*innen und ich haben kürzlich an einer internen Schulung zu „Remote Mob Programming für feste Teams“ teilgenommen. Wir wollten lernen, wie man am besten zusammen in einem Mob programmiert, welche Toolunterstützung es gibt und ob man diese Art der Arbeit leicht erlernen und in unseren Teams durchführen kann. In diesem Beitrag möchte ich meinen Erfahrungen aus dieser Schulung teilen.
Was ist Mob-Programmierung?
Mob-Programming oder auch Ensemble-Programming beschreibt einen Softwareentwicklungsansatz, in dem ein ganzes Team zusammen und gleichzeitig am gleichen Code arbeitet. In der heutigen Homeoffice-Zeit sieht das wie folgt aus:
- Alle Teammitglieder treffen sich in einer Online-Konferenz.
- Abwechselnd teilt ein Teammitglied den Bildschirm und ist zuständig für das Schreiben („die Schreibkraft“). Das Teammitglied schreibt allerdings nur das, was die anderen Mitglieder ausdiskutieren und im Anschluss diktiert haben! Die Schreibkraft nimmt dabei nicht an der Diskussion teil und schreibt auch nicht eigenmächtig Code.
- Nach 5 Minuten wird gewechselt, dann schreibt das nächste Teammitglied und teilt den Bildschirm. Nach weiteren 5 Minuten wird wieder gewechselt. Das geht solange, bis der Code fertig ist oder ein vorher festgelegter Zeitraum zu Ende ist.
Softwareseitig finden wir Unterstützung zur Durchführung des Mob-Programmings im Opensource-Tool mob. Arbeitet das Team in einem Git-Repository, erstellt mob mittels mob start einen temporären Entwicklungszweig, in dem für die Dauer des Mob-Programmings gearbeitet wird. Gleichzeitig bringt es einen Timer mit, der alarmiert, wenn die 5 Minuten Arbeitszeit vorbei sind. Mittels mob next werden alle Änderungen in den temporären Entwicklungszweig commited. Die nächste Person wird zum Schreiber und führt dann wieder mob start aus. Dadurch werden alle Änderungen des vorherigen Schreibers geladen. So kann nahtlos am Code weitergearbeitet werden. Nach 5 Minuten führt der Schreiber wieder mob next aus und die nächste Person ist an der Reihe. Ist die Mob-Programming-Runde zu Ende, wird mob done ausgeführt. Der Befehl fasst alle Änderungen zu einem Commit zusammen, welcher dann in den Haupt-Entwicklungszweig überführt werden kann.
Was haben wir in der Mob-Session gelernt?
In unserer Schulung haben wir eine Mob-Session durchgeführt. Wir haben uns im Vorfeld dazu ein Thema überlegt: Aufsetzen eines Kubernetes-Clusters mittels Ansible in der Azure und Deployment einer Beispielanwendung darin. Die Schulungsleiterin hat uns durch die Arbeitsweise geführt und uns bei Fragen unterstützt, sonst waren wir auf uns allein gestellt.
Was haben wir währenddessen festgestellt und gelernt?
- Einer der wichtigsten Punkte ist, dass jedes Teammitglied die gleiche Arbeitsumgebung besitzt. Für unser Mob-Programming brauchen wir aktuelle Versionen von git, Ansible (inklusive der gleichen Collections) und kubectl, sowie eine aktuelle Pythonversion mit einer Unzahl an Paketen.
- Wenn ein Teammitglied unter Windows arbeitet, ein weiteres in der WSL und ein drittes in einer Linux-VM, gibt es unzählige Stolpersteine, damit alle an einen Stand kommen, um sinnvoll arbeiten zu können. Natürlich sind wir dann irgendwann auf Docker umgestiegen.
Dazu haben wir einen sogenannten Management-Container erstellt, welcher alle benötigten Softwarepakete in den richtigen Versionen in einem Container installiert. Das hat 90% der Probleme beseitigt, die restlichen 10% konnten wir dann zusammen in der Mob-Session lösen. Bevor wir an diesem Punkt angelangt waren, verging allerdings über eine Stunde.
- Anfangs in der Mob-Session hatten wir das Gefühl, dass ein 5-Minuten-Intervall zum Wechseln sehr kurz ist und wir diesen vielleicht verlängern sollten. Wir haben allerdings schnell festgestellt, warum kurze Intervalle sinnvoll sind: jede Person sollte innerhalb von 30 Minuten einmal an die Reihe kommen, zu schreiben. Verlängert man das Intervall auf beispielsweise 10 Minuten, würde in einem 5-Personen-Team jeder nur knapp einmal in der Stunde drankommen. Das kann schnell zu Ablenkung führen. Durch kurze Intervalle bleibt die Konzentration bei den Personen höher, da jeder schnell wieder an der Reihe ist.
- In unserer Schulung haben wir auch viel über Zusammenarbeit gelernt. Es ist wichtig, dass jede Person in der Mob-Session auf die Aufgabe fokussiert ist. Aktive Teilnahme ist unbedingt erforderlich: kommt jemand nicht mit oder hat eine Idee zu einem Problem, sollte die Person das aktiv ansprechen. So bleibt jeder am Ball und verliert nicht die Lust am Arbeiten. Genauso sollte man sich aktiv für Pausen entscheiden, da solch fokussierte Arbeit und Diskussion schnell erschöpfend werden kann.
- Ein interessantes Problem während einer Mob-Session kann die ungleiche Wissensverteilung in einem Team sein. Hat der aktuelle Schreibende tieferes Wissen als die anderen Teammitglieder über das zu bearbeitende Thema, fühlt sich die Person womöglich ausgebremst und möchte von sich aus weiterschreiben. Hier ist allerdings Geduld und Ausdauer gefragt, um niemanden abzuhängen. Ist jemand anderes dann der Schreibende, kann der Experte sein Fachwissen mit dem Team teilen, so dass alle daran partizipieren.
- Da in einer Mob-Session viele verschiedene Personen zusammenarbeiten, können die Lösungen der Probleme entsprechend vielfältig sein. Hier hat es sich bewährt, dass jede Person ihren Lösungsansatz vorbringt und diskutieren darf, meist findet man dann im Team zusammen die Variante, auf die sich alle einigen können.
Im Flow: Produktiv im Mob
So eine Mob-Session kann sehr sinnvoll sein: Man teilt sein Wissen sofort mit dem Team, man benötigt kein Code-Review und vier Augen (oder 10) sehen bekanntlich mehr als zwei. Natürlich kostet so eine Session auch Kraft, da man praktisch durchgehend fokussiert sein muss und in ständiger Diskussion ist. Und wenn alle eine funktionierende Arbeitsumgebung haben, kommt man schnell in einen Flow, wo das Zusammenarbeiten sehr viel Spaß macht.
PS: Das Ergebnis unserer Session könnt ihr euch hier ansehen.
Interessiert Dich in welchen Services unsere Teams arbeiten?
> Hier eine Referenz dafür
Linux und Open Source Enthusiast. Aus dem traditionellen Betrieb kommend, schlage ich jetzt Brücken zwischen Betrieb und Entwicklung und tauche nebenbei in die Cloud-Native Landschaft ein.