Wenn KI-Agenten ins System kommen: Warum Inspect & Adapt kollabiert

Agile-Methoden haben ein echtes Problem gelöst. Sie haben Strukturen für den Umgang mit Unsicherheit geschaffen und Praktiken tief in Organisationskulturen verankert—Praktiken wie Inspect & Adapt. Zwanzig Jahre lang war der Zyklus vorhersehbar: man sprintet, schaut, was passiert ist, passt an, sprintet weiter. Der Rhythmus ist eng. Die Feedback-Schleife ist eng. Der Zyklus funktioniert.

Dann kommen KI-Agenten ins System.

Das Problem ist nicht, dass Agile nicht mehr funktioniert. Das Problem ist, dass KI bloßlegt, was „Inspect & Adapt“ wirklich voraussetzt—und die meisten Organisationen haben das nicht.

Lernsysteme folgen nicht dem Sprint-Takt

Agile geht von einem Release-Zyklus aus. Du sprintest. Nach zwei Wochen versammelt ihr euch. Ihr schaut, was ihr released habt. Ihr passt an. Die Feedback-Schleife ist an Releases gekoppelt.

KI-Agenten releasen nicht in Sprints. Sie verhalten sich und adaptieren kontinuierlich. Ein Sprachmodell wartet nicht auf die nächste Sprint-Review, um von einer Nutzer-Interaktion zu lernen. Ein Lernsystem pausiert nicht an der Sprint-Grenze, um Menschen aufzuholen. Es ändert sich während es läuft.

Das bedeutet: das Ding, das du inspizierst—das Systemverhalten—ist schon gedriftet, seit du es zuletzt gesehen hast. Der Agent hat einen Workflow optimiert. Nutzer finden sofort eine Umgehung. Drei Wochen später, bei der Sprint-Retrospektive, merkst du endlich das Muster. Aber der Agent hat sich inzwischen fünfmal ohne deine Inspection oder Adaption verändert.

Inspect & Adapt setzt ein menschliches Beobachtungsfenster voraus. KI-Agenten operieren außerhalb dieses Fensters.

Die Entscheidungen verschieben sich, die Governance nicht

Bei traditioneller Software läuft die Entscheidungskette so ab: Requirements → Development → Release → Observe → Adjust. Der Entscheidungspunkt ist klar. Du entscheidest, was zu bauen ist, baust es, releasest es, schaust, was passiert.

Bei KI-Agenten bricht die Sequenz auseinander. Das System führt nicht nur Entscheidungen aus—es bewertet sie. Es urteilt. Es überwacht seine eigenen Outputs und kalibriert sich basierend auf dem, was es antrifft. Wenn ein Agent auf Edge Cases stößt, escaliert er nicht zu einem Sprint-Backlog. Er generiert neues Verhalten in Echtzeit.

Jetzt ist die Frage nicht mehr „Was sollen wir bauen?“ Sondern „Welche Entscheidungen trifft das System gerade, und wer ist dafür verantwortlich?“

Die traditionelle Agile-Governance geht davon aus, dass Menschen entscheiden und KI ausführt. KI-Agenten invertieren das. Das System trifft Entscheidungen—manchmal gute, manchmal unerwartete. Deine Governance-Struktur—deine Retrospektiven, deine Backlog-Reviews, deine Entscheidungs-Boards—ist dafür konstruiert, menschliche Ausführung zu inspizieren, nicht System-Urteile.

Wenn du versuchst, Inspect & Adapt auf der Ebene des menschlichen Teams anzuwenden, inspizierst du das Falsche. Der echte Drift passiert in den Entscheidungsmustern des Agenten, nicht in den Liefermustern deines Teams.

Verantwortung wird verteilt

Hier bricht Governance wirklich zusammen. In traditionellem Agile, wenn etwas schiefgeht, traust du es zurück: Welches Team hat es released? Welcher Sprint? Welche Person hat entschieden? Verantwortung ist verankert. Du inspizierst das Verhalten des Teams, identifizierst, was schiefging, das Team passt an.

Mit KI-Agenten im Loop verteilt sich die Verantwortung. Ein Agent trifft eine Entscheidung basierend auf seinem Training. Ein Nutzer folgt dieser Empfehlung. Das Ergebnis ist gut oder schlecht je nach Kontext, den der Agent nie gesehen hat. Wer ist verantwortlich? Das Team, das das Modell gebaut hat? Die Person, die es deployed hat? Das System, das es trainiert hat? Der Mensch, der es nicht überschrieben hat?

Der Agent sitzt nicht in der Retrospektive. Er kann seine Reasoning nicht so erklären wie ein Mensch. Du kannst sein Verhalten beobachten—„der Agent hat X empfohlen, wenn er Y hätte empfehlen sollen“—aber das Verstehen warum erfordert das System zu instrumentieren, Logs zu analysieren, Diagnostics zu laufen. Das ist technische Untersuchung, keine Gesprächsrunde.

Inspect & Adapt setzt voraus, dass das Ding, das du inspizierst, zurück reden kann, seine Entscheidungen verteidigen kann, von Kritik lernen kann. KI-Agenten können das nicht in einer Sprint-Retrospektive. Sie können nur gemessen werden.

Observability wird fundamental

Hier taucht die echte Lösung auf. Du kannst nicht Inspect & Adapt ohne Observability. Nicht so, wie wir es gemacht haben. Die Sprint-Retrospektive war ein soziales Instrument—Menschen teilen Erfahrungen, entdecken Muster, beschließen zu ändern. Das zählt immer noch für Verhalten des Teams. Aber für Agenten-Verhalten brauchst du systematische Observation.

Du brauchst Metriken darüber, was der Agent entschieden hat, wann, unter welchen Bedingungen. Du brauchst zu sehen, ob diese Entscheidungen zu den Outcomes führten, für die das System optimiert war. Du brauchst zu wissen, der Gap zwischen optimiert-für und was dem Business tatsächlich wichtig ist. Du brauchst diese Daten live, nicht quartalsweise.

In dem Moment, wo du diese Observability baust, merkst du etwas: Die Feedback-Schleife für den Agenten ist nicht dein Sprint-Zyklus. Die Feedback-Schleife ist die Zeit zwischen „Agent hat Verhalten deployed“ und „du hast Sichtbarkeit, ob dieses Verhalten funktioniert“. Wenn dieses Fenster drei Wochen ist, kannst du nicht Agile sein mit KI. Du machst nur Versuch und Fehler in Slow Motion.

Hier läuft KI-Strategie-Consulting schief. Organisationen fokussieren auf das Modell—Accuracy, Latency, Feature Engineering. Sie verpassen die Infrastruktur-Frage: Haben wir Observability, ob dieses System gute Entscheidungen trifft? Haben wir eine Feedback-Schleife schneller als unser Release-Zyklus?

Ohne das hast du nicht Inspect & Adapt. Du hast Beobachtungs-Verzögerung.

Operating Models und Führung müssen sich zuerst verändern

Hier ist das Muster, das ich in Transformations-Projekten sehe: Organisationen versuchen, KI-Agenten auf existierende Agile-Strukturen aufzusetzen. Das Team bleibt gleich. Das Retrospektiven-Format bleibt gleich. Die Governance bleibt gleich. Nur das Tool ändert sich.

Das funktioniert nicht, weil das Tool geändert hat, was du governierst.

  • Observability-Infrastruktur zuerst. Du kannst nicht adaptieren, was du nicht siehst. Metriken, Instrumentation, Dashboards—das sind nicht Nice-to-have. Das sind die Voraussetzungen.
  • Schnellere Feedback-Schleifen. Wenn dein Feedback-Fenster ein Sprint ist, bist du zu spät dran. Das System hat sich schon adaptiert während du auf die Review gewartet hast. Du brauchst kontinuierliche Signale, nicht Batch-Retrospektiven.
  • Andere Entscheidungs-Modelle. Wer entscheidet, wenn das Verhalten eines Agenten falsch ist? Nicht eine Sprint-Review—das ist zu langsam. Nicht ein einzelner Engineer—das ist zu eng. Manche Entscheidungen brauchen Echtzeit-Eskalation. Manche brauchen Untersuchung. Manche brauchen Policy. Das ist nicht eine Scrum Master Entscheidung. Das ist ein Governance-Redesign.
  • Führung, die Supervision versteht, nicht nur Ausführung. Dein Engineering Manager ist trainiert, durch Sprint Planning, Task Breakdown, Delivery Tracking zu führen. Mit KI-Agenten shiftet die Rolle. Du supervisierst ein System, das Entscheidungen trifft. Das erfordert andere Skills—Diagnose, Experimental Design, Systems Thinking.

Der schwierigste Teil ist nicht die KI. Es ist die Umstrukturierung der Organisation, um wirklich in der Geschwindigkeit zu inspizieren und zu adaptieren, in der das System operiert.

Die echte Frage ist nicht mehr Agilität

Hier ist, was ich aus diesem sich wiederholenden Muster gelernt habe: KI macht Agile nicht irrelevant. Es legt bloß, ob deine Organisation wirklich die operationalen Grundlagen hat, die Agile hätte bauen sollen.

Hast du Observability, was in deinen Systemen passiert? Nicht nur „haben wir on-time released“—echte Sichtbarkeit in Systemverhalten, Drift, Edge Cases?

Hast du Feedback-Schleifen schneller als dein Release-Zyklus? Oder dauert es drei Monate, bis Insights auftauchen?

Kann deine Führung Entscheidungen basierend auf Metriken treffen, oder verlassen sie sich auf Intuition und laute Stimmen im Raum?

Hast du Governance, die für kontinuierliche Veränderung gebaut ist, oder ist sie immer noch an Batch-Zyklen verankert?

Agile sollte diese Fragen beantworten. Für viele Organisationen hat es das nie getan. Es hat nur einen Rhythmus geschaffen—Sprints, Standups, Retros—der sich wie Fortschritt anfühlte. KI-Agenten nehmen die Fähigkeit, sich hinter dem Rhythmus zu verstecken. Das System lernt schneller als du nachdenkst. Entweder baust du die Observability und Decision-Making Infrastruktur, um mitzuhalten, oder du managst ein System, das du nicht wirklich verstehst.

Inspect & Adapt bricht nicht zusammen mit KI. Deine Organisation tut es.

Boris Heuer

Boris Heuer
AI Engineer & Consultant

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen