Wenn ich beschreibe, wie ich heute größere Softwarethemen angehe, klingt das zunächst erstaunlich altmodisch. Ich beginne mit einer Idee, arbeite sie ausführlich durch, lasse mir teilweise sehr viele Fragen stellen, treffe möglichst viele fachliche Entscheidungen im Voraus und übergebe anschließend eine ausführliche Spezifikation an Codex.
Das hört sich verdächtig nach Wasserfall an.
Gleichzeitig ist der Prozess aber keineswegs starr. Während der Konzeptphase ändere ich Entscheidungen, verwerfe Teile der ursprünglichen Idee, ergänze neue Anforderungen und kann die gesamte Spezifikation immer wieder neu strukturieren lassen. Sobald erste Ergebnisse aus der Umsetzung zurückkommen, fließen neue Erkenntnisse wiederum in die nächste Runde ein.
Das klingt deutlich agiler.
Irgendwo zwischen diesen beiden Welten entstand bei mir irgendwann scherzhaft der Begriff „SpeedScrum“. Nicht als neue offizielle Entwicklungsmethode und auch nicht mit dem Anspruch, Scrum neu erfunden zu haben, sondern als Beschreibung des Gefühls, dass viele klassische Entwicklungsschritte plötzlich wesentlich schneller und mit deutlich weniger organisatorischem Aufwand ablaufen können.
Auf den ersten Blick sieht es tatsächlich nach Wasserfall aus
Bei größeren Themen beginne ich heute mit einer ausführlichen Konzeptphase, in der ChatGPT mir so lange Fragen stellt, bis die wichtigsten fachlichen Entscheidungen getroffen und bekannte Sonderfälle ausreichend betrachtet wurden. Anschließend entsteht daraus eine strukturierte Markdown-Spezifikation, die Codex als Arbeitsgrundlage erhält.
Der Ablauf wirkt damit zunächst sehr linear:
Idee, Anforderungen, Spezifikation, Umsetzung, Tests und schließlich Deployment.
Genau diese Reihenfolge verbindet man schnell mit klassischen Wasserfallmodellen, bei denen Anforderungen möglichst vollständig festgelegt werden, bevor die eigentliche Entwicklung beginnt.
Der entscheidende Unterschied liegt für mich allerdings darin, dass meine Spezifikation nicht als unveränderliche Wahrheit behandelt wird.
Wenn sich während der Diskussion herausstellt, dass eine ursprüngliche Annahme falsch war, ändere ich sie. Wenn Codex während der Analyse des vorhandenen Projekts auf einen Widerspruch stößt, kann das Konzept erneut angepasst werden. Wenn Tests später zeigen, dass eine Anforderung problematisch war, gehe ich wieder zurück in die Konzeptphase.
Die einzelnen Phasen sind also deutlich erkennbar, aber die Richtung zwischen ihnen ist nicht ausschließlich vorwärts.
Scrum passt ebenfalls nur teilweise
Scrum verfolgt einen anderen Ansatz. Arbeit wird in überschaubare Abschnitte zerlegt, regelmäßig überprüft und auf Basis neuer Erkenntnisse weiterentwickelt. Planung findet nicht einmal vollständig am Anfang statt, sondern begleitet das Produkt über viele Iterationen.
Davon findet sich einiges in meiner heutigen Arbeitsweise wieder.
Ich zerlege größere Vorhaben in kleinere Aufgaben, arbeite iterativ und erwarte ausdrücklich, dass sich Entscheidungen im Laufe eines Projekts verändern können. Mit Agenda entsteht zusätzlich eine Struktur, in der einzelne Arbeitspakete getrennt vorbereitet, freigegeben und bearbeitet werden können.
Trotzdem würde ich meine Vorgehensweise nicht einfach Scrum nennen.
Ich arbeite allein. Es gibt keine Scrum-Rollen, keine Teammeetings, kein Sprint Planning mit mehreren Beteiligten, kein Daily und keinen organisatorischen Abstimmungsaufwand zwischen verschiedenen Menschen. Viele Probleme, für die Scrum sinnvolle Strukturen geschaffen hat, existieren bei mir deshalb in dieser Form gar nicht.
Andere Probleme entstehen dafür neu, weil ich mehrere KI-Systeme und Agenten gleichzeitig koordinieren kann.
KI verändert die Kosten von Planung
Der interessanteste Unterschied liegt für mich weniger in der Frage, welchem bekannten Prozess meine Arbeitsweise am ähnlichsten ist. Spannender finde ich, dass KI die Kosten einzelner Entwicklungsschritte verändert.
Eine sehr ausführliche Anforderungsanalyse konnte früher schnell viel Zeit verschiedener Personen binden. Jede zusätzliche Besprechung, Dokumentation und Rückfrage musste wirtschaftlich gegen die eigentliche Entwicklungszeit abgewogen werden.
Heute kann ich eine Idee über einen langen Zeitraum mit ChatGPT durchgehen, Widersprüche suchen lassen, Varianten vergleichen und am Ende aus dem gesamten Gespräch eine konsolidierte Spezifikation erzeugen.
Die Planung ist dadurch nicht kostenlos, aber sie wird erheblich günstiger.
Das verändert meine Entscheidung darüber, wie viel Vorarbeit sinnvoll ist.
Wenn eine zusätzliche halbe Stunde Konzeptarbeit verhindert, dass Codex mehrere Stunden in die falsche Richtung arbeitet, lohnt sich diese Vorbereitung sehr schnell.
Ausführliche Spezifikationen werden plötzlich wieder attraktiv
In vielen agilen Umgebungen wurden große Spezifikationsdokumente aus gutem Grund kritisch betrachtet. Sie waren teuer zu erstellen, schnell veraltet und vermittelten manchmal eine Sicherheit, die in einem veränderlichen Projekt gar nicht existierte.
Mit KI verschiebt sich dieses Verhältnis.
Eine ausführliche Spezifikation kann heute aus einem ohnehin geführten Gespräch automatisch strukturiert werden. Wenn sich Anforderungen ändern, kann das Dokument mit vergleichsweise wenig Aufwand neu konsolidiert werden. Dadurch verliert eine ausführliche Dokumentation einen Teil ihrer früheren Schwerfälligkeit.
Für mich wird sie deshalb wieder attraktiver, ohne dass ich sie als unveränderlichen Vertrag betrachten muss.
Ich möchte möglichst viel Klarheit vor der Umsetzung erreichen und gleichzeitig die Freiheit behalten, diese Klarheit später wieder zu korrigieren.
Das klingt zunächst widersprüchlich, ist für mich aber einer der größten Vorteile meiner heutigen Arbeitsweise.
Die Umsetzung wird ebenfalls wesentlich schneller
Der zweite große Unterschied liegt natürlich bei Codex.
Eine umfangreiche Spezifikation wäre wenig hilfreich, wenn ich anschließend jede einzelne Zeile selbst schreiben müsste und dadurch Wochen in der Umsetzung gebunden wäre. Genau an dieser Stelle verändert KI den Prozess erneut.
Codex kann eine klar beschriebene Aufgabe wesentlich schneller umsetzen, als ich sie in vielen Fällen selbst programmieren würde. Dadurch werden die Iterationen kürzer.
Ich kann ein Konzept ausführlich vorbereiten, die Umsetzung anstoßen, das Ergebnis prüfen und relativ schnell mit den dabei gewonnenen Erkenntnissen wieder in die nächste Runde gehen.
Ausführliche Planung und schnelle Iteration schließen sich dadurch nicht mehr so stark gegenseitig aus wie früher.
Vielleicht ist genau das mein „SpeedScrum“
Der Begriff ist nicht als fachlich saubere Definition gedacht. Er beschreibt für mich eher die Kombination aus zwei Dingen, die früher schwerer miteinander vereinbar waren.
Auf der einen Seite steht eine intensive Vorabklärung, die fast schon an klassische Spezifikationsmethoden erinnert. Auf der anderen Seite stehen sehr kurze technische Umsetzungszyklen, schnelle Änderungen und die Möglichkeit, Entscheidungen jederzeit neu zu bewerten.
Das Ergebnis ist weder klassischer Wasserfall noch klassisches Scrum.
Wenn ich dafür eine nüchterne Bezeichnung bräuchte, würde ich wahrscheinlich von KI-gestützter spezifikationsgetriebener Entwicklung sprechen.
Das klingt allerdings deutlich weniger charmant als SpeedScrum.
Agenda fügt noch eine weitere Ebene hinzu
Mit Agenda und meinem Gartenstuhl-Test verändert sich der Ablauf noch einmal, weil zwischen Spezifikation und konkreter Umsetzung eine eigene Orchestrierungsebene entsteht.
Codex kann ein größeres Konzept zunächst analysieren und in einzelne Aufgaben zerlegen. Diese Aufgaben werden nicht automatisch alle sofort ausgeführt, sondern landen in Agenda und können dort einzeln freigegeben werden.
Dadurch kann ich ein umfangreiches Thema weit im Voraus durchdenken und vorbereiten, ohne sämtliche Änderungen gleichzeitig starten zu müssen.
Die Planung kann also umfangreich sein, während die konkrete Umsetzung trotzdem in kleinen Einheiten stattfindet.
Gerade diese Kombination macht für mich einen großen Teil der neuen Arbeitsweise aus.
Auch Tests verändern den Rhythmus
Dasselbe gilt für Qualitätssicherung.
Meine automatisierten Tests sollen nicht einfach bestätigen, dass die Umsetzung funktioniert, sondern möglichst Situationen finden, in denen sie von der Spezifikation abweicht. Wenn Fehler weitgehend automatisch gefunden, korrigiert und erneut geprüft werden können, verkürzt sich auch diese Schleife.
Damit entsteht ein Prozess, der sehr ausführliche Planung, schnelle Umsetzung und schnelle Rückkopplung miteinander kombiniert.
Genau diese Kombination wäre in einem klassischen Projekt mit vielen manuellen Übergaben und deutlich langsameren Implementierungszyklen wesentlich teurer.
Die eigentliche Frage ist deshalb nicht Wasserfall oder Scrum
Je länger ich mit dieser Arbeitsweise experimentiere, desto weniger interessiert mich die Frage, welchem bestehenden Modell sie exakt entspricht.
Die interessantere Frage lautet für mich inzwischen:
Welche Methoden ergeben noch Sinn, wenn sich die Kosten der einzelnen Arbeitsschritte grundlegend verändern?
Wenn ausführliche Planung plötzlich viel günstiger wird, kann mehr Vorarbeit sinnvoll sein.
Wenn Implementierung sehr schnell wird, können kleinere Iterationen häufiger stattfinden.
Wenn Dokumentation automatisch aktualisiert werden kann, verliert sie einen Teil ihrer früheren Last.
Wenn Tests weitgehend automatisiert erzeugt und ausgeführt werden können, lässt sich Qualitätssicherung aggressiver betreiben.
Und wenn Agenda mehrere vorbereitete Aufgaben koordinieren kann, verändert sich sogar die Art, wie ich meine eigene Zeit einsetze.
Vielleicht brauchen wir deshalb langfristig weniger Diskussion darüber, ob eine Arbeitsweise ausreichend agil oder ausreichend klassisch ist, und mehr darüber, welche Probleme die jeweiligen Methoden ursprünglich lösen sollten.
Denn genau diese Rahmenbedingungen verändern sich gerade.