dot.coaching - Agile is un-dead – warum das Produkt Agile sterben musste

Agilität ist nicht tot, aber das, was wir daraus gemacht haben, schon. Was einst als Haltung begann, ist zum Produkt geworden: zertifiziert, skaliert, industrialisiert. An der Agile Unconference erinnerte Dave Thomas daran, worum es ursprünglich ging und warum wir wieder lernen müssen, Fragen zu stellen, statt Rezepte zu verkaufen.

Ich war vergangene Woche an der Agile Unconference. Ein Format, das seinem Namen gerecht wird, offen, ungefiltert, manchmal unbequem. Und dieses Jahr war ein ganz besonderer Gast dabei: Dave Thomas, einer der Mitverfasser des Agile Manifesto. Er begann seine Keynote mit einem Satz, der bei mir hängen blieb:

„Agility isn’t dead. The product ‘Agile’ is dead.“

Es war still im Raum. Nicht, weil niemand etwas verstanden hätte. Sondern, weil jeder wusste, dass er recht hat.

Was mich an diesem Satz besonders beschäftigt hat, ist nicht nur seine Zuspitzung, sondern seine Präzision. Er beschreibt ein Muster, das ich seit Jahren in Organisationen beobachte und das weit über Agilität hinausgeht.

Vom Mindset zum Marktprodukt

Wenn ich in den letzten Jahren eines beobachtet habe, dann dies: Wir haben Agilität zu einem Produkt gemacht. Ein Produkt mit Zertifizierungen, Frameworks, Checklisten und Toolsets. Ein Produkt, das sich verkaufen lässt und das längst seine eigene Industrie geworden ist. Wir haben es soweit gebracht, dass es von aussen oft wie ein Religionskrieg gewirkt hat. Es ging nicht darum, einander zu verstehen, sondern, wer recht hat. Welches Framework das Richtige ist. SAFe versucht jedes Framework und Denkmodell zu integrieren - ein Synkretismus der Agilität, also eine Verschmelzung unterschiedlicher Überzeugungen zu einem neuen Glaubenssystem. Das Ergebnis: eine Methodenkirche, die mehr mit Kontrolle als mit Lernen zu tun hat.

Was einst als Einladung zum Umdenken gedacht war, wurde zu einem Dogma mit Ritualen, Rollen und Begriffen, die kaum noch jemand hinterfragt. Scrum, Kanban, SAFe, alles Methoden, die in ihrem Kern durchaus Sinn stiften können. Aber sie sind nur Werkzeuge. Und Werkzeuge sind nie das Ziel.

Ganz zu Beginn der Agilität galten Organisationen im Denken einzelner CEOs bereits als Agile, wenn es irgendwo in der Organisation ein Team gegeben hat, dass Scrum eingesetzt hat. Wenn Organisationen heute sagen, sie „machen Agile“, meinen sie selten die Haltung dahinter. Sie meinen das Produkt. Sie reden über Velocity, Artefakte, Events, aber nicht über Sinn, Verantwortung oder Lernkultur.

Und genau das meinte Dave Thomas.

Nicht die Agilität ist tot.
Tot ist das, was wir aus ihr gemacht haben.

Solution looking for a problem

Erst kürzlich hat mir ein Kunde erzählt, dass die Beteiligung im PI Planning für die meisten Teilnehmenden bereits nach 2h abnimmt. "Die meisten hören einfach auf, mitzureden", sagte er. Wir haben dann mit ein paar Fragen gemeinsam die Situation analysiert und es wurde schnell klar, dass dort jemand gewirkt hat, der seine Lösung stärker fokussiert hat, wie die nachhaltig effiziente und effektive Zusammenarbeit der Teams.

Die betroffenen Teams verantworten eine breite Palette unterschiedlicher Produkte mit unterschiedlicher Marktreife in unterschiedlichen Märkten. Wer das alte Modell der Two-Speed-it kennt, kann sich das so vorstellen, dass diese Teams den Bereich run-the-business verantworten.

Die "Two-Speed IT" ist ein IT-Organisationsmodell, das zwei Geschwindigkeiten vorsieht:

• Run-the-Business (RTB): Dies ist die "langsame" Geschwindigkeit, die sich auf die Stabilität und Effizienz der Kernsysteme konzentriert. 
• Change-the-Business (CTB): Dies ist die "schnelle" Geschwindigkeit, die auf Innovationen und neue Technologien setzt. 

Übrigens: In aktuellen Blog Beitrag von David gibt es eine vertiefte Auseinandersetzung zu den verschiedenen Geschwindigkeiten und eine Übersicht über drei Betriebsmodelle, die auf die jeweilige Geschwindigkeit ausgelegt sind. Darin verweist er auch auf die Grundlagen und Notwendigkeit der Diskussion eines Target Operating Models. Falls dich also das Thema der Two-Speed-IT anspricht und du mehr wissen möchtest, hier geht es zum erwähnten Blog Beitrag.

Aber zurück zum Thema. Die betroffenen Teams arbeiten folglich im Tagesgeschäft an laufenden Kundenanfragen, also an einem „run-the-business“-Thema. Sie sind Teil eines Systems, das auf Stabilität, nicht auf Veränderung ausgelegt ist. Selbstverständlich gibt es in diesem Kontext Arbeiten, die sich planen lassen, aber es liegt in der Natur der Sache, dass Kundenanfragen oft ungeplant kommen (also nach meiner Erfahrung sehr, sehr, sehr oft und dann auch noch unerwartet).

Und dann stülpt man solchen Teams ein Framework über, das aus einer Produktentwicklungslogik kommt, in der Unsicherheit, Hypothesen und Experimente dazugehören. Ein Framework also, das darauf optimiert wurde, dass verschiedene Teams, die an einem gemeinsamen Produkt arbeiten, ihre Arbeiten gemeinsam für einen begrenzten Horizont planen, damit sie Abhängigkeiten frühzeitig erkennen und adäquat behandeln können. Was passiert nun, wenn dieses Planungskonstrukt auf Teams angesetzt wird, deren Arbeit hinsichtlich Planbarkeit, Abhängigkeit und Koordination nicht die gleichen Kriterien erfüllt? Das Meeting läuft, die Methode ist korrekt angewendet, aber niemand spürt, warum das ganze Sinn ergeben sollte. Es entsteht eher ein SAFe-Theater, als echter Mehrwert für die Teams. 

Übrigens ist das kein SAFe-Problem. Das gleiche Phänomen haben auch Teams, die eine Ticketsystem betreuen und gemäss Scrum in Sprints planen sollen. Und leider sind das auch keine Einzelfälle. Ich habe in den letzten Jahren viele Organisationen gesehen, die denselben Fehler gemacht haben. Scrum für Teams, die Tickets abarbeiten. Kanban für Gruppen, die keine Flussprobleme, sondern Entscheidungsprobleme haben. SAFe für Strukturen, die sich gar nicht skalieren müssen.

Es ist immer wieder das gleiche Muster: Solution looking for a problem.

Wir stülpen Methoden über Kontexte, die wir gar nicht verstehen. Und wundern uns dann, dass Agilität nicht wirkt.

Wenn du einen Hammer hast, sieht alles wie ein Nagel aus

Ein Satz, den ich in letzter Zeit oft im Kopf habe. Er beschreibt die Haltung, mit der viele Agile Coaches – und ja, auch wir Berater – unterwegs waren. Wir hatten ein Werkzeug, das funktionierte. Und weil es funktionierte, wollten wir es überall anwenden.

Ich schliesse mich da bewusst nicht aus. Auch ich habe in meiner Anfangszeit als Agile Coach Frameworks eingeführt, weil sie „state of the art“ waren. Scrum Master, Product Owner und Kanban Schulungen durchgeführt und die Methoden eingeführt. Und ich habe erst mit der Zeit verstanden, dass es nicht darum geht, wie ein Framework heisst, sondern ob es in einem Kontext Wirkung entfalten kann.

Heute frage ich deshalb anders. Ich frage nicht: „Wie führen wir SAFe ein?“
Sondern: „Was ist euer eigentliches Problem?“ „Was hindert euch daran, schneller zu lernen, besser zu entscheiden, oder mutiger zu handeln?“ Oder ich versuche Teams bewusst zurück zur Frage der Problemstellung zu bringen. Das kommt nicht immer gut an, weil wir ja Erfolg daran messen, Lösungen zu bringen und nicht darin, Probleme verstanden zu haben. Aber ich bin da bewusst ein wenig stur. Wenn ich das Problem nicht verstanden habe oder merke, dass die Teams kein gemeinsames Problemverständnis haben, dann gibt es halt so viele Extrarunden, bis A) jemand entscheidet, welches Problem gelöst werden muss, oder B) ein gemeinsames Problemverständnis vorhanden ist.

Denn Agilität ist kein Zustand, den man erreicht. Es ist ein fortlaufender Prozess des Verstehens, Lernens und Anpassens.

Das nächste Label: PUMO

Vor einigen Tagen postete eine Kollegin einen Beitrag über ein neues Akronym: PUMO. Es soll die aktuelle Weltsituation beschreiben – Polarized, Unthinkable, Metamorphic, Overheated.

Falls ihr auch gerne Yuval Noah Harari lest, werdet ihr diesen Gedankensprung hoffentlich mögen. Das Problem dieser Labels ist, dass sie unser ur-bürokratisches Hirn maximal animieren. Wie gerne wir das doch haben. Jedes Ding hat seinen Namen und seinen Platz. Leider führt das oft auch dazu, dass wir die komplexe Welt, die in den schönen Zwischentönen und Farben sich zeigt, in Schwarz und Weiss einteilen wollen und dabei so viel verloren geht. Im Falle von PUMO führt es dazu, dass ähnlich wie bei VUCA und BANI, die Menschen ja sagen, ohne sich wirklich mit der Thematik auseinander zu setzen. Ja zu einem Label zu sagen ist so viel einfacher, wie durch eigenes Denken und Handeln zu erkennen, was gerade passiert.

Ich habe geantwortet, nicht weil ich das Akronym schlecht fand, sondern eben, weil es sinnbildlich für etwas steht, das mich seit Jahren beschäftigt: Unser Drang, jede Unsicherheit mit einem neuen Begriff zu erklären.

„Vielleicht sind es auch wir mit unserem Drang, alles zu kennzeichnen, die Treiber dieser Überhitzung.“

Ich meine das ernst. Wir sind in einer Zeit angekommen, in der wir Ungewissheit lieber umetikettieren, als sie auszuhalten. Wir schaffen neue Labels, weil es sich danach anfühlt, als hätten wir etwas verstanden. Aber oft verstehen wir nur unsere eigene Angst nicht. Und das betrifft nicht nur Akronyme wie PUMO, VUCA oder BANI. Es betrifft auch unsere Methodenwelt. Wir bauen immer neue Frameworks, immer neue Zertifikate, immer neue „Playbooks“ – und verlieren dabei das, worum es eigentlich geht: Das gemeinsame Nachdenken über das, was wirklich wichtig ist.

Das eigentliche Problem: Wir haben verlernt zu fragen

Wenn ich mit Führungsteams arbeite, beginne ich fast immer mit einer simplen Frage:

„Was ist euer wirkliches Problem, eure grösste Herausforderung?“

Und erstaunlich oft bleibt der Raum still. Nicht, weil die Menschen keine Probleme hätten, sondern weil sie gelernt haben, Antworten zu geben, bevor sie verstanden haben, worauf eigentlich.

Genau da liegt für mich der Kern der heutigen Agilitätskrise. Nicht in den Methoden, sondern in der fehlenden Haltung.

Wir sind zu schnell geworden im Lösen.
Zu ungeduldig im Verstehen.
Zu beschäftigt im Optimieren.

Dabei ist genau das, was Agilität ursprünglich wollte, verloren gegangen:
Das neugierige Erkunden.
Das gemeinsame Lernen.
Das bewusste Entscheiden im Hier und Jetzt.

Komplexität braucht Kontext, nicht Rezepte

In seiner Un-Keynote sagte Dave Thomas noch etwas anderes, das mir hängen geblieben ist:

„In a complex world, problems don’t exist in isolation.“

Das klingt banal, ist aber zentral. Denn was wir in Organisationen oft als „ein Problem“ sehen, sind in Wahrheit viele miteinander verflochtene Probleme, die sich gegenseitig beeinflussen.

Die Teams, die beim PI Planning Zeit verschwenden, sind da ein gutes Beispiel. Gehen wir davon aus, dass diese Teams früher nach einem vereinbarten Schema gearbeitet haben. Danach wurde SAFe eingeführt und nun entdeckt, dass PI Planning für diese Teams eher als Zeitverschwendung wahrgenommen wird. Was heisst das jedoch für diese Teams? Weg vom Scrum-Modus und hin zum Kanban-Modus? Schnell im Elfenbeinturm etwas Geschicktes ausdenken und zur Umsetzung befehlen? Nein!

Ein Team, das in einem PI Planning keinen Mehrwert sieht hat keine Planungsproblem.  Ein Team, das zu langsam liefert, hat selten nur ein Prozessproblem.
Vielleicht ist es die Architektur.
Oder die Entscheidungslogik.
Oder der fehlende Sinn.
Oder einfach die Erschöpfung nach Jahren der Dauertransformation.

Jedes weitere planlose Eingreifen verändert das System erneut.

Diese Systeme sind in der Regel in drei Dimensionen zu verstehen.

• Dem technischen System; also der Sicht auf die Technologien, die Soft- und Hardwarelösung (das könnte zum Beispiel ein Schalterapplikation mit all den Umsystemen sein).
• Dem wertschöpfenden System; also der Sicht auf die Art der Zusammenarbeit und in diesem Sinne der Prozesse der Zusammenarbeit (das könnte zum Beispiel Scrum sein).
• Dem sozialen System; also der Sicht auf das konkrete Team oder im weiteren Sinne auf die gruppendynamischen Prozesse in einem Team (das spielen zum Beispiel die Teamgrösse, die Beziehungen im Team und viele weitere Faktoren eine Rolle).

Solche Systeme sind in der heutigen Welt folglich immer komplex. Und auch wenn wir es gerne anders hätten, und damit hoffen das unsere einfachen Antworten wieder passen, wir sind mit komplexen Systemen konfrontiert. Darum funktionieren einfache Antworten nicht. Darum funktioniert auch „Agile as a Product“ nicht.

Komplexität verlangt, dass wir gemeinsam lernen, wie das System reagiert.

Dass wir beobachten, anpassen, wieder beobachten. Dass wir Hypothesen formulieren – und uns erlauben, sie zu verwerfen. Das ist der Kern agilen Denkens.

Nicht die Methode.
Nicht das Framework.
Sondern die Haltung, im Ungewissen handlungsfähig zu bleiben.

Was heisst das für Organisationen?

Es heisst vor allem, dass Organisationen wieder lernen dürfen, selbst zu denken. Dass sie aufhören dürfen, Rezepte einzukaufen. Dass sie vielleicht auch gut daran tun, mit Beratungsunternehmen zu arbeiten, die keine Lösungen verkaufen, sondern Prozesse begleiten. Und dass sie sich die Zeit nehmen dürfen, den eigenen Kontext zu verstehen, bevor sie etwas verändern.

Ich sage bewusst dürfen, nicht müssen. Denn der Druck, alles „richtig“ zu machen, ist Teil des Problems.

In vielen Organisationen, die wir begleiten, ist das der entscheidende Wendepunkt: Wenn sie merken, dass Agilität kein Ziel ist, sondern ein Werkzeug, um mit Unsicherheit umzugehen. Wenn sie verstehen, dass Veränderung nicht beginnt, wenn ein Framework ausgerollt wird, sondern wenn die Haltung im Denken und Entscheiden sich verändert. Und wenn sie erleben, dass genau daraus wieder Energie entsteht. Energie, die nicht aus Überforderung, sondern aus Sinn kommt.

Agilität lebt, in Menschen, nicht in Methoden

Ich glaube fest daran: Agilität ist lebendig. Sie lebt in den Menschen, die Fragen stellen, auch wenn es unbequem ist. In den Teams, die sich trauen, mit ihren Kunden zu lernen. In den Führungspersonen, die den Mut haben, Entscheidungen transparent zu machen, statt sie zu kontrollieren. Sie lebt in den Momenten, in denen man nicht weiss, wie es weitergeht – und trotzdem weitergeht. Das Produkt ‚Agile‘ mag tot sein. Vielleicht musste es sogar sterben, damit Agilität wieder leben kann. Aber die Haltung, die Idee, das Prinzip, sie leben weiter. In jeder Organisation, die den Mut hat, sich selbst zu reflektieren.

Und in jeder Zusammenarbeit, die sich auf echtes Lernen einlässt.

Zum Schluss

Vielleicht ist das die eigentliche Einladung, die von Dave Thomas’ Worten ausgeht: Nicht Agilität zu retten, sondern sie wieder zu entdecken. Nicht neue Frameworks zu suchen, sondern den Mut, alte Fragen neu zu stellen. „Agile is un-dead“ – weil Leben Bewegung ist. Und weil Lernen nie abgeschlossen sein sollte.