Unternehmen trennen sich vermehrt vom agilen Gedanken. Die Methoden sind zu Nebenrollen ‚mutiert‘.
Die agilen Rollen befinden sich in einer echt prekären Lage. Warum? Wenn Wertschöpfung gefordert ist, wo ist die dann in diesen Rollen enthalten? Sind das nur noch Nischenrollen?
Wie Sie sicher wissen, haben sich die Unternehmen von dem getrennt, was sie jetzt als Nischenrollen wahrnehmen, die nicht direkt mit dem Gewinn verbunden sind. Dazu gehören Product Owner, Scrum Master, Agile Coaches, interne Berater, Projektmanager, Programmmanager sowie UX-, Marketing-, Kommunikations- und HR-Rollen. Die agilen Rollen, so werde ich hier argumentieren, befinden sich in einer besonders prekären Lage. Agile selbst befindet sich seit langem in einer Zwickmühle. Hier werden wir die beiden meiner Meinung nach größten Probleme erörtern.
Warum Agile an Schwung verliert
So ist es und vielleicht haben Sie es schon bemerkt: Viele Unternehmen trennen sich zunehmend von Rollen, die sie mittlerweile als Randerscheinungen betrachten – Positionen, die nicht unmittelbar zum Gewinn beitragen. Die direkte Wertschöpfung tritt deutlicher in den Vordergrund. Zu den Rollen zählen Product Owner, Scrum Master, Agile Coaches, interne Berater, Projekt- und Programmmanager sowie Fachkräfte aus den Bereichen UX, Marketing, Kommunikation und HR. Besonders die agilen Rollen stehen, wie ich es seit über einem Jahr wahrnehme, auf wackligem (bis keinem) Boden (mehr). Agile selbst steckt seit geraumer Zeit in einem Dilemma. Lassen Sie uns die zwei zentralen Probleme betrachten, die meiner Meinung nach am meisten ins Gewicht fallen. Spoler: Ja, es gibt dafür eine Lösung.
Die politische Naivität von Agile
Agile Teams neigen dazu, einen Fehler zu begehen, den ich als „Tailism“ bezeichne – das Gegenteil des top-down gesteuerten „Commandism“. Um diesen Ansatz zu rechtfertigen, wird oft das Cynefin-Modell überstrapaziert: Mit großen Gesten wird dann alles als „komplex“ deklariert, wodurch Vorabplanung und gründliche Kontextanalyse als überflüssige Zeitverschwendung abgetan werden. Erläuterung:
Tailism → Nach- bzw. hinterherlaufen
„Fragen, was die Leute wollen, und es direkt umsetzen, ohne Untersuchung, ohne tieferliegende Probleme zu erforschen und ohne dabei zu helfen, die Annahmen zu verbessern.“
Investigation → Untersuchung, Forschung
„Kontinuierlicher Erkenntnisprozess, der jeder konkreten Entscheidung vorausgeht, dabei Ideen hervorbringt, Ziele optimiert, Annahmen prüft und hilft, das Denken neu auszurichten.“
Commandism → Anordnen, Durchsetzen
„Durchsetzen einer Richtung per Managementanweisung, ohne diese auf Erkenntnisse oder demokratische Prozesse zu stützen und Forschung überwiegend für Marketingzwecke zu nutzen.“
Stattdessen heißt es: Einfach loslegen! Das System anstoßen, beobachten, was passiert, und dann „iterativ“ darauf reagieren. Klingt plausibel, oder? Doch hier liegt ein Haken: Begriffe wie „Iteration“ bleiben oft schwammig und undefiniert. Selbst die Mitautoren des Agilen Manifests sind sich nicht einig, was genau damit gemeint ist. Noch entscheidender ist, dass Agile und UX den Begriff „Iteration“ völlig unterschiedlich auslegen.
Eine treffende Analogie bietet das Schachspiel (siehe Titelbild): Wer Züge macht, nur um die Reaktion des Gegners zu testen, verliert „Tempo“ und strategischen Vorteil. Zu viele unüberlegte Schritte führen schnell in den Zugzwang – eine Lage, in der jeder weitere Zug die Situation nur verschlimmert. Sie habenzuviele Züge verbrannt – und auf Asche (wie Sand) lässt sich schlecht laufen. Auch nicht rennen.
Im agilen Kontext bedeutet das: Die Geduld der Nutzer ist begrenzt. Wenn zu viele Versuche vergeudet werden, verlieren sie das Interesse – und mit ihnen die Chance, wirklich etwas zu bewegen. Die Lehre aus dem Zugzwang ist klar: Iteration ohne Rücksicht auf begrenzte Möglichkeiten führt irgendwann zu schlechten Entscheidungen. Ein zielloses Stolpern ist kein Ersatz für fundierte Recherche – und die erhoffte Wertschöpfung bleibt auf der Strecke.
Hinzu kommt, dass Agile oft in die Falle des „Verankerns und Anpassens“ tappt. Die erste Lösungsidee – egal welche – prägt den Rahmen, der sich in den Hirnen festsetzt (Framing), in dem alle weiteren Iterationen gefangen bleiben. Warum? Agilisten betonen gerne, dass Code leichter zu ändern sei als ein Gebäude. Doch dabei wird die politische Realität der Arbeit ignoriert. Wie Jeffrey Pfeffer treffend bemerkt: Ist etwas erst einmal umgesetzt, wird es schwierig, den Kurs zu ändern. Die Kosten und der Nutzen sind dann real, nicht mehr hypothetisch, und eine erneute Überarbeitung erfordert politischen Willen (und schon wieder (noch) nicht verdientes Geld), der oft fehlt.
Dazu kommt, dass dann hier noch verstärkend eine Wahrnehmungsverzerrung hinzukommt. Der Effekt heisst „sunk cost fallacy“ – können Sie ja mal gerne googeln (oder eine KI befragen).
UX-Experten haben vergeblich versucht, Agile darauf hinzuweisen:
- Es geht darum, Ergebnisse zu schaffen, die sowohl Nutzern als auch Unternehmen zugutekommen.
- Solche Ergebnisse entstehen durch kluge Designentscheidungen.
- Diese Entscheidungen werden meist weit über der Ebene der Produktteams getroffen.
- Design und Einflussnahme sind daher zwangsläufig politisch geprägt.
Agile Antwort? Spott, eine Verdopplung des „Tailism“-Fehlers und die stur wiederholte Überzeugung, dass „mehr Software“ immer die Lösung sei. Ist sie nicht. Damit hat sich Agile selbst geschadet. Indem es die politische Dimension (des Unternehmens) ausblendete, öffnete es eine strategische Lücke, die UX-Experten verzweifelt mit einem Wechsel in Produktmanagement-Rollen zu füllen versuchten. Doch als Agile- und PM-Rollen an Ansehen verloren, litt auch die UX-Arbeit, die ohnehin selten hoch genug in der Hierarchie verankert war, um wirklich wirksam zu sein.
Es sollten reale Werte, die dem Kunden dienen, geschaffen werden.
Auch bei der Definition von „Wert“ hat Agile versagt. UX-Profis wissen: Was Nutzer als „wertvoll“ bezeichnen, sagt wenig darüber aus, ob sie ein Produkt später tatsächlich nutzen. Agile verfängt sich hier in der gleichen Sackgasse wie Fokusgruppen – die geäußerten Wünsche der Nutzer sind kein verlässlicher Indikator für ihr Verhalten. Wenn Forschung eine optimale Lösung nahelegt, Nutzer aber etwas anderes fordern, baut ein typisches Agile-Team oft schnell das Geforderte – und ignoriert, dass der beste Weg oft politisches Geschick erfordert, das vielen Teams fehlt.
Kleine, feine – aber nutzlose Dekräume – ohne Fortschritt
So bleibt Agile in kleinen Denkräumen stecken. Die Frage, ob mehr Software überhaupt nötig ist, wird gar nicht erst gestellt. Strategische Forschung, um größere Ziele zu definieren? Fehlanzeige. Das agile Credo „Build-Measure-Learn“ ähnelt eher einem oberflächlichen „Build-Measure-Build“ – der „Learn“-Teil bleibt stumm. Wer jetzt einen Vergleich zum bekannten PDCA Zyklus herleiten möchte, wird es schnell merken: Dort, wo eigentlich das eigentliche Lernen stattfinden sollte, ist – nix. Warum? Lernen ist teuer, aufwändig, anstrengend und macht (nicht) immer Spass. Das kann man dann weglassen.
Überlegen Sie mal: Entscheidungen sind wie Wetten. Eine schlechte Entscheidung bleibt schlecht, selbst wenn sie zufällig Erfolg hat. Wer die Qualität von Entscheidungen ignoriert, übersieht Chancen, Risiken zu minimieren – mit teuren Konsequenzen. Wie Maxwell Maltz es beschrieb: Beim Roulette setzen Menschen erst und zittern dann ums Ergebnis, wenn nichts mehr zu ändern ist. Agile handelt oft ähnlich – anstatt die Qualität vorab zu optimieren, wird auf Iteration und Zufall gehofft. Das ist magisches Denken, kein Fortschritt.
Was Organisationen wirklich wollen
Kommen wir zum zweiten Problem: Agile Teams überprüfen selten abgeschlossene Arbeit. Stattdessen heißt es meist: „Auf und weiter zum Nächsten (Ding)!“ Wenn Iterationen stattfinden, dann oft nur, weil Einzelne eigenmächtig handeln und später um Verzeihung bitten, statt vorher um Erlaubnis zu fragen. Das liegt auch an einem typischen Ablenkungsmanöver großer Organisationen – und das sollte niemanden überraschen.
Der Spalt zwischen (agilem) Wunsch und (harter) Wirklichkeit
Unternehmen wollen keine echte Agilität, auch wenn sie es behaupten. Was sie wollen, ist Jeff Sutherlands verlockendes Versprechen: „Doppelte Arbeit in halber Zeit.“ Das kann funktionieren, aber nicht mit dem bisher oft gesehenen Verhalten der letzten 10 Jahre. Dieses gefunde Schaubild zeigt es kaum besser: Na, wo ist der Spalt?
Agile sollte ursprünglich das Leben von Entwicklern verbessern. Doch als klar wurde, dass Agilität der ganzen Organisation nutzen könnte, kam der Haken: Echte Agilität würde etablierte Machtstrukturen stören. Igitt! Sie erfordert, wie Andy Grove betonte, dass Entscheidungen auf die niedrigste verantwortungsvolle Ebene delegiert werden. Ja, wo kommen wir den da hin, wenn ich als [Chef] nichts mehr entscheiden soll?
Und genau das wollen die meisten Führungskräfte nicht. Abgeben. Delegieren (aber nur ein bischen). Sie streben danach, ihre Macht zu festigen, ihre Einflusssphären zu sichern und ihre Positionen als Sprungbrett zu nutzen. Das ist ein ganz anderes Spiel mit anderen Regeln. Daraus ergibt sich eine goldene Regel der Beratung: Kunden wollen weniger den maximalen Wert als vielmehr, dass Sie sie – den Kunden – gut aussehen lassen – und das sind oft zwei Paar Schuhe. Stellen Sie sich vor:
Der Berater: (Experte für Entscheidungsqualität:) „Ich helfe Ihnen, Ihre Entscheidungen langfristig zu verbessern.“
Die Führungskraft (Chef, bis Unternehmenslenker): „Solange niemand meine bisherigen Entscheidungen infrage stellt. Werde ich in Frage gestellt, wird das wohl nicht funktionieren.“ Jetzt denke Sie mal über potentielle Aufträge nach …
Die Realität hat das alles eingeholt, oder?
Agile zeigt hier Parallelen zu subversiven Bewegungen. Denken Sie an das frühe Christentum, das gegen Macht und Klassen antrat – bis es von den Römern vereinnahmt wurde. Ähnlich hat die traditionelle Hierarchie Agile übernommen und zu einem Werkzeug ihrer Ziele umgeformt. Am Ende steht „Geschwindigkeit“ im Vordergrund: Organisationen wollen ihre Pläne schneller und mit weniger Ressourcen umsetzen, statt echte Entscheidungsfreiheit zu fördern. Agile hat diesen Wunsch bis jetzt) nicht erfüllt – und so richtet sich die Hoffnung nun auf KI. Was abzuwarten bleibt …
Was bleibt? Agile hat Potenzial, doch seine politische Blindheit und die wahren Prioritäten von Organisationen bremsen es aus. Vielleicht lohnt es sich, innezuhalten und zu fragen: Wie können wir Agilität so gestalten, dass sie nicht nur Tempo, sondern erst Wertschöpfung und dann den echten Wandel bringt? Das ist eine Frage, die zum Nachdenken einlädt – und vielleicht den Anfang einer neuen Richtung markiert. Eine Frage bleibt hier entscheidend:
Mit allem und durch (aktuell) alles, was sich verändert: Womit kann ich am Ende des Tages meine Rechnungen bezahlen? Willkommen in der Post-Agilität, in der Wertschöpfung (wieder mal) in Vordergrund steht. Und wie das geht: Sprechen Sie mich an. Es geht und es gibt dafür Lösungen.