Retrospektive als Türöffner für die Agilität?

In meinen Einsätzen als Agile Coach in der Organisation will ich nicht in erster Linie die Agilität „verkaufen“, sondern den Teams in ihrer täglichen Arbeit Unterstützung bieten.

Immer mehr stelle ich dabei fest, dass ich mit dem Thema Retrospektive das Interesse wecken kann. „Zurückschauen? Optimieren auf Basis von gemachten Erfahrungen und Erkenntnissen? Wo ist denn der Unterschied zu den Lessons Learned?“ Diese Frage kommt oft. Und wenn es mir dann gelingt aufzuzeigen, dass Retrospektiven eben nicht nur „alter Wein in neuen Schläuchen“ sind, sondern ein ständiges sich weiterentwickeln, dann habe ich meistens das Interesse geweckt und mein Ziel erreicht.

Für mich sind die Retrospektiven ein Baustein auf dem Weg zur lernenden Organisation. Regelmässiges Hinterfragen des WIE zusammenarbeiten, identifizieren von Handlungsfeldern, fokussieren, definieren und umsetzen von Massnahmen. Und nicht vergessen – die Wirkungskontrolle. Hat die definierte Massnahme den gewünschten Effekt?

Schnell erkennen die Teams den Nutzen und die Wichtigkeit, Retrospektiven in absehbarer Zeit zu wiederholen. Mein Tipp: die Dauer bis zur nächsten Retrospektive sollte ca. 4-6 Wochen nicht überschreiten. Und definierte Massnahmen sollten idealerweise in diesem Zeitraum umgesetzt werden.

Kurz noch was zum Begriff Team. Immer mehr arbeite ich nicht nur mit Projekt-, sondern auch mit Linienteams zusammen. Was ist der Unterschied: Projektteams haben ein Ziel, ein „gemeinsames Objekt der Begierde“. Die Zusammenarbeit und die Kultur ist meist nicht vergleichbar mit der eines Linienteams. Oft fällt mir auf, dass die Linienteams eher „Organisationgruppierungen“ entsprechen und eben diese gemeinsame Zielorientierung nicht haben. Offenheit und Transparenz fehlen oft, Misstrauen stellt sich ein. Was macht eigentlich der Andere? Muss immer nur ich Aufträge übernehmen? Die Stimmung im Team ist angespannt. Den Anstoss für eine Retrospektive gibt oft eine Veränderung im Team; z.B. ein neuer Teamleiter, welcher Retrospektiven bereits kennt, erlebt hat, oder von dieser reflektierenden Methode schon gehört hat. Mit der Durchführung einer ersten Retrospektive kann in solchen Teams oft ein Kulturwandel angestossen werden.

Und ja – Retrospektiven zahlen auf verschiedene Werte und Prinzipien der Agilität ein und sind deshalb ein Türöffner für die Agilität.

Iteration Zero – Der Weg von der Produktidee zum Initialen Backlog

Wie schliesse ich methodisch die Lücke zwischen der Produktidee und dem initialen Backlog?

Wir im Coaching-Team haben eine Methodik entwickelt, die anhand von einfachen Praktiken zum Erfolg führt. Das Baby haben wir Iteration Zero genannt.

Iteration_Zero

Die Iteration Zero stellt sicher, dass der Kunde und der Wert des potentiellen Produktes (für den Kunden und die Unternehmung) im Zentrum stehen.

Die Iteration Zero wurde vor 1.5 Jahren in unserem Coaching-Team entworfen. Jedoch hat sie in unserem Umfeld keinen Anklang gefunden, wir haben sie in die Schublade gelegt.

1/2 Jahr später haben wir sie wieder rausgenommen und siehe da…. sie hat eingeschlagen wie eine Bombe!

Ich habe mittlerweilen 10x die Iteration Zero bei Projekten durchgeführt, immer mit viel Erfolg! Wobei auch „Fail Fast“(„Learn fast“:-)) für mich als Erfolg gewertet wird, da die Erkenntnis gewonnen wurde, dass der PO den Kunden zu wenig kennt, somit auch nicht seine Bedürfnisse.

Gestern habe ich die Iteration Zero bei einem Grossprojekt abgeschlossen. Es werden jetzt drei Projekte daraus weitergeführt. Fazit: ein voller Erfolg! In 4 Tagen haben wir gemeinsam mit den Top-Stakeholdern (aus der GL) die Produktvision & Personas erstellt, Story-Maps und Customer-Journeys erstellt und daraus das MVP, Epics und User Stories abgeleitet. An jedem Workshop-Tag hat uns ein Kunde besucht und mit uns die Produktidee weiterentwickelt. Sehr befruchtend!

Als Schlüssel zum Erfolg ergeben sich für mich:
– derjenige der das Produkt/die Produktidee verantwortet muss am Workshop mit dabei sein. (ganz egal, in welcher Hierarchie-Stufe er sich befindet)
– UX muss on Board sein
– über alle Iteration-Zero-Workshops muss das Team konstant sein
– die Workshops sollte jeweils mindestens 4 h dauern und allerhalb der Büro-Räume stattfinden (Open Mind!!)
– Adaption der Methodik Iteration Zero ist zwingend, Iteration ebenfalls, wir haben den Elevator-Pitch ca. 4x geschärft 🙂
– mit Kunden wird alles viel spannender und vor allem fokussierter, also unbedingt Kunden miteinbinden!

Jetzt freue ich mich auf Fragen und Anregungen von euch.

Nachtrag Anfang 2018:

Die Iteration Zero hat Flügel bekommen und ist jetzt öffentlich verfügbar. Siehe iterationzero.works.

 

SHU HA RI und Service Angebote

Was hat SHU HA RI mit Service Angeboten zu tun?

Oft werde ich gefragt was den ein Agile Coach so tut.  Naja.. irgendwie kommt der Namen der Tätigkeit ja schon recht nahe denke ich mir da gelegentlich…. Wenn die Frage dann, vermutlich wegen meines Gesichtsausdrucks, präzisiert wird fange ich an zu verstehen. Trainierst du auch Teams? Machst du auch Beratungen von Teams oder einzelnen Menschen?
Oder machst du nur Coaching ?

Selbstverständlich biete ich Training, Beratung  und Coaching an. Jetzt sind die Gesprächspartner meistens etwas in der Klemme. Was sollen sie nun von mir wollen? Schnell kommt die Anfrage; Lass uns mal mit Coaching starten… da kann man nichts falsch machen…

Welchen Service könnte ich nun sinnvollerweise meinem Gesprächspartner anbieten?  Dabei mache ich mir folgende Gedanken:

Aus den Budo- Kampfsportarten habe ich mir das SHU HA RI Konzept ausgelehnt. Es bezeichnet die drei Stufen eines Lernenden zum Beispiel in Aikido oder Karate.

SHU bedeutet genau so zu lernen wie der Lehrer es dir zeigt. Es dient als Grundlage um die nächste Stufe zu erreichen. Wörtlich bedeutet das Wort „Bewahren“ oder „Gehorchen“.  Ich setze den Service „Training“ der Stufe SHU gleich. Wenn also der Gesprächspartner erst mit Agile beginnen will oder erst vor kurzem gestartet ist, dann befindet er sich auf der Lernstufe SHU und dann bin ich sein Trainer.

HA bedeutet „frei werden“ oder auch „Frustration“ aber auch „mit Traditionen brechen“. Auf dieser Lernstufe haben die Teams oder die Menschen verstanden was und wie Scrum und die agilen Werte und Prinzipien funktionieren. Sie stossen mit dem Befolgen des Scrum Guides an Grenzen. Sie kommen mit dem gelernten in ihrem Umfeld nicht weiter. Sie müssten mit der Tradition brechen um ein höheres Level des Lernens zu erreichen. Wenn sich ein Team oder ein Mensch im HA befindet bin ich vor allem Berater. Ich versuche Erfahrungen zu vermitteln und neue Ansätze zu erklären.

RI bedeutet „verlassen“, „trennen“, den eigenen Impulsen folgen. Teams und Menschen auf dieser Lernstufe haben hohe Kompetenzen im Agilen Kontext entwickelt. Sie sind Profis auf ihrem Fach. Sie können abschätzen, wenn sie ausgetretene Pfade verlassen können oder sogar verlassen müssen um wertvolles, Neues zu schaffen. Auf dieser Lernstufe kommt Beratung nur noch selten vor. Hier ist Coaching gefragt.

Dies sind in etwa die Überlegungen die ich mir mache, wenn ich gefragt werde, welchen Service ich einem Auftraggeber/ Kunde anbieten sollte. Ich überlege mir auf welcher Lernstufe sich das Team oder der Mensch befindet und biete entsprechend Training, Beratung oder Coaching an.

PS: in einigen Umgebungen findet man alle drei Lernstufen im Team…  😉

Think – Pair – Share

In Projekten welche in einem anspruchsvollen fachlichen Umfeld und in kurzer Zeit etwas erreichen wollen stellt sich immer die Frage;  wie schaffe ich als Coach eine gute Lernumgebung?

Neben kurzen Iterationen oder Sprints mit guten Retrospektiven kann man schon sehr viel erreichen. Nur das reicht oft nicht. Wie gelingt es eine steilere Lernkurve zu erhalten?

Auf der Suche nach einer Antwort bin ich über das Konzept Think-Pair-Share gestolpert.

Im wesentlichen geht es darum:

Think:
Die Teammitglieder lernen zuerst individuel und vertiefen ihr Wissen. Um Wissen aufzubauen kann auch eine Timebox verwendet werden. Dh, das Team trifft sich für eine Stunde. Jedes Teammitglied hat Zeit sich mit einem Thema auseinander zu setzen und sich Gedanken darüber zu machen.  Das kann von 5 Minuten bis 30 Minuten dauern.

Pair:
In Zweierteams tauschen sich die Teammembers über das gelesene oder gelernte aus.  Der erste Lernpartner beschreibt wie er das Thema verstanden hat und was er gelernt hat und was für ihn wichtig ist. Der Lernpartner 2 macht sich Notizen. Als nächstes werden die Rollen umgedreht. Diese Timebox kann von 5 Minuten bis 15 Minuten gehen. Beide Lernpartner haben die Lerninhalte des anderen Verstanden und können beide Perspektiven  einnehmen.

Share:
Zum Abschluss stellen die Lernteams der Gruppe die Ergebnisse vor. Das kann als Minivortrag oder mit Flips gemacht werden.

Mit dieser Form der Lernverantstaltung sollte es möglich sein in einem kleinen Team innerhalb einer Stunde 3 bis 4 Themen in einer guten Tiefe zu erarbeiten. Dieser Event könnte zum Beispiel nach einem Refinement oder nach einem Planning 1 oder 2 stattfinden, wenn das Team erkennt das es mehr über das Thema in der User Story wissen sollte.

Natürlich kann diese Methode auch angewendet werden während der normalen Arbeit um die Software Craftsmanship zu verbessern.

 

kooperativ