Arbeiten wir noch agil oder sind wir bereits agil? 

Agilität in wenigen Worten zu beschreiben, ist nicht einfach. Nähern wir uns dem Thema historisch, so kommen wir am AGIL-Schema des Soziologen Talcott Parsons nicht vorbei, welcher vier Funktionen definiert, die jedes langfristig überlebensfähige System erfüllen muss [3]:

• Adaption: Die Fähigkeit sich flexibel auf sich verändernde äußere Bedingungen anzupassen,
• Goal Alignment: Die Fähigkeit Ziele zu definieren und zu verfolgen,
• Integration: Die Fähigkeit kohärente Entscheidungen und Handlungen zu treffen und so die einzelnen Teile des Systems zusammenzuhalten,
• Latency: Die Fähigkeit grundlegende Konzepte, Werte und Strukturen aufrecht zu erhalten.

Insbesondere die ersten beiden Funktionen Adaption und Goal Alignment finden sich auch in modernen Definitionen wieder, etwa: „Agilität ist die Fähigkeit einer Organisation, flexibel, aktiv, anpassungsfähig und mit Initiative in Zeiten des Wandels und Unsicherheit zu agieren.“ [4]

Seitdem sich agile Methoden spätestens durch das Agile Manifest von 2001 [5] sukzessive in der Softwareentwicklung und Wirtschaft etablierten, sind eine Vielzahl an Vorgehensmodellen und Frameworks zum agilen Arbeiten entstanden. Ohne an dieser Stelle darauf tiefer einzugehen, herrscht Einigkeit darin, dass sich Agilität im Kern um Mindset und Werte dreht. Das agile Manifest selbst spricht gar nicht von Praktiken oder Prozessen, sondern beschränkt sich auf die Definition seiner vier berühmten Wertepaare 

• Individuals and interactions over processes and tools,
• Working software over comprehensive documentation,
• Customer collaboration over contract negotiation,
• Responding to change over following a plan

und leitet aus diesen zwölf Prinzipien agiler Softwareentwicklung her.

Betrachten wir Agilität in Organisationen wird ersichtlich, dass sich Varianten von Scrum [6] auf Teamlevel mit einer Verbreitung von über 80% als de-facto-Standard etabliert haben. [7] Häufig wird die Agilität eines Teams sogar mit der Nutzung von Scrum gleichgesetzt. „Doing Agile“ par excellence: Hauptsache das Jira-Board steht und ein Review findet statt.

Dies lässt sich auch am Beispiel des weitverbreitetsten [8] Skalierungsframeworks SAFe beobachten: Es werden neue Rollen (Release Train Engineer, Product Management, System Architect, …), neue hierarchisch wirkende Strukturen (Release Trains, Solution Trains, …) und viele bekannte Methodiken (Design Thinking, Kanban, Systemisches Denken, …) eingeführt. Auf den ersten Blick kann SAFe daher sehr erschlagend wirken, siehe auch nachfolgende Abbildung. Kein Wunder also, dass die ein oder andere Organisation bei der Einführung vor lauter Methodik die Werte aus den Augen verliert.

Um eine gedankliche Brücke zwischen „Being Agile“ und „Doing Agile“ zu schlagen, hilft Shuhari [9], ein Konzept aus der japanischen Kampfkunst. Dieses unterteilt den Prozess des Lernens und Könnens in drei Phasen:

• Shu: In Shu wird ein gelehrter Weg angewandt. Anpassungen oder Orientierungen an anderen Stilen sind nicht gewünscht und die Anweisungen des Meisters sollen detailgetreu befolgt werden.
• Ha: Ist die Praxis einmal verinnerlicht, darf im zweiten Schritt von dieser abgewichen werden. So wird aus verschiedenen Quellen eine eigene, schon teilweise individuelle Praxis.
• Ri: In der letzten Phase hat der Schüler die Lehre der Meister vollumfänglich verinnerlicht und durchdrungen. Er lernt nicht mehr von anderen, sondern entwickelt sich auf Grundlage der eigenen Erfahrungen und Erkenntnisse weiter.

In der Sprache von Agilität korrespondiert Shu mit der „Doing agile“-Phase, wohingegen Ri mit der „Being Agile“-Phase identifiziert werden kann. Die strikte Anwendung eines Frameworks, lässt sich in der Shu-Phase einordnen. 

Es gibt also gute Gründe, im ersten Schritt mit dem Einsatz agiler Methoden zu beginnen. Zudem hat (Unternehmens- oder Team-)Kultur die manchmal lästige Eigenschaft, veränderungsresistent zu sein. Change Manager sprechen von drei bis fünf Jahren, die es dauert, um kulturellen Wandel nachhaltig in einer Organisation zu verankern. [10] Und natürlich lässt sich ein gewachsenes Unternehmen, mit bestehender Hierarchie und Kultur sowie einer zumeist heterogenen Produkt- und IT-Landschaft nicht einfach agilisieren, indem man sich vornimmt, von morgen an agiler zu sein. In den Worten von Craig Larman, einem der Begründer des LeSS-Frameworks: „Kultur folgt Struktur“. [11]

Auch wenn insbesondere die „Zertifizierungsinflation“ kritisch hinterfragt werden darf, können agile Vorgehensmodelle und Frameworks Organisationen eine gute Orientierung zu einem möglichen (!) Zielbild geben. Sie schlagen etablierte und sinnhafte Praktiken vor, welche die Etablierung agiler Werte und eines agilen Mindsets fördern. Auch SAFe, unser Beispiel aus dem vorherigen Absatz, basiert in seinem Kern auf Werte, Mindset und Prinzipien, welche sich oft hinter einer Vielzahl von Methodiken versteckt...

Letztendlich ist Agilität kein feststehendes Zielbild, sondern vielmehr eine kontinuierliche Reise. Die feierliche Ankunft im Ziel Agilität gibt es also gar nicht. Welcher Rahmen am besten passt und wie dieser zur eigenen Firmenkultur und Produktlandschaft adaptiert werden sollte, muss jede Organisation individuell herausfinden. Zum Glück fordert das 12. Prinzip des Agilen Manifests genau zu dieser Reflexion auf: „At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.“