Stefan Wunder’s Agile Coaching Kata – A role play based training for challenging communication situations in teams

By TBB-Bilder (Own work) [CC BY-SA 4.0], via Wikimedia Commons
I have been working out a training to improve communication skills of Agile Coaches, Scrum Masters, and other leaders.

The training is based on the idea of a coding kata and provides a framework to practice techniques and tools, which are based on coaching, conflict management, and moderation, in a role play setting. The goal is that the participants strengthen their ability to communicate and to lead their team(s).

Below you can download the material needed for practicing the kata.

The facilitators guide includes all information for the facilitator / trainer of the kata. Read this first!

The handout includes all information for the participants of the kata. Each participants should get one.

The thinking hats by De Bono as poker cards includes a printing template for the six thinking hats by De Bono as poker cards. This is a useful tool for the kata.

Downloads (current version: 1.0):

Currently the downloads are only available in German!

Agile Coaching Kata – Facilitators Guide (PDF)
Agile Coaching Kata – Facilitators Guide (Microsoft Word 2016)

Agile Coaching Kata – Handout (PDF)
Agile Coaching Kata – Handout (Microsoft Word 2016)

Thinking hats by De Bono as poker cards (PDF)
Thinking hats by De Bono as poker cards (Microsoft Word 2016)

I am currently working on an English version, which will be published within next next weeks.

Feel free to comment, taylor, and republish. The material is licensed unter the CC BY 4.0 license.

I am happy about your feedback, experience reports, and taylored versions. Please share them in the comments. Based on your feedback I plan to provide updates in the future.

I would like to thank everyone who supported me with this work! Special thanks to my colleagues at AVL, the participants of my sessions at Agile Coach Camp 2017 and Agile Facilitation Lab 2017 and the moderators of the Scrum User Group Graz who provided valuable feedback.

 

 

 

Advertisements

User Story KATA

Um die Qualität der User Stories in unseren mittlerweile 25 Scrum Teams bei Infonova weiter zu verbessern und anzugleichen führe ich gerade eine User Story KATA in unsere Entwicklungsabteilung durch. Ich habe die KATA mit Kollegen gestaltet und möchte die Idee dahinter gerne vorstellen:

Motivation:

Ausschlaggebend für einen erfolgreichen Sprint ist die Vorbereitung der User Stories. User Stories zu strukturieren ist einfach (siehe BDD), wie jedoch Product Owner und Team zu einem gemeinsamen Verständnis der Requirements kommen ist eine Herausforderung, die es zu jedes Mal aufs Neue zu meistern gilt. Als Check, ob ein gemeinsames Verständnis gegeben ist dient uns die Schätzung des Teams und die Definition of Ready. Wird eine User Story ohne ausreichendem gemeinsamen Verständnis commitet, passiert es nicht selten, dass das Commitment nicht gehalten werden kann, was die Planbarkeit eines Projektes schwierig macht. Bisher ist die Verwendung der DoR noch nicht über alle Teams etabliert. Mit Hilfe der KATA soll die Ausrollungen der DoR unterstützt werden und zu einer Qualitätssteigerung der Arbeitsweise führen.

Ziel:

  • Die Planbarkeit durch die Richtige Handhabung einer DoR und die daraus resultierenden geringeren Unterbrechungen und Scope-Changes im Sprint steigern.
  • Das kollaborative Erarbeiten der Requirements mit Product Owner und Team, sowie die Handhabung der Definition of Ready erlebbar machen und bewusst üben.

Vorbereitung:

Die Grundlage der KATA ist ein fiktives Business Szenario und eine dazu definierte User Story, jedoch ohne Akzeptanzkriterien, die in der KATA von den Teilnehmern ausgearbeitet werden sollen. Das Beispiel erscheint auf den ersten Blick bewusst trivial, enthält jedoch eine gewisse Komplexität, die nur durch genauere Beschäftigung mit der User Story zum Vorschein kommt.

Ablauf:

Es nimmt jeweils ein Entwicklerteam (4-6 Entwickler) + Scrum Master + Product Owner and der KATA teil. Alle Teilnehmer sind in der KATA in der Rolle des Entwicklerteams. Ich spiele in der KATA den Product Owner und stelle dem Team die vorbereitete User Story vor. In den folgenden 60 Minuten ist es die Aufgabe des Teams die User Story durch geschickte Fragen zu erforschen und die Akzeptanzkriterien in Form von Szenarien (siehe BDD) zu definieren. Nach und nach zeigt sich dem Team die wahre Komplexität der User Story. Nach einer Stunde breche ich diesen Prozess ab und lasse das Team das Ergebnis mit einer DoR auf die Erfüllung Dieser prüfen und schließlich die User Story zu schätzen.

Erfahrungen:

Nachdem ich nun mit 5 Teams die KATA durchgeführt habe kann ich ein erstes Zwischenresüme ziehen. Was den Teilnehmern der KATA meist zum ersten mal bewusst wird ist, wie wenig Zeit sie eigentlich für die Vorbereitung von User Stories investieren (meist weniger als 5% eines Sprints). Zum Anderen ist vielen die Bedeutung der DoR auf den Sprinterfolg noch nicht klar und wird durch die KATA erst richtig verstanden. Die teilgenommenen Teams können in der täglichen Arbeit auf die KATA als gemeinsames Erlebnis zurückblicken und so den sich langsam einschleichenden Prozess-Schlendrian entgegenwirken. Die Teilnehmer haben Spass an der KATA, was die wichtigste Grundlage ist, damit das transportierte Wissen auch weiterhin im Arbeitsalltag Anwendung findet.

Conclusio:

Zur Einführung von zentralen Prozess-Veränderungen, wie einer DoR scheint eine KATA hervorragend geeignet zu sein. Die aktive Einbindung der Mitarbeiter, der Spass-Faktor und das gemeinsame Erlebnis sind wesentliche Erfolgskriterien für nachhaltige Veränderung. Vermutlich wird jedoch die KATA nach einer gewissen Zeit wiederholt werden müssen um einen erneuten Impuls zu geben.

Wer an Details interessiert ist, bitte direkt an mich wenden.

3 Konzepte aus den Martial Arts in der Softwareentwicklung

Die Softwareentwicklung hat schon länger erkannt, dass wir uns von den traditionellen asiatischen Kampfkünsten (z.B. Karate) einige Praktiken und Tugenden abschauen können um unsere Fähigkeiten als Entwickler zu steigern. Disziplin, Fokus, ständige Verbesserung durch Lernen, ein gesunder Geist, Professionalität, Meisterlichkeit, usw. sind Schlagworte, die man heute mehr als je zuvor im Zusammenhang mit “Software Crafmanship” hört.

Source: http://best-selfdefense.blogspot.co.at/

Kata

Die Kata bezeichnet im Karate eine abgeschlossene Übung, bei der exakt definierte Bewegungsabfolgen durch häufige Wiederholung bis zur Perfektion trainiert werden. Selbes Prinzip findet sich in der Softwareentwicklung als Code Kata wieder, wo Entwickler-Skills wie Clean Code, Test Driven Development (TDD) oder Pair Programming anhand von einfachen Code Beispielen trainiert werden. Die Regeln einer KATA müssen dabei genau beachetet werden. Der Weg zur Lösung erfolgt bewusst in “Baby-Steps” die auftretenden Probleme und die einzelnen Lösungsschritte die notwendig sind bewusst zu machen. Die Lösung ist dabei nicht im Fokus der Code Kata sondern der Weg zur Lösung steht im Vordergrund der Übung. In agilen Unternehmen werden Katas regelmässig zur Weiterbildung der Entwickler durchgeführt. Eine Liste von populären Code Katas findet ihr hier: http://ccd-school.de/coding-dojo/

Dojo

Als Dojo wird im Karate der Übungsraum bezeichnet, in dem Katas durchgeführt werden. Das Prinzip der Coding Dojo bezeichnet demnach das Zusammenkommen mehrerer Entwickler in einem Raum um eine Code Kata gemeinsam durchzuführen. Es gibt unterschiedliche Durchführungsarten einer Coding Dojo. Die Teilnehmer können in wechselnden Paaren (Pair-Programming) an der Kata arbeiten (Randori Kata). Es kann jedoch auch von einem Teilnehmer die Lösung auf einem Beamer vorzeigen (Prepared Kata). Letztlich ist es jeodoch jedem Frei mit Durchführungsarten zu experimentieren. Auf http://codingdojo.org/ findet ihr mehr Infos zu Coding Dojos.

Shuhari

Shuhari ist ein Lern-Konzept, das bei den traditionellen Martial Arts angewendet wird um eine Kampfkunst bis zur höchsten Stufe ( dem Meistergrad) zu erlernen. Die folgende Erläuterung stammt von Wikipedia:

  • shu (守?) “protect”, “obey” — traditional wisdom — learning fundamentals, techniques, heuristics, proverbs
  • ha (破?) “detach”, “digress” — breaking with tradition — detachment from the illusions of self
  • ri (離?) “leave”, “separate” — transcendence — there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical

Stellen wir uns vor, wir möchten Scrum nach den drei Shu-ha-ri Schritten erlernen: Im ersten Schritt wird streng das Lehrbuch (die Tradition) befolgt, bis dieses verstanden wurde. Erst wenn wir Scrum nach Lehrbuch anwenden können entfernen wir uns langsam von der Tradition um  zu experimentieren (z.B. Individuelles Anpassen des Prozesses an das eigene Unternehmen). Hat man den Umgang mit allen agilen Methoden und Techniken, als auch die eigenen Adaptionen zu einem Schlüssigen Gesamtkonzept vereinheitlicht und kann die Techniken, Werte und Methoden  jederzeit anwenden, so hat man den dritten Lern-Schritt (“ri”)erreicht.