Agile Reflection

In unserer Organisation ist das Thema Agilität bereits mehrere Jahre am brennen. Jetzt hat es ein Ausmass erreicht, bei dem sich auch unagile-Mitarbeitende mit dem Thema profilieren wollen.

Folge davon ist, dass ich urkomische Auswüchse vom Umgang mit Agilität beoachten kann.

Hier ein Beispiel:

Agilität nach dem Giesskannen-Prinzip

Agilität lässt sich wie Wasser mit der Giesskanne auf Pflanzen (Mitarbeitende / Teams / Vorgesetzte …) verteilen. Alle Pflanzen werden regelmässig begossen…. Ab wievielen Güssen ist man Agile? Ab wievielen Güssen hat man ein Zertifikat als Agilist/Scrum Master/Agile Coach… verdient? ….

Mein Kommentar dazu ist, dass Agilität überhaupt nichts mit Aufgüssen zu tun hat. Das Lernen von Flexibilität im Umgang mit Veränderungen (was Agilität ja bedeutet) muss sehr spezifisch, persönlich und adaptiv angewendet werden. Der Wunsch sich zu Verändern und zu Lernen kann niemandem geschenkt werden, hier muss ganz viel intrinsische Motivation beim Empfänger vorhanden sein, sonst ist jeder Tropfen Agilität verschwendet. Agilität hat sehr viel mit Act (Handeln) und Erleben zu tun. Und da die Verankerung von Erlebnissen in Form von Erfahrungen seine Zeit braucht, nützt es auch nichts, hier mal zünftig auf die Tube zu drücken und mit der Giesskanne mal allen einen Guss Agilität zu vermitteln. Das bringt uns keinen Schritt weiter in der Agilisierung unserer Organisation.

Im Gegenteil kann dies dazu führen, dass die Pflanzen überwässert sind…. sie haben viel mehr Wasser erhalten als sie aufnehmen könnnen.  Da kann dann auch der beste Agile Coach nicht mehr viel ausrichten…

Heute in der FH einen neuen Begriff gehört. Laterale Führung.

nach Wikipedia:

Die Laterale Führung (lat. latus „Seite“) umschreibt die Situation der Führung ohne direkte Weisungsbefugnis. Die Einflussnahme auf die Willensbildung und das Handeln innerhalb einer Organisation geschieht ohne direkte Hierarchiebeziehung. Aufgrund der unterschiedlichsten Organisationsformen in sozialen Gemeinschaften (wie es auch Unternehmen darstellen) sind Führungskräfte mit verschiedensten Führungssituationen konfrontiert, darunter die der lateralen Führung.

 

Spannendes Gebiet um die Anforderungen von Agilen Teams an die Führung zu prüfen und zu hinterfragen.

Ich bin dann mal weg zum Nachforschen… 🙂

Ich bin über diesen Satz gestolpert… naja, gelesen in einer Bachelorarbeit.

Teams, die in die Kategorie Manager-led Teams  fallen, also ausschliesslich  Teamaufgaben ausführen und keinen Gestaltungsraum für deren Ablauf haben, entsprechen nach der Definition der Agilität und agilen Methodologien nicht einem agilen Team. (Hackman, 2002)

Seit einem halben Jahr hat sich die Aufgabenstellung unseres Teams verändert. Wir sind vom Agilen Team in die Richtung „Wertvolle Ressourcen die arbeiten müssen“ geändert worden. Bisher konnte ich meinen Unmut über die neue Situation nicht genau bestimmen. Mit dem oben erwähnten Satz sind mir dann einige Dinge klarer geworden.

Nach Sigi Kaltenecker und Hackman haben Teams folgende Eigenschaften:

• Gemeinsame Aufgaben, um eine überzeugende Mission zu erfüllen
• Klare Grenzen in Bezug auf den Informationsfluss, die Angleichung an andere Organisationseinheiten, Ressourcen und Entscheidungsgrundsätze
• Befugnis zur Selbstverwaltung innerhalb dieser Grenzen
• Stabilität über einen angemessenen Zeitraum
  (Hackman, 2002, S.41ff; Kaltenecker, 2015, S.4).

Zu den Grenzen der Befugnisse eines Teams sagt Hackman (2002) weiter, dass es hilfreich ist, bei der Entscheidung über das Ausmass der Befugnisse darüber nachzudenken, wer in der besten Lage ist, jede der vier Funktionen die erfüllt werden müssen, zu bewältigen:

•  Ausführen der Teamaufgaben
• Überwachung und Steuerung von Arbeitsabläufen und Arbeitsfortschritt
• Gestaltung des Teams und seines organisatorischen Kontexts
• Festlegung der allgemeinen Richtung

In unserem Team sind dies die Gestaltung des organisatorischen Kontextes der sich verändert hat. Dazu kommt, dass wir neu Management getrieben sind, sprich wir die Festlegung unserer allgemeinen Richtung nicht mehr selber gestalten, sondern neben Strategie auch operative Dinge vorgegeben werden.

Es kommen auch immer mehr Task hinzu welche die Überwachung unserer Abläufe und Arbeitsfortschritte vom Management gemacht werden und nicht mehr vom Team.

Im Moment sagt mir meine innere Stimme, das ich die wesentlichen Punkte getroffen habe, die mich bisher aufgeregt haben in unserer Teamemtwicklung. In einem nächsten Schritt versuche ich herauszufinden was noch für eine positive Verbesserung tun könnte.

 

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.

Meiner Überlegung liegt die Theorie der intrinsischen Motivation nach Pink zugrunde.  (Offizielle Webseite)

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.

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.

 

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…  😉

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.