Überall liest man es: „Wir haben jetzt AI-gestützte Entwicklung eingeführt. Mal GitHub Copilot, mal ChatGPT und immer öfter Claude. Code-Generierung, automatische Reviews, Pair Programming mit dem AI-Assistenten sind im Alltag angekommen. Die Welt muss wissen, dass man dem Club auch beigetreten ist.
Was niemand auf LinkedIn verkündet, ich als Berater aber immer öfter höre: „Die Lieferzeiten haben sich nicht verbessert. Features brauchen immer noch genauso lang bis zum Kunden.“
Überraschend? Nicht wirklich. Wir hatten diese Enttäuschung schon einmal.
Das kennen wir doch
Vor zehn, fünfzehn Jahren war Agile der Heilsbringer. Teams arbeiten in kurzen Sprints, liefern häufiger, sind produktiver. Die Erwartung: Wenn Teams schneller arbeiten, liefert die Organisation schneller. Die Realität: Teams wurden tatsächlich besser. Aber die Lieferzeiten zum Kunden? Die blieben oft erstaunlich lang.
Mit AI passiert gerade exakt das Gleiche. Wieder die gleiche Annahme: Schnellere Einheiten führen zu schnellerer Lieferung. Wieder das gleiche Denkmodell. Und die Enttäuschung wird ähnlich groß werden.
Denn der Fehler liegt nicht in der Technologie. Der Fehler liegt im Denkmodell.
Wo die Zeit wirklich bleibt
Nimm ein typisches Feature. Von der Idee bis zur Auslieferung vergehen, sagen wir, 60 Arbeitstage. Wie viele davon wird tatsächlich an diesem Feature gearbeitet? In vielen Organisationen sind es zwei bis drei Tage. Manchmal weniger.
Der Rest ist Warten.
Warten auf Priorisierung. Warten auf ein anderes Team, das eine Schnittstelle bereitstellen muss. Warten auf eine Freigabe. Warten in einer Queue, weil das nächste Team gerade mit etwas anderem beschäftigt ist. Warten auf ein Review. Warten auf ein Deployment-Fenster.
Und jetzt die entscheidende Frage: Was passiert, wenn AI die reine Arbeitszeit halbiert?
Aus drei Tagen Arbeit werden anderthalb. Die 57 Tage Wartezeit bleiben. Statt 60 Tagen dauert das Feature jetzt 58,5 Tage. Das ist keine Transformation. Das ist ein Rundungsfehler.
Das System, nicht die Einheiten
Der Fehler liegt im Denkmodell. Wer glaubt, dass schnellere Entwickler zu schnellerer Lieferung führen, denkt in Einheiten statt in Systemen.
Das ist, als würde eine Spedition schnellere LKWs kaufen, obwohl die Fahrzeuge 95% der Zeit im Stau oder an der Rampe stehen. Der LKW ist nicht das Problem. Die Straße ist das Problem. Die Rampe ist das Problem. Die Koordination zwischen Lager, Disposition und Fahrer ist das Problem.
In Softwareorganisationen ist es nicht anders. Das System, durch das Arbeit fließt, bestimmt die Liefergeschwindigkeit. Nicht die Geschwindigkeit der einzelnen Arbeiter.
Das heimtückische Problem
Hier wird es richtig unangenehm. Und zwar gerade dort, wo Teams ihre Arbeit gut organisieren.
Stell Dir vor, ein Team begrenzt konsequent, wie viele Aufgaben es gleichzeitig bearbeitet. Das ist gut. Das Team arbeitet fokussiert und liefert schnell. Jetzt wird dieses Team durch AI noch schneller. Was passiert?
Das Team liefert seine Arbeit zügiger ab. Lokal sieht alles hervorragend aus. Kurze Bearbeitungszeiten, das Board sieht gesund aus.
Aber was passiert mit der Arbeit, die noch gar nicht beim Team angekommen ist? Sie wartet im Backlog. Und weil das Team jetzt schneller arbeitet als neue Arbeit nachfließt, sieht das eigene Backlog vielleicht sogar kleiner aus. Das Problem liegt woanders: Beim nächsten Team in der Kette, das nicht schneller geworden ist, wächst das Backlog. Und beim übernächsten.
Genau hier entsteht das unsichtbare Problem: Die Arbeit verschimmelt nicht auf dem Board. Sie verschimmelt in den Backlogs. Und das Tückische daran: Die Verantwortlichen sehen oft, dass ihr Backlog wächst. Aber sie können nichts dagegen tun. Die Arbeit kommt schneller rein, als sie abgearbeitet werden kann. Mit jedem Tag, den eine Anforderung im Backlog altert, sinkt ihr Wert. Je größer das Backlog wird, desto länger altert jede einzelne Anforderung darin.
Bei einem meiner Kunden haben wir deshalb die Backlog-Größe als Gesundheitsindikator eingeführt. Das Prinzip ist einfach: Wie beim Blutdruck gibt es einen Bereich, der gesund ist. Liegt die Anzahl der Backlog-Items innerhalb dieses Bereichs, ist alles in Ordnung. Steigt sie darüber hinaus, ist das ein Signal, dass etwas im System nicht stimmt. Den Bereich legt der Verantwortliche selbst fest, denn nur er kennt den Kontext. Entscheidend ist, dass es diesen Bereich gibt und dass jemand hinschaut.
Was stattdessen hilft
Wenn die reine Arbeitszeit nur einen Bruchteil der Durchlaufzeit ausmacht, dann liegt das Verbesserungspotenzial woanders: im Flow der Arbeit durch das Gesamtsystem.
Das bedeutet: sichtbar machen, wo Arbeit wartet. Verstehen, warum sie wartet. Queues zwischen Teams verkürzen. Abhängigkeiten reduzieren oder besser koordinieren. Und ja, auch die Backlogs im Blick behalten, nicht nur die Boards.
Keine dieser Maßnahmen erfordert neue Tools, neue Frameworks oder neue Methoden. Sie erfordern einen anderen Blick: weg von der Frage „Wie mache ich Teams schneller?“ hin zu „Wie bringe ich Arbeit schneller zum Kunden?“
AI ist nicht das Problem
Ich bin großer Befürworter von AI. Tatsächlich nutze ich Claude zum Beispiel, um meine Gedanken, Ideen und Beobachtungen zu sammeln, sortieren und in Artikel, wie diesen zu gießen. AI kann Teams entlasten, Routinearbeit reduzieren und Kapazität freisetzen. Es wäre dumm, diese Möglichkeiten nicht zu nutzen.
Aber AI löst nicht das Problem, das die meisten Organisationen tatsächlich haben. Genauso wenig wie Agile es vor fünfzehn Jahren gelöst hat. Nicht weil Agile oder AI schlecht wären, sondern weil das Problem woanders liegt.
Wer die Liefergeschwindigkeit verbessern will, muss auf den Flow schauen. Auf das System. Auf die Zeit, in der niemand an dem Feature arbeitet, das der Kunde braucht.
Solange das nicht passiert, beschleunigst Du den Teil, der kaum ins Gewicht fällt. Und wunderst Dich, warum sich nichts ändert.
Wolfgang Wiedenroth ist Trainer und Berater bei it-agile und spezialisiert auf Kanban, Lean-Praktiken und cross-team Prozessoptimierung mit Fokus auf Flusseffizienz. Als akkreditierter Trainer und Consultant der Kanban University unterstützt er Organisationen dabei, ihre Wertströme sichtbar und steuerbar zu machen.