Scrum ist tot, Kanban ist zurück: Warum KI-gestützte Entwicklung tägliche User Acceptance Tests ermöglicht

Die verschobene Constraint: Von teurer Implementierung zu teuren Entscheidungen

Scrum entstand 1995 in einer Welt, in der Implementierung die kritische Ressource war. Jede Codezeile kostete Zeit, jeder Deploy war riskant, User Acceptance Testing erfolgte in wochenlangen Zyklen am Ende eines Sprints. Die Methodik optimierte genau diese Constraint: Bündle Anforderungen, plane in festen Iterationen, liefere in kontrollierten Releases.

Diese Welt existiert nicht mehr. Eine Harvard-Business-School-Studie von Dell'Acqua et al. (2025) zeigt: Einzelne Entwickler mit KI erreichen die Performance ganzer Teams ohne KI. Teams mit KI arbeiten 12-16% schneller. Gleichzeitig ermöglichen KI-gestützte Test-Tools tägliche User Acceptance Tests – ein Bottleneck, der traditionell Continuous Delivery verhinderte, löst sich auf.

Der neue Bottleneck ist nicht mehr 'Wie schnell können wir implementieren?', sondern 'Welche Entscheidungen treffen wir?' Produktvision, Priorisierung, strategische Ausrichtung – das sind die teuren Ressourcen. Scrum optimiert jedoch weiterhin die alte Constraint: Sprint Planning, feste Zyklen, gebündelte Releases. Das führt zu einem Paradoxon, das der Scrum Expansion Pack (Jocham/Sutherland, Januar 2026) dokumentiert: 78% der Organisationen nutzen KI in der Entwicklung, aber 80% sehen keinen messbaren Business-Impact.

Warum Scrum zum Bottleneck wird: Wenn Features schneller fertig sind als Tickets

Die Realität in KI-beschleunigten Teams: Ein Entwickler erhält eine Anforderung, implementiert sie mit KI-Unterstützung in zwei Stunden, führt automatisierte Tests durch und liefert. Bis das Jira-Ticket erstellt, kategorisiert und in den Sprint aufgenommen ist, ist das Feature längst produktiv. Der Prozess wird zum Overhead.

• Sprint Planning dauert länger als die Implementierung vieler Features
• Retrospektiven analysieren Workflows, die sich bereits dreimal verändert haben
• Daily Standups berichten über abgeschlossene Arbeit statt aktuelle Blocker
• Velocity-Messung wird bedeutungslos, wenn Throughput exponentiell steigt

Yuji Isobe beschreibt in seiner Analyse (Medium, Juni 2025), warum Kanban-Flow für explorative KI-Tasks besser geeignet ist: Unpredictable, experimentelle Entwicklung passt nicht in fixe Sprint-Boundaries. Pienso bestätigt: Fixed Sprint Planning kollidiert mit der Natur von KI-gestützter Entwicklung, die iterativ und erkundend ist – nicht planbar in Zwei-Wochen-Zyklen.

Kanban kehrt zurück: Continuous Delivery und tägliche UAT als neue Normalität

Kanban wurde oft als 'Scrum light' abgetan – ein Framework für Support-Teams, nicht für strategische Produktentwicklung. Doch genau die Eigenschaften, die es scheinbar schwächer machten, werden zu Stärken: keine festen Zyklen, kontinuierlicher Flow, Pull-Prinzip statt Push-Planung.

KI macht User Acceptance Testing praktikabel für tägliche Releases. Taazaa dokumentiert (Dezember 2025): Traditionelles UAT war der Bottleneck für Continuous Delivery – manuelle Tests, Stakeholder-Koordination, mehrtägige Feedback-Zyklen. KI-gestützte Test-Tools ändern das fundamental: Automatisierte Acceptance-Kriterien-Validierung, Anomalie-Erkennung, kontinuierliches Feedback.

Der neue Workflow: Von Sprint-Releases zu kontinuierlicher Auslieferung

1. Feature-Anforderung geht in Kanban-Board (WIP-Limits statt Sprint-Kapazität)
2. Entwickler zieht Task, implementiert mit KI-Unterstützung
3. Automatisierte Tests und KI-gestütztes UAT laufen kontinuierlich
4. Bei Passing: Direktes Deployment in Produktion
5. Stakeholder-Feedback fliesst sofort in Backlog zurück
6. Nächster Task wird gezogen – kein Sprint-Ende, keine Batch-Planung

Dieser Flow reduziert Lead Time dramatisch. Statt auf Sprint-Ende zu warten, erreichen Features Nutzer in Stunden oder Tagen. Das Business kann schneller lernen, Hypothesen validieren, pivotieren.

Die Gegenposition: Warum Scrum.org sagt, dass Scrum relevanter wird, nicht obsolet

Fairness gebietet: Die Scrum-Community argumentiert nicht, dass sich nichts ändern muss. Die Position von Scrum.org (Oktober 2025) ist differenzierter: Scrum basiert auf empirischen Prinzipien – Transparenz, Inspektion, Anpassung. Diese sind technologie-unabhängig. KI macht sie nicht obsolet, sondern kritischer.

KI erhöht die Komplexität und Unsicherheit in der Produktentwicklung. Genau deshalb brauchen wir empirische Prozesse – nicht weniger, sondern intensiver. Die Frage ist nicht Scrum oder nicht, sondern wie wir Scrum anpassen.

SD Times (Juni 2026) schlägt pragmatische Anpassungen vor: kürzere, weniger rigide Zeremonien, aber iterative Auslieferung und menschliche Koordination bleiben essenziell. Sprint-Länge von zwei Wochen auf drei Tage reduzieren. Daily Standups zu Async-Updates machen. Velocity durch Flow Efficiency ersetzen.

Diese Position hat Substanz. Nicht jede Organisation ist bereit für Continuous Delivery. Nicht jedes Produkt profitiert von täglichen Releases. Regulierte Branchen brauchen weiterhin strukturierte Review-Zyklen. Die Frage ist: Ist das eine Anpassung von Scrum – oder bereits ein neues Framework?

Ein neues Framework oder Scrum 2.0? Was Schweizer Entscheider wissen müssen

Die ehrliche Antwort: Wir wissen es noch nicht. Was sich abzeichnet, ist kein klarer Sieger zwischen Scrum und Kanban, sondern eine fundamentale Neuordnung der Software-Entwicklung. Rollen verändern sich radikal – wie in 'Von Job-Titeln zu Archetypen: Wie KI klassische Software-Rollen auflöst' beschrieben.

Die Risiken sind real. GitClear dokumentiert (2024): Mit steigender KI-Adoption sank Refactoring von 25% (2021) auf unter 10% (2024), Code-Duplikation stieg um das Achtfache. Stack Overflow zeigt: Entwickler-Sentiment zu KI-Tools sank von über 70% (2023) auf 29% (2025). Eine Anthropic-Studie (Shen/Tamkin 2026) belegt: Teilnehmer mit KI schnitten bei Verständnis-Tests 17% schlechter ab – die grösste Lücke beim Debugging.

FINMA-Konformität und revDSG bei KI-gestütztem UAT

Schweizer Finanzdienstleister können nicht einfach zu täglichen Releases wechseln. FINMA verlangt dokumentierte Change-Prozesse, Risk Assessments, Audit Trails. KI-gestützte UAT-Tools müssen revDSG-konform sein – keine Personendaten in Cloud-basierten Test-Systemen ohne geeignete Garantien.

• On-Premise-Deployment von KI-Test-Tools oder Schweizer Cloud-Provider mit Datensouveränität
• Dokumentierte Validierung der KI-Test-Logik (Nachvollziehbarkeit für Audits)
• Manuelle Review-Stufe für kritische Changes trotz Automatisierung
• Integration in bestehende ITSM-Prozesse (nicht Ersatz)

Das bedeutet nicht, dass Continuous Delivery unmöglich ist – aber sie erfordert ein Hybrid-Modell. Wie in 'Die Pilot-Produktion-Lücke: Warum 78% der KI-Agenten nie produktiv gehen' analysiert: Der Schritt von Pilot zu Produktion scheitert oft an regulatorischen und Governance-Anforderungen.

Handlungsempfehlungen: Evolution statt Revolution, aber ohne Selbsttäuschung

Die Versuchung ist gross, entweder alles über Bord zu werfen oder so zu tun, als ändere sich nichts. Beides ist falsch. Die produktive Haltung: experimentiere strukturiert, messe ehrlich, optimiere den neuen Bottleneck.

1. Identifiziere deine aktuelle Constraint: Ist es noch Implementierung – oder bereits Entscheidungsfindung, Koordination, Produktvision?
2. Starte Experimente in nicht-kritischen Produktbereichen: Ein Team auf Kanban + tägliche KI-UAT, eins auf angepasstes Scrum. Messe Lead Time, Quality Metrics, Team Satisfaction.
3. Investiere in echte Metriken: Flow Efficiency, Deployment Frequency, Mean Time to Recovery – nicht nur Story Points. Velocity aus der Scrum-Ära misst nicht mehr, was zählt.
4. Bilde Product Owner und Stakeholder weiter: Der neue Bottleneck ist ihre Entscheidungsgeschwindigkeit. Wenn ein Feature in zwei Stunden entwickelbar ist, aber drei Tage auf Freigabe wartet, liegt das Problem nicht bei Scrum oder Kanban.
5. Schütze Qualität aktiv: Setze Code-Review-Standards, Refactoring-Quoten, Verständnis-Tests. KI beschleunigt – aber ohne Guardrails in Richtung technischer Schulden.

Die strategische Frage ist nicht 'Scrum oder Kanban?', sondern 'Wie optimieren wir für die neue Constraint?' Wie in 'Abwarten oder handeln? Warum KI-Zögern 2026 teurer ist als strukturiertes Investieren' argumentiert: Wer 2026 noch in Sprint-Zyklen denkt, die für Pre-KI-Geschwindigkeiten designed wurden, verliert nicht an Konkurrenten – sondern an die eigene Trägheit.

Fazit: Das Ende von Scrum, wie wir es kannten – aber nicht das Ende empirischer Produktentwicklung

Scrum ist nicht tot im Sinne von 'vollständig obsolet'. Aber Scrum, wie es 1995 konzipiert und in den 2000ern und 2010ern praktiziert wurde – fixe Zwei-Wochen-Sprints, Sprint Planning als zentrales Planungsinstrument, Velocity als Haupt-Metrik – passt nicht mehr zu Workflows, in denen ein Individuum die Leistung eines Teams erreicht und Features schneller entwickelt werden als Prozesse sie erfassen können.

Kanban kehrt nicht zurück, weil es überlegen ist, sondern weil die Umstände sich geändert haben. Continuous Delivery ist keine theoretische Idealvorstellung mehr, sondern praktikable Realität dank KI-gestützter UAT. Die Constraint verschob sich. Frameworks müssen folgen.

Was bleibt: empirische Prinzipien. Transparenz über was wirklich passiert (nicht was geplant war). Inspektion der Ergebnisse (nicht nur Outputs). Anpassung basierend auf Evidenz. Diese Prinzipien sind wertvoller denn je – aber ihre Umsetzung braucht wahrscheinlich ein komplett neues Framework. Ob wir es 'Scrum 2.0', 'KI-native Agile' oder ganz anders nennen, ist zweitrangig.

Entscheidend ist: Optimiere für die richtige Constraint. Und 2026 ist das nicht mehr die Implementierung.