Der neue stabile Zustand ist, mit instabilen Zielen und Rahmenbedingungen umzugehen. Dies ist zugleich Kern und Ursprungsort agiler Prinzipien. Sie machen aus der Not eine Tugend.
Derzeit ist alles, was gut ist, „agil“: die Organisation, das Change Management, die Strategieentwicklung, das Projektmanagement… Obwohl allerorten gerne verwendet, gibt es bislang keine mehrheitlich anerkannte Bedeutung des Begriffs „Agilität“. Dementsprechend findet aktuell ein Wettlauf um die Deutungshoheit statt. Für Menschen, die mit Lean Management oder Formen der Kanban-Methode zur Produktionssteuerung – beide eng verbunden mit dem Toyota-Produktionssystem aus der beginnenden zweiten Hälfte des 20. Jahrhunderts – vertraut sind, dürfte der Begriff der Agilität nicht neu sein. Einen wahren Karriereschub erfuhr der Begriff „Agilität“ Anfang des Jahrtausends durch seine rasante Verbreitung in der Softwareentwicklung, um schließlich 2001 mit dem „Agilen Manifest“ richtig amtlich zu werden. Unterzeichnet von 17 in unterschiedlichen Gebieten der Softwareentwicklung tätigen Menschen, fordert das Manifest:
Wir suchen nach besseren Wegen, Produkte zu entwickeln, in dem wir es selbst praktizieren und anderen dabei helfen, dies zu tun. Wir erkennen dabei sehr wohl den Wert der Dinge auf der rechten Seite an, wertschätzen jedoch die auf der linken Seite noch mehr.
Manifesto for Agile Software Development, 2001
~ P1 Quarterly als PDF Download ~
Was waren die Treiber, die zu diesen veränderten Werten und Grundannahmen geführt haben? (Software-)Entwicklungsprojekte liefen in den 90er Jahren standardmäßig nach der Wasserfallmethode ab: Ein präziser, detaillierter, dem Anspruch auf Vollständigkeit folgender Anforderungskatalog wird zu Beginn mit dem Kunden erstellt. Dieser Katalog bestimmt Struktur und Inhalt des Projektes, das über den gesamten Projektverlauf nicht mehr verändert wird. Am Ende übergibt der Projektleiter, zufrieden – weil er glaubt, er habe die Anforderungen des Kunden optimal erfüllt – und zugleich erschöpft – weil weder das ursprünglich veranschlagte Budget noch der Liefertermin eingehalten werden konnten –, dem Kunden sein Produkt. Dieser Vorgang endete häufig mit einer tiefen Enttäuschung des Kunden. Beispielsweise fehlten den Produkten regelmäßig implizite oder unbewusste Anforderungen, die der Kunde zwar gedacht oder gemeint, aber nicht im Lastenheft aufgeführt hatte. Oder die Anforderungen an das Produkt hatten sich während des Entwicklungszeitraums bereits so stark verändert, dass der Kundennutzen im Moment der Übergabe kaum noch dem entsprach, was eingangs erwartet wurde. Mit agilen Ansätzen kam ein fundamentaler Unterschied in die Welt: Die in der alten Denke eher variablen Faktoren Zeit und Budget werden jetzt fix (und fix bedeutet fix, nicht etwa eine Annäherung an fix) und der vormals fixe Inhalt (der Anforderungskatalog) wird flexibel. Flexibel meint dabei nicht beliebig, vielmehr wird der Inhalt – gemeinsam mit dem Kunden – in einer iterativen, inkrementellen Vorgehensweise kontinuierlich aktualisiert und priorisiert. Umgesetzt werden nur jene Anforderungen, die einerseits ganz oben auf der Prioritätenliste stehen und andererseits von einem Umsetzungsteam innerhalb eines festgelegten Zeitraums umgesetzt werden können.
Der wohl prominenteste Ansatz, diese agile Denke anhand eines eindeutig beschriebenen „Rahmenwerks“ im Alltag umzusetzen, ist Scrum. Der Begriff entstammt dem Rugbysport und bezeichnet dort das „angeordnete Gedränge“: Scrum beruht auf der oben geschilderten Erfahrung, dass moderne Entwicklungsprojekte zu komplex sind, um sich vollständig planen zu lassen. Und auf der Erkenntnis, dass sich die Unklarheit hinsichtlich Anforderungen und Lösungsansätzen in den Griff bekommen lässt: durch eine definierte, sich wiederholende Vorgehensweise mit ebenso klar definierten Rollen sowie unter enger Einbindung der Mitarbeiterexpertise und Kundensicht. Ein zentrales Element von Scrum ist die vollständige Selbstorganisation innerhalb des meist interdisziplinär besetzten Umsetzungsteams. Entscheidend für das Gelingen dieser Vorgehensweise ist eine einvernehmlich festgelegte Definition von „fertig“. Agile Ansätze wurden in der Softwareentwicklung „kultiviert“, hielten rasch Einzug in das IT-unabhängige Projektmanagement und verbreiten sich aktuell geradezu „viral“ als neues Organisations- und Management-Paradigma.
In der Softwareentwicklung hat man frühzeitig eine für Mensch und Organisation unangenehme Wahrheit akzeptiert: Langfristige Zielvorgaben und Pläne sind in einem immer volatileren Umfeld nicht mehr durchzuhalten. Statt weiterhin die Denkmodelle und Konzepte alter Zeiten für fundamental neue Gegebenheiten zurechtzubiegen, akzeptieren agile Ansätze diese neuen Gegebenheiten und machen aus der Not eine Tugend. Dies erklärt auch die vergleichsweise schnelle Verbreitung des „Agilen“ über Professionsgrenzen hinweg. Es erlaubt Mensch und Organisation, offiziell Dinge zu tun, die schon längst inoffizielle Realität sind und dennoch als subversiv gelten – so zum Beispiel die Ignoranz der „Lehmschicht“ im mittleren Management, die sich darin zeigt, dass nicht alles, was „von oben“ kommt, direkt auf die operative Ebene durchgereicht wird, und die damit letztlich den Laden vor Überforderung schützt. Agile Ansätze (vor allem Scrum mit seinem Product Backlog) erfordern einen kontinuierlichen Diskurs über organisationale Prioritäten und nur jene Aufgaben, die ganz oben auf der Prioritätenliste stehen, werden im Rahmen der monetären, zeitlichen und kapazitiven Möglichkeiten umgesetzt. Alle anderen Aufgaben werden erlaubterweise ignoriert.
Ein stetig wachsender Teil der Unternehmen erlebt ihr Umfeld als sehr wettbewerbsintensiv; geprägt von schnellen und zahlreichen technologischen Entwicklungen, wenig vorhersehbaren Änderungen der Rahmenbedingungen sowie durch sich schnell und abrupt ändernde Kundenpräferenzen. Auf der Suche nach Lösungen für diese Ausgangslage stößt man nun immer häufiger auf die Agilität. Dabei wird sie in der allgemeinen Hast oft unzureichend durchdrungen und nicht selten gleichgesetzt mit Schnelligkeit, Dynamik (von was genau wird meist nicht klar) und Tatkraft. So beobachten wir heute, wie sich Unternehmen extrem ambitionierte Ziele stecken, zeitgleich Investoren-, Effizienz- und Innovationsziele verfolgen und dabei weiter an der Geschwindigkeitsschraube drehen. In zahlreichen Firmen hat die Geschwindigkeit auf der Beschlussebene inzwischen die Geschwindigkeit auf der Umsetzungsebene überholt. Das daraus folgende Credo: „Dann müssen wir eben agiler werden!“
Agil zu werden bedeutet, diese Fähigkeiten und Kompetenzen bei allen Führungskräften und Mitarbeitern zu kultivieren – und nicht ausschließlich an der Unternehmensspitze. Dies setzt zuweilen einen großen Mind Shift voraus. So ist beispielsweise kaum vorstellbar, dass eine wenig ausgeprägte und auf Kontrolle setzende Organisationskultur einen guten Rahmen für die Einführung von Scrum darstellt – setzt Scrum doch darauf, das Paradoxon von Begrenzung und Freiheit durch stringente Priorisierung und Selbstorganisation aufzulösen. Auch wird es nicht damit getan sein, Führungskräften agiles Handwerkszeug, verbunden mit einem starken Appell zu mehr Agilität, an die Hand zu geben und gleichzeitig bestehende Zielvereinbarungs-, Budget- und Kommunikationsprozesse völlig unverändert zu lassen.
Ist man aber in der (glücklichen) Lage, Teil eines Unternehmens zu sein, in dem all diese Aspekte gedacht, gemeinsam verhandelt und fortgeschrieben werden dürfen, dann steht einer Bewegung hin zu mehr Agilität nichts im Wege; ja, womöglich hat sie dann bereits begonnen.
