Wie Agile zu AgileFall wurde
2001 trafen sich siebzehn Softwarepraktiker in einem Skiort in Utah und schrieben ein Dokument, das eine ganze Industrie verändern sollte. Das Agile Manifesto entstand aus echter Frustration: Projekte ertranken in upfront-Planung, übermäßiger Dokumentation und Entwicklungszyklen so lang, dass die Welt sich schon weitergedreht hatte, bis etwas ausgeliefert wurde.
Die Antwort war elegant. Vier Werte. Zwölf Prinzipien. Das Wesentliche: Menschen vor Prozessen, funktionierende Software vor Dokumentation, Kundenzusammenarbeit vor Vertragsverhandlungen, Reagieren auf Veränderung vor dem Befolgen eines Plans.
Was dann passierte, ist bekannt.
Die Unternehmen übernahmen die sichtbare Oberfläche von Agile. Daily Standups standen im Kalender. User Stories füllten Jira-Boards. Sprint-Planning-Meetings fraßen Montagvormittage. Teams bezeichneten sich stolz als "agil."
Aber darunter blieb die alte Logik. Scope wurde noch immer vorab festgelegt. Budgets wurden noch immer aus Anforderungsdokumenten berechnet. Sprints wurden zu zweiwöchigen Wasserfällen. Steve Blank prägte den Begriff dafür: AgileFall.
Warum AgileFall passiert
Das Dreieck des Projektmanagements macht das Problem sichtbar. Klassisches Projektmanagement fixiert das Ziel und die Zeit, berechnet dann, welche Ressourcen nötig sind. Agile dreht das um: Du fixierst die Zeit (ein Sprint) und die Ressourcen (das Team, das du hast), und lieferst das wertvollste funktionierende Inkrement, das du kannst. Scope bleibt flexibel, weil Lernen und Anpassung ins System eingebaut sind.
Diese Umkehrung erfordert eine echte Verschiebung im Denken über Kontrolle, Planung und Vertrauen. Die meisten Organisationen vollzogen sie nie. Sie übernahmen die Methoden, ohne die Werte oder die Managementlogik zu ändern. Martin Fowler hat beschrieben, wie das Wort "agil" semantisch ausgehöhlt wurde, bis es ein Label war, das man auf Praktiken klebt, die mit dem ursprünglichen Denken wenig zu tun haben.
Jetzt passiert es mit KI-Agenten
Heute surrt die Softwarewelt mit einem neuen Toolset: Claude Code, Codex, MCP, RAG-Pipelines, Vektordatenbanken, verwaltete Agenten, Agentic Frameworks, Kontextdatenbanken.
Die Gespräche klingen vertraut:
"Welche IDE soll ich für Agentic Coding nutzen?" "Ist MCP sinnvoll oder überschätzt?" "Claude Code oder Codex, was ist besser?" "Wie baue ich eine Agentic Pipeline wie StrongDM?"
Das sind alles Varianten derselben Frage: Welches Tool brauche ich?
Und es ist die falsche Frage. Wieder.
Nicht weil Tools keine Rolle spielen. Sondern weil kein Tool, kein Framework, kein Protokoll autonome Softwareproduktion liefert, wenn das zugrunde liegende System nicht für Vertrauen, Verifikation und Feedback ausgelegt ist.
Die Shiny-Tool-Falle
Die Benchmarks der führenden Coding-Modelle sind auf Standardaufgaben ungefähr gleichauf. Der Unterschied zwischen Teams, die mit KI-Agenten gute Ergebnisse erzielen, und solchen die enttäuscht sind, liegt nicht primär im gewählten Modell. Er liegt im System um das Modell herum: Wie Arbeit spezifiziert wird, wie Output verifiziert wird, wie Feedback-Schleifen gebaut sind, wie Vertrauen aufgebaut und erhalten wird.
Das Feld ist noch jung. Niemand hat die definitive Toolchain. Anthropic selbst ist transparent darüber: Das Scaffolding und die Harnesses um Agenten herum werden veraltet, wenn die nächste Modellgeneration kommt. Eine Strategie, die auf einem spezifischen Tool aufbaut, baut auf Sand.
Lucas Meijer hat das prägnant formuliert: Jage nicht jedem glänzenden neuen Tool hinterher. Löse das Problem, das du tatsächlich hast.
Die richtige Frage
Wenn "Welches Tool soll ich nutzen?" die falsche Frage ist, was ist dann die richtige?
Welches System brauche ich, damit ich dem Output autonomer Agenten genug vertrauen kann, um ihn zu shippen?
Das ist keine Tool-Frage. Es ist eine Produktionssystem-Frage. Eine Vertrauensfrage.
Sie zu beantworten erfordert Nachdenken über Spezifikation, Verifikation, Feedback, Eskalation und Evidenz, nicht darüber, welches Framework man installiert.
Im dritten Teil dieser Serie zeigen wir konkret, was das bei der Entwicklung von Zedl bedeutet und welche Prinzipien dabei konstant geblieben sind, auch wenn sich die Tools geändert haben.
Wer davon profitiert
- Entwicklerteams, die mit KI-Agenten arbeiten und sich fragen, warum die Ergebnisse inkonsistent sind
- Tech Leads, die eine Strategie für den Einsatz autonomer Agenten entwickeln
- CTOs, die den Unterschied zwischen Tool-Adoption und echtem Systemwandel verstehen wollen
- Alle, die gerade in der AgileFall-Falle stecken und nicht wissen, warum Agile "nicht funktioniert"
Häufige Fragen
Was ist AgileFall konkret? AgileFall beschreibt den Zustand, in dem eine Organisation die sichtbaren Praktiken von Agile (Standup, Sprint, User Stories) übernimmt, aber das alte Wasserfall-Denken darunter beibehält. Scope ist immer noch fix, Flexibilität ist nur auf dem Papier.
Ist Scrum dann schlecht? Scrum ist ein Werkzeug. Wie alle Werkzeuge funktioniert es in dem System, für das es gedacht ist. Mit dem richtigen Werteverständnis als Fundament ist Scrum nützlich. Ohne dieses Fundament wird es zum Ritual.
Welche KI-Tools empfiehlt ex-nihilo? Wir empfehlen keine spezifischen Tools pauschal, weil sie sich zu schnell ändern. Was wir empfehlen: das System zuerst zu designen, dann die Tools darin zu wählen. Wir nutzen aktuell Claude Code intensiv, wissen aber, dass das in einem Jahr anders aussehen kann.
Was bedeutet "das System" konkret bei KI-Agenten? Wie Aufgaben spezifiziert werden, welche Verifikationsschritte jeder Output durchläuft, wo Vertrauensgrenzen liegen (welche Aufgaben brauchen noch menschlichen Review?), und wie Feedback zurück ins System fließt wenn etwas schiefgeht.
Hat Agile versagt? Die Ideen hinter dem Agile Manifesto haben nicht versagt. Die Implementierungen, die die Ideen durch Rituale ersetzt haben, haben versagt. Das ist ein wichtiger Unterschied, gerade jetzt wo wir den gleichen Fehler mit KI wiederholen könnten.
Ist ex-nihilo selbst "agil"? Wir arbeiten iterativ und nutzen Elemente aus Agile wo sie sinnvoll sind. Aber wir würden uns nicht als "agile Organisation" bezeichnen, weil dieses Label zu nichts mehr verpflichtet. Was uns wichtig ist: echte Flexibilität im Scope, kurze Feedback-Schleifen, und Shippen über Planung.