Agilität ist in aller Munde. Jede Organisation, die was auf sich hält, will das auch. Aber muss das wirklich sein? Schauen wir doch mal hin…
Agilität ist kein Selbstzweck
“Ab morgen müssen wir alle agil sein” – so der Leitspruch in vielen Agilen Transformationen. Und wozu? Wer kümmert sich primär um dieses Vorhaben? Schweigen…
Fast 20 Jahre ist es her, da haben sich einige Menschen zusammengesetzt und die unterschiedlichen Ansätze, wie man Projekte durchführt und Produkte entwickelt, reflektiert und darüber philosophiert. Es ging dabei u.a. auch um die Intention der unterschiedlichen Ansätze. Herausgekommen ist das Agile Manifest. Und genau da finden wir im Vergleich zu den meisten sogenannten Agilen Transformationen schon den ersten Hebel, um die Wirksamkeit des Unterfangens, agil zu werden, deutlich zu verbessern. Agilität (oder Scrum/Kanban/etc.) ist ja kein Selbstzweck. Dem beabsichtigten Wandel muss ja eine Absicht zu Grunde liegen: wozu will eine Organisation “nach” der Agilen Transformation in der Lage sein, was sie vorher noch nicht konnte? Woher weiß die Organisation, dass sie das dann kann? Wie stellt die Organisation fest, dass die eingeschlagene Richtung tatsächlich immer noch valide ist? Du merkst schon, dass hier bestimmte Dinge hinterfragt werden, die wir typischerweise auch in der Produktentwicklung hinterfragen:
Wozu das Ganze? Was ist die Vision des Wandels?
Wenn die Relevanz des Wandels nicht klar ist, bildet sich eher Widerstand statt Begeisterung. Darum ist eine weitere Sache, die man sich zu Herzen nehmen sollte:
“Mach’ Betroffene zu Beteiligten” – ansonsten kann es noch mehr Widerstand geben.
Im Anschluss kann man die Frage stellen, wer sich für den Wandel so sehr verantwortlich fühlt, dass sie diesen Wandel aktiv begleitet. In Scrum gesprochen stellt sich also die Frage, wer Product Owner für den Wandel ist. Da es ja um Organisationsentwicklung geht, sollte das Thema nicht stiefväterlich nebenbei gemacht werden. Außerdem reden wir von “Ownership” – d.h. die Person, die diesen Wandel maßgeblich begleitet, sollte jemand sein, der von allen Seiten vertraut wird und die das entsprechende Mandat hat, das nötig ist, um Wandel zu bewerkstelligen.
Reflexion des Status Quo
Um mehr Klarheit hinsichtlich der Vision zu bekommen, nutze ich gern die S.W.O.T.-Analyse, um einen Startpunkt und eine erste Vorstellung davon zu bekommen, wohin die Reise gehen soll. Im weiteren Verlauf des Wandels kommt dann häufig die Kraftfeldanalyse zum Einsatz, doch dazu in einem anderen Beitrag mehr. Ich brauche dazu Flipchartpapier oder gleich die größeren Moderationstafeln inkl. Papier. Dann viele Stifte (mind. für jede Teilnehmer*in einen Stift) und Haftnotizen.
Schritt 1: Auf nach Utopia
Wie ist die Organisation/das Unternehmen, wenn diese “ideal” ist? Was kann sie dann, was sie heute nicht kann? Und wozu? Was ist der Wert dieser Fähig- und Fertigkeiten? Diese Fragen betrachten wir losgelöst von allen Schwierigkeiten, die sich gegebenenfalls auf der Reise ergeben.
Schritt 2: Die S.W.O.T.-Analyse
Nun gilt es, mit “schonungsloser” Ehrlichkeit die folgenden Fragen zu diskutieren:
- Was sind unsere Stärken als Organisation?
- Welche Möglichkeiten ergeben sich daraus?
- Wie zahlen diese auf das Ziel ein?
- Was sind unsere Schwächen als Organisation?
- Welche Risiken bzw. Gefahren ergeben sich daraus?
- Wie stehen diese dem Ziel im Weg?
Die Antworten auf die Fragen werden auf Haftnotizen geschrieben (idealerweise pro Antwort ein Zettel) und dann auf dem vorbereiteten Template (s.u.) verortet.
Schritt 3: Strategien ableiten
Was lernen wir als Organisation aus den Punkten, die die S.W.O.T.-Analyse ergeben hat? Welche Möglichkeiten gibt es, um mindestens die relevanten Stärken weiterhin stark zu halten? Und welche Möglichkeiten gibt es, zumindest die relevanten Schwächen zu adressieren? Diese kann man mit folgenden Blickwinkeln nochmals schärfen:
- Was könnten wir tun?
- Was sollten wir tun?
- Was möchten wir tun?
- Was müssen wir jetzt tun?
- Warum?
Und auch eine andere Blickrichtung ist interessant:
- Was möchten wir nicht tun?
- Wo schauen wir grad nicht hin?
- Warum?
Insbesondere mit den o.g. Fragen hat man nun noch mal die Möglichkeit, die Erkenntnisse, was alles zu tun möglich ist, in eine mögliche Sequenz zu bringen. Einige Ideen dazu , was man alles machen könnte, liefert das Agile Manifest. Aber eben nicht alles. Der Unterschied des Herangehens liegt hier also darin, dass man von der Auswirkung (Vision und Impact) her schaut und nicht von dem Werkzeug (Agilität/Scrum) aus. Man könnte also fast Value-Driven-Development oder Impact-Driven-Development sagen 😉
Das Team, das den Wandel begleitet
Es braucht Aufmerksamkeit und Handlung, um den Wandel zu bewerkstelligen. Und das Team, dass den Wandel begleitet, sollte in diesem Kontext als Vorbild dienen. Die Grundlagen des Empirismus (Transparenz, Inspektion und Adaption) müssen gelebt werden. Auch der o.g. Ansatz, Betroffene zu Beteiligten zu machen, ist hier in Fleisch und Blut übergegangen. Doch wie der Wandel eine Vision braucht, so braucht auch das Team, das den Wandel begleitet, etwas ähnliches. Man spricht hier häufig von einer Mission. Die Vision klärt das Zielbild des Wandels. Die Mission klärt, wie wir (in diesem Fall das Team, das den Wandel begleitet) zum Wandel beitragen.
Muss es also immer Agilität sein? Ich meine nicht. Doch die Punkte aus dem Agilen Manifest haben in meiner bisherigen Erfahrung immer sehr positiv zum Wandel und der zugrundeliegenden Intention beigetragen. Wahrscheinlich trifft es die universelle Coaching-Antwort “Es kommt drauf an…” am Besten. Solltest Du Dich in der Situation eines Wandels befinden, kannst Du die o.g. Punkte wie folgt zusammenfassen:
- Was ist die gewünschte Auswirkung des Wandels? (Die Vision)
- Wer kümmert sich um diesen Wandel (in vollem Umfang)? (Begleiter des Wandels inkl. Product Owner – oder lieber Reisebegleiter und Journey Guide?)
- Welchen Beitrag leisten die Reisebegleiter? (Die Mission)
- Wie sieht die Strategie aus, um die Auswirkungen zu realisieren?
Auch wenn die oben genannten Punkte offensichtlich scheinen, so kommen die zumindest in den Umgebungen, die ich bisher kennenlernen durfte, häufig viel zu kurz…
Links
- Manifesto for Agile Softwaredevelopment
- S.W.O.T.-Analyse (auf gamestorming.com)
- Kraftfeldanalyse (auf gamestorming.com)