Pairing, Ensemble Programming, Swarming – Collaboration-Frameworks für Developer effektiv nutzen!

Wie können Entwickler:innen konkret während eines Sprints zusammenarbeiten? Und da meine ich nicht ein gelegentliches „Schau mal bitte mit drauf, ich komm da grad nicht weiter.” Welche verschiedenen Möglichkeiten gibt es hier ganz konkret? Zwar empfiehlt der Scrum-Guide:

Der:die Scrum Master:in dient dem Scrum Team … unter anderem dadurch, die Teammitglieder in Selbstmanagement und interdisziplinärer Zusammenarbeit zu coachen.

Dennoch fällt vielen Scrum-Praktiker:innen dazu nur wenig ein. Daher möchte ich in diesem Artikel drei konkrete sogenannte Collaboration-Frameworks für Developer vorstellen: 

1. Pairing 
2. Ensemble Programming (auch Mob Programming oder salopp Mobbing)
3. Swarming

Unsere Fragen dazu lauten jeweils: „Was ist das eigentlich? Und wann ist es hilfreich?”

Pairing (Extreme Programming)

Dies ist das älteste und bekannteste der drei Frameworks. Die Ausprägung „Pair Programming” wurde mit „Extreme Programming“ bekannt und bereits 1999 in „Extreme Programming Explained” von Kent Beck als eine der Kernpraktiken von XP beschrieben. Neben Pair Programming hat sich die intensive Zusammenarbeit von zwei Personen an einer Aufgabe auch bei vielen anderen komplexen, wissensorientierten Tätigkeiten sehr bewährt.

Wie genau funktioniert Pair Programming?

Kurz gesagt funktioniert Pair Programming so, dass zwei Entwickler:innen gemeinsam an demselben Code arbeiten, kurz: 

• 2 Menschen 
• 1 gemeinsamer Fokus
• 1 Keyboard und 1 Bildschirm

Dabei gilt üblicherweise folgender Rahmen für die Zusammenarbeit:

• In jedem Paar hat einer der Partner die Rolle des Fahrers (Driver) und einer die des Navigators.
• Fahrer haben die Tastatur und setzen den gerade anstehenden Schritt bei der Entwicklung um, z.B. den gerade eben geschriebenen Unit-Test zum Laufen zu bringen.
• Navigatoren überlegen, wo die ,Reise‘ als nächstes hinführen könnte und was dabei zu beachten ist. Darüber helfen sie, wenn der Driver nicht weiter weiß, bringen ihr Wissen zur Programmiersprache oder auch zur Programmstruktur ein, führen einen kontinuierlichen Code-Review durch, notieren offene Enden, um die man sich später kümmern sollte, sammeln mögliche Code-Verbesserungen und lernen gleichzeitig von ihrem Driver praktische Kniffe z.B. zur Bedienung der Entwicklungsumgebung. Geht das Paar testgetrieben vor, führen sie eine Liste mit möglichen nächsten Tests und stoßen ggf. ein Gespräch über die weitere Vorgehensweise an.
• Die beiden tauschen dabei häufig ihre Rollen, z.B. alle 5-10 min.
• Viele Teams profitieren auch davon, die Zusammensetzung der Paare immer wieder zu ändern. Hier reicht die empfohlene Spanne von ,alle 30 min‘ bis zu ,alle zwei Tage‘. 

Wann ist Pair Programming hilfreich?

Pair Programming ist bei praktisch allen Entwicklungsaufgaben hilfreich. Das klingt vielleicht erstaunlich oder gar übertrieben. Aber was für Aufgaben würde man denn besser alleine erledigen? Meist Routine-Aufgaben, die in dieser Form bereits öfters erledigt wurden. Der dabei entstehende Code hat dann naturgemäß eine strukturelle Redundanz, die gegen das DRY-Prinzip (Don’t Repeat Yourself) verstößt. Hier lohnt es sich meistens, sich zeitnah zu fragen, ob „Weiter so!” die beste Vorgehensweise ist. Und das geschieht sinnvollerweise nicht allein, sondern idealerweise mit Ensemble Programming. So entsteht schnell ein gemeinsames Verständnis der Redundanz und wie das Team sie in Zukunft vermeiden will. 

Das heißt übrigens nicht, dass man nie alleine arbeiten darf. Wenn man mal eine Idee alleine durchdenken oder ausprobieren will, kann das hilfreich sein. Nur sollte man anschließend lediglich die Idee in den Produktiv-Code einbringen: Man entwickelt ihn zu zweit neu. Das geht verblüffend schnell, führt zu einer besseren Qualität und erzeugt mehr Verständnis für die neue Idee im Team.

Ensemble Programming

Bei dieser von Woody Zuill bekannt gemachten Art zu arbeiten, entsteht Code, indem die Perspektiven und das beste Wissen von vier oder mehr Menschen einfließen. Woody nannte diese Art zu arbeiten „Mob Programming”. Da die verkürzte Form „Mobbing” aber doch für viele einen negativen Beigeschmack hat, verbreitet sich zunehmend die Bezeichnung „Ensemble Programming”.

Wie genau funktioniert Ensemble Programming?

Der Rahmen für Ensemble Programming ist ganz ähnlich wie beim Pair Programming:

• 4 oder mehr Menschen
• 1 gemeinsamer Fokus
• 1 Keyboard und 1 Bildschirm

Das Set von allgemein akzeptierten Regeln ist klein. Eigentlich immer dabei ist:

• 1 Driver, oft auch Typist genannt. Setzt den vom Team festgelegten nächsten Schritt um.
• Die Rolle des Driver wechselt häufig, oft reihum.
• Das Team einigt sich auf weitere Rollen, benennt sie und klärt, wer sie wann einnimmt und wie sie wechseln.

Häufig anzutreffende weitere Rollen sind:

• Navigator: Hat verstanden, wo das Team hin will und hat einen Plan. Das Team vertraut ihm.
• Facilitator: Beobachtet die Teamdynamik. Fragt, wenn die Tests grün sind: „Sind wir zufrieden mit dem Code?“, „Wer kann ein hilfreiches Refactoring vorschlagen, das wir jetzt durchführen sollten?“ Der Facilitator unterstützt das Team auch bei hitzigen Diskussionen und hilft ihr, gegenseitige Freundlichkeit, Respekt und Neugier auf die Perspektive der anderen wach zu halten.
• Scout: Findet Dinge heraus, die gleich wichtig werden. Klinkt sich dabei evtl. zeitweise aus dem gemeinsamen Fokus aus. Beispiel: Recherche in Handbüchern. Hilft Ensemble, wenn sie drohen stecken zu bleiben (meistens wegen Informationsmangel)
• Housekeeper: Erledigt Routineaufgaben, die das Team abhalten würden, voranzukommen. Läuft quasi mit Putzwedel um das Team.

Wann ist Ensemble Programming hilfreich?

Ensemble Programming bringt ein Maximum an Lösungskompetenz zum Tragen. Gleichzeitig wird extrem viel gemeinsames Verständnis geschaffen.

In meinen Scrum-Trainings arbeiten Kleingruppen von Teilnehmern oft spontan als Ensemble, indem sie z.B. eine Reihe von Fragen gemeinsam diskutieren und nacheinander für jede eine Lösung finden.

Teams sollten selbstbestimmt beginnen, Ensemble Programming für sich zu entdecken. Manche Teams beginnen z.B. mit einer Stunde pro Woche, um miteinander und voneinander zu lernen und dabei ein reales Problem zu lösen. Nach ersten positiven Erfahrungen steigert sich dann oft die Frequenz. Es gibt sogar Teams, die dazu gekommen sind, fast nur noch als Ensemble zu programmieren, weil sie dabei ihre optimale Leistungsfähigkeit erreichen.

Swarming

Diese Art zusammenzuarbeiten ist am schwierigsten zu erklären. Von außen wirkt es manchmal chaotisch, ähnlich wie ein Ameisenhaufen auf den ersten Blick chaotisch erscheint. Es gibt praktisch keine vorher festgelegten Regeln, sondern diese entstehen selbstorganisiert und kontextabhängig.

Vielleicht hilft ein Beispiel am ehesten: Auf meiner Session zu Collaboration-Frameworks für Entwickler auf der Agile Lean Munich 2022 habe ich zu Beginn der Session die Teilnehmer in ein Swarming gebracht mit dieser Aufgabenstellung: „Für unsere Session müssen wir jetzt schnell gemeinsam diesen Raum umgestalten! Wir brauchen Pair-Programming-Stationen, eine Ensemble-Programming-Station und einen Bereich, in dem wir alle zusammensitzen und reden können. Dort sollten auch zwei Flipcharts Platz haben. 2 Monitor-Attrappen findet ihr im Eingangsbereich. Bitte helft alle zusammen, dass wir so bald wie möglich mit der Session starten können!” 

Und los ging’s! Wie ein Wirbelwind haben alle mit angepackt, spontan hat sich eine Teilgruppe gebildet, die sich um die Pairing-Stations gekümmert hat, und eine für die Ensemble-Station. Zwei haben passende Flipcharts gesucht und wieder andere haben flugs die Stühle für den Lernbereich aufgestellt. Nichts davon habe ich konkret angewiesen oder eingeteilt. Keine drei Minuten später konnte die Session beginnen. So fühlt sich Swarming an!

Und wie funktioniert nun Swarming?

Tja. Das ist schwer zu sagen. Salopp gesagt: „Alle helfen zusammen. Alle packen mit an.“

Es gibt nur wenige feste Regeln:

• So viele Menschen wie verfügbar sind, mindestens 4
• Alle haben ein klares, gemeinsames Ziel
• Es gibt nicht mehr einen gemeinsamen Fokus, sondern Untergruppen mit jeweils eigenem Fokus bilden sich und lösen sich wieder auf. Diese Untergruppen können durchaus z.B. Pairing oder Ensemble Programming einsetzen.
• Alle organisieren sich selbst in welcher Form auch immer, um zum Ziel beizutragen
• Alle bringen sich mit allen ihren Fähigkeiten ein, unabhängig von einer offiziellen Rolle oder Spezialisierung

Darüber hinaus finden einige Teams diese Regeln hilfreich:

• In regelmäßigen, kurzen Abständen zu einem kurzen Sync zusammenkommen, z,B. einmal pro Stunde
• Ein Facilitator beobachtet und unterstützt die Dynamik der Selbstorganisation.
• Der Facilitator arbeitet selbst mit. Oder auch: Der Facilitator arbeitet NICHT selbst mit.

Wann ist Swarming hilfreich?

Swarming ist eine extrem intensive Art der Zusammenarbeit, die in unglaublich kurzen Zeiten zu fertigen Ergebnissen führt. Swarming ist besonders gut geeignet, wenn die Teilnehmer mehr als nur genau eine Art von Tätigkeit erledigen können – oder zumindest bereit sind, sich in weitere Tätigkeiten einzuarbeiten.

Viele Teams haben zunächst Berührungsängste mit Swarming. Sei es, weil sie glauben, es nicht zu können. Oder weil sie befürchten, dass es ineffizient sein könnte.

Tatsächlich erfordert es eine gewisse Übung, so zusammenzuarbeiten. Andererseits empfinden viele es als extrem befriedigend und bereichernd. Ich kann nur empfehlen, es einfach mal auszuprobieren und dabei immer wieder gemeinsam über die Erfahrung damit zu sprechen und daraus zu lernen.

Mit der Erfahrung stellt sich dann auch heraus, wie groß (oder klein!) das gemeinsame Ziel sein muss, damit sich ein intensives Swarming einstellt. Ein Startpunkt könnte sein, dass ein Team ein Swarming auf eine User Story macht, oder sich in zwei Gruppen aufteilt, die separat auf zwei User Stories swarmen.

Fazit

Während Pair Programming bereits eine gewisse Bekanntheit hat, nutzen die wenigsten Teams die großen Vorteile, die in den Collaboration-Frameworks „Ensemble Programming” und „Swarming” stecken.

Damit zu experimentieren, ist für viele Teams ein echtes Aha-Erlebnis. Sie lernen nicht nur, selbst passende Collaboration-Frameworks auszuwählen oder sogar zu erfinden. Sie haben so auch die Möglichkeit, Selbstorganisation in der Praxis zu erleben und davon zu profitieren.

Welche Erfahrungen hast du mit Pairing, Mobbing/Ensembling oder Swarming gemacht? Welche anderen Rahmen für die Zusammenarbeit von Entwickler:innen nutzt dein Team? Teile deine Sichtweise und Erfahrung gerne unten in einem Kommentar!

Übrigens: In meinem Certified Scrum Developer-Kurs kannst du mehr über Collaboration-Frameworks für Developer erfahren und einige selbst erleben. Darüber hinaus sind sie natürlich auch Thema in meinen „Advanced Scrum Mentoring“-Programmen, wie z.B. dem CSP-SM oder dem A-CSPO. Dort erfährst du mehr über Hintergründe und lernst weitere Frameworks kennen, sowohl für Online- als auch für In-Person-Kontexte.