Agilität ist in aller Munde. Aber was bedeutet das eigentlich?
In letzter Zeit werde ich immer öfter mit dem Thema konfrontiert. Agil an sich ist dabei nichts neues, zumindest nicht in der Software-Entwicklung. Die dort gemachten (positiven) Erfahrungen will man in die Organisationsstrukturen und das Management übertragen, oder allgemein auf andere Produkte und Prozesse. Das ist auch nicht neu. Warum wir immer wieder darüber sprechen? Ich sehe zwei Gründe: Zum einen wissen viele nicht wie oder wofür eigentlich. Zum anderen, und das ist schlimmer, haben viele die falschen Gründe.
Wenn nach den Gründen gefragt wird höre ich immer Argumente wie „das macht uns schneller“, „damit können wir besser auf Veränderungen reagieren“ und „damit erreichen wir kürzere Release-Zyklen“. Nun, das klingt erstmal mehr nach Prozessoptimierung als nach agilen Methoden. Was nicht verwerflich ist, mit Prozessoptimierung kennen sich die Menschen aus, das ist die bewährte Methode der letzten Jahrzehnte. Man merkt aber wie kurz das Gras ist wenn man fragt wie agile Methoden dabei helfen „schneller“ und „flexibler“ zu sein. Dann werden ganz schnell die immer gleichen Aussagen wiederholt und alle Beteiligten merken das man eigentlich gar nicht weiß wie. Das wird dann unangenehm.
Warum diese einseitige Sicht auf Agilität und die damit einhergehenden eindimensionalen Versuche der Umsetzung vorherrschen liegt aus meiner Sicht auch an der Rezeption aus der Software-Entwicklung. Welche Ergebnisse und Vorteile sieht das Management denn in der agilen Software-Entwicklung? Eben genau die schnelleren Ergebnisse und flexiblere Reaktion auf Veränderung. Was da intern in den agilen Teams stattfindet, das wird selten reflektiert. Die Stakeholder sitzen eben nur im Review, aber nicht in der Retro oder im Planning, um das mal in SCRUM zu formulieren. Es ist also an der Zeit die Lampe mal etwas höher zu hängen.
Was bedeutet Agil denn eigentlich?
Das Wort „agil“ bedeutet erstmal „von großer Beweglichkeit zeugend, regsam und wendig“. Beweglich und wendig sind relativ passive, reagierende Eigenschaften. Auf den ersten Blick also ziemlich Deckungsgleich mit unserem oben ermittelten Eindruck. Doch was ist mit „regsam“? Das wirkt schon aktiver. Und es gibt einen Zusatz, je nach Quelle steht da weiterhin: „aktiv auf Veränderungen reagierend“, „aus sich selbst heraus handlungsfähig“ oder „flexibel und darüber hinaus proaktiv, antizipativ und initiativ zu agieren“.
Und genau da kommt ein wichtiger Unterschied ins Spiel. Agil ist etwas anderes als flexibel, es ist mehr, es geht darüber hinaus. Flexible Organismen reagieren, agile Organismen agieren. Und bei der Bedeutung des Wortes „agieren“ sind wir dann schon bei „etwas betreiben, tun“. Ein agiler Organismus ist also einer der aus sich selbst heraus etwas tun und antreiben kann. Das klingt nach deutlich mehr als einer Prozessoptimierung.
Agilität bedeutet nicht die Prozesse in einer Organisationseinheit im Hinblick auf die Ergebnisse zu verbessern. Agilität bedeutet die Arbeitsweise dieser Organisationseinheit und die Interaktion mit ihr komplett zu verändern. Die Einheit wird selbstständig und handlungsfähig, und eben erst dadurch auch flexibler und schneller. Wir wollen das an einem unorthodoxen Beispiel darstellen.
Führen per Auftrag
Die Idee der agilen Methoden ist nicht neu, nur das sie einen anderen Namen haben. Tatsächlich kennen wir ein Beispiel aus einem Bereich in dem niemand damit rechnet: dem Militär. Eine Organisation die versucht ihre eigene Größe und Komplexität mit strenger Hierarchie und Gliederung zu lösen. Selbst hier hat man schnell erkannt das die reine Befehlskette von oben nach unten zwar hilft die Komplexität der Organisation zu beherrschen, aber nicht die Aufgaben zu bewältigen vor denen die Organisation steht.
Ein einfaches Beispiel: eine Truppe bekommt den Befehl einen bestimmten Bunker zu besetzen und zu halten. Der Befehl kommt von ganz oben nach ganz unten (inklusive Laufzeit) und soll ausgeführt werden. Die Truppe marschiert los, und stellt fest der Bunker existiert nicht mehr. Er wurde gesprengt. Das Problem ist nun das die Truppe nicht weiß warum sie den Bunker besetzen und halten soll. Sollte sie nur verhindern das der Feind ihn bekommt? Oder sollte sie von hier aus selber eine Sicherung für benachbarte Truppen bilden? Sie kennt den übergeordneten Plan nicht. Daher bleibt nichts übrig als zurück zu melden das der Bunker nicht mehr existiert und auf weitere Anweisungen zu warten (inklusive Laufzeit der Meldungen über die Befehlskette). Die Führung bekommt nun die Meldung der Bunker existiert nicht mehr, weiß aber sonst nichts von der Situation vor Ort und kann diese schlecht einschätzen. Die Führung hat keinen Zugang zu den Kenntnissen ihrer Experten vor Ort.
Das Problem lässt sich zusammenfassen: Hierarchien sind gut wenn feste Pläne ohne Abweichung einfach nur umgesetzt werden sollen. Die Organisation einer Armee zu Friedenszeiten zum Beispiel. Im Einsatz ändern sich die Bedingungen aber ständig. Kein Plan überlebt den ersten Feindkontakt sagt man. Auf diese ständigen Änderungen muss man flexibel reagieren können. Denn nur wer schnell reagieren kann, kann spontane Gelegenheiten nutzen. Und das wusste man beim Militär schon anno 1900. Daher wurde damals schon beschrieben das man eine Wandlung von „Führen per Befehl“ zu „Führen per Auftrag“ vollziehen muss. Die Truppe vor Ort muss ausreichend über den Gesamtplan informiert werden um selbstständig entscheiden zu können was bei unvorhergesehenen Änderungen zu tun ist. Was man zum Gesamtplan unter den neuen Umständen noch bestmöglich beitragen kann und was nach oben gemeldet werden muss. Man sagt: der Untergebene muss in die Lage versetzt werden vor Ort zu entscheiden was sein Vorgesetzter an seiner Stelle in der neuen Situation tun würde um das übergeordnete Ziel zu erreichen.
Merke: um gute Entscheidungen treffen zu können, muss ich gut informiert sein. Vor allem muss ich das übergeordnete Ziel kennen.
Deswegen funktioniert agil
Der Grund warum agile Software-Entwicklung besser funktioniert als frühere Modelle ist genau hier zu finden. Frühere Modelle haben starre Vorgaben und feste Entwicklungsprozesse geschnürt. Veränderungen in der Umgebung (Kunden, Anforderungen, Technologien, Marktlage) konnten schwer umgesetzt werden weil Entscheider keinen Zugang zu ihren Experten hatten und mit Meldungen „von unten“ nicht viel anfangen konnten. Gleichzeitig konnte man „von unten“ nicht viel tun weil man immer auf Anweisungen „von oben“ warten musste.
Die Lösung ist hier ähnlich wie seinerzeit beim Militär. Die Führung beschäftigt sich nicht mehr mit den Details der Umsetzung, das überlässt sie den Experten vor Ort. Die Führung gibt eine Marschrichtung vor, eine Auftragslage, strategische Ziele. Die einzelnen Einheiten können dann, bei ausreichender Informationslage, selber entscheiden was sie am besten dazu beitragen können. Sollten Probleme auftreten die das Ziel in Frage stellen, wird nach oben berichtet. Die Qualität der Informationen nach oben kann deutlich verbessert werden wenn man unten weiß was oben benötigt wird. Die Ressourcen vor Ort können besser genutzt werden, die Experten können sich sinnvoller einbringen und in ihrem Fachgebiet optimale Lösungen finden.
Und ja, damit wird man schneller und flexibler. Weil die einzelnen Einheiten (bis runter zu einzelnen Mitarbeitenden) besser informiert sind, vor Ort entscheiden und damit flexibler agieren können. Sie werden überhaupt erst in die Lage versetzt eigenaktiv zu agieren weil sie über die Informationen verfügen die sie benötigen um Entscheidungen zu treffen. Das ermöglicht allen Beteiligten Chancen zu erkennen und zu nutzen. Das macht die Einheiten gleichzeitig resilienter, weil Teams intern und extern auch bei Ausfällen selbstständig neue Wege finden können um Ausfälle zu heilen.
Und genau diesen (meist ungesehenen) Faktor in der agilen Software-Entwicklung wollen wir auf Organisationen übertragen. Das ist der Mehrwert, der macht uns schneller, flexibler, aktiver und lebensfähiger in einer unübersichtlichen und sich verändernden Umwelt. Das ist wie in der Natur: wer sich besser anpassen kann, kann besser überleben. Es geht also nicht einfach nur darum schneller und flexibler zu werden oder sich (einmalig) anzupassen. Es geht darum die Anpassungsfähigkeit dauerhaft in die eigene Organisation aufzunehmen und einen lebensfähigen Gesamtorganismus zu bilden der alle seine Ressourcen möglichst optimal nutzen kann. Lasst Eure Experten nicht in der Hierarchie versauern, befähigt sie dazu im Unternehmen zu wirken. Die wissen schon was zu tun ist wenn sich in ihrem Bereich etwas verändert.
Oder wie ich immer zu sagen Pflege: bring die richtigen Leute an die richtigen Stellen und sorge dafür das sie arbeiten können.
https://de.wiktionary.org/wiki/agil
https://de.wiktionary.org/wiki/agieren
https://de.wikipedia.org/wiki/Agilität_(Management)
https://de.wikipedia.org/wiki/VUCA
https://de.wikipedia.org/wiki/Führen_mit_Auftrag
https://de.wikipedia.org/wiki/Management_by_Objectives