Swarm Programming weiter gedacht

Im deutschen Sprachraum ist das Wort Mob Programming — für das Konzept, bei dem eine ganze Gruppe von Programmierern an einem einzelnen Computer programmiert — für viele zu dicht an Mobbing dran. Es hat sich deshalb der Begriff Swarm Programming eingebürgert. 

Wenn man jedoch eine alte Metapher – mit Driver, Navigator, und oft auch Scout, Facilitator und Housekeeper – durch eine neue ersetzt, ergibt sich die Möglichkeit, die Gedankenspielräume, die sich dadurch eröffnen, weiter zu erforschen. Und am Ende noch effektiver in der Gruppe zu programmieren.

Wir haben diese Methode erprobt und in der Praxis umgesetzt – und weiter ausgebaut!

Neue Worte, neue Rollen

Zunächst war es uns wichtig, ein treffendes, stimmiges Vokabular zu finden. Die Drohne sitzt am Laptop und schreibt Code. Der OVERMIND (all-caps sind hier wichtig) ist die vereinte Stimme des Schwarms, die alle Teilnehmer einschliesst; inklusive der Drohne.

Es gibt keine anderen Rollen. Das ist wichtig. Nur durch flache Hierarchien kann man sich wirklich die Schwarmintelligenz zu Nutze machen.

Ablauf des Swarm Programming

Im veralteten Konzept des Mob Programmings nutzt man die Kreativität der Masse. Einzelne können Dinge bemerken, die der Gruppe entgangen sind.

In der Praxis ist dieses Konzept jedoch hoffnungslos ineffizient. Unser Ansatz der Schwarmprogrammierung behebt dieses Problem: Wenn ein Mitglied des Schwarms etwas bemerkt, stellt es diese Idee vor. Alle Mitglieder des Schwarms wiederholen daraufhin diese Idee, gleichzeitig und mit einer Stimme im Wortlaut, sie sprechen als der OVERMIND, der der Drohne sagt was sie tun soll.

Jedwede Diskussion ist hier strikt untersagt und läuft dem Konzept des Schwarms zuwider. Der Schwarm ist nur dann ein Schwarm, wenn er einen Konsens hat. Mit genug Übung, so konnten wir feststellen, lässt sich das Konzept des unabhängigen Denkens jedoch gut unterdrücken.

Der Erfolg liegt auf der Hand: Entscheidungen werden schneller getroffen und führen so zu höherer Produktivität.

Sprungbrett für neue Prozesse

Mit dieser soliden Grundlage konnten wir schnell weitere Konzepte einbringen, die den Prozess noch weiter agilifizieren.

Summen

Wie der Bau von Schiffen sich an der Physiognomie von Delfinen orientiert hat, so können sich auch Software Developer ein Beispiel an der Natur nehmen: Alle Mitglieder des Schwarms sind dazu angehalten, zu summen, wenn sie nicht gerade als OVERMIND fungieren oder dem Schwarm neue Ideen präsentieren. Unnötige, dissidente, abweichende Stimmen werden so unterbunden und das Gruppenbewusstsein gestärkt.

Unsere Praxiserfahrung zeigt, dass so auch die Konzentration gestärkt wird! Tatsächlich gaben zwei Drittel unserer Teilnehmer*innen an, dass sie Schwierigkeiten hatten, überhaupt noch einen klaren Gedanken zu fassen, was alle Hindernisse bei der Implementierung von modernen Lösungen in Enterprise-Java-Frameworks beseitigte. Auch die Umsetzung komplexer Architekturen, welche Technologien wie Single-Consumer-Kafka, Blockchain, Cloudmigration ohne Sicherheitskonzept oder dergleichen beinhalten, fällt viel leichter, wenn es niemanden gibt, der die unnötige Frage nach dem Sinn hinter der Technologieentscheidung stellt.

Bienentanz

Viele Studien (mehr als hier jemals verlinkt werden könnten) belegen, dass es unter Menschen viel mehr visuelle als auditive Denker gibt. Warum sollten also Ideen nur verbal präsentiert werden?

Genau wie die Bienen durch ihren Tanz Informationen über weite Entfernungen kommunizieren, so können auch Entwickler*innen ihre Ideen mit Körpersprache durch rhythmische Bewegungen untermalen, um so noch deutlicher zu kommunizieren. Der Schwarm hat daraufhin die Aufgabe, diese Bewegungen als OVERMIND mitzumachen. Sie werden dabei so oft wiederholt, bis sie wirklich bei allen synchron sind, was Fehlkommunikationen drastisch reduziert.

Des Weiteren kann der gesundheitliche Vorteil von Sport am Arbeitsplatz gar nicht deutlich genug hervorgehoben werden.

Schwarmgedächtnis

Da der Bienentanz dazu führte, dass bestimmte Konzepte bis zu fünfzehnmal ausgeführt werden mussten, gab es durch diese Wiederholung einen starken Erinnerungseffekt. Tatsächlich gaben nicht weniger als drei Teilnehmer*innen an, dass sie die besprochenen Refactorings bis in ihre Träume verfolgt haben.

Also machten wir uns diesen Effekt zu Nutze! Wozu Protokolle und Dokumentation, wenn sich die meisten Teilnehmer*innen mit solcher Klarheit an alles erinnern konnten? Die Zeitersparnis war unmittelbar spürbar und wir denken nun laut über die Abschaffung unseres Wikis nach.

Skalierung

Die schlechte(?) Nachricht ist, dass unsere Schwarmprogrammierung mindestens 7 Leute braucht, um ihre volle Effektivität zu entfalten. (Obwohl auch Soloschwarmprogrammierung eine gute Methode ist, um den der Schwarmprogrammierung zugrunde liegenden SSSS-Zyklus zu üben: Suggerieren SpiegelnSequenzierenSummen.)

Die gute Nachricht ist aber, dass unsere Methode quasi beliebig nach oben skalierbar ist. Sie ist deshalb herkömmlichen Frameworks wie SAFE mindestens gleichgestellt.

Troubleshooting

Sollte es – wider erwarten – Probleme geben, haben wir hier ein paar Ideen, die euch beim Abbau von Impediments behilflich sein könnten.

Hierarchien flachbügeln

Nicht in allen Unternehmen ist die Idee von flachen Hierarchien wirklich leicht einführ- bzw. umsetzbar.

Um die Assimilation der Mitarbeiter*innen in ein arbeitsfähiges Kollektiv zu erleichtern, empfehlen sich Einheitsoutfits. In der Praxis bewährt haben sich Jeans und schwarze Rollkragenpullover, aber auch gleichfarbige Hoodies mit deutlich sichtbarem Firmenlogo helfen dabei, die hinderliche Individualität abzubauen.

Divergenz mitigieren

Nicht allen Mitarbeitern*innen fällt das Einordnen in den Schwarm leicht. Als nützliches Werkzeug hat sich der reverse fish-bowl herausgestellt: Der divergente Mitarbeiter / die divergente Mitarbeiterin setzt sich auf einen Stuhl in die Mitte, der Schwarm spricht Anweisungen, die der/die Mitarbeiter*in wiederholen muss.

Dabei ist es (erstens) wichtig, Augenkontakt zu vermeiden, und (zweitens) sollte der Schwarm auf keinen Fall den Namen des Mitarbeiters / der Mitarbeiterin benutzen. Namen sind ein Relikt von Individualismus und haben im Schwarm keinen Platz!

Diese Übung wird wiederholt, bis sich der/die Mitarbeiter*in zehnmal fehlerlos in Folge in den Schwarm eingefügt hat. Wir empfehlen Sessions von neunzig Minuten, dann Pause zum Wassertrinken, dann Fortsetzung, bis das Problem behoben ist.

Unendliches Potenzial

Dies sind nur die ersten Ansätze für ein breites Feld der Effizienzsteigerung. Schwarmprogrammierung hat binnen kürzester Zeit zu einer vollständigen Transformation unserer Firmenkultur geführt.

In diesem Sinne: Bssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss

Für neue Blogupdates anmelden:


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.