Was wollt ihr über Coding Dojos wissen?

Ich schreibe aktuell an einem Artikel zu dem Thema. Für mich sind Coding Dojos ein effektives Mittel um aktiv die kontinuierliche Verbesserung voranzutreiben. Das ist mir sehr wichtig, denn es geht viel Potential verloren, indem Wissensmanagement nur passiv abläuft. Wer sich z.B. den eigenen Code von vor 3 Jahren anschaut, wird hoffentlich feststellen, dass er heute besser entwickelt. Dieser Prozess vollzog sich quasi nebenbei. Meine Intension ist deshalb aktiv Werkzeuge zu testen und nutzen, um Verbesserungen forcierter anzugehen.

Coding Dojos sind in dem Kontext ein erprobtes Mittel. Weitere habe ich in diesem Artikel bzw. in der unten stehenden Grafik aufgelistet:

 

 

Den geneigten Leser würde ich bitten mir auf Twitter, Facebook oder am besten hier in die Kommentare mitzuteilen, welche Erfahrungen er mit Coding Dojos gemacht hat, wo Probleme liegen, was Erfolge waren und was er gerne in einem Artikel dazu lesen würde. Zur Anregung kann diese kleine MindMap dienen:

Werbung

Wie hole ich mein Team ab

Innovation bedeutet immer auch Veränderung. Der Mensch als Gewohnheitstier muss deshalb abgeholt werden, sonst bleibt er zurück. Welche Möglichkeiten hat eine Führungskraft hierfür?

Zunächst einmal gilt es Folgendes zu trennen:

• Kann ein Mitarbeiter mit der Veränderung nicht Schritt halten?
• Oder will er sich nicht verändern?

Während ersterem mit den richtigen Werkzeugen gut beizukommen ist, muss letzteres über Prinzipien und Werte gesteuert werden. Ausgenommen von der Regel sind Menschen, die nur deshalb nicht wollen, weil sie nicht können. Kann also beispielsweise jemand nicht tanzen, so wird er auch nicht auf die Tanzfläche wollen, nur um sich zu blamieren.

 

Prinzipien/Werte:

Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln).

 

Werkzeuge:

• Retrospektive: Für mich das wertvollste Werkzeug überhaupt. Egal ob tägliche Einzelretrospektiven oder wöchentliche Gruppenretrospektive, wichtig ist: So häufig wie möglich, Ergebnisse festhalten und vor allem umsetzen. Mehr dazu hier.
• Coding Dojos: Alle 1-2 Wochen für 2 Stunden. Erste spürbare Ergebnisse zeigen sich in kürzester Zeit. Ich arbeite gerade an einem Fachartikel dazu. Bis dahin schaut ihr hier.
• Pair Programming: Super für die Vermeidung von Inselwissen und das Etablieren eines kontinuierlichen Wissenstransfers. Gerade bei Teammitgliedern, die sich schwer tun mit neuen Praktiken (z.B. TDD) geeignet oder mit heterogenen Teams aus Junior und Senior Developer. Für weitere Informationen schaut in den Wikipedia-Artikel.
• Open Spaces / World Cafe: Interessante Konferenzformate zur Optimierung des Wissensmanagements. Einen Artikel dazu habe ich in der dotnetpro veröffentlicht.
• Bloggen: Lässt sich vortrefflich mit der Retrospektive bündeln. Kann als Quelle für andere (und einem selbst) Teammitglieder dienen. Das Schreiben und Widerholen begünstigt auch den Lernprozess.
• Scrum: Eine agile Methode zur Produktentwicklung, die die kontinuierliche Verbesserung fest im Prozess implementiert hat. Alle meine bisherigen Blogbeiträge zum Thema findet hier.
• Communities: In nahezu jeder größeren Stadt gibt es dedizierte Communities, z.B. Scrum Stammtisch, .NET User Group, SQLPass, etc.. Ein Austausch mit Dritten ist immer hilfreich, v.a. wenn Entwickler in anderen Firmen die neue Vorgehensweise bereits erfolgreich anwenden.
• Externe Consultants: Empfinde ich als besonders hilfreich um die anfänglichen Klippen zu umschiffen.

Abschließend sei noch gesagt, dass es eine Vielzahl an Werkzeugen gibt, jedoch muss das Tool auch zur Person bzw. der Gruppe passen. Pair Programming ist z.B. etwas, das nicht jeder Entwickler möchte.

Mich würde interessieren, wie bei euch Änderungen eingeführt wurden? Gab es Kollegen, die sich schwer damit taten? Wie hat die Führungskraft diejenigen abgeholt? Gibt es ein besonders hilfreiches Werkzeug, das bei euch Wunder bewirkt hat? Würde euch ein längerer Artikel mit konkreten Beispielen interessieren?

 

Edit 16.05.2014: Daniel Marbach hat mir ein interessantes Buch zu dem Thema empfohlen. Eine Rezension darüber wird folgen, da ich es inzwischen auf meinem Kindle habe.

Kata 2048

Kürzlich nahm ich bei der .NET User Group Karlsruhe an der Kata 2048 teil. Eine vollständige Formulierung in Form von User Stories oder einer Anforderungsliste gibt es bisher nicht. Weil im Netz aber so viel darüber diskutiert wird, möchte ich an dieser Stelle meinen Kata Vorschlag veröffentlichen.

In den nächsten Tagen werde ich noch einen kleinen Bericht und/oder Video online stellen, in dem ich von einer Scrum Schulung berichte, die wir Inhouse anhand des Spiels durchgeführt haben. Bei genauer Betrachtung bietet 2048 reichlich Diskussionsstoff, so z.B. für die gemeinsame Domänensprache und die Priorisierung von Anwenderwünschen.

Die Kata ist als Architektur-Kata zu verstehen, die in mehreren Sprints umgesetzt werden soll (auch wenn ich keine User Stories geschrieben habe…). Als Veranstalter des Coding Dojos empfehle ich deshalb die einzelnen Teile erst nacheinander pro Runde herauszugeben. Darüber hinaus habe ich absichtlich schwammige und doppeldeutige Begriffe gewählt, um den Alltag mit den Fachabteilungen zu simulieren. Ich setze voraus, dass die Teilnehmer das Spiel zumindest kurz gespielt haben oder zuvor gezeigt bekommen.

 

Sprint Goal 1: Veröffentlichung der ersten Basisversion für Tester und Product Owner 

• Das Spielfeld ist quadratisch und hat 4×4 Felder
• Beim Start des Spiels werden zwei zufällige Felder mit dem Wert 2 belegt
• Ab diesem Zeitpunkt hat der Spieler immer 4 Zugmöglichkeiten: Rechts, Links, Oben, Unten
• In allen Fällen bewegt sich jedes Feld so weit in die vorgegebene Richtung, bis eine von 3 Situation eintrifft:
  • Der Rand des Spielfeldes ist erreicht
  • Das Feld trifft auf ein benachbartes Feld mit einem unterschiedlichen Wert (Bsp.: Feld mit Wert 2 trifft auf Feld mit Wert 4)
  • Das Feld trifft auf ein benachbartes Feld mit gleichem Wert (Bsp. Feld mit Wert 2 trifft auf Feld mit Wert 2)
• Felder mit gleichen Werten “paaren” sich. Die Summe erhält das Feld, das näher an dem Rand liegt, in dessen Richtung gezogen wurde. Das andere Feld verbleibt ohne Wert.
• Es handelt sich um einen gültigen Zug, wenn sich mindestens ein Feld bei dem Zug verändert hat. Andernfalls ist es ein ungültiger Zug.
• Bei einem gültigen Zug entsteht auf einem zufällig gewähltem, leeren Feld der neue Wert 2
• Bei einem ungültigen Zug passiert nichts
• Das Spiel ist zu Ende, wenn keine gültigen Züge mehr möglich sind oder ein Feld den Wert 2048 erreicht

 

Sprint Goal 2: Go Live Version releasen

• Statt zufällig gewählte Felder mit dem Wert 2 zu belegen, soll der Wert zufällig 2, 4 oder 8 sein
• Die Größe des Feldes soll konfigurierbar sein. Es bleibt aber bei der quadratischen Form und die Mindestgröße beträgt 4×4
• Der Wert zum Gewinnen des Spiels soll konfigurierbar sein. Möglich sind 1024, 2048 oder 4096
• Biete 2 unterschiedliche Oberflächen an (z.B. Konsole, WinForm, WPF, Web)

 

Sprint Goal 3: Kostenpflichtige Version mit erweitertem Gameplay entwickeln

• Füge die Option hinzu genau einen Zug rückgängig machen zu können
• Einführung eines Highscore: Wenn sich zwei Felder “paaren”, dann soll der neu entstandene Wert zu dem Highscore hinzugezählt werden. Der Highscore wird solange hochgezählt bis das Spiel zu Ende ist

 

Sprint Goal 4: Wünsche der kostenpflichten Abonnenten einbauen

• Das Spielfeld muss nun nicht mehr quadratisch sein. Beispiel gibt es hier.
• Erweitere die Option des Rückgängigmachens auf beliebig viele, sodass bis zum Start des Spiels zurückgegangen werden kann

 

Sprint Goal 5: Das Spiel ist ein Riesenerfolg und die Wissenschaftler auf der ganzen Welt benötigen eine automatische Lösungsroutine

• Schreibe einen Solver. Treffe dafür notwendige Annahmen und versuche eine allgemeine Schnittstelle für Dritthersteller anzubieten

 

Meine Lösung möchte ich demnächst auf GitHub zur Verfügung stellen. Gerne verlinke ich die Implementierung der Leser oder nehme Erweiterungen der Kata mit auf. Falls eine Umstellung der einzelnen Anforderungen innerhalb der Sprint Goals Sinn macht, bitte in die Kommentare posten.