Abschied von Agile
(lewiscampbell.tech)- Eine kritische Neubewertung der Agile-Methodik, die die Softwarebranche beherrscht hat: In der Praxis sei sie kaum mehr als eine Ansammlung vager Prinzipien und die Neuverpackung bereits gelöster Probleme gewesen
- Die Gegenüberstellung zu Waterfall sei weitgehend ein Trugbild, und zentrale Konzepte wie iterative Entwicklung und Kundenbeteiligung seien bereits in Forschungen der 1970er Jahre formuliert worden
- Agile wurde stets nur als Gegenteil des Waterfall-Modells definiert, obwohl die Grenzen des Waterfall-Modells bereits in den 1970er Jahren allgemein bekannt waren
- Mit dem jüngsten Aufkommen von Large Language Models (LLM) gewinnt Spec-Driven Development wieder an Bedeutung, und dokumentenzentrierte Entwicklung rückt erneut in den Vordergrund
- Der Agile-Leitsatz „funktionierende Software statt umfassender Dokumentation“ wandelt sich nun zu der Einsicht: „Umfassende Dokumentation erzeugt funktionierende Software“
- Es ist an der Zeit, die von Agile hinterlassene Unschärfe hinter sich zu lassen und zu klaren Prinzipien und einem ingenieurmäßigen Ansatz zurückzukehren
> RIP Agile, we hardly knew ye.
> And I mean that literally - because no one was ever clear on what it was.
> Ruhe in Frieden, Agile. Wir haben dich kaum wirklich gekannt.
> Und das ist ganz wörtlich gemeint – denn niemand wusste je so genau, was es eigentlich war.
Das Identitätsproblem von Agile
- Agile war eine gewaltige Strömung, die die gesamte Softwarebranche erfasste, verbreitete sich aber faktisch als Konzept, dessen Bedeutung unklar blieb
- Immer wenn Zweifel aufkamen, lautete die Antwort wiederholt: Das sei nicht das echte Agile
- Liest man das Agile Manifest (2001) tatsächlich, findet man kaum konkrete Anleitungen, sondern eher vage Sinnsprüche wie „Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung“
- Prinzipien wie „Anforderungsänderungen selbst spät in der Entwicklung willkommen heißen“ sind kommerziell unrealistisch
- Unter dem Banner des „wahren Agile“ wurde den Problemen der Praxis immer wieder ausgewichen, als hätten sie mit dem Manifest nichts zu tun
- Wenn die Agile-Industrie Agile nicht richtig praktiziert und das Manifest selbst inhaltlich dünn ist, stellt sich die Frage, worin Agile überhaupt konkret besteht
„Ein Waterfall-Gespenst geht in der Software um“
- Agile wurde immer nur darüber definiert, was es nicht ist: Waterfall. Wer nicht Agile mache, mache Waterfall, und Waterfall funktioniere nicht – so die Logik
- Dass Waterfall nicht funktioniert, war jedoch seit 1970 bereits bekannt, und Winston W. Royce erklärte die Gründe dafür präzise
- Royce empfahl als Alternative, mit Programmdesign zu beginnen, Software-Prototypen zu erstellen, um Anforderungen zu schärfen, und den Kunden formell, tiefgehend und kontinuierlich einzubinden
- All dies wurde später als Innovation von Agile dargestellt, stand aber tatsächlich bereits im Jahr nach der Mondlandung (1970) geschrieben
- Fußnote 1: Wie gelang den Programmierern des Apollo Guidance Computer eine solche Leistung ganz ohne Story Points und ohne das Prinzip zu kennen, dass „kontinuierliche Aufmerksamkeit für technische Exzellenz die Agilität erhöht“?
Das Bell-Thayer-Papier von 1976 und die Geschichte iterativer Entwicklung
- Das Papier von Bell und Thayer aus dem Jahr 1976 gilt als die erste Veröffentlichung, die den Begriff „Waterfall“ verwendete; der Begriff selbst diente dort als Beispiel für etwas, das man gerade nicht tun sollte
- Das Fazit der empirischen Untersuchung in dieser Arbeit: Fehler in Anforderungen werden im Softwareentwicklungsprozess erst dann entdeckt, wenn man versucht, die Anforderungen durch das Design zu erfüllen
- Iterative Entwicklung war nichts Neues und wurde schon Jahrzehnte vor Agile fortlaufend verfeinert
- Auch bevor das Manifest die Branche angeblich befreite, war Waterfall nicht mehr Stand der Technik, und kaum jemand zweifelte ernsthaft an der Wirksamkeit von Anforderungen und Spezifikationen
Der Aufstieg von Spec-Driven Development und das Danach von Agile
- Mit der Verbreitung von Large Language Models (LLM) verstärkt sich der Trend, dass Programmierer wieder Spezifikationen (specifications) schreiben
- LLMs sind anfällig für mehrdeutige Eingaben, weshalb eine klare Problembeschreibung zunehmend als Weg gilt, korrekten Code zu erzeugen
- Wenn Agile „funktionierende Software statt umfassender Dokumentation“ betonte, stellt Spec-Driven Development die Gegenthese auf: „Umfassende Dokumentation erzeugt funktionierende Software“
- Royce wies bereits 1970 darauf hin, dass Dokumentation, Spezifikation und Design bis zum Schreiben des Codes im Grunde dasselbe Konzept sind, und dass bei schlechter Dokumentation auch das Design schlecht ist
- Betont wird dabei, dass ohne Dokumentation auch kein Design existiert
- Blickt man auf die Forschungen von 1970 und 1976 zurück, wird deutlich, dass das Agile Manifest von 2001 keine neuen Einsichten geliefert hat
- Agile habe lediglich mit vager Definition und kommerzieller Verpackung bestehende ingenieurmäßige Ansätze ersetzt, ohne echten Fortschritt zu bringen
- Die Fachaufsätze jener Ingenieure seien inhaltlich deutlich klarer gewesen
- Während sich die Softwareentwicklung weiter verändert und entwickelt, ist es an der Zeit, Agile der Geschichte zu überlassen und auf eine neue Perspektive umzuschwenken
- Wir sollten zu den klaren Prinzipien und dem ingenieurmäßigen Denken jener ernsthaften Ingenieure aus der Vergangenheit zurückkehren
21 Kommentare
Ich verstehe nicht, warum man Methodologien so sehr wie heilige Schriften behandelt. Ich finde, dass auch der ursprüngliche Autor zwar nur eine andere Ausrichtung hatte, aber letztlich genauso dogmatisch war.
Ich finde, das Fazit ist etwas überzogen. Kommerzialisierung oder übermäßige Formalisierung können zwar ein Problem sein, aber das heißt nicht, dass Werkzeuge wie Sprints oder Backlogs nutzlos geworden sind. Sie haben auch dabei geholfen, eine horizontale, zielorientierte Meeting-Kultur zu etablieren. Dass SDD wichtiger geworden ist, stimmt zwar, aber weil sich diese Spezifikation selbst schnell und kollaborativ mit KI erstellen lässt, ist das weiterhin agil. Der zweiwöchige Sprint wurde nur auf ein paar Stunden verkürzt; das Wesen der iterativen Verfeinerung scheint mir aber unverändert geblieben zu sein.
Dem stimme ich zu
Schon allein die Botschaften, die uns der Abbau vertikaler Entscheidungsstrukturen und die iterative Verbesserung in kurzen Zyklen hinterlassen, sind groß (natürlich gilt das ebenso für Projektmanagement-Methoden und -Tools).
Die Schlussfolgerung, dass „Agile selbst keine neuen Einsichten geliefert habe und die Gesamtheit der Menschen, die Agile befürworten, als blinde Agile-Fanatiker diffamiert“ werde, scheint mir etwas überzogen.
Sehe ich genauso. Agile ist nach wie vor relevant. Das klingt, als würden Leute ins Blaue hinein reden, die nie in der Praxis gearbeitet haben.
Was für ein unsinniger Text. Der Kern ist doch, dass man schon die Spec selbst agil schreiben muss ... Bei Agile geht es darum, sich schnell an Veränderungen der Kundenanforderungen anzupassen.
Wegen solcher falschen Missverständnisse und halbherzigen Vorstellungen von Agile geraten sowohl Agile als auch die Entwicklungskultur in die falsche Richtung.
Was genau bedeutet es, die Spezifikation selbst agil zu schreiben?
Der Kern des Artikels ist doch von vornherein, dass man gar nicht weiß, was Agilität überhaupt ist. Es wurde immer nur darüber geredet, dass Agile diese und jene Eigenschaften habe und man dies und das tun müsse, aber einen Artikel, der tatsächlich zeigt: Das ist ein Produkt, das mit einer agilen Methodik entstanden ist, habe ich bis heute nicht gesehen. Selbst wenn man sich das Manifest ansieht, bleibt es irgendwie vage. Vielleicht könnten Sie einmal ein konkretes Beispiel zeigen.
Das ist der grundlegende Inhalt, der in den meisten Büchern über agile Methoden vorkommt, etwa Kent Becks Extreme Programming oder Jeff Sutherlands Scrum. Man kann sich auch User Stories ansehen. Die meisten Menschen wissen offenbar nicht genau, dass die Grundlage von Agile kurze Sprints und Demos sind, um sich schnell an Kundenanforderungen anzupassen.
Es sind Punkt 3 und 4. Spezifikationen detailliert zu schreiben, hat eine unendliche Tiefe. Es geht darum, dass es ein Maß gibt, das zur Organisation passt. Wenn man sich die Geschichte erfolgreicher Services anschaut, dann war es meines Wissens in 99 % der Fälle ein wesentlicher Faktor, nicht zu viel Energie darauf zu verwenden, Spezifikationen exakt auszuarbeiten. Man sollte sich darin nicht verlieren. Wenn man sich ansieht, wie Dinge wie Summoners War, Dungeon & Fighter, Zigbang oder Lineage entstanden sind, versteht man das.
Was, wenn ein Waterfall-Zyklus nur einen Tag dauern würde?
In letzter Zeit sehe ich solche Fälle häufiger.
Leider scheint man das am häufigsten zu sehen...
Hierzulande ist Agile für Entwickler nichts weiter als ein Mittel, um Termindruck aufzubauen.
Nach manchen Maßstäben sind heute ohnehin alle agil. Ich frage mich, ob es je eine Zeit gab wie jetzt, in der so schnell ausgeliefert und Feedback eingeholt wird.
Ich weiß nicht, was vom Agilen außer kurzen Release-Zyklen überhaupt noch übrig bleibt.
Backlog und Sprint gab es schon vorher in anderer Form, und auch die Kommunikation mit dem Kunden passt in vielen Punkten nicht zur Realität. Letztlich haben meiner Meinung nach Verbesserungen bei DevOps mehr Fortschritt in der Entwicklung gebracht als Agile.
Schon dieser Text selbst ist nicht agil!
Da man durchaus Code lesen muss, scheint aus dieser Perspektive die Aussage „Code statt Dokumentation“ gültig zu sein, und da Dokumentation als Anweisung vom LLM als dem Ausführenden gelesen werden muss, kann ich ihr aus dieser Perspektive ebenfalls zustimmen. Daher scheint das Fazit zu sein, dass letztlich beides gleichzeitig wichtig ist.
Das Problem heutiger LLM-Produkte ist die technische Schuld, die sich in der Betriebsphase ansammelt. Für einen kontinuierlichen Betrieb müssen Entwickler am Code beteiligt sein, und dafür sollte Code meiner Meinung nach zumindest vorerst noch in der Lage sein, Dokumentation zu ersetzen.
Um den Einwand vorsichtig zu formulieren: Ich denke nicht, dass Code Dokumentation ersetzen kann. Programmiersprachen verfügen noch nicht über die Ausdrucksstärke und Vermittlungskraft natürlicher Sprache, und ganz praktisch: Wer soll all diesen Code überhaupt komplett lesen?
Zu hoffen und sich zu wünschen, einmal Code zu haben, der Dokumentation ersetzen kann, ist wie der Turmbau zu Babel, den man nie vollenden wird.
Da erscheint es mir sinnvoller, sich lieber gründlich mit OOAD zu beschäftigen.
Umgekehrt halte ich es auch für schwierig, dass natürliche Sprache Code ersetzt. Natürliche Sprache ist im Vergleich zu Code zwar schnell, aber viel zu abstrakt. Für das Computing müssen am Ende dennoch die Details ausgearbeitet werden, und es scheint unrealistisch, dass natürliche Sprache diese Rolle übernehmen kann.
Beim Schreiben von Software ist nicht so sehr Abstraktheit das Problem, sondern eher Unklarheit. Natürliche Sprache ist ihrem Wesen nach mehrdeutig. Sie kann verschiedene Bedeutungen haben. Vielleicht funktionieren deshalb Versuche, in natürlicher Sprache zu programmieren, nicht besonders gut. Unter diesen Umständen ist es völlig undenkbar, dass natürliche Sprache Code ersetzt.
Ich kann Ihrer Meinung gut nachvollziehen.
Es gibt eindeutig Bereiche, die sich nicht durch Code ersetzen lassen.
In diesem Sinne wollte ich es etwas anders ausdrücken: Gut lesbarer Code macht es möglich, dass man keine Dokumentation mehr erstellen muss.
Auch die Dokumentation, die sich im Lauf eines langlebigen Softwareprojekts ansammelt, erzeugt bei Entwicklerinnen und Entwicklern kognitive Belastung. Im Kern geht es darum, die Arbeit zu verringern, ständig zwischen Code und Dokumentation hin- und herzuschalten.
Ich denke nicht, dass am Ende ausschließlich Code übrig bleiben kann.
Ich denke, das kann je nach Kontext und Situation unterschiedlich sein.
Vielen Dank für Ihren Kommentar.
Hacker-News-Kommentare
Durch Agile habe ich ein interessantes Phänomen beobachtet
Wenn es scheitert, wird das so interpretiert, dass man es „nicht konsequent genug gemacht hat“.
Dasselbe Muster sehe ich auch bei Cloud, Microservices, Austeritätspolitik usw. — die Ursache des Scheiterns ist immer mangelhafte Umsetzung, nie der Ansatz selbst, denn der gilt als unfehlbar.
Wenn ein Team Agile ausprobiert und es nicht funktioniert, kommt sofort das Abwehrargument: „Dann war das eben kein echtes Agile.“ Am Ende wird Agile zu einem Konzept, das gar nicht scheitern kann.
Das Agile Manifesto behandelt nur Werte und Prinzipien. Das Problem ist eine Unternehmenskultur, die das gewaltsam in einen Prozess pressen will.
Dass man bei Misserfolg zuerst nach innen schaut, ist nicht zwangsläufig schlecht. Im Vergleich dazu, immer äußere Umstände verantwortlich zu machen, kann ein System, das Selbstreflexion fördert, sogar gesund sein.
Eine dem Kunden versprochene Roadmap und flexible Reaktionsfähigkeit lassen sich nur schwer vereinbaren. In der Praxis ahmen planungsgetriebene Organisationen Agile meist nur nach.
Wenn es scheitert, heißt es am Ende nur: „Man hätte mehr Agenten einsetzen müssen.“ Das klingt wie der Witz, dass „Tokens nie wirklich ausreichen“.
Ich habe angefangen, die Formalisierung von Agile zu fürchten
Ich habe ein Team mit 40 Leuten erfolgreich geführt, aber echtes Agile lässt sich auf nur vier Sätze zusammenfassen — Menschen, funktionierende Software, Zusammenarbeit mit dem Kunden und Reagieren auf Veränderung.
Das Problem ist, dass „Agile“ mit großem A inzwischen selbst zu einem unflexiblen Prozess verkommen ist.
Wenn die Zahl der Beteiligten wächst, wird Zielabstimmung schwieriger, und am Ende braucht man doch Kontrolle und Verfahren.
Teilweise war sogar das Recht, Tickets zu erstellen, eingeschränkt — also alles andere als flexibel.
Wenn die Dokumentation fehlt, wird Wartung unmöglich, und am Ende landet man bei YOLO-Entwicklung.
Das Agile in den Großunternehmen, in denen ich gearbeitet habe, war eine Lüge
Ein Kollege sagte einmal: „Wenn man die Arbeit des nächsten Sprints vorher schon macht, wird man immer pünktlich fertig.“
Das heißt: Agile funktionierte dort eher als System zur Erzeugung von Kennzahlen als zur Erledigung echter Arbeit.
Manager sind zufrieden, solange die Zahlen steigen, und das Produkt verkommt zum Nebenprodukt der Statistik.
Es lohnt sich, den Originaltext des Agile Manifesto noch einmal anzuschauen
Das ist der einzige gemeinsame Nenner. Man sollte sich daran erinnern, wie furchtbar Waterfall vor Agile war.
Es war die Waffe, die die Zeit beendet hat, in der feste Termine und fixe Deliverables erzwungen wurden.
Denn wenn Teams wirklich autonom arbeiten, bedroht das ihre eigene Rolle.
Wie Kent Beck in „Extreme Programming“ sagte, war Agile ein Versuch, die Tyrannei eingebildeter Allwissenheit zu vermeiden
Das frühere Waterfall versuchte, schon in der Entwurfsphase alles vorherzusagen, und ignorierte Lernen und Feedback.
Mit der Zeit haben jedoch Rituale und Formen von Agile dessen Wesen überdeckt.
Ich mag Agentic programming weiterhin, aber am Ende bleibt die Rolle des Menschen, der den Kontext zusammenhält, entscheidend.
Der Originalartikel war verwirrend
Erst hieß es, Agile habe nichts Neues geschaffen, dann wurde behauptet, Agile sei tot, sobald LLMs Code schreiben.
Dabei ist der Kern von Agile, unvollständige Spezifikationen anzuerkennen und sie iterativ zu verbessern.
Dieses Prinzip gilt weiterhin.
Agile ist nur eine Variante davon; das Problem waren eher die vielen schlechten Umsetzungen.
Gute Produkte entstehen am Ende immer aus dem Kreislauf Spezifikation → Lernen → Korrigieren.
Prozesse wie Backlog Grooming oder Sprint Review hemmen Änderungen eher, als dass sie sie ermöglichen.
Spezifikationsbasierte Entwicklung wird meiner Meinung nach nicht lange tragen
Funktionierende Software zu bauen und iterativ weiterzuentwickeln, ist immer noch schneller — letztlich also die Rückkehr von Agile.
Die Qualität der Spezifikationen ist gestiegen, und Reviews sind leichter als direkt Code zu prüfen.
Siehe GitHub-Link
Im Manifest stehen keine Begriffe wie Daily Standup oder Agile Coach
Im Kern geht es darum: „Mikromanagt Programmierer nicht.“
Anders gesagt: Gebt motivierten Menschen das Umfeld und das Vertrauen, das sie brauchen.
Kent Beck, Martin Fowler und andere Gründer wollten ursprünglich flexible Leitlinien
Mit der Zeit wurde das Ganze jedoch kommerzialisiert, und fanatische Anhänger sorgten für noch mehr Verwirrung.
Ob es funktioniert, hängt am Ende von den Fähigkeiten und der Haltung der Menschen ab.
Auch die Sprint-Länge sollte an die Situation angepasst werden, und wenn keine Spezifikation existiert, muss das Team selbst eine erstellen.
Auch im KI-Zeitalter bleibt Agile gültig, wenn es von klugen Menschen sinnvoll eingesetzt wird.
Ich habe mich gefragt, was genau mit „eine Spec schreiben“ gemeint ist
In allen Agile-Projekten, an denen ich gearbeitet habe, gab es Designdokumente, und die Tickets wurden aus diesen Dokumenten abgeleitet.
Ticket-basierte Entwicklung ohne Dokumente klingt wie die Hölle.
Jeder interpretiert sie so, wie es ihm passt.
Ein ticketzentrierter Ansatz kommt dem reinen Agile sogar näher.
Bei Fake-Agile tun Dokumente von PO oder PM so, als wären sie die Wahrheit.
Die von dir beschriebene Arbeitsweise kommt meiner beabsichtigten Bedeutung von „eine Spezifikation schreiben“ am nächsten