Coding Dojo: Ein Raum des Lernens für Praktiken agiler Softwareentwicklung

„Ich kann mir kaum einen besseren Ort zum Lernen vorstellen als ein Coding Dojo.” 

Unsere Softwareentwickler:innen führen einmal im Monat interne Coding Dojos durch, um zu lernen, Wissen zu vertiefen und Neues auszuprobieren. Nun bieten sie die Coding Dojos auch bei Unternehmen vor Ort an, was auf eine sehr gute Resonanz bei den Teilnehmenden stößt. 
Moritz Kohl ist agiler Software Engineer und hat selbst schon Coding Dojos für Software-Teams bei Unternehmen begleitet. Er erzählt uns von seiner Erfahrung mit dem Format.

Der Begriff „Dojo“ (jap. Dōjō, 道場) stammt aus dem japanischen Kampfsport und bedeutet „Ort des Weges” oder übertragen „Raum des Lernens“.

Im geschützten Raum der Trainingsgemeinschaft werden Techniken und Praktiken für den Kampf trainiert und durch stete Wiederholung eingeübt und verinnerlicht.
Dabei werden Katas als Übungsmethode verwendet: stilisierte Kampf-Abläufe, in denen bestimmte Elemente und Stile durch praktische Anwendung trainiert werden. 

Coding Dojos, Coding Katas und Constraints

Coding Dojos übertragen dieses Konzept auf das Üben von Praktiken und Techniken der Softwareentwicklung und finden ebenfalls in einer Trainingsgruppe statt.

Wichtiger Bestandteil der Coding Dojos sind in Anlehnung an das Kampfsporttraining die Coding Katas. Entwicklungsmethoden, aber auch die Verwendung von neuen Programmiersprachen, Frameworks oder Tools werden dabei in konstruierten Szenarien, in denen Aufgaben zu lösen sind, angewandt und dadurch eingeübt.

Innerhalb der Coding Dojos können Constraints zur Erhöhung des Schwierigkeitsgrades festgelegt werden. Die Constraints schaffen Rahmenbedingungen, die die Situation in der Kata für die Trainees erschweren. Dabei handelt es sich häufig um Methoden, die die Zusammenarbeit innerhalb der Gruppe komplexer machen, indem sie z.B. eine besonders effektive Kommunikation bei der Zusammenarbeit verlangen. In der Analogie zum Kampfsport lassen sich die Constraints als verschiedene Gürtel, also Fortschrittsgrade sehen, die es zu meistern gilt.

Moritz, für die Coding Dojos klinkt ihr euch für einen Tag aus dem Projektgeschäft aus, um gemeinsam Neues zu lernen und auszuprobieren. Von dem, was man so hört, habt ihr Spaß dabei. 🙂 Ist es also vor allem eine Teambuildingmaßnahme? Oder geht es wirklich darum, sich für die Arbeitspraxis weiterzubilden? 

Ich kann mir kaum einen besseren Ort zum Lernen vorstellen als ein Coding Dojo. Hier lernst du Dinge, indem du sie direkt anwendest und wiederholst. Ohne äußere Störung kannst du austesten, was in welcher Situation funktioniert. Die Katas sind dabei die Aufgaben, die du lösen musst und die dich dazu motivieren, eine Sache zu üben.

Hast du ein Beispiel für eine Coding Kata?

Ein Beispiel ist eine Kata zum Refactoring. Auf der Basis vorgefertigter Codebasen und einer Liste von Anforderungen, die zu beachten sind, wirst du dazu herausgefordert, ein bestimmtes Verhalten bei der Entwicklung zu erfüllen, aber mit einer besseren Softwarequalität.
Es gibt auch Katas, bei denen es darum geht, Software direkt ,from scratch’ zu entwickeln anhand einer Liste von Anforderungen. Das entspricht nicht unbedingt einem realistischen Szenario in der Arbeitswelt, aber darum geht es auch gar nicht. Bei der Coding Kata geht es darum, Neues in einem gestellten Umfeld zu üben, um es dann für einen realen Fall technisch und methodisch sicher anwenden zu können.

Es werden kleine Miniszenarien oder auch Muster trainiert, die man dann während der realen Arbeit wiedererkennt. In der Softwareentwicklung gibt es für jede Aufgabe immer mehrere Lösungen. Aber es sind nicht alle unbedingt gleich qualitativ oder gleich effektiv. In den Katas testen wir die aus und finden heraus, was in welcher Situation besonders gut funktioniert.

Also lassen sich neben technischen Themen auch Programmierpraktiken üben?

Absolut. Einfache Katas eignen sich z.B. prima, um Praktiken wie das Pair Programming zu üben. Losgelöst vom Daily Business, aber mit einer klaren Aufgabe. Man kann so herausfinden, wie es sich anfühlt und was die Vorteile oder auch die Nachteile sind.
Und der große Vorteil im Training: Wir können kleine Ratschläge und Tipps geben, wie das Ganze noch besser klappen könnte oder was die Teilnehmer:innen sonst noch ausprobieren können.

Welche Constraints setzt ihr euch in den Dojos und wer entscheidet darüber?

Die Vorschläge kommen abwechselnd aus der Gruppe. Wir entscheiden darüber dann gemeinsam. Dann sitzen wir alle zusammen oder aufgeteilt in kleinere Grüppchen und setzen uns die Constraints.

Ein Beispiel für einen Constraint ist der Blind Navigator. Beim Pair Programming hast du den Navigator und Driver. Der Driver schreibt den Code und der Navigator macht die Ansagen/hilft dem Driver dabei, „in die richtige Richtung zu lenken” – eben ein bisschen wie beim Rallyefahren. Der Constraint ist nun, dass der Navigator blind ist, d.h. er sieht nicht, was der Driver tut: Das übt die Kommunikation zwischen den beiden sehr effektiv.

Wie groß sollten die Gruppen sein, die gemeinsam eine Kata lösen?

Je kleiner die Gruppen sind, desto größer ist der Lerneffekt. Daher bilden wir, wenn wir die Dojos in Unternehmen durchführen, kleine Gruppen aus idealerweise zwei Teilnehmer:innen, denen wir als Trainer dann über die Schulter schauen, um hier und da zu helfen und in die richtige Richtung zu lotsen.

„Das Ziel ist, nach dem Training in der Lage zu sein, bestimmte Muster wiederzuerkennen, für die ich dann einschätzen kann, welche Programmiertechnik oder -methode mir am besten helfen wird."

Was ist der Outcome, der Effekt für dich bei solchen Dojos? Wirklicher Erkenntnisgewinn, der dir dann für deine reale Entwicklungstätigkeit später weiterhilft oder ist doch eher Spielerei – die ja auch einen Lerneffekt impliziert, aber vielleicht mit weniger konkretem Anwendungswert?

Das ist eine gute Frage, die auch regelmäßig am Ende Dojos aufkommt. Natürlich ist jedem bewusst, dass man gerade innerhalb sehr konstruierter Settings trainiert hat, die sich erst einmal so in der Realität nicht wiederfinden. Aber das ist ja gerade auch der springende Punkt. Das Ziel ist, nach dem Training in der Lage zu sein, bestimmte Muster wiederzuerkennen, für die ich dann einschätzen kann, welche Programmiertechnik oder -methode mir jetzt am besten helfen wird. Es geht aber auch darum, zu erkennen, welche Limitierungen einzelnen Methoden unterliegen. Also richtig einschätzen zu können: Für welchen Fall ist das Ganze sinnvoll und wann verzichte ich lieber darauf. All das kann man über Dojos einschätzen lernen. Also ja: Es handelt sich schon um einen echten Effekt, der umso größer ist, desto weniger du eine bestimmte Methode vorher schon kanntest oder angewandt hast. Es bringt dir ganz effektiv eine Erweiterung deines Repertoires an Methodiken und Techniken, die du einsetzen kannst in der realen Welt.
Meine Erfahrung zeigt mir: Früher oder später wirst du über Fälle stolpern, bei denen du diese oder jene im Dojo trainierte Technik gewinnbringend anwenden kannst.

„Wichtig ist: Entwicklungspraktiken sollten nicht zum Dogma erhoben werden."

Was ist deine Erfahrung hinsichtlich der Offenheit von Entwicklerteams, auch mal zu alternativen Praktiken zu greifen?

Es gibt immer Leute, die bestimmten Praktiken aus Prinzip nicht vertrauen und sie ablehnen. So eine pauschale Wertung finde ich schade, aber das muss man dann akzeptieren und respektieren in der Zusammenarbeit oder als Trainer. Wenn es eher um situationsbedingte Ablehnung geht, die z. B. daher rührt, dass alle im Team gewohnt sind, immer auf die eine Art zusammenarbeiten, dann sollte man argumentativ vorgehen, um mit einer neuen Methode die Perspektive schließlich zu erweitern. Wenn es dann gut läuft, hat man über den Aha-Effekt schließlich alles erreicht.

Wichtig ist immer: Entwicklungspraktiken sollten nicht zum Dogma erhoben werden. Wenn das Team merkt, dass bestimmte Methoden zu einem technischen Case nicht passen und die Sache weder qualitativer, noch effektiver gestalten, dann sollte es jeder Zeit möglich sein zu sagen: Wir lassen das in dieser Situation.

„Es gibt immer Leute, die bestimmten Praktiken aus Prinzip nicht vertrauen und sie ablehnen. Wenn wir die dann im Dojo aber für spezielle Szenarien einsetzen, können wir bei den Leuten wieder eine differenzierte Sichtweise eröffnen."

Warum ist das so wichtig?

Ohne eine differenzierte Sicht und eine selbstbestimmte Anwendung bleibt schnell das Gefühl hängen, eine Praktik funktioniert pauschal nicht oder behindert sogar.

Ich habe im Hinblick auf TDD (Test Driven Development) beobachtet, dass viele daran scheitern, weil sie es zu dogmatisch angegangen sind. Sie entwickeln dann eine generelle Ablehnung dagegen und sagen dann „geh mir weg mit TDD, das funktioniert nicht”.

Wenn wir dann im Dojo TDD aber für spezielle Szenarien einsetzen, können wir bei den Leuten wieder eine differenzierte Sichtweise eröffnen. TDD lässt sich beispielsweise super einsetzen, um Legacy Code zu testen. Wenn man das dann zusammen durchspielt und die Leute sehen, dass es funktioniert, dann haben sie in Zukunft wieder ein sehr nützliches Tool mehr im Werkzeugkasten.

Gebt ihr in den Dojos die Praktiken vor, die getestet werden?

Nein, wir sind in der Gestaltung der Dojos völlig offen. Wir haben nicht den Plan, bestimmte Praktiken durchzunehmen. Wir reagieren flexibel auf die konkrete Situation der Teilnehmer:innen, die ja immer anders ist. Wir haben natürlich ein gewisses Angebot an gängigen Praktiken, versuchen aber immer darauf zu achten, dass es neue Impulse für die Gruppe gibt, um ihre konkreten Themen mal auf andere Art und Weise anzugehen.

Das Hauptziel des Dojos ist es nicht, einen bestimmten Kanon an Praktiken durchzuspielen, sondern das Hauptziel ist es, zum Weiterlernen und zum Trainieren anzuregen. Wir wollen den Menschen zeigen, wie sie in einem gestellten Setting den Mehrwert einer Methode austesten und darin besser werden können. Du wirst etwas Neues nur dann annehmen, wenn du selbst den Vorteil darin erkennst.  

Aber ich sag’s nochmal: Die Katas helfen ja genau dabei, die Settings zu erkennen, in denen ich ein Praktik, TDD oder etwas anderes, gewinnbringend einsetzen kann. 

Welchen Tipp hast du für Softwareentwicklungs-Teams, die etwas verändern möchten, aber noch auf der Suche nach der passenden Methode sind?

Probiert es aus! Fragt uns an für ein Dojo oder veranstaltet selbst eines. Es gibt ja in Bezug auf die verschiedenen Techniken kein richtig oder falsch. Jeder muss für sich selbst herausfinden, was das Ergebnis sein soll und welcher Weg dafür am besten geeignet ist. Das ist nicht selten auch sehr von der Person selbst und ihrer Art zu entwickeln abhängig.

Wer es selbst ausprobieren will: Vorgefertigte Katas findet man im Netz zur freien Nutzung. Man sollte aber in der Gruppe idealerweise auch einige Entwickler oder Entwicklerinnen dabei haben, die in der Methode, die geübt werden soll, schon Erfahrung haben

Wenn du sagst, dass das Weiterlernen und das Neuentdecken das Hauptziel des Coding Dojos ist: Was ist denn der entscheidenste Faktor für den Erfolg von Softwareentwicklung, den ich über Weiterlernen positiv beeinflussen kann?

Da gibt es vieles, was ich durch Weiterlernen positiv beeinflussen kann. Aber ich würde sagen: Die Kommunikation ist am Ende das Wichtigste. Softwareentwicklung ja nichts anderes als das Lösen eines komplexen Problems, übersetzt in für Maschinen verständliche Sprache. Auf dem Weg zur Lösung gibt es permanent Veränderungen. Hier können nur die gute Ergebnisse schaffen, die in der Lage sind, gut zu kommunizieren.

Wobei wir wieder bei den Constraints sind, die innerhalb der Dojos unabhängig von der verwendeten Praktik die Gelegenheit bieten, Kommunikation zu fördern.

Ganz genau, so ist es.

Besten Dank Moritz für den Einblick!

Das Interview führte Anika Dewald