1. Etappe – Die Management-Retro oder besser gesagt „Der Eintagesklassiker“

Streckenkunde

Als ich mir Gedanken über ein passendes Synonym für mein Faible zum Radsport gemacht habe, war und ist der Eintagesklassiker für mich das Synonym was den Charakter einer Management-Retro am besten beschreibt.
Ok…die erste Etappe soll ein Eintagesrennen sein??? Passt ja nicht zu einer Tour, vollkommen richtig. Aber sind wir mal ehrlich, eine Management-Retro grenzt sich aus meiner Sicht vom normalen Tagesgeschäft eines Agilisten ab. Irgendwie auch skurill, zählen doch die Eintagesrennen zur ältesten Disziplin des Radsports. Das kommt mir bei Management-Terminen genauso vor ;). Eintagesrennen sind geprägt von einer anspruchsvollen Streckenführung sowie ein Terrain, was bekanntlich den „Klassiker-Fahrern“ bzw. Allroundern zugutekommt. Adaptiert auf die Management-Retro trifft es das wie die Faust aufs Auge. Nach oftmals nicht mehr als einer Stunde ist der Termin vorbei, das Management erweist sich zudem noch als schwierig und unvorhersehbar. Für mich bedeutet das, sich auf Alles gefasst zu machen und möglichst eine große Bandbreite an Gedanken, Ideen und Vorschlägen parat zu haben.

Den Begriff der Management-Retro habe ich das erste Mal bei meiner CSP-Zertifizierung von Andy Schliep (@andreasschliep) gehört. Und wenn ich so darüber nachdenke, leuchtet es mir auch immer mehr ein warum man es „Retro“ nennt. Oftmals bleibt uns Agilisten nur die Reflexion über DAS was das Management agil nennt.

• Wo findet eine wirklich gute Einführung von agilen Methoden in Unternehmen statt?
• Wer sorgt für nachhaltige Aus- und Weiterbildung der Scrum Master und Product Owner?
• Wo werden die Trainingsschwerpunkte gesetzt? Team, Product Owner, Scrum Master oder beim Management?
• Wer sorgt für ein effektives Abhängigkeitsmanagement bei mehreren Teams (man denke nur an die Flight Levels…)?

Für mich fühlt es sich so an, als müsse man noch schnell auf den abfahrenden „Agile-(Release)-Train“ (Wortwitz :)) aufspringen, um ja nicht den Trend zu verpassen. Also schnell ein paar Metaplanwände, Post-Its und bunte Sitzwürfel bestellt und den Mitarbeitern stolz erzählt, dass man ab morgen auch agil ist…CHAPEAU!

Nun habe ich mich selbst im Laufe meiner Zeit oftmals gefragt wie man als Verfechter agiler Gedanken den Hebel abseits des Teams ansetzen kann. Die Probleme zu analysieren fällt uns allen vermutlich nicht schwer. Mehr oder weniger zusammengewürfelte, „crossfunktionale“ Teams. Auserkorene Scrum Master und Product Owner mit wenig bis keinen Rollenverständnis (woher auch). Und ein Management, welches ihre neue Rolle ebenfalls nicht verstanden hat. Symptome zu bekämpfen ist ja bekanntlich nur eine Seite der Medaille. Aber an die Ursache zu kommen und diese zu heilen, stellt sich in der Praxis oftmals als schwierig heraus.

Vorbereitung

Unzählige Gedanken schwirrten in meinem Kopf.

• Wie am besten beginnen?
• Worauf lege ich den Schwerpunkt in der einen Stunde
• Den roten Faden nicht verlieren
• Adhoc-Visualisierung oder doch schon vorbereitete Sachen?

Schwierig oder kaum zu beantwortende Fragen. Und ein Patentrezept schon mal gar nicht. Also nochmal bei Andy nachgehakt und gefragt wo er den Schwerpunkt sehen würde. Die simple Antwort: „Beginne mit den agilen Manifest – den Grundgedanken agilen Arbeitens!“
Ja klar…das ist mir auch schon in den Sinn gekommen. Aber mal ehrlich, das Management mit 4 Leitgedanken konfrontieren? Ich habe lange darüber nachgedacht und gehe sogar noch einen Schritt weiter zurück. Ich beginne mit den Lean Principles!

Warum ich das mache? Weil mir die 5 Prinzipien des Lean Managements noch stärker den Zweck des Ganzen ausdrücken. Sie sind so kompromisslos, unmissverständlich und haben jedes für sich ein extrem starken inhaltlichen Ausdruck.
Wie beschreibt es Klaus Leopold in seinem Buch „Agilität Neu denken – Warum agile Teams nichts mit Business Agilität zu tun haben“ so schön: Wir machen Scrum ja nicht der Methode wegen…
Und genau dort liegt der Knackpunkt, der im Laufe der Zeit in Unternehmen immer mehr verschwimmt. Die Methode ist nicht das Ziel!

Also werde ich die Retro mit einer Frage beginnen:

„Warum arbeiten Wir eigentlich agil?“

Ich möchte die Gedanken aber auch die Annahmen des Managements verstehen. Ein besseres Bild bekommen, was denn damals die Intension und auch die Idee hinter der Einführung war.
Nach der ersten Bestandsaufnahme versuche ich über das Agile Manifest Alle  „Zurück auf Start“ zu holen um dahingehend die Überleitung zu den Lean Principles durchzuführen. Bei den Prinzipien ist es mir vor allem wichtig, auf VALUE STREAM und FLOW näher einzugehen. Ich habe vielmals die Erfahrung gemacht, dass die Ausrichtung der agilen Teams am Business als einzige Änderung gesehen wird. Ja, es ist unumgänglich den Fokus der Teams auf das Business zu lenken, viel wichtiger ist aus meiner Sicht jedoch der darauffolgende Schritt die wertschöpfenden Prozesse kritisch zu hinterfragen. Denn wie schreibt Jeff Sutherland so schön: „[..]Doing Twice the Work in Half the Time“. Das wird uns jedoch nicht gelingen, wenn man nicht am Value Stream arbeitet.
FLOW ist ja bekanntlich der stetige Fluss der Arbeit. Und der kann nur Fließen je weniger Störungen bzw. Abhängigkeiten man als Team hat. Also möchte ich auch hier darauf hinweisen, dass Weniger mehr ist und man versuchen sollte Störfaktoren wie Meetings zu reduzieren und Abhängigkeiten zu z.B. Entscheidungsträgern zu minimieren, indem man diese versucht ins Team bzw. an den PO zu verlagern.

Hier enden meine Überlegungen schon. Nicht, dass ich nicht weiterwüsste. Ich glaube jedoch, dass ich maximal bis hierhin kommen werde ehe das Meeting seinen eigenen Verlauf nimmt. Also spare ich mir die Energie und hebe mir sie für adhoc-Ideen auf.

Ziel

Einige von Euch werden sich jetzt fragen: Wieso das Ganze? Absolut berechtigt. Ich verfolge mit meiner Aktion jedoch ein Ziel. Das Management nachhaltig zum Umdenken zu bewegen und es als Motor für die agile Transformation zu gewinnen. Was für uns ja so sonnenklar ist, ist es für das Management ja leider nicht. Also stelle ich dem Management drei Ideen vor, von denen ich überzeugt bin, dass sie einen langfristigen Effekt haben können.

Der Aufbau einer agilen Community (Ja, klingt langweilig und bestimmt schon 20mal thematisiert)!

Aber in meinem Umfeld fehlen entscheidende Punkte. Erstens gibt es keine treibende Kraft und zweitens sieht man es heute nicht als „Teil“ der Arbeit an.  Wie aber die Mitarbeiter dazu bewegen sich auf Agilität einzulassen, wenn es den Stellenwert nicht genießt?

Der Aufbau und die Weiterentwicklung von Product Ownern und Scrum Mastern

Wer kennt es nicht: Scrum Basis Training, Multiple Choice Test und CSM/PSM-Zertifikat in der Hand! Juhu, wir haben in zwei Tagen 10 Scrum Master ausgebildet…jetzt gehen wir steil! …weit gefehlt. Teams sollen sich entwickeln, um nachhaltig bessere Leistung zu erbringen. Das benötigt erfahrene Scrum Master mit dem nötigen Handwerkszeug. Und das gibt’s leider nicht nach einem Tag Scrum Basis Schulung. Also liegt der Fokus auf dem Committment vom Management hier langfristig die Rollen sowohl extern als auch intern weiterzubilden.

Die Forderung nach „Back to the roots“

Meine letzte Forderung bezieht sich auf das, was Lyssa Adkins so schön den Core of Agile nennt. Mit einem Team die Kernprinzipien des agilen Manifests zu leben und dabei so wenig wie möglich extern gesteuert zu werden. In meinem speziellen Falle bedeutet das:

• Entscheidungen trifft das Team
• Der Product Owner führt ein echtes Stakeholder-Management durch und trifft Entscheidungen hinsichtlich des Produkts
• Es werden keine weiteren Rollen eingeführt, die es in Scrum nicht gibt
• Es wird keine Schattenwelt mit Entscheidungsgremien, Ausschüssen u.Ä. bedient

Update nach Durchführung folgt! Das soll’s erstmal gewesen sein. Euch viel Spaß beim Lesen und ich hoffe auf den Ein oder anderen Kommentar!

Ride on, Cheers Sascha