Is Agile dead?

Seit einiger Zeit wird auf Social Media die Frage diskutiert: «Is Agile dead?» Keine Ahnung, wo das seinen Anfang nahm, aber das Thema läuft seit etwa vier Jahren, seit 2023 intensiver mit Steigerung im Jahr 2024.

Dieselbe Frage wird bezogen auf Design Thinking diskutiert. Die Methodenkrise wurde u.a. deutlich, als die Design- und Innovationsberatung IDEO, welche die Methode begründet hat, im Jahr 2023 ein Drittel ihrer Belegschaft entlassen hat.

Insgesamt dreht sich der Diskurs darum, ob der Einsatz agiler Methoden in Projektmanagement und Organisationsentwicklung als Trend zu Ende ist.

Es ist über zwanzig Jahre her, dass eine Gruppe von Software-Entwicklern das agile Manifest (2001) publiziert hat. Wir hatten Zeit, Erfahrungen mit Agile zu sammeln. Die apodiktische Behauptung, dass Agile tot sei, sagt offenkundig weniger über den Wert agiler Methoden als über die Tücken einer naiven Umsetzung.

Erst vor rund zehn Jahren hat sich in IT-Organisationen unter dem Begriff Devops die enge Zusammenarbeit von Entwicklung und Betrieb etabliert. Ich kann mich noch gut an das Erscheinen des Buches «Projekt Phoenix» erinnern, das den Wechsel von Wasserfallprojekten zu agilem Projektmanagement beschreibt. Das ist heute Standard.

Teams erarbeiten sehr viel häufiger als früher in bereichsübergreifender Zusammenarbeit und in kurzen Iterationen, was tatsächlich gebraucht wird. Sie nähern sich ohne übertriebenen Perfektionismus, schrittweise und unter Einbindung der internen oder externen Kunden dem Produkt. Qualitätssicherung ist kein abschliessender Arbeitsschritt mehr, der ein Go-live absichert, sondern findet kontinuierlich gemeinsam mit Anwendern im Austausch über ihre Anforderungen statt. Projekte, die in die falsche Richtung laufen, werden beendet oder neu ausgerichtet.

Für das Nein auf die Frage: «Is Agile dead?» gibt es viele Gründe, die alle, die viel in Projekten arbeiten, längst gut kennen:

• Kundenorientierung als oberste Priorität
• Interdisziplinäre Teams
• Iterativ und inkrementell
• Ideation, Co-creation, Prototyping
• Kurze Info-Meetings in hoher Frequenz (Daily, Weekly, Retro-Meetings, etc.)
• Viel persönliche Kommunikation (face-to-face)
• Lieber schnell als spät scheitern (Fail fast)
• Zügiges Vorankommen (Sprints)
• Selbstorganisation statt Hierarchie

Es ist uninteressant, Antworten auf die Frage zu suchen, ob Agile am Ende ist. Ist es nicht. Viel interessanter ist es, die Tücken der Implementierung und die Erfahrungen damit zu beleuchten.

Beliebt ist die Unterscheidung zwischen «doing agile» und «being agile» und ja: Es macht Sinn, die mechanische Anwendung agiler Arbeitsformen von Einstellungen zu unterscheiden, die sinnvolle Arbeitsweisen in der Zusammenarbeit nach sich ziehen.

Gleichzeitig gehen bei mir aber auch ein Alarmlämpli an, wenn ich lese, dass es eben auf das richtige Mindset ankäme. Es scheint mir zu einfach, ein Scheitern von Agile durch einen unterlassenen Kulturwandel zu erklären. Weil Organisationen sich nicht über die Kultur ändern, sondern die Kultur von der Organisation erzeugt wird.

Auch mag ich es nicht, wenn die Frustration über misslingende Umsetzung mit dem Gefühl intellektueller Überlegenheit verbunden wird, so nach dem Motto: ihr habt Agile leider eben nicht in seiner vollen Schönheit verstanden, darum habt ihr es nicht geschafft.

Stattdessen ist meine Arbeitshypothese, dass Fundamental-Agilisten selbst etwas nicht verstanden bzw. ausreichend berücksichtigt haben, nämlich wie ihre Methoden anschlussfähig an die Gegebenheiten und die Logik einer Organisation gemacht werden können.

Denn in jeder Organisation gibt es immer gute Gründe für einen eingeschwungenen Zustand, selbst wenn der hochgradig dysfunktional ist. Deshalb kann der konsequente Wechsel auf Agile für die Umsetzenden teilweise unvernünftig sein bzw. zu viele Schritte entfernt vom Stand der Dinge. Drum findet dieser Wechsel dann auch nicht statt und Agile kann seine Wirksamkeit nicht entfalten.

In den letzten Jahren habe ich einige Organisationen bei der Einführung agiler Methoden und der Umstellung auf Selbstorganisation begleiten dürfen. Dabei habe ich ebenso die Sinnhaftigkeit, aber auch Schwierigkeiten in der Anwendung erlebt.

Persönlich halte ich viel vom kreativen und fallspezifischen Einsatz agiler Methoden, korrekt in der Anwendung und flexibel im Kontext.

Dabei helfen die folgenden Umsetzungsprinzipien:

Wichtig ist, die Anschlussfähigkeit selbstorganisierter Bereiche an den Rest der Organisation sicherzustellen. Das betrifft vor allem HR-Themen wie z.B. den Abgleich von Teamzielen hier und individuellen Zielvereinbarungen dort. Agilität in gewissen Bereichen oder Themen muss vereinbar sein mit Rollen, Karrierewegen und Gehaltsstufen in der Gesamtorganisation. Die Anschlussfähigkeit ist vor allem im Verständnis von Führung und Zusammenarbeit unerlässlich.

Wenn Change-Management als Projektkommunikation verstanden wird, ist das altmodisch und vor allem wirkungslos. Ausreichend Information, ein paar Workshops, Dialogformate und die Vorstellung, dass Veränderung vor allem Überzeugungsarbeit ist – der Effekt ist oft gering.

Agile Methoden funktionieren komplett anders. Mitarbeitende werden systematisch befähigt, sich einzubringen, so dass Veränderungsdynamik aus der Breite der Organisation entsteht.

Gleichwohl: Die Wahl der Mittel muss vom Ziel abhängen und das Ziel muss den Ursachen für organisationale Schieflagen entgegenwirken.

Mehrmals habe ich schon beobachten können, dass Teams in die Selbstorganisation entlassen werden, wenn es an Führung fehlt. Unter Führung verstehe ich die Aufgabe, den Rahmen dafür zu schaffen, dass eine Organisation kontinuierlich ihren Daseinszweck und damit ihre Zukunftsfähigkeit absichert. Führung muss spürbare Impulse setzen, Richtung geben und Prioritäten verfolgen.

Selbstorganisation kann ein strategischer Entscheid sein. Niemals darf sie mit dem Verschwinden von Führung verbunden sein und stattdessen eine Illusion von Basisdemokratie und konfliktfreier Konsensbildung zulassen.

So trivial es klingt, so selten findet es statt: dass Instrumente und Methoden in der Transformation nach Ziel und Effekt geplant werden statt nach als Aktivitätenplan, den man umsetzt, ohne die Wirksamkeit zu überprüfen. Das gilt auch für agile Methoden.

Die allermeisten Veränderungsvorhaben brauchen eine massgeschneiderte Change-Architektur, die selektiv jene Instrumente, Methoden und Tools zusammenbringt, die im spezifischen Fall zielführend sind. Das umfasst oft auch, aber nicht ausschliesslich agile Methoden.

Für viele Organisationen ist es problematisch, eine agiles, iteratives Prototyping mit hohem Zeitdruck und limitierten finanziellen Mitteln zusammenzubringen. Sie erleben, dass viel diskutiert wird, das Budget mit jeder Woche zusammenschmilzt und die Ergebnisse hinter den Anforderungen zurückbleiben. Das hängt auch mit der vermeintlichen Unvereinbarkeit von agilen Methoden und Meilensteinplanung zusammen.

Ich denke an eine Fachhochschule, die einen neuen Masterstudiengang mit Studierenden und allen Fachbereichen in einem iterativen, inkrementellen Design-Thinking-Prozess entwickeln wollte. Wenige Wochen vor Publikation der Kursangebote für das kommende Jahr gab es noch keine Klarheit über die Grundstruktur des Curriculums. Schlecht, denn es ging ja nicht primär um den Kreativprozess, sondern im ersten Schritt um ein Ergebnis, das attraktiv genug ist, genügend Anmeldungen zu generieren.

Es ist eine zentrale Anforderung an Projektmanagement, dass Timing und Budgeteinsatz planbar und monitoringfähig sein müssen. In der agilen Welt sind diese Stellschrauben keinesfalls old-fashioned, sondern müssen als KPI der Selbstregulation im Team omnipräsent sein.

Obwohl Feedback seit ewigen Zeiten Gegenstand von Personalentwicklung ist, sind viele Organisationen nicht gut darin. Oft wird Feedback mit Kritik verwechselt, und Kritik in der Sache wird mit Kritik an der Person durcheinandergebracht. Nicht nur in selbstorganisierten Teams, aber gerade in diesen, ist nichts möglich ohne eine gut entwickelte Feedback-Kultur. Einfach weil man über Abweichungen vom gemeinsam vereinbarten Kurs sprechen können muss.

Es scheint banal, aber es ist oft sehr anspruchsvoll, einfache Feedbackregeln zu etablieren. Meine Erfahrung ist, dass es wichtig ist, Feedback praktisch zu üben und auch Transparenz über Missverständnisse zum vermeintlich konfliktfreien Miteinander herzustellen.

Oder anders: keine Methodenreiterei. Mittlerweile haben sich die meisten Teams von wöchentlichen Teamsitzungen verabschiedet und sind zu Daily-, Weekly- und Retro-Meetings gewechselt. Viele Mitarbeitende erleben, dass solche Meetings genauso langweilig und ebenso unproduktiv sein können wie die früheren Teamsitzungen.

Wenn ein Kanban-Board als To-Do-Liste geführt wird und niemand analysiert, an welchen Stellen im Arbeitsprozess welcher Sand im Getriebe ist und warum, dann ist nichts gewonnen.

Wenn im Daily alle nur schematisch die vorgegebenen Fragen abarbeiten, ohne dass übergreifende Blockaden und Erfolgsfaktoren herausgearbeitet werden, ist auch nicht viel erreicht.

Kurzum: Alle agilen Arbeitsmethoden ebenso wie die wunderbaren Visualisierungstechniken dazu entfalten erst dann ihren Nutzen, wenn das Wozu der Anwendung reflektiert und beantwortet wird. Dasselbe galt und gilt für alle anderen Methoden, Instrumente und Tools, die in Change-Projekten zum Einsatz kommen. Sind sie nur Selbstzweck, bringen sie nichts.

Schon vor Jahren sprach ein Berater-Kollege gern von «rollierender Planung». Würde man heute nicht mehr so sagen. Stattdessen sprechen wir von agilem Projektmanagement und meinen damit eine Prozessführung unter Nutzung auch agiler Methoden.

In meinen Projekten plane ich immer eine Steuerungsdimension ein, mit festen Terminen und klaren Meeting-Strukturen, idealerweise unter Einbezug der Kundensicht, z.B. über ein Advisory-Board. Weil es in Projekten immer anders kommt als man anfangs dachte. Dafür braucht es Früherkennungsmechanismen, Flexibilität, Steuerungsentscheide und ein Fortschritts-Monitoring. Es kommt dabei nicht auf agile Meeting-Formate an, sondern Agilität als Prinzip der Verlaufssteuerung.

Ich verberge nicht, dass mir der auf Social Media geführte Diskurs «Is Agile dead?» gefällt. In meiner Wahrnehmung war es an der Zeit, dass der inflationäre Gebrauch von Buzzwords kritisch hinterfragt wird. Ebenso: dass die Frage nach konkreten Umsetzungserfolgen und Beweisen für die Richtigkeit des Vorgehens nachdrücklich gestellt wird.

Warum mich das freut? Auch weil es mit meiner eigenen Expertise zusammenhängt.

Um es klar zu sagen: Ich finde es gut, dass das Wissen über Change und auch die Moderationskompetenz für typische Workshop-Formate von Unternehmen internalisiert wird. Für grössere Organisationen macht es Sinn, Ressourcen aufzubauen, die z.B. wissen, wie Design-Thinking funktioniert und welche Tools in welchem Schritt eingesetzt werden können.

Gleiches gilt für viele andere Methoden, die Unternehmen internalisieren. Es gibt jede Menge Weiterbildungen und jede Menge Templates zum Download, und so kann eigentlich jede und jeder ein User-Interview führen, eine Persona erstellen oder ein Brainstorming durchführen.

Um auch das klar und selbstbewusst zu sagen: Eine ganz andere Kompetenz ist das agile Management von Change-Architekturen, das gerade in komplexeren Projekten gefragt ist. Dafür braucht man natürlich auch eine Toolbox mit bewährten und aktuellen Instrumenten und Methoden. Vor allem aber muss man aus Erfahrung wissen, wie sich Überraschungen und Widerständen im Projektverlauf bewältigen lassen und Schritt für Schritt vorankommen. Das ist ein Agility-Parcours, für den es Training braucht (siehe Foto).

Entscheidend für den Erfolg bleibt, hochgradig präsent zu sein und mit konkreten Menschen im konkreten Projekt einer konkreten Organisation treffsicher und mit Fingerspitzengefühl spürbare Veränderung und greifbare Ergebnisse zu erzielen.

Das ist es, womit ich meinen Lebensunterhalt verdiene.  😊