AGILE, wie wir es kennen, verschwindet

Aktueller Stand der Forschung zur agentischen Softwareentwicklung: Die agilen Praktiken werden nicht mehr angepasst. Ihre ökonomischen, methodischen und personellen Grundannahmen entfallen.

FC
Frank Csehan
23. Mai 2026 · 13 min Lesezeit

Die Grundlagen, auf denen die Annahmen des Agile Manifesto beruhen, verschwinden mit Agentic Coding. Die folgenden Grundannahmen, aus denen die agilen Praktiken abgeleitet wurden, entfallen: die ökonomische Annahme, dass Implementierung der Engpass sei; die methodische Annahme, die das Agile Manifesto in vier Wertepaaren formuliert hat; die personelle Annahme über Teams, Lernwege und Rollen; die metrische Annahme, dass Erzeugungsgeschwindigkeit Lieferqualität approximiert. An mehreren dieser Stellen wird die agile Logik nicht ergänzt oder verschoben. Sie wird umgekehrt.

Unterstützt werden diese Aussagen durch den aktuellen Stand der Forschung zur agentischen Softwareentwicklung, soweit er zwischen Oktober 2025 und Mai 2026 als arXiv-Preprints oder begutachtete Beiträge erschienen ist.

Eine andere Knappheit

Agile entstand in einer Zeit, in der die teuerste und langsamste Ressource der Softwareentwicklung Menschen waren. Entwicklerinnen und Entwickler kosteten Geld, Einarbeitung dauerte Monate, Kontextwechsel waren teuer, gute Architektinnen und Architekten waren rar. Aus dieser Knappheit folgten mehrere Kernprinzipien.

Selbstorganisation entstand, weil zentrale Planung zu langsam und zu schlecht informiert war, um knappe Entwicklerzeit sinnvoll zuzuteilen. Timeboxing entstand, weil sich Aufgaben in Monaten weder zuverlässig schätzen noch verlässlich nachverfolgen ließen, und kleinere Zeitfenster die Fehlerkosten begrenzten. Velocity entstand, weil ein Team seine eigene durchschnittliche Liefergeschwindigkeit besser kannte als jede externe Kapazitätsplanung. Das Prinzip “Working software over comprehensive documentation” entstand, weil eine vollständige Spezifikation vor dem Code teurer war als der Code selbst und ohnehin schnell veraltete.

Jede dieser Antworten ist sinnvoll, solange die Implementierung der Engpass ist. Genau diese Annahme verändert sich. Bhati nennt den neuen Engpass Verification Debt. Apostolou, Bosch und Holmström Olsson sprechen von einer Capability-Deployment Verification Gap. Sie beschreiben in ihren 16 Interviews mit zwölf Unternehmen das gleiche Bild aus zwei Richtungen: Vier Unternehmen demonstrierten höhere agentische Fähigkeiten, konnten diese aber nicht produktiv einsetzen, weil verlässliche Verifikation fehlte. Bandara et al. legen mit Agentsway ein Vorgehensmodell vor, in dem Verifikation und menschliche Orchestrierung gleichberechtigt neben die Code-Erzeugung treten.

Damit kippt das Optimierungsproblem. Wenn nicht mehr knapp ist, wie schnell ein Mensch Code schreiben kann, sondern wie schnell eine Organisation den erzeugten Code prüfen, einordnen und verantworten kann, dann sind alle agilen Antworten auf die alte Knappheit fehladressiert. Selbstorganisation ist eine Antwort auf knappe Implementierungskapazität. Sie ist keine Antwort auf knappe Verifikationskapazität. Velocity misst Erzeugungstempo. Sie misst nicht Prüfkapazität. Timeboxing strukturiert menschliche Arbeit in Iterationen. Es strukturiert keine Gate-Sequenz aus Spezifikation, Code, Test, Evidence Bundle, Review und Freigabe.

Eine Methodik, die für eine andere Knappheit gebaut ist, wird nicht durch Anpassung modernisiert. Sie verliert mit ihrem Optimierungsproblem ihre Berechtigung. Das ist die ökonomische Bruchstelle.

Umkehrung statt Erweiterung

Das Agile Manifesto formuliert vier Wertepaare. Drei davon werden im agentischen Arbeiten nicht ergänzt, sondern in ihre Umkehrung gedrängt. Der vierte bleibt formal stehen, ändert aber seinen Adressaten.

Working software over comprehensive documentation. Spec-Driven Development verkehrt diese Reihenfolge. Piskala beschreibt das Spektrum von Spec-First bis Spec-as-Source. Feng und Chen zeigen in einer Pilotstudie, dass strukturierte Signaturen bei Repo-Level-Generierung die Test-Pass-Rate erhöhen können. Lulla et al. messen für eine AGENTS.md in zehn Repositories mit 124 Pull Requests eine Laufzeit-Reduktion von 28,64 Prozent und einen Token-Verbrauch-Rückgang von 16,58 Prozent. Galster et al. dokumentieren acht Konfigurationsmechanismen in 2.853 Repositories, darunter Context Files, Skills, Subagents, Commands, Rules und Hooks. Diese Artefakte stehen nicht nach dem Code als Dokumentation. Sie stehen vor dem Code als Bedingung der Möglichkeit. Ohne sie wird der Output unspezifischer, langsamer und teurer. Die Manifesto-Reihenfolge ist nicht erweitert. Sie ist umgekehrt.

Individuals and interactions over processes and tools. Wenn das Werkzeug der Hauptproduzent ist, verliert dieser Satz seinen Sinn. Koch formuliert in Agentic Agile-V, dass lange Chatverläufe keine belastbaren Engineering-Verträge sind. Die Interaktion wird zum Risiko, das durch Prozesse und Tools eingehegt werden muss. Conversation-to-Contract-Gate, Acceptance Gates, TDD-Governance (Hasanli et al.), Policy-as-Prompt (Kholkar, Ahuja), Plane-Trennung in CI/CD (Barnes, Ghaleb) — die Forschung dreht die Achse. Prozesse und Tools werden zu den Trägern der Verbindlichkeit, weil Interaktionen und Individuen sie nicht mehr garantieren können.

Customer collaboration over contract negotiation. Die agentische Wende erzwingt, dass Anforderungen prüfbar werden. Eine Spezifikation, die als Eingabe für einen Agenten dient, ist ein Vertrag im technischen Sinn: Akzeptanzkriterien, Constraints, Testfälle. Das ist nicht Vertragsverhandlung im juristischen Sinn, aber es ist auch nicht die mündlich-kooperative Anforderungsklärung des klassischen Agile. Die Spec wird wieder zum Vertrag, nur eben in maschinenlesbarer Form.

Responding to change over following a plan. Dieser Satz steht formal weiter, aber sein Adressat wandert. Verändert wird der Plan jetzt mit Gate-Disziplin: Welche Änderung darf der Agent ausführen, welche braucht menschliche Freigabe, welche darf nie automatisch wirken? Die Forschung zur Plane-Trennung bei Barnes und Ghaleb und zu Governance-Layern bei Koch, Xu et al. und Kholkar liest sich an manchen Stellen näher an V-Modell-Disziplin als an Scrum.

Eine Methodik, deren tragende Werte in drei von vier Paaren umgekehrt werden, lässt sich nicht ohne Begriffsbruch weiterführen. Sie muss sich neu begründen, oder sie verliert ihren Anspruch.

Wer wird Senior?

Die Diskussion über agentische Werkzeuge spricht vom Menschen als Orchestrator. Das ist die freundliche Formulierung. Die schärfere Lesart ist personalstrukturell und unangenehmer.

Horikawa et al. untersuchen 15.451 Refactoring-Instanzen in 12.256 agentischen Pull Requests. Refactoring kommt häufig vor, zielt überwiegend auf Maintainability und Readability und bleibt oft lokal. High-Level-Designarbeit ist schwächer vertreten. Das ist genau die Verteilung, die Junior-Entwicklerinnen und -Entwicklern als Lernfeld zugewiesen war: kleine Tickets, lokale Verbesserungen, Tests schreiben, Lesbarkeit erhöhen. Pinna et al. zeigen für 7.156 agentische Pull Requests deutliche Stärken bei bestimmten Task-Typen, vor allem in der Klasse umrissener, lokal beschränkter Änderungen. Robbes et al. dokumentieren in ihrer Adoptionsstudie die schnelle Verbreitung gerade für diesen Tätigkeitstyp.

Was Agenten gut können, ist also nicht ein willkürlicher Ausschnitt der Entwicklungsarbeit. Es ist im Wesentlichen der Bereich, über den Junior-Entwicklerinnen und -Entwickler Seniorität aufbauen. Wenn dieser Lernpfad strukturell verkürzt oder ganz übersprungen wird, entsteht eine Frage, die in der Methodik-Debatte selten gestellt wird: Woher kommen in fünf Jahren die Menschen, die agentische Outputs verlässlich prüfen, einordnen und verantworten? Apostolou et al. nennen verlässliche Verifikation als den fehlenden Baustein, der mehrere Unternehmen daran hindert, höhere agentische Stufen produktiv einzusetzen. Verifikation in dieser Tiefe verlangt Erfahrung, die im klassischen Modell durch genau die Arbeit aufgebaut wurde, die Agenten heute übernehmen. Diese Beobachtung führt das wissenschaftliche Material zwar nicht direkt, sie folgt aber aus der Kombination der genannten Befunde mit der gängigen Personalstruktur in Softwareteams.

Auch die Scrum-Rollen geraten unter Druck. Scrum Master und Agile Coaches hängen fast vollständig an der menschlichen Teamdynamik. Sie sind die Antwort auf Konflikte, Kommunikationsdefizite, fehlende Selbstorganisation und unausgesprochene Erwartungen. In einem Workflow, in dem ein Mensch mit einem Agenten arbeitet, sind diese Themen weniger zentral. Was zentral wird, ist technische Workflow-Architektur: Gate-Design, Spec-Strukturen, Toolrechte, Hook- und Policy-Konfiguration, MCP-Setup, Evidence-Bundle-Schemata. Galster et al. dokumentieren acht solcher Mechanismen, und die meisten von ihnen sind keine Coaching-Themen, sondern Engineering-Themen. Eine Rolle, deren Arbeitsfeld so eng an einer schwindenden Komponente der Methodik hängt, wird nicht reformiert. Sie wird redimensioniert.

Der Product Owner wird durch Business-Architektinnen und -Architekten ersetzt. Der PO als Schnittstelle zwischen Fachbereich und Entwicklungsteam war eine Antwort darauf, dass Entwicklungszeit teuer war und Fachbereiche keine direkte Übersetzungsfähigkeit zur Implementierung hatten. Wenn die Übersetzung in maschinenlesbare Spezifikationen wandert und Implementierungskapazität günstiger wird, verschwindet ein Teil der Vermittlungsleistung. Die Verantwortung für Akzeptanzkriterien, Spec-Pflege und Gate-Entscheidungen lässt sich näher an den Fachbereich rücken, als es das Scrum-Modell vorsah. Der Product Owner ist in seiner agilen Definition so nicht mehr notwendig.

Die Metrik-Umkehrung

Eine Metrik ist sinnvoll, solange ihr Vorzeichen stabil ist. Mehr ist gut oder weniger ist gut. Eine Metrik, deren Vorzeichen sich umkehren kann, ist keine Metrik. Sie ist ein Signal, das je nach Kontext bewertet werden muss.

Velocity steht genau an dieser Stelle. Agarwal, He und Vasilescu untersuchen 401 Agent-First-Repositories und 117 IDE-First-Repositories mit gematchten Kontrollgruppen. Sie finden kurzfristige Velocity-Gewinne, die in den agentischen Gruppen front-loaded sind. Zugleich steigen Static-Analysis-Warnings und Cognitive Complexity deutlich. Ehsani et al. zeigen in 33.596 agentischen Pull Requests, dass reviewer abandonment das häufigste Muster in der manuell kategorisierten Teilmenge abgelehnter PRs ist. Hohe Erzeugungsgeschwindigkeit korreliert nicht mit hoher Lieferqualität. Sie korreliert in den agentischen Gruppen mit wachsender Komplexität und nicht bewältigter Review-Last.

Damit kippt Velocity in einem agentischen Umfeld von einer Tugend zu einem Risikoindikator. Eine hohe agentische Velocity bei stabiler Review-Kapazität ist verdächtig, nicht gut. Eine Methodik, die ihre zentrale Steuerungsmetrik in eine Risikometrik umdeuten muss, sollte das nicht beschönigen. Velocity bleibt messbar. Sie verliert ihren Sinn als Steuerungsgröße. Burndown teilt dieses Schicksal, weil sein Sinn dieselbe Annahme voraussetzt: dass Erzeugungsgeschwindigkeit Liefergeschwindigkeit approximiert.

Ein Ersatz existiert noch nicht. Gate-Durchlaufzeit, Evidence-Vollständigkeit, Verifikationsdichte, Policy-Konformität, bestandene Akzeptanzkriterien pro Zeit — alles plausible Kandidaten, keine ausgereifte Praxis. Diese Lücke verdient die Hervorhebung. Die agile Bewegung steht ohne stabile Steuerungsmetrik da, während die alte Metrik nicht nur unzuverlässig wird, sondern in ihr Gegenteil kippt.

Ein Geschäftsmodell verschwindet

Eine Ebene kommt im wissenschaftlichen Material kaum vor, ist aber für das Schicksal der agilen Methodik wichtig. Agile ist seit Mitte der 2000er-Jahre auch ein Beratungs- und Zertifizierungsmarkt. SAFe, Scrum.org, LeSS, Scaled Agile Inc. und eine Vielzahl unabhängiger Coaches leben von Trainings, Zertifikaten und Transformationsprojekten. Ihr Produkt sind Team-Coaching, Rituale, Rollenmodelle und Skalierungs-Frameworks.

Die Forschung deutet auf andere Schwerpunkte. Bandara et al. legen mit Agentsway ein Vorgehensmodell vor, in dem Rollen, Lernschleifen, Fine-Tuning, Orchestrierung und Verifikation im Zentrum stehen. Xu et al. fordern einen Governance-First-Ansatz für Agent Engineering. Kholkar und Ahuja entwickeln Policy-as-Prompt als Übersetzung von Governance-Regeln in Laufzeit-Guardrails. Koch arbeitet an einer mehrschichtigen Übersetzung von Governance-Normen in Runtime-Guardrails sowie an einer V-Modell-Variante für agentisches Arbeiten. Galster et al. dokumentieren die Konfigurationsebene der bestehenden Werkzeuge. Das alles sind Engineering-Themen, keine Coaching-Themen.

Damit entsteht ein strukturelles Übergangsproblem. Eine Industrie, deren Geschäftsmodell auf der Vermittlung von Ritualen, Rollen und Selbstorganisationspraktiken aufgebaut ist, kann sich nicht ohne Verlust ihrer Identität in einen Markt für Gate-Architektur, Spec-Engineering und Policy-Konfiguration umstellen. Das verlangt andere Methoden, andere Curricula, andere Werkzeuge und andere Auftraggeber im Unternehmen. Auch hier ist es nicht zwingend, dass die alte Industrie verschwindet. Es ist aber zwingend, dass sie ihren bisherigen Anspruch der methodischen Marktführerschaft nicht halten kann, ohne sich selbst neu zu erfinden. Eine Erneuerung dieser Größenordnung ist historisch eher selten und meist nur durch Generationenwechsel hindurch möglich.

Was übrig bleiben könnte

Welche agilen Beiträge tragen weiter, weil sie nicht an der entfallenden Knappheit hängen?

Kleine Lieferpakete bleiben sinnvoll, weil sie die Risikoabsicherung kleiner machen, unabhängig davon, wer den Code schreibt. Enger Kontakt zu Fachbereichen bleibt sinnvoll, weil Spezifikationen ohne fachliche Rückkopplung schnell falsch werden. Reflexion in regelmäßigen Abständen bleibt sinnvoll, sofern ihr Ergebnis im Arbeitsumfeld des Agenten landet, nicht nur auf einem Whiteboard. Verantwortlichkeit für die Lieferung bleibt sinnvoll, weil Agenten weder Verantwortung tragen können noch tragen sollen. Transparenz über laufende Arbeit bleibt sinnvoll, allerdings in der Form prüfbarer Artefakte, nicht in Form regelmäßiger Statusgespräche.

Das ist eine deutlich kürzere Liste als das, was die agile Bewegung als Methodik exportiert hat. Sie enthält im Wesentlichen Praxisweisheiten, die älter sind als das Agile Manifesto und auch ohne es trügen. Was sie nicht enthält, ist der spezifisch agile Apparat aus Velocity, Sprint-Schätzung, Selbstorganisation als Steuerungsprinzip, Scrum-Rollen und Ritualtaktung. Genau dieser Apparat war es, der Agile von älteren Praxistraditionen unterschieden hat. Was bleibt, wenn dieser Apparat verschwindet, ist nicht Agile mit Agenten. Es ist eher disziplinierte, prüfungsbewusste Softwareentwicklung mit kurzen Feedbackzyklen, wie sie auch ohne den Begriff Agile begründbar wäre.

Schluss

Die agile Methodik geht nicht unter, weil ihre Anhänger sie aufgeben. Sie geht unter, weil die Bedingungen, gegen die sie optimiert war, in mehreren Schichten gleichzeitig entfallen. Die Knappheit verschiebt sich von der Implementierung zur Verifikation. Die Personalstruktur, die ihren Begriff von Team und Lernpfad trug, verliert ihre Reproduktionsbasis. Die Steuerungsmetrik kehrt ihr Vorzeichen um. Die Beraterökonomie, die die Methodik organisiert hat, steht ohne anschlussfähiges Produkt da.

Vier dieser Verschiebungen sind in den 22 ausgewerteten Arbeiten direkt belegt. Die fünfte, die Geschäftsmodellfrage, ist abgeleitet. Wer die belegten Verschiebungen einzeln betrachtet, sieht eine Anpassung. Wer sie zusammenliest, sieht ein anderes Bild. Es ist nicht das Ende von Software-Engineering-Praktiken. Es ist das Ende der spezifischen Synthese, die Agile genannt wurde, in jener Form, in der sie zwanzig Jahre lang gelehrt und verkauft wurde.

Die offenere Frage betrifft das Tempo. Apostolou et al. zeigen, dass die Industrie noch früh steht. Sieben der zwölf befragten Unternehmen arbeiten auf der niedrigsten Reifestufe. Vier können höhere Stufen demonstrieren, aber nicht produktiv einsetzen. Das verschafft der bestehenden Methodik Zeit. Es ändert aber wenig an der Richtung. Die Gates, Artefakte, Plane-Trennungen, Spec-Strukturen und Governance-Layer, die in der Forschung dokumentiert sind, kommen früher oder später in der Praxis an. Wenn sie ankommen, werden Velocity-Diagramme, Daily-Stand-up-Protokolle und Sprint-Boards nicht abgeschafft. Sie werden nur immer offensichtlicher das Falsche zeigen.

Anmerkung zur Evidenz und Methodik

Der Essay stützt sich auf eine eigene Auswertung von 22 Arbeiten zur agentischen Softwareentwicklung aus dem Zeitraum Oktober 2025 bis Mai 2026. Es handelt sich nicht um eine formale systematische Literaturübersicht. Auswahl und Lesart sind meine.

Die Belege für die ökonomische, methodische, personelle und metrische Bruchstelle stammen direkt aus den ausgewerteten Arbeiten. Der Abschnitt zur Beraterökonomie geht über das wissenschaftliche Material hinaus und ist als solcher gekennzeichnet. Auch die Frage nach den Lernwegen von Junior-Entwicklerinnen und -Entwicklern zur Seniorität ist eine Ableitung aus den Tätigkeitsverteilungen, die in den Studien beschrieben sind, und keine direkt belegte These der Forschung.

Eine Forschungslücke bleibt deutlich. Es gibt kaum belastbare Längsschnittstudien zu Teams, die über ein Jahr hinweg agentisch arbeiten. Cross-Team-Koordination ist kaum untersucht. Die Übersetzung agiler Metriken in agentische Workflows ist offen. Verantwortung nach Incidents, Performance-Bewertung und Skill-Entwicklung sind ebenfalls unterbelichtet.

Völlig offen ist die kaufmännische Planung und Einordnung der Werthaltigkeit der produzierten Ergebnisse.

Literatur

Die folgende Liste nennt die lokal ausgewerteten Fassungen. Bei arXiv-Arbeiten verweist der Link auf die jeweilige Abstract-Seite.

Agile SDLC KI Agenten Methodik Forschung Scrum