Agiles Projektmanagement in KI-Projekten bedeutet in der Praxis: iterativ Wert liefern, aber nicht nur Software entwickeln, sondern gleichzeitig Daten, Modelle, Deployment, Monitoring und Risiken steuern. Scrum selbst arbeitet mit Empirie, Product Goal, Sprint Goal und Increment. Für KI-Projekte kommt dazu, dass Datenverfügbarkeit, Modellgüte und spätere Überwachung Teil des Produkts sind, nicht nur der Code.
Der zentrale Unterschied zu klassischen Softwareprojekten ist die höhere Unsicherheit. In KI-Projekten steht am Anfang oft noch nicht fest, ob die Daten geeignet sind, ob das Modell die Zielqualität erreicht oder ob sich das Verhalten später im Betrieb verändert. Genau deshalb kombiniert CRISP-ML(Q) Geschäfts- und Datenverständnis früh, ergänzt eine eigene Evaluationsphase und sieht ausdrücklich Monitoring und Maintenance wegen möglicher Modellverschlechterung vor. Google empfiehlt zusätzlich, mit einer einfachen Baseline und einer soliden Pipeline zu starten, statt zu früh zu komplex zu werden.
Ein praxistaugliches agiles Setup für KI ist daher meist diese Kombination:
Scrum oder Kanban für Planung und Priorisierung, CRISP-ML(Q) für den KI-Lebenszyklus, MLOps für Reproduzierbarkeit, Deployment und Betrieb, und ein Governance-/Risikorahmen wie NIST AI RMF für verantwortliche Steuerung. Das ist keine einzelne offizielle Methode, sondern eine sinnvolle Kombination aus etablierten Bausteinen.
So sehen die typischen Phasen in einem agilen KI-Projekt aus:
- Use Case und Zielbild klären: Welches Problem soll gelöst werden, mit welchem geschäftlichen Nutzen?
- Daten verstehen und prüfen: Verfügbarkeit, Qualität, Relevanz, rechtliche Zulässigkeit.
- Baseline bauen: erstes einfaches Modell oder sogar regelbasierter Vergleich.
- Iteration in Sprints: Daten verbessern, Features testen, Modell trainieren, evaluieren.
- Produktivsetzung: Pipeline, Versionierung, Tests, Freigaben.
- Monitoring: Qualität, Drift, Ausfälle, Risiken, Retraining.
Wichtig ist: In einem KI-Sprint ist das Increment oft nicht nur eine sichtbare App-Funktion. Ein valides Sprint-Ergebnis kann auch sein: ein bereinigter Datensatz, ein dokumentierter Baseline-Vergleich, ein Evaluationsbericht, eine reproduzierbare Trainingspipeline, ein Deployment-Workflow oder ein Monitoring-Dashboard. Das passt zur Scrum-Logik, solange am Ende ein überprüfbares Ergebnis entsteht, auf dessen Basis entschieden werden kann. Das ist eine fachliche Ableitung aus Scrum, CRISP-ML(Q) und MLOps.
Für die Rollen funktioniert meist dieses Modell gut:
Der Product Owner verantwortet Geschäftsnutzen und Prioritäten.
Das interdisziplinäre Team besteht typischerweise aus Data Science, Data Engineering, ML Engineering, Softwareentwicklung und Fachbereich.
Zusätzlich braucht KI fast immer klare Zuständigkeiten für Datenqualität, Compliance, Dokumentation und Betrieb. NIST betont dafür Governance, Rollenklärung, Verantwortlichkeit und laufendes Risikomanagement über den gesamten Lebenszyklus.
Besonders wichtig in KI-Projekten ist ein anderes Backlog-Denken. Das Backlog sollte nicht nur Features enthalten, sondern auch Arbeitspakete zu Datenbeschaffung, Labeling, Datenqualität, Bias-/Risikoprüfungen, Evaluationsmetriken, Experimenten, Deployment und Monitoring. Sonst wird das Projekt scheinbar agil gemanagt, aber die eigentlichen KI-Risiken bleiben unsichtbar. NISTs Playbook und CRISP-ML(Q) stützen genau diese breitere Sicht
Ein häufiger Fehler ist, KI wie ein normales Feature-Projekt zu behandeln. Dann entstehen Probleme wie: unklare Datenbasis, fehlende Qualitätskriterien, zu frühe Modellkomplexität, keine Reproduzierbarkeit, kein Drift-Monitoring und zu spätes Nachdenken über Risiken, Fairness, Erklärbarkeit oder menschliche Aufsicht. Google, Microsoft und NIST adressieren diese Punkte jeweils aus Engineering-, Betriebs- und Governance-Sicht.
