Scrum ist Mainstream geworden, man kann es nicht anders sagen. Aller Orten, nicht nur in der Softwareentwicklung, hört man, dass Scrum seinen Siegeszug beim Thema „Agiles Projektmanagement“ angetreten hat. Zunächst vorausgeschickt: Ich besitze selbst so ein Zertifikat als Gedrängemeister, sogar noch ein altes, nicht das Neue. Und doch: Ich kann nicht umhin, auf eine Nebenwirkung von Scrum hinzuweisen, die mir immer wieder begegnet, wenn ich Scrum-Teams coache: Einseitige Fokussierung auf die Produktionsrate, die velocity.

Velocity = Medikament mit Nebenwirkung

Die Grundidee in Scrum, die ich moniere, ist überspitzt gesagt, folgende: Wir schätzen, wie viel wir tun können. Dann tun wir es. Am Ende stellen wir fest, wie viel wir wirklich tun konnten und nennen das velocity. Mit Hilfe der Velocity rechnen wir hoch, wie viel wir denn in den nächsten Iterationen (Sprints) erreichen können und bis wann das Produkt wohl das erste Mal releasefähig sein wird. Wenn wir in einem Sprint so viel erreichen konnten wie wir geschätzt und geplant hatten, nennen wir den Sprint „erfolgreich“, ansonsten nennen wir ihn „fehlgeschlagen“. Offenbar haben wir dann falsch geschätzt und müssen unsere Schätzungen verbessern.

Die Gefahr dabei ist folgende: Der Product Owner wird in der Regel versuchen, mit dem Team zu verhandeln, ob sie nicht in diesem Sprint ein wenig mehr leisten können als im Sprint davor. Das Team muss ihm sagen, ob es glaubt, das zu schaffen oder nicht. Das Team muss am Ende eines Sprints auch „bekennen“, ob es das, was es wollte, auch geschafft hat. Auf Basis der Erfahrungen aus den letzten Sprints wird das Team die nächste Sprint-Verhandlung führen.

Eine auch in Scrum häufig genutzte Möglichkeit, den Umfang des nächsten Sprints festzulegen, ist die Wetter-von-gestern-Regel aus dem Extreme Programming:

Das Wetter von heute wird ungefähr so wie das Wetter von gestern. Will sagen: Die Geschwindigkeit im nächsten Sprint wird so groß wie die im vorherigen Sprint.

Diese Regel kann zu stark schwankenden Werten für die Vorhersage führen, was den Product Owner nicht zufrieden stellt. Daher verwenden viele Scrum Teams gern einen Mittelwert für die Velocity über die letzten „n“ Sprints (n=2,3,4,5,… je nachdem). Die Eigenschaft des Mittelwertes ist es jedoch, dass die Hälfte der Messwerte über dem Mittel, die Hälfte unter dem Mittel liegen werden. Das bedeutet: Wenn das Team voraussagt: „wir schaffen im nächsten Sprint 25 Einheiten, weil wir im Mittel halt immer so viele schaffen“, dann muss als Konsequenz davon die Hälfte aller Sprints „fehlschlagen“. Warum? Weil nun mal die tatsächliche Velocity in der Hälfte aller Fälle kleiner ist als deren Mittelwert.

Da es für ein Team unangenehm ist, dem Product Owner zu sagen: „Hallo, Verzeihung, wir werden den Sprint nicht wie vorhergesagt schaffen!“, tendieren nun viele Teams dazu, einen von zwei Auswegen zu wählen:

  1. Sie machen Überstunden, um den aktuellen Sprint eben doch wie vorhergesagt zu schaffen.
  2. Sie verhandeln beim nächsten Sprint über eine niedrigere Zahl für die vorausgesagte Velocity.

Der Ausweg Nr. 1 ist ein klarer Widerspruch zu dem, was Beck und Fowler in ihrem Buch Planning Extreme Programming eigentlich mit der Wetter-von-gestern-Regel erreichen wollten: eine über lange Zeit aufrechterhaltbare Teamgeschwindigkeit, die das Team weder stresst noch unterfordert.

Der Ausweg Nr. 2 (wenn er wiederholt angewendet wird) führt beim Management und beim durchschnittlichen Product Owner zur Befürchtung, dass die Velocity ständig nachlassen könnte. Der Product Owner wird versuchen, „dagegen“ zu verhandeln.

Was für ein dummes Spiel! Team und Product Owner geraten so sehr leicht auf verschiedene Seiten des Seils, an dem sie ziehen. Lassen wir das doch besser bleiben.

Ausweg: Das kollaborative Spiel

Was tun wir also stattdessen? Wir hören am besten mit dem Verhandeln auf! Product Owner und Team fangen an, gemeinsam ein kollaboratives Spiel zu spielen, mit dem Ziel, den Wert der funktionierenden Produktes zu maximieren. Und das geht so:

  1. Das Team schätzt die Komplexität der Anforderungen, wie bisher auch (z.B. in Komplexitäts-Punkten 1, 2, 3, 5, 8, 13, usw.).
  2. Das Team macht zunächst keine Voraussage, wie viel sie in den nächsten Wochen schaffen werden.
  3. Das Team beginnt einfach, die wichtigsten Anforderungen zu realisieren und sammelt Erfahrungen.
  4. Der Scrum Master misst, wie lange die Realisierung einer Anforderung der Komplexität 1, 2, 3, 5, 8 oder 13 im Schnitt gedauert hat und bekommt für jede „Komplexitätsklasse“ eine Zahl in Kalendertagen heraus, die Durchlaufzeit oder auch cycle time genannt wird.
  5. Wenn der Product Owner das nächste Mal fragt: „Wie lange werden die nächsten 6 Anforderungen zur Realisierung brauchen?“, gibt ihm der Scrum Master diese cycle time-Messwerte und erklärt: „Die nächsten 6 Anforderungen in Deinem Backlog haben die Komplexitätsklassen 1, 3, 2, 8, 5 und nochmal 3. Unsere Erfahrung mit der cycle time ist: Bei Parallelarbeit an 3 Anforderungen (WIP=3) dauern diejenigen aus der 1er-Klasse einen Tag, die 2er und 3er zwei Tage, die 5er und 8er bis zu 10 Tage. Also dauern die nächsten 6 Anforderungen voraussichtlich (1+2+2+10+10+2)/3=9 Tage.“

Ist das nicht schön? Keine „fehlgeschlagenen“ Sprints mehr. Kein Verhandeln mehr nötig. Das Team legt seine Daten offen, der Product Owner kann darin lesen wie in einem Buch. Kein Grund mehr, dem Team zu misstrauen und zu fragen, ob es sich nicht etwas mehr anstrengen könnte und ob es nicht meint, im nächsten Sprint doch noch etwas mehr zu schaffen. Die Fokussierung auf die Produktionsrate hört auf.

Hier und Jetzt

Die Menschen im Team können sich nun darauf konzentrieren, die cycle time pro Anforderung zu minimieren. Das tun sie, indem sie einerseits die Zahl gleichzeitig bearbeiteter Anforderungen (work in progress, multi-tasking) minimieren und andererseits den Entwicklungsprozess verbessern. Immer wenn die Realisierung einer Anforderung stockt, fragt sich das Team einfach: „Woran liegt das?“ und versucht, dieses Problem jetzt und sofort zu lösen. Die Gedanken der Teammitglieder befinden sich dann in der Gegenwart, im Hier und Jetzt.

Nochmal zum Vergleich: Die Gedanken bei der herkömmlichen Sprint-Planung mit Hilfe der velocity befinden sich meist in der Zukunft („was werden wir wohl schaffen?“) oder in der Vergangenheit („was haben wir am Anfang des Sprints vorausgesagt?“). Beides ist weniger gesund und weniger zufriedenstellend als wenn die Menschen gedanklich in der Gegenwart sind.

Sparen Sie also Energie, investieren Sie nicht in die Zukunft, sondern in das Hier und Jetzt: Good bye, good old velocity!

, Agile Entwicklung , Prozesse und Kultur