Das zweitwichtigste Fortschrittsmaß für den Sprint

Hätte man mich vor zwei oder drei Jahren gefragt, wie ich erkenne, ob ein Sprint erfolgreich ist, dann hätte ich wahrscheinlich eine schnelle Antwort gefunden. Das Agile Manifest hat dafür ein wichtiges und eindeutiges Prinzip:
 

> Working software is the primary measure of progress.

Warum ist das so? Funktionierende Software ist das Ergebnis unserer Arbeit, mit der wir realweltliche Probleme modellieren und für unsere Nutzenden lösen. Um “das Richtige” zu bauen, ist diese Arbeit im Scrum Team durch unseren Product Owner, z.B. nach Mehrwert für den Kunden, sortiert. Wir arbeiten also an möglichst wertstiftenden Themen. Zum anderen haben wir eine Definition of Done im Team aufgestellt, die auch als internes Qualitätsmerkmal fungiert. Wir arbeiten also mit hoher Qualität an den wichtigen Dingen. Wenn diese Dinge abgeschlossen sind, haben wir nachhaltigen Wert geschaffen.

In einem Sprint kann ein Team an mehr als nur einem Backlog Item arbeiten. Vorausgesetzt das Backlog ist sinnvoll nach Wert sortiert und wird linear von wertvoll nach weniger wertvoll abgearbeitet, dann gilt, je mehr Backlog Items am Ende des Sprints nach unserer Definition of Done fertig sind, desto höher wird der kumulierte Wert unseres Inkrements. Deswegen können uns auch auch Kanbanmetriken, wie Durchsatz oder Cycletime, helfen, um den Erfolg eines Sprints zu quantifizieren. Zumindest können wir darüber im Vergleich zu vorherigen Sprints sehen, ob wir eher langsamer oder schneller werden.

Egal wie hoch die absolute Anzahl der abgeschlossenen Backlog Items ist, ich setze sie gerne in Relation zu dem, was wir zu Sprintbeginn geplant haben. Schließt man deutlich mehr oder deutlich weniger Backlog Items ab, als ursprünglich geplant, dann hat man ein Problem mit der Qualität der Planung. Natürlich sollte man innerhalb des Sprints auch offen sein, den Plan zu ändern, solange das Sprintziel nicht gefährdet wird. Für mich sagt die Planungsqualität allerdings nichts über den tatsächlich geschaffenen Wert aus, sondern sie ist ein Hinweis an das Team, dass dort vielleicht noch Optimierungspotential besteht. Man kann eine über die Marktstellung entscheidende User Story umgesetzt haben und trotzdem 80% der geplanten Aufgaben im Sprint nicht abgeschlossen haben – war das deswegen ein schlechter Sprint?
 

Fokus auf fertige Backlog Items ist gut, aber…

… tatsächlich habe ich mich mit meinem Team in einer solchen Lage wiedergefunden. Am Sprintende hatten wir gerade mal 14% von dem geschafft, was wir uns vorgenommen hatten. Das Team bestand weitestgehend aus Experten, die fokussiert (also ohne Ablenkungen von anderen Projekten) am Sprint arbeiten konnten. Wir haben versucht an unserer Definition of Done zu arbeiten, an der crossfunktionalen Zusammenarbeit, wir haben sogar die Sprintlänge von zwei auf drei Wochen erhöht – ohne messbare Verbesserung unserer Performance, wenn man die klassischen Sprintmetriken, wie Durchsatz oder Velocity, betrachtet.

Was uns jedoch immer das Gefühl von Erfolg gegeben hat, war die Präsentation der Sprintziele in der Sprint Review. Es ist schon merkwürdig, dass ein Großteil der Backlog Items unfertig waren, aber das Sprintziel erreicht werden konnte. In unserem Fall war das zum Beispiel die Skalierung unserer Infrastruktur von zehn Testkunden auf realistische 2000+ gleichzeitige Kunden. Dieses Ziel haben wir erreicht, aber andere Backlog Items, die sich mit der Verbesserung unseres Algorithmuses oder Dokumentation beschäftigt haben, blieben unfertig. Klar, nicht jedes Sprintziel war perfekt formuliert, aber es hat uns stets Orientierung gegeben und am Ende des Sprints den Raum für ein neues und sinnvolles Ziel im nächsten Sprint geöffnet.
 

Der Twist

Eine Sache habe ich bis hierhin verschwiegen: Bei meinem Scrum Team handelte es sich nicht um ein typisches Softwareentwicklungsteam mit Frontend, Backend und Usereingaben, sondern um ein Team im Bereich von Machine Learning. Das ist insofern relevant, als dass wir natürlich auch Code und Software schreiben, aber die Art und Weise, wie unsere Software zu ihren Ergebnissen kommt, unterscheidet sich nach meinem Verständnis maßgeblich von anderen Softwareprojekten. Es gibt hier keinen direkten Algorithmus, den wir implementieren, um direkt ein Problem zu lösen, sondern wir machen innerhalb unserer Software Experimente. Wir geben Trainingsdaten in eine Black Box von KI-Modellen, ändern ein paar Parameter, lassen die Cloud eine Woche drauf rumdenken und am Ende kommt ein neuer veränderter Algorithmus raus, den wir in der echten Welt verproben können. Wir schreiben also den Lösungsweg nicht direkt, sondern trainieren unsere künstliche Intelligenz, in der Hoffnung, dass sie diesen Sprint besser arbeitet, als in der letzten Iteration.

… Allerdings können wir vorab nicht wissen, ob unsere Arbeit tatsächlich zu einer Verbesserung führt. Wir machen Experimente, deren Ausgang wir nicht exakt vorhersehen können. Wir vermuten und erhoffen uns Verbesserungen, aber messen können wir sie erst nach getaner Arbeit, langen Berechnungen und aufwändigen Auswertungen. Das ist allerdings in anderen Bereichen der agilen Softwareentwicklung nicht anders: Wir können vielleicht Backlog Items genau so wie angefordert umsetzen, aber ob sie auch den gewünschten Mehrwert für Nutzende bringen, das lässt sich häufig erst später unter hohem Aufwand erfragen oder messen. 

Wegen unseres Fokus auf KI-Modelle und ihre mathematischen Grenzen wirkt unser Sprint Review weniger wie eine Software Demonstration, sondern erinnert häufig eher an einen wissenschaftlichen Vortrag über quantitative Datenanalyse an der Universität, weil wir stellenweise genau so arbeiten. Das Ergebnis ist (leider?) nicht immer funktionierende Software, wie es das Agile Manifest empfehlen würde. Der Weg dorthin ist zu komplex, um selbst kleinste Schritte zu kleinen Mehrwerten innerhalb einer Iteration gehen zu können. Zu häufig misslingen Experimente oder ihre Berechnungen brauchen zu lange. Dennoch ist es wichtig, auch diese sehr mathematisch theoretischen Probleme unseres Produktes mit fachlichen Stakeholdern zu diskutieren. Sie können wertvollen Input dazu geben, welche Aspekte für sie wichtig sind und welche wir zur Vereinfachung unseres Modells vernachlässigen können, z.B. weil bestimmte Sonderfälle in der Realität zu selten vorkommen und daher für die breite Betrachtung und das Training der KI irrelevant sind.
 

Zurück zu Scrum

So gesehen kann mein Team also in einem Sprint entweder Glück haben, und die KI arbeitet nachher tatsächlich effizienter und besser, oder wir haben gelernt, dass die letzten Experimente der vorangegangenen Iteration nicht die gewünschten Ergebnisse gebracht haben. Dieses Lernen ist entsprechend das Ergebnis unserer Arbeit, die Grundlage für Diskussion und Weiterentwicklung. Lernen ist selbst ein iterativer Prozess. Nicht umsonst haben wir in Scrum explizit Raum zum Lernen: Im Daily lernen wir, ob wir uns auf einem guten Weg zur Erreichung des Sprintziels befinden, im Review lernen wir, ob unser Produkt unsere Stakeholder und Nutzenden überzeugt und in der Retro lernen wir, wie wir uns besser organisieren können. Regelmäßiges Inspect & Adapt ist ein Kernelement der Arbeit in komplexen bis chaotischen Arbeitsfeldern und muss mindestens zwischenzeitlich auch als legitimes Ergebnis eines Sprints angesehen werden.

Es klingt etwas wie eine Ausrede: “Unser Produkt ist einfach so komplex, das braucht Zeit und man kann kein neues Inkrement in zwei Wochen abschließen.” Klar sind andere Softwareprodukte auch komplex, aber dieses Team und Produkt rund um unsere KI haben mir gezeigt, dass sich nicht alle Mehrwerte in Code messen lassen. Sie lassen sich auch nicht immer in die gewohnten kurzen Sprintiterationen pressen. Und diese Erfahrung hat mir persönlich geschmerzt, weil ich bislang durchweg sehr gute Erfolge mit Scrum in der Produktentwicklung gemacht habe. Scrum hat uns in vielen unklaren Situationen dank der  kleinschrittigen Planung und schnellen Inspektionszyklen geholfen, komplexe Probleme in handhabbare Stücke zu zerkleinern und so erfolgreich zu bearbeiten. Damit konnten wir schnell prüfen, ob unsere Ergebnisse das gebracht haben, was wir und unsere Nutzenden sich davon versprochen haben. Es ist seltsam zu sehen, dass die Entwicklung von KI-Modellen einen ganz eigenen Rhythmus zu haben scheint. 

Fazit: Primary and secondary measure of progress

Identifiziert man für sein Team, dass eine bestimmte Erkenntnis notwendig für die Entscheidung des weiteren Vorgehens ist, so kann man daraus auch ein Lernziel als Backlog Item erstellen und in den nächsten Sprint aufnehmen. Ich empfehle hierbei eine sprachliche Formulierung zu wählen, die outcomeorientiert ist, wie “Wir sind in der Lage, immer den optimalen Parameter für X zu bestimmen, egal wie Z aussieht.”

Wenn ich nun am Ende eines Sprints eine Erfolgsmessung vornehme, dann unterscheide ich ab jetzt in zwei Kategorien:

1. Das wichtigste Fortschrittsmaß (oder Englisch “primary measure of progress”) bleibt für mich der gestiegene Mehrwert für den Kunden. In der Regel passiert das durch funktionierende Software.
2. Das zweitwichtigste Fortschrittsmaß (oder “secondary measure of progress”) ist das Lernen des Teams und der Stakeholder, das den Weg zur weiteren Wertsteigerung klarer macht.

Letztendlich ist der Mehrwert immer noch das, warum wir Produkte entwickeln und damit ganz klar der Hauptindikator für einen erfolgreichen Sprint. Das bedeutet aber nicht, dass man den Lernaspekt vergessen sollte. Er ist in vielen Situationen notwendig, um spätere Mehrwerte effektiv zu erreichen. Allerdings ist dauerhaftes Lernen ohne konkrete Mündung in ein verbessertes Produkt nicht im Sinne von Scrum. Daher steht für mich die Priorisierung dieser beiden Kategorien fest und der “primary measure of progress” aus dem Agilen Manifest hat auch weiterhin für mich Bestand.