Letzte Woche durfte ich mit zwei Kollegen die Iteration Zero am agile Breakfast in Bern vorstellen. Anwesend waren Agilisten von allen grossen Firmen in Bern.
Die Iteration Zero zeigt einen Weg auf, wie man von der Produktidee zu einem initialen Backlog kommt, dies mit Fokus auf den Kunden und den Wert des potentiellen Produktes für den Kunden und die Unternehmung. Ich habe bereits Ende letzten Jahres in diesem Blog die Iteration Zero vorgestellt.
Die Praktiken der Iteration Zero versteht man am besten, wenn man sie erlebt. Deshalb haben wir nach einer sehr kurzen Einführung in Kleingruppen direkt mit der Produktidee gestartet und über die Personas und die Vision Map das MVP anhand einer Produkt Box gestaltet.
Die Teilnehmer waren gelinde gesagt begeistert. Viele haben aber bemängelt, dass wir nicht eine ausführliche Dokumentation abliefern können, inkl. einer intensiven Schulung.
Bei der Reflexion des Events ist mir bewusst geworden, dass wir als Agile Coaches uns schon lange von dieser Dokumentations- und Theoriegläubigkeit verabschiedet haben. Unser Erfolg basiert doch unter anderem darauf, dass wir ohne Angst Dinge ausprobieren, frei im Geist und möglichst ungebunden uns bewegen können. Eigene Fehler gehören bei mir zum Alltag und der Schlüssel zu meinem Erfolg ist aus diesen Fehler lernen zu können. Da helfen mir Bücher und Theorie eher wenig. Viel wichtiger ist für mich der Austausch mit meinen Agile Coaching Kollegen. Und Erfahrungen sammeln, Erfahrungen sammeln, Reflektieren und nochmals ausprobieren …. unser Team von Agile Coaches hat die Abkürzung ACT sehr bewusst gewählt 😀.
Wie findet man heraus, was dazu führt, dass ein Team nach einer langen Performance Phase plötzlich in eine Phase der Demotivation gerät? Kann es sein, dass die Summe der Motivation der einzelnen Teammitglieder die Teammotivation darstellt?
Auslöser zu diesen Fragen war ein Workshop an welchem das Team gefragt wurde; Was muss sich ändern, damit ihr wieder voll motiviert an dem Projekt mitarbeitet?
Antwort des Teams: Wir wissen nicht was geändert werden muss damit wir wieder Spass an unserer Tätigkeit und in unserer Organisation haben.
Die Demotivation ist offensichtlich und feststellbar. Sachliche Veränderungen oder Vorschläge zum Mitwirken haben keine Besserung hervorgebracht. Das Team befindet sich mehr oder weniger offensichtlich in einer Widerstandssituation. Selbst die Wunder-Frage: Wie sieht für dich / euch die perfekte Zukunft aus? bringt keine Verbesserung der Situation, keinen konstruktiven Lösungsprozess.
Ein neuer Ansatz ist gefragt. Meine Hypothese lautet dass die einzelne Motivation einen grossen Beitrag zur gesamt Teammotivation beiträgt. Ich vermute auch dass die Demotivation nicht nur aus fachlichen Situationen in der Organisation und dem Projekt herrührt. D.h die intrinsische Motivation der einzelnen Teammembers ist der Kern des Problems.
Hier könnten folgende Fragen gestellt werden welche auf die Elemente nach Pink einzahlen.
Sinnhaftigkeit; Hat sich etwas an der Sinnhaftigkeit meiner Arbeit verändert? Sehe ich den Sinn meiner Tätigkeit heute anders als noch zur Zeit als wir ein Performance Team waren?
Meisterschaft; Werde ich heute in meiner Tätigkeit gefördert um eine Meisterschaft zu erreichen? Werde ich weiterhin als meisterlich in meinem Fach wahrgenommen? Warum werden meine Argumente nicht mehr gehört? Ist mein Beitrag weniger Wert als früher?
Autonomie; Bin ich heute freier oder eingeschränkter in meiner Autonomie als zur Zeit als ich noch in einem Performance Team war? Warum glaube ich dass ich heute weniger Autonomie im Handeln und Entscheiden habe?
Zu jedem Bereich könnten noch weitere Fragen gestellt werden welche dazu führen zu verstehen was sich subjektiv verändert hat.
Aus den Antworten müsste es dann gelingen, Verbesserungsvorschläge zu entwickeln welche es den einzelnen Teammembers erlaubt die intrinsische Motivation zurück zu gewinnen welche dann wieder zu einer Verbesserung der Teamsituation führt.
Allerdings… aus Erfahrung kommt noch eine weitere Betrachtungsweise dazu. Ich behaupte dass es einen Zusammenhang zwischen Motivation und Statistik besteht. 🙂 die Formel lautet:
Motivation = Eintretenswahrscheinlichkeit x Gewinnerwartung
Meine Motivation wird durch zwei Faktoren wesentlich geprägt. Gewinnerwartung; Was kann ich durch meinen Einsatz gewinnen? Je höher der Gewinn, desto höher die Motivation. (Gewinn ist nicht nur materiell gemeint). Der Höchste Gewinn nutzt aber nichts, wenn der Faktor Eintretenswahrscheinlichkeit = 0 ist. D. h. Wenn ich nicht daran glaube das ich eine Chance habe zu gewinnen wird die Gewinnerwartung mit 0 multipliziert, Ergebnis ist 0. Also keine Motivation.
Das bedeutet, dass alle intrinsische Motivationsfaktoren keinen Wert haben, wenn das Team oder die Teammembers nicht daran glauben das sich etwas verändern wird oder die Eintretenswahrscheinlichkeit der Veränderung = 0 ist.
Letzte Woche habe ich die Ausbildung zum Kanban Coach gestartet, mit einem Grundlagen-Training zum Thema Coaching.
Meine Schlüsselerlebnisse dieser zwei Tage möchte ich gerne mit euch teilen:
1. Demut vor den Menschen, Positive Energie und immer mit dem Fokus „Hilfe zur Selbsthilfe“ als Coach agieren.
2. Energie zur Veränderung kann ich niemandem schenken. Die Energie muss vom Coachee selbst kommen. Meine Impulse bewirken im besten Fall, dass die Startenergie nicht so gross sein muss und auf dem Veränderungsweg ein paar Restaurants zur Verpflegung vorhanden sind.
3. Veränderungsgeschwindigkeit kann ich nicht beliebig beschleunigen. „Auch wenn wir an Gras ziehen, wächst es deshalb nicht schneller.“
4. Nur wo wir Energie reinstecken, kommt auch Energie raus. Wenn ich z.B. in einem Team Verbesserungen bewirken will, mich aber nur einmal im Monat eine halbe Stunde damit auseinander setzen will, wird sich auch nichts verändern/verbessern.
5. Der Satz „Never change a Running System“ wird bei Arbeitssystemen, bei denen Kanban gelebt wird, zu „Always run a changing System“.
6. Als Coach muss ich sehr gut ausgebildete Fühler/Antennen haben. Ich muss immer über mehrere Kanäle mein Gegenüber erfassen können, die erfassten Informationen analysieren, neue Strategien ableiten und diese Umsetzen. Also in kurzen Iterationen agieren und reflektieren. Inspect and adapt in Reinkultur betreiben und das sehr intensiv. Kommt uns das irgendwie bekannt vor? 😍
Ich freue mich auf die weiteren Module der Ausbildung 🌈, die von Sigis Kaltenecker und Klaus Leopold durchgeführt wird.
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.
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.
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… 😉
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.
Wir möchten zielsicherer, schneller und schlanker werden – kein Problem: Kanban hilft euch dabei. Wirklich?
Vielfach werde ich damit konfrontiert, dass mit Kanban alles besser werden soll. Und was passiert, wenn wir nicht besser werden – trotz Kanban?
Die Limitierung unseres Workloads ist eines der Kanban Praktiken, welche uns helfen kann schneller zu werden. Wir führen ein Kanban System inklusive WIP-Limiten ein und werden dadurch produktiver – kann sein, muss aber nicht.
Sind wir beispielsweise ein nicht in sich geschlossenes System – haben also Abhängigkeiten nach *“aussen“ – wird es schon schwieriger. Es können Wartezeiten durch Bottlenecks oder Blocker in unserem System auftreten, welche von „aussen“ verursacht werden. Die Durchlaufzeit – welche durch das WIP-Limit also eigentlich kürzer werden sollte – wird nicht massgeblich optimiert. Kanban hilft uns hier nicht schneller zu werden- soll ich nun wieder damit aufhören?
Die Kanban Praktik „Visualisiere“ gibt Antwort: Unser Arbeitsfluss wird visualisiert. Unsere Herausforderungen mit Abhängigkeiten und Schnittstellen werden nun transparent – die Lösung obliegt jedoch nicht dem Kanban System an sich. Es ist lediglich ein Hilfsmittel diese sichtbar zu machen: Bottlenecks und Blocker aufzuzeigen, damit ich den evolutionären Wandel (eines der Kanban Prinzipien) anstossen kann…
*PS: Warum setze ich „aussen“ in Gänsefüsschen? Wir müssen uns klar werden was „aussen“ bedeutet. Ausserhalb des Teams, der Firma, des Einflussbereichs,…? Dies beeinflusst massgeblich mein Kanban-System und den evolutionären Wandel bzw. die kontinuierliche Verbesserung.
Seit einiger Zeit grüble ich an einem Slogen eines „Agile Transition Programms“ nach.
Schneller, schlanker, effizienter…
Schneller; ja, Time to Market ist ein wichtiger Punkt bei der agilen Produktentwicklung. Aber nach Geschwindigkeit streben ist ja ein alter Hut.
Schlanker; Was mag das genau bedeuten? Weniger Kosten? Weniger Prozesse, Weniger Qualität im Produkt. Mit etwas Phantasie und gutem Willen kann man sagen, ok, weniger Verschwendung, das ist ja auch ein agiles Prinzip.
aber jetzt kommts…
effizienter
Echt jetzt?
In unseren Trainings verwenden wir oft die Stacey Matrix um zu erklären warum eine Firma Agilität braucht.
Wir starten die Produktenetwicklung in einem Bereich wo wir nicht genau wissen wie die Anforderungen und die Technologie das neue Produkt beeinflussen werden. Wir starten in einem komplexen Umfeld.
Über Iteration und Iteration findet das Team heraus, welches Produkt die besten Chancen auf dem Markt haben wird. Wir reduzieren von Iteration zu Iteration die Komplexität und finden heraus was wirklich funktioniert.
Wir lernen wie das richtige Produkt hergestellt wird.
Daraus schliesse ich das es im Agilen Produktentwicklungsprozess vor allem darum geht das „Richtige“ auf den Markt zu bringen. Da kann der Herstellungsprozess schon ab und zu Umwege machen…. aber Scrum ist da ja auch sehr effizient wenn es um die Herstellung von Produkten geht und Vermeidung von Overhead.
Wenn das Produkt dann mal da ist kann die Unternehmung oder das Team ja an der Effizienz feilen, oder das Produkt weiter verbessern und den Begeisterungsfaktor erhöhen.
Zurück zu meinem, eingangs erwähnten „Agile Transition Programm“.
Wie erkläre ich nun dem Management, dass sie den Slogan falsch gewählt haben? Es sollte nicht Schneller, schlanker, effizienter heissen, wenn schon dann Schneller, schlanker, effektiver.
Hier könnten folgende Fragen gestellt werden welche auf die Elemente nach Pink einzahlen.
