In Kürze: Wenn Code zu günstig ist, muss die Disziplin woanders herkommen
Generative KI beseitigt die natürliche Einschränkung, die teure Entwickler der Softwareentwicklung auferlegt haben. Wenn das Programmieren fast nichts mehr kostet, verschiebt sich die Frage von „können wir es bauen?“ zu „sollten wir es bauen?“ Die Grundsätze des Agilen Manifests sorgen für die Disziplin, die diese Kosten früher erzwungen hat. Ignorieren Sie diese auf eigene Gefahr, wenn Ralph Wiggum in der nächsten KI-Phase auf Agile im Alltag trifft.
Der Unsinn über KI und Agile
Ihr LinkedIn-Feed ist voll von selbstbewusstem Unsinn über Scrum und Agile und KI.
Ein Lager streut „KI-gestützt“ über Scrum-Praktiken als Rettung in der Not. Sie versprechen, dass KI Ihr Daily Scrum effizienter, Ihre Sprintplanung genauer und Ihre Retrospektiven aufschlussreicher machen wird. Die Autoren haben zwar keine Ahnung, wozu Scrum eigentlich da ist, und KI verstärkt jetzt ihre Verwirrung noch, da sie nun selbstbewusster präsentiert wird. (Dunning-Kruger als Dienstleistung, sozusagen.)
Das andere Lager erklärt Scrum für obsolet. Sie behaupten, dass KI-Agenten und Vibe Coding bzw. AI Engineering iterative Frameworks überflüssig machen werden, weil die Softwareerstellung praktisch im Schlaf und ohne Grenzkosten erfolgen wird. Scrum ist ihrer Meinung nach ein starres Dogma, das für eine Welt der autonomen Codegenerierung ungeeignet ist; ein Relikt in der neuen Welt der KI-Entwicklung im Stil von Ralph Wiggum.
Beide Lager verfehlen das Thema völlig.
Die finanzielle Kontrolle, das Ralph Wiggum umschifft
Jahrzehntelang gab es bei der Softwareentwicklung eine natürliche Einschränkung: Die Entwickler waren teuer. Ein Team von fünf Entwicklern kostete inklusive Nebenkosten jährlich 750.000 Dollar oder mehr. Diese Kosten erzwangen Disziplin. Man konnte es sich nicht leisten, etwas Falsches zu entwickeln. Jede Funktion musste gerechtfertigt werden. Jede Iteration erforderte Konzentration.
Die Kosten waren ein Hindernis. Sie erzwangen Produktentscheidungen.
Generative KI beseitigt dieses Kriterium. Die Codegenerierung nähert sich den Grenzkosten von Null. Tools wie Cursor, Claude und Codex erzeugen funktionierenden Code in wenigen Minuten. Vibe Coding verwandelt Produktideen noch vor dem Mittagessen in funktionierende Prototypen.
Der Trend beschleunigt sich. Denken Sie an die „Ralph Wiggum“-Technik, die jetzt auf Twitter und LinkedIn kursiert: eine autonome Schleife, die KI-Code-Agenten stundenlang ohne menschliches Zutun arbeiten lässt. Sie definieren eine Aufgabe, gehen weg und kommen zurück, um fertige Funktionen, bestandene Tests und übergebenen Code vorzufinden.
Das Versprechen ist verführerisch: kontinuierliche, autonome Entwicklung, bei der die KI ihre eigene Arbeit bis zur Fertigstellung iteriert. Geoffrey Huntley, der Erfinder dieser Technik, hat eine solche Schleife drei Monate lang laufen lassen, um einen funktionierenden Compiler für Programmiersprachen zu entwickeln. [1] Es überrascht nicht, dass sich der Werbeslogan selbst schreibt: „Programmieren Sie im Schlaf.“
Aber beachten Sie, was mit diesem Modell verschwindet: Das menschliche Urteil darüber, was es wert ist, gebaut zu werden. Überprüfungszyklen, die Architekturfehler aufdecken. Unterschiedliche Auffassungen, die Teams dazu zwingt, sich zu fragen, ob eine Funktion es verdient hat, zu existieren. Wie ein Praktiker über diese autonomen Schleifen bemerkte: „A human might commit once or twice a day. Ralph can pile dozens of commits into a repo in hours. If those commits are low quality, entropy compounds fast.“ [2]
Das finanzielle Kontrolle über die Kosten ist verloren. Die Fülle der Möglichkeiten fühlt sich befreiend an, ist aber auch gefährlich.
Was hindert die Teams daran, schneller als je zuvor in die falsche Richtung zu laufen, wenn es kein Expense Gate gibt? Was hält Unternehmen davon ab, Unmengen von Funktionen zu entwickeln, die niemand will? Was erzwingt die Disziplin, die früher durch die Kosten gewährleistet wurde?
Die Prinzipien die Disziplin erzwingen
Die Antwort ist genau das, was das Agile Manifest bieten soll.
Fangen Sie mit dem ersten Wert an: „Working software over comprehensive documentation“. In einer KI-Welt ist es trivial, Dokumentation zu erstellen. Funktionierende Software zu erstellen ist ebenfalls einfach. Aber funktionierende Software zu erstellen, die tatsächliche Kundenprobleme löst, bleibt schwierig. Bei der Betonung auf „funktionierend“ ging es nie darum, dass der Code kompiliert. Es ging darum, dass die Software etwas Nützliches tut. Diese Unterscheidung ist jetzt wichtiger als zuvor.
Dann ist da noch die Einfachheit: „the art of maximizing the amount of work not done“. Als Softwareentwickler der limitierende Faktor waren, sparte man Geld, indem man Funktionen von zweifelhaftem Wert wegließ. Jetzt, wo die Entwicklung fast nichts mehr kostet, erfordert das Weglassen von Funktionen eher Disziplin als Wirtschaftlichkeit. Der Produktverantwortliche, der fragt: „Sollen wir das bauen?“ statt „Können wir das bauen?“, wird ebenfalls wichtiger als zuvor.
„Working software is the primary measure of progress“. KI kann tausende Codezeilen pro Stunde erzeugen. Keine davon stellt den Fortschritt an sich dar. Stattdessen wird der Fortschritt an der funktionierenden Software anhand der Benutzer gemessen, die sie nützlich finden. Die Zusammenarbeit mit den Kunden und die Feedback-Schleifen sorgen für diese Messung. Eine hohe Output-Geschwindigkeit ohne Validierung präsentiert hingegen eine Verschwendung in noch nie dagewesenem Umfang.
Und dann das Thema technische Exzellenz: „Continuous attention to technical excellence and good design enhances agility“. Dieses Prinzip trennt jetzt das Überleben eines Produktteams vom seinem Scheitern.
Die Tech-Debt-Falle
Autonome KI-Entwicklung produziert Code, der gut genug funktioniert, um ausgeliefert zu werden. Die KI erzeugt plausible Implementierungen, die die Tests bestehen und die unmittelbaren Anforderungen erfüllen. Sechs Monate später entdeckt das gleiche Team den Horror unter der Oberfläche: You build it, you ship it, you run it. And now you maintain it.
Das ist eine „künstliche“ technische Schuld, die sich in noch nie dagewesenem Tempo aufbaut.
Das Agile Manifest forderte eine „nachhaltige Entwicklung“ und Teams, die „ein konstantes Tempo auf unbestimmte Zeit“ beibehalten. Dies waren keine bürokratischen Gemeinkosten, die von Prozessenthusiasten erfunden wurden. Es waren Überlebensanforderungen, die durch schmerzhafte Erfahrungen gelernt wurden.
Organisationen, die diese Prinzipien aufgeben, weil KI die Programmierung billig macht, werden ein vertrautes Muster entdecken: anfängliche Schnelligkeit, gefolgt von einer erdrückenden Verlangsamung. Der Code, der so einfach zu erstellen war, wird unmöglich zu warten. Die Funktionen, die so schnell zur Verfügung standen, werden zu Verbindlichkeiten, die nicht sicher geändert werden können.
Technische Exzellenz ist in einer KI-Welt keine Option. Sie ist der Unterschied zwischen einem Produkt und einem Haufen unwartbaren Codes.
Der „Sollten wir es bauen“-Rahmen
Die grundlegende Frage der Produktentwicklung war schon immer: Bauen wir das Richtige?
Als die Entwicklung noch teuer war, zwang der Aufwand selbst zu dieser Frage. Die Teams konnten es sich nicht leisten, alles zu bauen, also mussten sie sich entscheiden. Die Produktverantwortlichen mussten rücksichtslos Prioritäten setzen. Stakeholder mussten Kompromisse eingehen.
Jetzt, wo das KI-gestützte Entwickeln von Produkten preiswert ist, ist der Zwang weg. Unternehmen können alles bauen. Oder sie glauben zumindest, dass sie das können.
Der Druck kommt von oben. Management und Stakeholder berücksichtigen zunehmend eine schnellere Produktbereitstellung, die durch KI-Funktionen ermöglicht wird. Nachträgliche Änderungen, die früher schwierige Gespräche erforderten, scheinen jetzt kostenlos zu sein. Prototypen, die früher Wochen brauchten, können heute innerhalb von Stunden entstehen. Die Erwartungshaltung wird immer größer: Wenn KI es schneller machen kann, warum liefern wir dann nicht mehr? Dieser Druck erschwert diszipliniertes Produktdenken gerade dann, wenn es am wichtigsten ist.
Die Betonung des Agilen Manifests auf „Zusammenarbeit mit dem Kunden“ und „Reagieren auf Veränderungen“ ist genau deshalb so wichtig, weil die Anforderungen durch Product Discovery und nicht durch Spezifikation entstehen. Feedbackschleifen mit echten Benutzern sind wichtiger, wenn Teams schneller funktionierende Software produzieren können. Ohne diese Schleifen erzeugen Teams Funktionen in einem Vakuum, losgelöst von den Menschen, die sie für wertvoll halten müssen.
Der Produktmanager, der diese Disziplin beherrscht, wird unersetzlich. Der Produktverantwortliche, der das Backlog als Parkplatz für jede Idee behandelt, wird zu einer massiven Bürde, wenn er die Schaffung von KI-generierten Ausschuss zuläßt.
Was bleibt und was sich ändert im Zeitalter von Ralph Wiggum und Agile
Die zentralen Feedbackschleifen bleiben unverzichtbar: etwas Kleines entwickeln, es den Nutzern präsentieren, aus den Reaktionen lernen, anpassen. Dieser Rhythmus existierte bereits vor allen Frameworks. Er wird auch alles überdauern, was als Nächstes kommt.
Iterationszyklen können sich verkürzen. Wenn Teams in wenigen Tagen statt in Wochen sinnvolle, funktionierende Software produzieren können, sind kürzere Zyklen sinnvoll. Das Prinzip bleibt bestehen: Liefern Sie häufig funktionierende Software. Deren spezifische Kadenz passt sich den Fähigkeiten an.
Sich Herausfordern als Kommunikationpraxis wird kritischer werden. In effektiven Teams haben Entwickler schon immer Produktvorschläge hinterfragt: „Ist das wirklich das Wertvollste, was wir entwickeln können, um die Probleme unserer Kunden zu lösen?“ Diese Spannung ist gesund. Das Leben ist eine Verhandlung, ebenso wie Agile. Wenn KI in wenigen Minuten Implementierungsoptionen generieren kann, wird diese Herausforderung zur wichtigsten Quelle der Disziplin. Die Frage verschiebt sich von „Wie lange wird das dauern?“ zu „Sollen wir das überhaupt entwickeln?“ und „Woher wissen wir, dass es funktioniert?“
Kundenfeedback-Schleifen werden wichtiger, wenn die Geschwindigkeit zunimmt. Bei diesen Schleifen ging es schon immer darum, die Lücke zwischen dem, was Teams entwickeln, und dem, was Kunden benötigen, zu schließen, den Fortschritt in Richtung sinnvoller Ergebnisse zu überprüfen und den Weg anzupassen, wenn die Realität den Annahmen widerspricht. Wenn Teams schneller mehr funktionierende Software produzieren können, werden diese Kontrollpunkte präziser. Die Frage verschiebt sich von „Sehen Sie, was wir entwickelt haben“ zu „Was sollten wir als Nächstes entwickeln, basierend auf dem, was wir gelernt haben?“
Die tägliche Koordination passt sich in ihrer Form an, nicht in ihrem Zweck. Das Ziel bleibt: den Fortschritt überprüfen und den Plan anpassen. Im Kreis zu stehen und die Aufgaben von gestern zu rezitieren, war schon immer nutzlos im Vergleich zur Beantwortung der Frage: Sind wir noch auf dem richtigen Weg und was blockiert uns? Jetzt wird es entscheidend: Schnellere Implementierungszyklen machen eine häufige Synchronisation wichtiger, nicht weniger wichtig.
Technische Disziplin wird zum Überlebensfaktor, nicht zum Overhead. Das schwierigere Problem besteht darin, Teams dabei zu unterstützen, Qualitätsstandards aufrechtzuerhalten, wenn die Auslieferung reibungslos verläuft. Praktiker, die KI-generierten Code erkennen können, die auf einer sinnvollen Überprüfung bestehen und die Qualitätsdefinitionen vor einer Erosion unter dem Lieferdruck schützen, werden immer wichtiger. Diejenigen, die sich in erster Linie auf den „Prozess“ konzentrieren und dogmatisch vorgehen, werden überflüssig.
Wenn die Implementierung kostengünstig ist, werden Produktentscheidungen zum Engpass. Die Person, die Annahmen schnell validieren, plausible, aber wertlose Funktionen ablehnen und den Fokus beibehalten kann, wird zum wichtigsten Kapital des Teams.
Dies sind Anpassungen, keine Abkehr. Die Prinzipien bleiben bestehen, weil sie ein dauerhaftes Problem angehen: die Entwicklung von Software, die Kundenprobleme in komplexen Umgebungen löst. KI verändert die Kostenstruktur. Sie verändert nicht das ursprüngliche Problem.
Wir werden nicht dafür bezahlt, Scrum zu praktizieren.
Ich habe dies bereits zuvor erwähnt, und es trifft auch hier zu: Wir werden nicht dafür bezahlt, Scrum zu praktizieren. Wir werden dafür bezahlt, die Probleme unserer Kunden innerhalb der vorgegebenen Rahmenbedingungen zu lösen und gleichzeitig zur Nachhaltigkeit des Unternehmens beizutragen.
Vollständige Offenlegung: Ich verdiene einen Teil meines Lebensunterhalts damit, Menschen in Scrum zu schulen. Ich habe ein persönliches Interesse an diesem Thema. Aber dies ist nur dann von Bedeutung, wenn Scrum den Teams tatsächlich dabei hilft, einen Mehrwert zu schaffen. Wenn Scrum Ihnen hilft, Ihre Ziele zu erreichen, nutzen Sie Scrum. Wenn Teile von Scrum in Ihrem Kontext nicht mehr diesem Ziel dienen, passen Sie es an. Der Scrum Guide selbst besagt, dass Scrum ein Rahmenwerk ist, keine Methodik. Es ist absichtlich unvollständig.
Die Befürworter der These „Scrum ist veraltet” kritisieren eine Karikatur: starre Zeremonien, die dogmatisch und ohne Rücksicht auf Ergebnisse durchgesetzt werden. Diese Karikatur existiert in einigen Unternehmen. Es handelt sich dabei nicht um Scrum. Es ist eine schlechte Umsetzung, vor der das Agile Manifest in seinem ersten Wert warnt: „Individuen und Interaktionen stehen über Prozessen und Werkzeugen.”
Die Frage ist nicht, ob man Agile buchstabengetreu praktizieren soll. Die Frage ist, ob Ihr Team über die Feedbackschleifen, die Disziplin und die Kundenorientierung verfügt, um zu vermeiden, dass mit AI-Geschwindigkeit das Falsche entwickelt wird. Wenn Sie diese Dinge haben, ohne sie als „Agile“ zu bezeichnen, ist das in Ordnung. Bezeichnen Sie es, wie Sie möchten. Die Bezeichnungen sind nicht von Bedeutung. Die Ergebnisse sind es.
Wenn Ihnen diese Dinge fehlen, wird KI Sie nicht retten. Sie wird Ihr Scheitern nur beschleunigen.
Fazit: Lagern Sie Ihr Denken nicht aus
Die Werkzeuge haben sich verändert. Die grundlegende Herausforderung ist dieselbe geblieben.
Es bleibt schwierig, Software zu entwickeln, die Kunden in komplexen Umgebungen, in denen Anforderungen eher durch Entdeckung als durch Spezifikationen entstehen, als wertvoll empfinden. Die Kostenbarriere ist weggefallen, aber die Notwendigkeit von Disziplin bleibt bestehen.
Die Prinzipien des Agilen Manifests sorgen für diese Disziplin. Sie sind keine Relikte einer Welt vor der KI. Sie sind das Gegenmittel gegen durch KI beschleunigte Verschwendung.
Lagern Sie Ihr Denken nicht an die KI aus. Die Fähigkeit, Code sofort zu generieren, beantwortet nicht die Frage, auf die es ankommt: Nur weil Sie ein Feature schnell entwickeln könnten, sollten Sie es auch tun?
Welche Disziplin hat in Ihrem Unternehmen die alte „Kostenkontrolle“ ersetzt? Oder hat noch nichts sie ersetzt?
Ralph Wiggum & Agile: The Sources
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.