Zum Inhalt springen

Suchen...

Post-Agile: Was Unternehmen jetzt wirklich brauchen

„Agil“ hatte mal eine Bedeutung. Heute bedeutet es fast nichts mehr, und dieser Bedeutungsverlust hat eine echte Chance für eine Organisationsentwicklung geschaffen, die tatsächlich passt.

10 Min. Lesezeit
Cover für Post-Agile: Was Unternehmen jetzt wirklich brauchen

„Post-agile“ beschreibt die Phase und Denkweise, die auf den Zeitpunkt folgt, an dem „agil“ seine einheitliche Bedeutung verlor und zu vage wurde, um Unternehmen als Leitfaden zu dienen. Das ursprüngliche agile Manifest galt nur für Softwareentwicklungsteams, nicht für ganze Unternehmen. Was heute funktioniert, ist eine auf die jeweilige Entwicklungsphase des Unternehmens zugeschnittene Organisationsentwicklung, die sich gezielt auf schnelle Iterationen, echtes Kundenfeedback und bewährte Entscheidungsmodelle stützt.

Das Wichtigste in Kürze

  • Das agile Manifest ist ein Manifest ausschließlich für agile Softwareentwicklung, nicht für agiles Management oder organisatorische Führung – dennoch wenden Unternehmen es so an, als würde es all das abdecken.
  • Die Anwendung eines starren Frameworks wie SAFe drängt Unternehmen in der Differenzierungsphase noch tiefer in starre Rollenstrukturen, anstatt ihnen bei der Anpassung zu helfen, da es organisatorische Blaupausen kopiert, anstatt passende Lösungen zu entwickeln.
  • Schnelle Iterationen und echtes Kundenfeedback sind Praktiken aus der agilen Ära, die nach wie vor wertvoll sind, aber die meisten Organisationen, die behaupten, agil zu arbeiten, sammeln kein echtes Feedback mehr, weil sie die Einführung verzögern.
  • Eine Auseinandersetzung mit dem Management über Fehlfunktionen löst automatisch eine Abwehrhaltung aus, und je mehr eine Position verteidigt wird, desto mehr glaubt der Verteidiger daran, was direkte Argumente kontraproduktiv macht.

Warum „Agile ist tot“ zum Schlagwort der Stunde wurde

„Agile ist tot“ wurde um das Jahr 2024 herum zum geflügelten Wort, und der Grund dafür ist struktureller Natur, nicht modischer. Das Wort hat seine Unterscheidungskraft verloren.

Michael Mahlberg vergleicht das Schicksal von „agil“ mit dem Wort „modern“. Es gab eine Zeit, in der „modern“ auf bestimmte Maler und bestimmte Architekten hinwies. Wenn du heute sagst, du hättest ein modernes Haus, fragen die Leute nach deiner Hausautomation und nicht danach, ob Mies van der Rohe es entworfen hat. „Agil“ ist denselben Weg gegangen. Es bedeutet mittlerweile kaum mehr als „neu“.

Für große Unternehmenskunden ist der Begriff mehr als nur leer geworden. Er schadet sogar aktiv. In Unternehmen mit mehreren tausend Mitarbeitern belastet „agil“ die Mitarbeiter und macht sie unglücklich – daher ist es ein Wort, das man vermeiden sollte. Aus dieser Perspektive begrüßt Michael das Ende des Begriffs.

Der „Agile Industrial Complex“ hat die Idee aus der Bahn geworfen

Marktkräfte, nicht böse Absicht, haben „Agile“ ausgehöhlt. Michael verweist auf Martin Fowlers frühere Beobachtung, dass ein „Agile Industrial Complex“ versucht habe, die Idee zu vereinnahmen, und dass diese Vereinnahmung stattfand, ohne dass jemand beschlossen hätte, irgendetwas zu untergraben.

Viele Beratungsfirmen haben sich aus diesem Bereich zurückgezogen. Große Unternehmen gaben ihren agilen Mitarbeitern Raum, ihre Karriere anderswo fortzusetzen. In den Vereinigten Staaten gab es eine Entlassungswelle, die inzwischen auch Europa erreicht hat.

Der Schaden entstand durch Überambitioniertheit. Unternehmen packten alles unter den agilen Dachbegriff: Design Thinking, Retrospektiven, Sprints, Planung – alles auf einmal. Die Leute waren am Ende überfordert und frustriert, und der Dachbegriff verlor jeglichen Halt auf das, was er eigentlich umfassen sollte.

Es gibt kein agiles Manifest, sondern nur eines für die Softwareentwicklung

Ein Punkt, der viele Leute irritiert: Es gibt kein agiles Manifest. Was es gibt, ist das Manifest für agile Softwareentwicklung.

Es ist kein Manifest für agiles Management. Es ist kein Manifest für die Führung eines Unternehmens. Es sagt fast nichts über den organisatorischen Rahmen aus, wird aber dennoch so weit gedehnt, dass es alles abdeckt. Mit dieser Ausweitung fangen die Probleme erst an.

Zum Thema Verbesserung enthält das Manifest einen einzigen Satz. Das zwölfte Prinzip besagt, dass das Team in regelmäßigen Abständen darüber nachdenkt, wie es seine Effektivität steigern kann, und sich entsprechend anpasst. Das funktioniert bei einem Team aus fünf oder sieben Leuten. Für eine Organisation mit Tausenden von Mitarbeitern ist das eine sehr dürftige Anleitung.

Was „Post-Agile“ eigentlich bedeutet

„Post-Agile“ ist keine neue Methode. Es ist ein Zeitpunkt, und zwei Personen haben dem Begriff Gewicht verliehen.

David J. Anderson, bekannt für die Kanban-Methode, verwendete ihn bereits 2010. Seine Argumentation ist logisch: Die Autoren des agilen Manifests beschrieben ihre Beobachtungen zu einem bestimmten Zeitpunkt. Alles, was danach kam, konnte das agile Manifest nicht beeinflussen – es ist also per Definition „Post-Agile“.

Alistair Cockburn, einer der Unterzeichner und derjenige, der die Teilnehmer zur Konferenz einlud, auf der das agile Manifest verfasst wurde, hat den Begriff ebenfalls verwendet. Die Linie, die er zieht, verläuft von modern über postmodern bis hin zu post-agil, da das ursprüngliche Wort keine Bedeutung mehr hat.

Was an seine Stelle tritt, ist weniger markenbezogen und anspruchsvoller: Organisationsentwicklung und Lösungen, die auf ein bestimmtes Unternehmen zugeschnitten sind, statt eines von der Stange gekauften Plakats.

Warum Agilität mit der Struktur großer Unternehmen kollidiert

Große Organisationen befinden sich in einer Entwicklungsphase, in der es vor allem auf strenge Strukturen ankommt – und Agilität passt da nicht hinein. Das Modell stammt von Friedrich Glasl, der drei Phasen beschrieb, die ein Unternehmen durchläuft: eine Pionierphase, eine Differenzierungsphase und eine Integrationsphase.

Man kann keine Phase überspringen. Jede Phase bereitet die nächste vor. Es gibt keine Differenzierungsphase ohne eine vorangegangene Pionierphase.

Die meisten großen Unternehmen stecken in der Differenzierungsphase fest. Rollen sind genau definiert, es gibt Anleitungen für alles, und wer was macht, ist klar festgelegt. Diese Klarheit ist das Gegenteil davon, wie agile Teams eigentlich arbeiten sollen.

Das erklärt, warum skalierte Frameworks in Konzernen so leicht Fuß fassen. Wenn man einem Unternehmen mit mehreren tausend Mitarbeitern ein großes Framework-Poster zeigt, fügt es sich nahtlos in ihre Welt ein, weil es sie noch tiefer in die Differenzierungsphase drängt, in der alles genau festgelegt ist. Die Passform stimmt zwar, aber sie zieht in die falsche Richtung.

Kopier-und-Einfüge-Blaupausen transformieren keine Organisationen

Ein Framework-Poster sieht nach einer schnellen Lösung aus. Du bezahlst dafür und scheinst die Antwort zu besitzen. Das ist die Falle.

Jedes einzelne Element eines skalierten Frameworks kann für sich genommen sinnvoll sein. Das Problem ist der Schritt, den gesamten Bauplan zu übernehmen und zu verkünden: „Das ist euer Unternehmen, nehmt es.“ Kopieren und Einfügen schafft keine funktionierende Organisation, und der schlechte Ruf, den „Agile“ in den letzten Jahren erworben hat, ist direkt aus dieser Gewohnheit entstanden.

Die Alternative ist schwieriger. Sie bedeutet, Methoden der Organisationsentwicklung anzuwenden und herauszufinden, was zu einem bestimmten Unternehmen passt. Ein Teil dessen, was die Branche in den letzten 25 Jahren gelernt hat, gehört in dieses Bild, aber als Material, aus dem man schöpfen kann, nicht als Ausgangsvorlage.

Stütze dich nicht auf einen einzigen Satz aus dem Manifest, wenn es ein ganzes Wissensspektrum gibt

Wenn du die Funktionsweise einer Organisation verbessern willst, gibt es weit mehr, worauf du zurückgreifen kannst, als nur das eine Prinzip des Manifests zur Reflexion.

Peter Senges Die fünfte Disziplin beschreibt lernende Organisationen. Lean, im Sinne des ursprünglichen Toyota-Produktionssystems, wie es Taiichi Ohno vorgeschlagen hat, liefert eine umfassende Darstellung, wie man iterativ verbessert, während die Arbeit läuft. Michael zieht hier bewusst eine Grenze: das ursprüngliche TPS, nicht die spätere Interpretation von Womack und Jones.

Der Punkt ist einfach: Ein einziger Satz über Reflexion ist eine schwache Grundlage, wenn die Verfügbarkeit einer ganzen Literatur zum Thema kontinuierliche Verbesserung hoch ist.

Wie man eine festgefahrene Organisation wieder funktionsfähig macht

Beginne damit, einen großen Schritt zurückzutreten – und stelle sicher, dass nicht nur die Unternehmensleitung diesen Schritt macht. In einem hierarchischen Unternehmen sind die Kernprozesse sehr ungleichmäßig über die Ebenen verteilt. Einer davon ist der Prozess, durch den sich eine Organisation ein Bild von sich selbst macht. Eine Neuausrichtung erfordert, dass dieser Prozess alle einbezieht, auch wenn die Unternehmensleitung ihn initiieren muss.

Diese Arbeit kostet Zeit, keine Beraterhonorare. Die Berater tun meist nicht viel. Was die Menschen brauchen, ist Freiraum – sowohl zeitlich als auch räumlich –, um ehrlich über die Situation zu sprechen und sich neu auszurichten.

Das größere Hindernis ist die Ermüdung. Organisationen, die zehn oder zwanzig Jahre damit verbracht haben, auf Agilität umzustellen, müssen nun zugeben, dass dies nicht der richtige Weg war, und erneut die Richtung ändern. Die Menschen sind des Wandels müde, und es ist nicht einfach, von ihnen zu verlangen, noch einmal umzuschwenken.

Warum sich die meisten Unternehmen noch nicht ändern werden

Veränderung beginnt mit einem echten Gefühl der Dringlichkeit, und das fehlt den meisten Unternehmen. Michael stützt sich hier auf Kotters Acht-Stufen-Modell für Veränderungen, bei dem Dringlichkeit an erster Stelle steht.

Die Dringlichkeit muss echt sein. Jemanden unter Wasser zu drücken, erzeugt zwar ein Gefühl der Dringlichkeit, aber es ist nur ein Spiel. Fünf Meilen vor der Küste ohne Boot zu sein, ist echte Dringlichkeit. Ein Gefühl der Gefahr zu erzeugen, das gar nicht existiert, bringt eine Organisation nicht in Bewegung.

Viele Unternehmen fühlen sich einfach zu wohl. Sie verdienen immer noch gut, die Maschine läuft, und eine bestimmte Anzahl von Burnouts pro Jahr wird als normal angesehen. Ohne spürbares Bedürfnis gibt es keine Veränderung.

Michaels eigenes Unternehmen richtet seine Arbeit genau darauf aus: Organisationen dabei zu helfen, nach einer agilen Transformation wieder arbeitsfähig zu sein. Nach seiner groben Einschätzung spüren nur etwa zehn Prozent der Unternehmen diesen Bedarf akut. Bei einem weiteren Drittel leiden zwar Menschen, doch das Leid ist im System noch nicht angekommen. Und vielerorts funktioniert das, was nur dem Namen nach „agil“ ist, ganz gut – warum also daran rütteln?

Die Unternehmen, die wirklich mit den Folgen der „agilen“ Umstellung zu kämpfen haben, haben eine Chance. Sie wollen die ausgereizte Terminologie nicht mehr, was ihnen den Freiraum gibt, herauszufinden, was sie tatsächlich brauchen.

Wie eine einzelne Person das Thema nach oben bringen kann

Wenn du als Tester, Entwickler oder Architekt das Problem erkennst, wird es nicht funktionieren, dich in der Hierarchie nach oben durchzusetzen. Lass die Führungskräfte stattdessen selbst erleben, was du erlebst.

In dem Moment, in dem du einem Manager sagst: „Das ist schlecht und funktioniert bei uns nicht“, setzt ein Reflex ein. Sie gehen in die Defensive. Und wenn jemand eine Position oft genug verteidigt hat, fängt er an, an seine eigene Verteidigung zu glauben – was es nur noch schwieriger macht, diese Position zu ändern.

Wenn du einen Standpunkt oft genug verteidigt hast, fängst du an, an die Verteidigung zu glauben. — Michael Mahlberg

Beziehe sie stattdessen in deine Situation mit ein. Bitte um Hilfe bei den Dingen, die nicht funktionieren. Wenn sie anfangen, es nachzuempfinden, kannst du kleine Informationshäppchen einstreuen: Aufgabenbelastung, Aufgabenwechsel, die Kluft zwischen dem definierten Prozess und dem, was das Team tatsächlich tut. Schau von da an über agile Ressourcen hinaus in Richtung Organisationsentwicklung, insbesondere in Richtung systemischer und systemtheoretischer Inhalte. Die Anhaltspunkte sind da.

Welche agilen Praktiken haben sich noch bewährt

Einige Praktiken bewähren sich fast überall, und die offensichtlichste ist die schnelle Iteration mit echtem Feedback. Viele Organisationen, die sich als agil bezeichnen, haben den „echten“ Teil aus den Augen verloren. Sie bauen Iteration auf Iteration auf und veröffentlichen erst nach einer längeren Zeitspanne, die selten die kürzestmögliche Zeit darstellt. Ohne Auslieferung an den Kunden ist das Feedback nicht echt.

Andere Elemente des ursprünglichen agilen Manifests sind für Teams nach wie vor nützlich, obwohl sie nie als Anweisungen für die Führung einer Organisation gedacht waren.

Bei organisatorischen Fragen liegen die besseren Antworten oft ganz außerhalb der agilen Welt. Wenn du einen soliden Weg suchst, Entscheidungen zu treffen, schau dir Soziokratie an, aber übernehme nur die Teile zur Entscheidungsfindung, anstatt das Ganze zu übernehmen. Diese Praxis ist mehr als ein Jahrhundert älter als Agilität.

Was skalierte Frameworks richtig machen – und wo die Falle lauert

Skalierte Frameworks enthalten wirklich gute Ideen, und die Menschen dahinter verstehen es, starkes Material auszuwählen. Release-Trains machen Sinn, wenn du Software in einer bestimmten Art von Umgebung entwickelst. Portfolio-Kanban ist eine der besseren Methoden, um die Arbeitslast in einem riesigen Unternehmen in den Griff zu bekommen.

Es gibt da eine Ironie, die den Kreis schließt und die man kennen sollte. Die Konferenz, auf der das Manifest entstand, hieß „Konferenz über leichtgewichtige Methoden“, und ein erklärtes Ziel war es, RUP-Begeisterten – den Anwendern des Rational Unified Process – überzeugende Gründe für einen Wechsel zu liefern. Dean Leffingwell hat Teile des RUP-Buches mitverfasst. Dean Leffingwell ist auch der Mann hinter SAFe.

Die Marke, die heute als „agil“ vermarktet wird, ist also stark von derselben Person geprägt, die einst genau den sehr schwerfälligen Prozess beworben hat, gegen den sich das agile Manifest richtete. Die einzelnen Teile können gut sein. Das Problem ist die Verpackung.

Der folgende Ratschlag ist praxisorientiert. Wenn du Portfolio-Kanban willst, kannst du es aus einem Framework übernehmen oder dir Klaus Leopolds „Flight-Levels“-Modell ansehen, das möglicherweise eine passendere Lösung bietet. Was den Teil von SAFe mit den festgelegten Rollen angeht, hat Michael bisher noch kein Unternehmen gesehen, das diesen wirklich hilfreich fand.

Diese Seite teilen