Die Kommentare zu meinem letzten Post zeigen ein Missverständnis, das ich selbst provoziert habe. „Scrum ist tot“ klingt wie ein Frontalangriff auf Agilität. Das Gegenteil ist gemeint.
Ich sage: Agilität ist wichtiger denn je. Scrum ist das falsche Vehikel für den neuen Takt.
Das ist kein Wortspiel. Das ist ein Unterschied, der in der Praxis alles verändert.
Das Manifest gilt. Komplett.
In meinem Whitepaper „Ein Prozess zur KI-gestützten Softwareentwicklung“ beziehe ich mich explizit auf alle zwölf Prinzipien des Agile Manifests von 2001. Nicht als historische Referenz. Als Grundlage für meinen Prozess.
Frühe und kontinuierliche Auslieferung wertvoller Software? Wichtiger denn je, weil KI den Zyklus von Stunden auf Minuten schrumpft.
Anforderungsänderungen sind willkommen, auch spät? Noch wichtiger, weil sich der Aufwand für eine Änderung dramatisch reduziert hat.
Ständige Aufmerksamkeit auf technische Exzellenz? Unverzichtbar, gerade weil KI schnell schlechten Code produziert, wenn niemand am Steuer sitzt.
Regelmäßige Reflexion und Anpassung? Selbstverständlich, nur nicht im Zwei-Wochen-Takt eines Sprints.
Das Manifest hat keinen Verfallsdatum. Es hat nur eine schlechte Implementierung bekommen, die jetzt nicht mehr passt.
Das Gegenargument, das ich ernst nehme
„Richtiges Scrum ist flexibel genug. Scrum schreibt keine zwei Wochen vor. Scrum schreibt keinen bestimmten Daily-Stil vor.“
Das höre ich oft. Es stimmt sogar, als Beschreibung eines Prinzips.
Das Problem: Wer jeden Einwand mit „das ist dann kein richtiges Scrum“ beantwortet, macht Scrum unfalsifizierbar. Ein Framework, das sich jeder Kritik entzieht, indem es sich selbst neu definiert, ist kein Framework mehr. Es ist eine Haltung.
Für Haltungen brauche ich kein Zertifikat. Und kein Scrum.
Boris Gloger, einer der bekanntesten Scrum-Vertreter im deutschsprachigen Raum, schreibt selbst: „Scrum ist tot, aber nur die alte, oberflächliche Art, Scrum zu betreiben.“ Die Scrum-Community selbst diskutiert seit mindestens zwei Jahren, dass „mechanisches Scrum“ nicht mehr funktioniert.
Meine Frage: Wenn das, was in 90% der Unternehmen als Scrum läuft, „kein richtiges Scrum“ ist, was sagt das dann über Scrum als praxistaugliches Framework aus?
Warum der Takt das entscheidende Problem ist
Scrum wurde für eine Welt gebaut, in der menschliche Teams Zeit brauchen, um zu lernen. Der Sprint gibt diesem Lernen einen Rahmen. Zwei Wochen, weil das die natürliche Kadenz menschlicher Arbeit war.
Diese Annahme stimmt nicht mehr.
Wenn die Durchlaufzeit von Anforderung zu lauffähigem, getesteten Code auf Stunden schrumpft, ist ein zweiwöchiger Sprint nicht falsch, er ist grobkörnig. Der Scrum-Prozess um den Sprint herum wird zum Bottleneck. Planning, Review, Retrospektive, Backlog-Grooming, alles im Rhythmus eines Takts, der sich aufgelöst hat.
Ein Entwickler beschrieb das 2025 so: Bis er ein Ticket erstellt, im Sprint Planning erklärt, geschätzt und zugewiesen hätte, war das Feature bereits fertig. Nicht halb fertig. Fertig, getestet, dokumentiert, gemergt.
Das ist keine Ausnahme. Das ist der neue Normalfall.
Flow ist die Antwort. Kanban ist das Werkzeug.
Wenn der Takt nicht mehr der Sprint ist, sondern das Issue, brauche ich ein System, das das abbildet.
Kanban tut das. Ich arbeite mit einem Kanban-Board als zentralem Artefakt. Das Issue ist die Single Source of Truth. Von der Anforderung zum Pull Request in einem kontinuierlichen Flow. Kein Sprint-Start, kein Sprint-Ende, kein Planning-Meeting, das den nächsten Zyklus einläutet.
Was bleibt: Stakeholder-Reviews, regelmäßig aber nicht sprint-gebunden. Retrospektiven, aber auf KI-Retrospektiven ausgerichtet, weil sich die Fragen verschoben haben. Issue-Grooming, aber im Dialog mit der KI, nicht in einem Meeting aller Beteiligten.
Das Agile Manifest nennt das „Reagieren auf Veränderung mehr als das Befolgen eines Plans“. In einer Welt, in der Anforderungen sich schneller umsetzen lassen als planen, ist das fast ein Plädoyer gegen den Sprint-Plan.
Was ich den Kritikern zugestehe
Ute Hamelmann hat in den Kommentaren geschrieben, er sehe die Idee, „den Menschen aus der Programmierung am besten ganz zu eliminieren“, kritisch. Das teile ich vollständig.
Mein Prozess ist kein Aufruf zur Mensch-losen Entwicklung. Er ist das Gegenteil. Wenn die KI das Tippen übernimmt, werden menschliche Entscheidungen wichtiger, nicht überflüssiger. Wer priorisiert? Wer entscheidet, ob das Richtige gebaut wird? Wer erkennt, dass der generierte Code zwar kompiliert, aber die falsche Architektur hat?
Das sind keine KI-Aufgaben. Das sind menschliche Aufgaben, die im alten Scrum-Rhythmus oft zu kurz kamen, weil die Zeit für Zeremonien draufging.
Ich nenne das den „Driver Seat“: Der Mensch bleibt am Steuer. Nicht weil die KI das so will, sondern weil gute Software menschliche Verantwortung braucht.
Fazit
Agilität hat gewonnen. Das Manifest trägt. Die zwölf Prinzipien sind aktueller als 2001.
Scrum war ein gutes Vehikel für eine Welt, die es nicht mehr gibt. Das ist kein Angriff auf die Menschen, die Scrum gut gemacht haben. Es ist eine Bestandsaufnahme.
Das nächste Framework, das jetzt verkauft wird, hat vermutlich die gleiche Halbwertszeit. Deswegen setze ich auf Prinzipien, nicht auf Prozesse. Auf Flow, nicht auf Sprints. Auf das Issue als Takt, nicht auf den Sprint als Planungseinheit.
Wer das mechanisches Kanban nennt, dem gebe ich dieselbe Antwort, die ich für mechanisches Scrum bekomme: Vielleicht. Dann nenn es halt nicht Kanban.
Schreibe einen Kommentar