Agile für KI: Sprints, die Modell-Training aushalten

Wo Scrum bei Modell-Arbeit bricht

Scrum funktioniert, weil Software-Aufwand grob planbar ist: Wer die Story versteht, kann sie schätzen. Modell-Arbeit bricht diese Kopplung. Ob ein Fine-Tuning die Qualitätsschwelle erreicht, ob ein RAG-Setup auf deinen Daten präzise genug antwortet – das weisst du erst nach dem Versuch. Zwei Wochen Arbeit können null sichtbaren Fortschritt liefern und trotzdem wertvoll sein, weil sie eine Sackgasse ausschliessen.

Prozessmodelle aus der ML-Welt füllen die Lücke, die Scrum offenlässt: CRISP-ML(Q) (Studer et al.) beschreibt den Lebenszyklus von Geschäftsverständnis über Daten-Aufbereitung bis Monitoring – mit Qualitätssicherung in jeder Phase. Continuous Delivery for Machine Learning (CD4ML, beschrieben von Sato, Wider und Windheuser bei martinfowler.com) überträgt CD-Prinzipien auf Modelle: kleine Schritte, automatisierte Pipelines, reproduzierbare Releases. Keines ersetzt dein agiles Framework – sie benennen die Arbeit, die dein Framework bisher unsichtbar gemacht hat.

Spikes statt Stories: Wie du Lernen und Liefern trennst

Modell-Arbeit als Spike. Timebox statt Schätzung, Lernziel statt Akzeptanzkriterien: «In fünf Tagen wissen wir, ob Ansatz A die 90-Prozent-Schwelle auf dem Eval-Set erreicht.» Der Spike ist erfolgreich, wenn er die Frage beantwortet – egal in welche Richtung.

Produktarbeit als Story. UI, Datenanbindung, Logging, Guardrails, Fallbacks – alles um das Modell herum ist deterministisch und gehört in normale Stories mit normalem Commitment. So liefert der Sprint sichtbaren Fortschritt, selbst wenn das Experiment scheitert.

Daten als eigene Items. Daten beschaffen, bereinigen, labeln und ein Eval-Set bauen ist oft die Hälfte des Aufwands – CRISP-ML(Q) widmet ihr eigene Phasen. Wer sie in «Modell bauen» versteckt, wundert sich über Faktor-zwei-Überraschungen.

Die Definition of Done, die KI-Features brauchen

Bei deterministischem Code beweisen Tests die Korrektheit. Bei probabilistischen Features beweisen sie nur den Rahmen – die eigentliche Frage ist: Wie gut ist es auf repräsentativen Fällen? Deshalb gehört in die Definition of Done ein Eval-Schritt: definiertes Testset, definierte Metrik, definierte Schwelle. Ein Review, das nur eine Demo auf drei handverlesenen Beispielen zeigt, prüft Charisma, nicht Qualität.

Und weil Modelle sich mit Daten, Prompts und Modellversionen verändern, ist die Eval-Pipeline kein Einmal-Artefakt, sondern Teil der CI – das ist der Kern von CD4ML. Jede Änderung am Prompt läuft gegen dasselbe Eval-Set wie jede Änderung am Code gegen die Tests. So bleibt «besser geworden» eine Messung statt einer Meinung, Sprint für Sprint.

Empfehlungen

• Trenne den Backlog in Liefern und Lernen. Stories mit Commitment für alles Deterministische, Spikes mit Timebox, Lernziel und Abbruchkriterium für Modell-Arbeit. Mische sie nie im selben Commitment.
• Definiere «gut genug» vor dem Spike. Qualitätsschwelle und Eval-Set stehen, bevor jemand trainiert oder promptet. Sonst verschiebt sich das Ziel mit jedem Ergebnis.
• Erweitere die Definition of Done. Kein KI-Feature ist fertig ohne bestandene Evaluation und aktives Monitoring-Signal. «Demo lief» ist kein Done-Kriterium.
• Mache Lernen sichtbar. Berichte im Review beide Währungen: gelieferter Produktfortschritt und beantwortete Forschungsfragen. Stakeholder akzeptieren negative Experiment-Ergebnisse – aber keine unsichtbaren.

Einordnung & Grenzen

• CRISP-ML(Q) und CD4ML sind Prozessmodelle, keine Garantien – sie strukturieren Arbeit, deren Ausgang offen bleibt. Übernimm die Phasen, nicht die Bürokratie: Ein Zwei-Pizza-Team braucht die Disziplin, nicht das Formularwesen.
• Mit Foundation-Modellen und Prompting statt eigenem Training schrumpft der Experiment-Anteil oft deutlich – dann reicht manchmal eine schlanke Eval-Pipeline. Prüfe zuerst, wie viel «Forschung» dein Feature wirklich enthält.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.