Agiles Arbeiten meets KI: Warum klassische Methoden in der Automatisierung versagen

Warum Scrum und Kanban bei KI-Projekten scheitern

Scrum wurde für Software-Entwicklung erfunden.

KI folgt anderen Gesetzmäßigkeiten.

Das zu ignorieren ist der häufigste Fehler, den ich bei meinen Kunden sehe.

Das Sprint-Problem: KI entwickelt sich nicht linear

Ein Sprint dauert 2 Wochen.

Ein Machine Learning Modell kann 3 Wochen brauchen, bis es erste brauchbare Ergebnisse liefert.

Was machst du in Woche 1 und 2? „Wir trainieren noch“ als Sprint-Ergebnis präsentieren?

Ich habe das miterlebt.

Ein Entwicklungsteam hat 6 Sprints lang praktisch nichts Vorzeigbares produziert – obwohl sie hervorragende Arbeit geleistet haben.

Das Problem: KI-Entwicklung hat andere Zeitzyklen.

Manchmal dauert die Datenaufbereitung 4 Wochen, dann funktioniert das erste Modell sofort perfekt.

Manchmal trainierst du 50 verschiedene Ansätze, bis einer funktioniert.

Das passt nicht in 2-Wochen-Rhythmen.

Backlog-Chaos: Wenn Algorithmen die Prioritäten ändern

Product Backlog funktioniert bei Features.

Bei KI ändern sich die Prioritäten durch die Erkenntnisse.

Beispiel aus meiner Praxis:

Wir wollten ein Sentiment-Analyse-Tool für Kundenfeedback bauen.

Geplant waren 5 Features:

1. Positive/Negative Klassifikation
2. Emotionserkennung
3. Themen-Extraktion
4. Trend-Analyse
5. Dashboard

Nach dem ersten Datenexploration stellte sich heraus: 60% unserer Daten waren unbrauchbar.

Plötzlich war Datenbereinigung Priorität 1.

Das stand nirgendwo im Backlog.

Bei KI-Projekten entscheiden oft die Daten über den nächsten Schritt – nicht der Product Owner.

Daily Standups werden zu Weekly Standups (und das ist okay)

„Was hast du gestern gemacht?“

„Hyperparameter optimiert.“

„Was machst du heute?“

„Hyperparameter optimiert.“

„Gibt es Blocker?“

„Das Training läuft noch 12 Stunden.“

So sehen Daily Standups bei KI-Teams aus.

Sinnlos.

KI-Entwicklung hat längere Feedback-Schleifen.

Ein Modell zu trainieren dauert manchmal Tage.

Einen A/B-Test auszuwerten braucht statistische Signifikanz – das sind oft Wochen.

Tägliche Synchronisation macht keinen Sinn, wenn sich täglich nichts Wesentliches ändert.

Die drei fundamentalen Unterschiede zwischen Software- und KI-Entwicklung

Softwareentwicklung: Du weißt, was du baust.

KI-Entwicklung: Du weißt, was du ausprobierst.

Das ist der Kernunterschied.

Unvorhersagbarkeit statt Planbarkeit

Bei Software schreibst du Code, er funktioniert (oder funktioniert nicht).

Bei KI trainierst du ein Modell, es funktioniert zu 73% – und du weißt nicht warum.

Nicht wegen schlechtem Code.

Sondern wegen unerwarteter Datenprobleme oder Modell-Performance.

Du kannst nicht planen, wann ein Modell die gewünschte Accuracy erreicht.

Du kannst nur experimentieren und iterieren.

Das macht klassische Projektplanung unmöglich.

Experimenteller vs. linearer Entwicklungsprozess

Softwareentwicklung folgt einem linearen Prozess:

Requirements → Design → Implementation → Testing → Deployment

KI-Entwicklung ist ein Experimentierkreislauf:

Hypothesis → Experiment → Evaluation → Learning → neue Hypothesis

80% meiner Zeit in KI-Projekten verbringe ich mit Experimenten, die nicht funktionieren.

Das ist normal.

Das ist sogar gut.

Jedes gescheiterte Experiment bringt dich der Lösung näher.

Bei Software wäre 80% Failed Code inakzeptabel.

Bei KI ist es der Weg zum Erfolg.

Datenqualität als kritischer Erfolgsfaktor

Software funktioniert mit synthetischen Testdaten.

KI steht und fällt mit echten, hochwertigen Daten.

Ich habe Projekte erlebt, wo das Team 6 Monate perfekten Code geschrieben hat.

Das Modell war trotzdem nutzlos.

Weil die Daten schlecht waren.

Bei KI-Projekten verbringst du 60-80% der Zeit mit Datenarbeit:

• Daten sammeln
• Daten bereinigen
• Daten labeln
• Daten validieren
• Data Pipelines bauen

Das steht in keinem Software-Sprint-Plan.

Aber ohne funktioniert KI nicht.

AI-first Arbeitsweisen: Was nach Scrum kommt

Ich arbeite seit 3 Jahren mit verschiedenen Ansätzen für KI-Teams.

Hier ist, was wirklich funktioniert.

Hypothesis-driven Development statt User Stories

Vergiss User Stories.

„Als Nutzer möchte ich…“ funktioniert nicht bei KI.

Stattdessen: Hypothesis-driven Development.

Jede Entwicklungsphase startet mit einer messbaren Hypothese:

„Wenn wir Feature X hinzufügen, verbessert sich die Modell-Accuracy um mindestens 5%.“

Oder:

„Wenn wir Algorithmus Y verwenden, reduziert sich die Trainingszeit um 50%.“

Jede Hypothese hat:

• Eine messbare Metrik
• Ein Zielwert
• Eine Zeitschätzung für das Experiment
• Kriterien für Erfolg/Misserfolg

So wird aus „Wir optimieren das Modell“ ein konkretes Experiment mit klarem Ergebnis.

Continuous Experimentation als Kernprozess

Bei Software entwickelst du Features.

Bei KI führst du Experimente durch.

Der wichtigste Prozess ist nicht Sprint Planning, sondern Experiment Design.

Unser Standard-Experiment-Workflow:

1. Hypothesis Definition (1 Tag)
2. Experiment Setup (2-3 Tage)
3. Execution (variabel: 1 Tag bis 2 Wochen)
4. Evaluation (1-2 Tage)
5. Decision (Weiter/Verwerfen/Pivot)

Wichtig: Jedes Experiment wird dokumentiert.

Auch die gescheiterten.

Besonders die gescheiterten.

Wir führen ein „Experiment Log“ mit:

• Hypothese
• Ansatz
• Ergebnis
• Learnings
• Next Steps

Das wird zur wertvollsten Ressource des Teams.

Data-centric Workflows für KI-Teams

Software-Teams organisieren sich um Features.

KI-Teams müssen sich um Daten organisieren.

Unser Workflow läuft nicht über ein Kanban-Board, sondern über eine Data Pipeline:

Jede Phase hat klare Übergabekriterien.

Kein „fertig“ ohne messbare Qualität.

Konkrete Arbeitsweisen für KI-gestützte Teams in der Praxis

Genug Theorie.

Hier sind die Arbeitsweisen, die ich täglich einsetze.

Die 3-Phasen-Methode für KI-Projekte

Ich teile jedes KI-Projekt in 3 Phasen:

Phase 1: Discovery (25% der Zeit)

Ziel: Verstehen, was möglich ist.

Aktivitäten:

• Datenexploration
• Proof of Concept
• Feasibility Assessment
• Erste Baseline-Modelle

Erfolgsmetrik: Ist das Problem mit KI lösbar?

Phase 2: Development (60% der Zeit)

Ziel: Das beste Modell bauen.

Aktivitäten:

• Iterative Modellverbesserung
• Feature Engineering
• Hyperparameter Optimization
• Cross-Validation

Erfolgsmetrik: Ziel-Accuracy erreicht.

Phase 3: Deployment (15% der Zeit)

Ziel: Modell in Production bringen.

Aktivitäten:

• Model Packaging
• API Development
• Monitoring Setup
• A/B Testing

Erfolgsmetrik: Modell läuft stabil in Production.

Wichtig: Die Phasen sind nicht linear.

Du springst zwischen Discovery und Development hin und her.

Das ist normal.

Agile Data Science: Sprints neu gedacht

Wir nutzen trotzdem „Sprints“ – aber anders.

Unsere KI-Sprints dauern 3-4 Wochen (nicht 2).

Jeder Sprint hat ein Experiment-Ziel, kein Feature-Ziel.

Sprint-Planung läuft so:

1. Experiment Review: Was haben wir letzte Sprints gelernt?
2. Hypothesis Priorisierung: Welche Experimente sind am vielversprechendsten?
3. Resource Allocation: Wer arbeitet an welchem Experiment?
4. Success Criteria: Wie messen wir Erfolg?

Sprint Review zeigt nicht Features, sondern Erkenntnisse:

• Welche Hypothesen wurden bestätigt/widerlegt?
• Welche neuen Erkenntnisse haben wir gewonnen?
• Wie hat sich die Modell-Performance entwickelt?
• Was sind die nächsten logischen Experimente?

Cross-funktionale KI-Teams richtig organisieren

Ein KI-Team braucht andere Rollen als ein Software-Team.

Unsere Standardbesetzung für ein KI-Projekt:

Wichtig: Der Product Manager ist NICHT der Scrum Master.

Er definiert Business-Ziele, nicht Sprint-Ziele.

Die Experiment-Priorisierung macht das gesamte Team gemeinsam.

Tool-Stack und Prozesse: Was funktioniert wirklich

Die Tools für KI-Teams sind andere als für Software-Teams.

Hier ist unser bewährter Stack.

Projektmanagement-Tools für KI-Teams

Jira ist okay für Software.

Für KI nutzen wir eine Kombination:

Experiment Tracking: MLflow

• Alle Experimente werden automatisch geloggt
• Parameter, Metriken, Artifacts in einer Ansicht
• Vergleich verschiedener Modell-Versionen

Task Management: Notion

• Hypothesis Backlog
• Experiment Documentation
• Team Learnings
• Data Quality Dashboards

Communication: Slack + Daily Data Reports

• Automatisierte Reports über Modell-Performance
• Alerts bei Data Quality Issues
• Channel für jedes laufende Experiment

Das wichtigste Tool ist aber ein shared Experiment Log.

Wir dokumentieren JEDES Experiment – egal ob erfolgreich oder nicht.

Versionierung von Modellen und Daten

Code versionierst du mit Git.

Aber was ist mit Modellen und Daten?

Unser Ansatz:

Data Versioning: DVC (Data Version Control)

• Jeder Datensatz hat eine Versionsnummer
• Reproducible Data Pipelines
• Automatic Data Lineage Tracking

Model Versioning: MLflow Model Registry

• Jedes Modell wird automatisch versioniert
• Staging/Production Environments
• Rollback-Möglichkeit bei Performance-Verschlechterung

Code Versioning: Git + Pre-commit Hooks

• Automatische Code Quality Checks
• Experiment Metadata wird automatisch committed
• Jupyter Notebooks werden vor Commit bereinigt

Ohne Versionierung ist KI-Entwicklung nicht reproducible.

Und nicht reproducible heißt nicht debuggable.

Testing und Deployment in KI-Umgebungen

Unit Tests für KI-Code sind anders als für normale Software.

Du testest nicht nur Funktionen, sondern auch Datenqualität und Modell-Performance.

Unser Testing-Framework:

Data Quality Tests

• Schema Validation (sind alle Spalten vorhanden?)
• Data Freshness (sind die Daten aktuell?)
• Statistical Tests (hat sich die Datenverteilung geändert?)
• Completeness Checks (wie viele Missing Values?)

Model Performance Tests

• Accuracy Threshold Tests
• Latency Tests
• Memory Usage Tests
• Bias Detection Tests

Integration Tests

• End-to-End Pipeline Tests
• API Response Time Tests
• Load Tests

Deployment läuft über Blue-Green Deployment mit automatischem Rollback.

Wenn die Modell-Performance um mehr als 5% sinkt, wird automatisch zur vorherigen Version zurückgeschaltet.

Häufige Fehler beim Übergang zu KI-gestützten Arbeitsweisen

Ich habe die gleichen Fehler bei fast jedem Kunden gesehen.

Hier sind die häufigsten – und wie du sie vermeidest.

Der Scrum Master wird zum AI Product Owner

Klassischer Fehler:

Das Unternehmen will „agil“ bleiben und macht den Scrum Master zum AI Product Owner.

Problem: Ein Scrum Master versteht Prozesse, aber nicht Data Science.

Er kann keine Experimente priorisieren, weil er nicht einschätzen kann, was realistisch ist.

Die Lösung: Der AI Product Owner muss technischen Background haben.

Er muss verstehen:

• Wie Machine Learning funktioniert
• Was Data Quality bedeutet
• Wie lange Modell-Training dauert
• Welche Metriken relevant sind

Bei uns ist der AI Product Owner immer ein Data Scientist oder ML Engineer mit Business-Verständnis.

Nie ein reiner Projektmanager.

Warum klassische Definition of Done nicht funktioniert

Software: „Feature funktioniert wie spezifiziert“ = Done.

KI: „Modell erreicht 85% Accuracy“ = Done.

Aber was, wenn das Modell nur 84% erreicht?

Ist es dann nicht Done?

Klassische Definition of Done führt bei KI zu endlosen Optimierungsschleifen.

Unser Ansatz: Probabilistische Definition of Done.

Statt „Modell muss 85% Accuracy erreichen“ definieren wir:

„Modell erreicht mindestens 80% Accuracy und ist besser als der bisherige Baseline-Ansatz.“

Plus Zeitlimit:

„Wenn nach 4 Wochen Optimierung keine signifikante Verbesserung erreicht wird, ist das aktuelle Modell Production-ready.“

Das verhindert Perfektionismus und ermöglicht iterative Verbesserung in Production.

Change Management für traditionelle Teams

Der schwierigste Teil ist nicht die Technik.

Es ist das Change Management.

Software-Entwickler sind gewohnt, deterministische Systeme zu bauen.

KI ist probabilistisch.

Das ist ein Mindset-Wechsel.

Was ich bei jedem Übergang mache:

1. Erwartungsmanagement

• Ehrlich kommunizieren: 80% der Experimente scheitern
• Das ist normal und wertvoll
• Erfolg wird anders gemessen

2. Pair Programming für KI

• Erfahrene Data Scientists arbeiten mit Software-Entwicklern zusammen
• Knowledge Transfer über Code Reviews
• Gemeinsame Experiment-Planung

3. Continuous Learning

• Wöchentliche „ML Learning Sessions“
• Case Studies erfolgreicher Experimente
• Post-Mortems gescheiterter Ansätze

Der Übergang dauert 3-6 Monate.

Plane das ein.

Und feiere kleine Erfolge – auch die „gescheiterten“ Experimente, die wertvolle Erkenntnisse liefern.

Häufig gestellte Fragen

Wie lange dauert der Übergang von Scrum zu KI-gestützten Arbeitsweisen?

In meiner Erfahrung dauert die Umstellung 3-6 Monate. Das Team muss neue Denkweisen lernen und Prozesse etablieren. Wichtig ist, den Übergang schrittweise zu gestalten und nicht alle Prozesse gleichzeitig zu ändern.

Kann man Scrum und KI-Entwicklung überhaupt nicht kombinieren?

Doch, aber du musst Scrum deutlich anpassen. Längere Sprints (3-4 Wochen), experiment-basierte Ziele statt Feature-Ziele und flexible Zeitplanung. Pure Scrum-Implementierung funktioniert nicht bei KI-Projekten.

Welche Rollen braucht ein KI-Team unbedingt?

Mindestens: Data Scientist, Data Engineer und ML Engineer. Bei kleineren Teams kann eine Person mehrere Rollen übernehmen, aber alle Bereiche müssen abgedeckt sein. Ein Product Manager mit KI-Verständnis ist ebenfalls wichtig.

Wie misst man den Erfolg von KI-Experimenten?

Durch vorab definierte, messbare Metriken wie Accuracy, Precision, Recall oder Business-KPIs. Wichtig: Auch gescheiterte Experimente sind erfolgreich, wenn sie Learnings liefern. Wir dokumentieren alle Experimente systematisch.

Was sind die größten Herausforderungen beim Übergang?

Change Management ist schwieriger als die Technik. Teams müssen lernen, mit Unsicherheit umzugehen und probabilistisch zu denken statt deterministisch. Außerdem brauchen sie neue Tools und Versionierungs-Strategien für Daten und Modelle.

Welche Tools sind für KI-Teams essentiell?

MLflow für Experiment Tracking, DVC für Data Versioning, ein Cloud-Provider für Computing-Power und ein gutes Dokumentations-Tool wie Notion. Git allein reicht nicht – du brauchst Tools, die speziell für Data Science entwickelt wurden.

Wie geht man mit der Unvorhersagbarkeit von KI-Projekten um?

Durch timeboxed Experimente mit klaren Go/No-Go-Kriterien. Setze Zeitlimits für Optimierungsschleifen und definiere Mindest-Performance-Schwellen. Plane mit Puffern und kommuniziere Unsicherheiten transparent an Stakeholder.

Funktionieren klassische Projektmanagement-Tools für KI-Teams?

Nur bedingt. Jira kann für Task-Management genutzt werden, aber du brauchst zusätzliche Tools für Experiment Tracking und Data Lineage. Wir nutzen eine Kombination aus verschiedenen spezialisierten Tools.

Wie organisiert man Code Reviews für Machine Learning Code?

ML Code Reviews sind anders als Software Code Reviews. Du prüfst nicht nur Code-Qualität, sondern auch Experiment-Design, Datenqualität und Modell-Validierung. Pair Programming zwischen erfahrenen Data Scientists und Software-Entwicklern hilft beim Knowledge Transfer.

Was passiert, wenn ein KI-Projekt komplett scheitert?

Das passiert in 15-20% der Fälle und ist normal. Wichtig ist, früh zu erkennen, wenn ein Ansatz nicht funktioniert und schnell zu pivotieren. Dokumentiere alle Learnings – sie sind wertvoll für zukünftige Projekte. Ein „gescheitertes“ Projekt kann andere vor den gleichen Fehlern bewahren.