SprintGoals und Überstunden

Ist das SprintGoal ein Versprechen vom Team an den ProductOwner? Eines, dass um jeden Preis eingehalten werden muss, notfalls mit Überstunden und Urlaubsverzicht?

Ja, könnte man so sehen. Der ProductOwner bekommt immer genau das am Ende eines Sprints, was das Team zu Anfang im SprintPlanning ihm zugesagt hat. Hat das Team sich verschätzt, so muss es sehen, wie es den Karren wieder aus dem Dreck prügelt. Egal wie: Das BurnDownChart soll am letzten Tag des Sprints bei 0 landen. Punktlandung. Der ProductOwner ist zufrieden, denn er hat das Erwartete bekommen, oder nicht?

Nein, tatsächlich bekommt er nicht das Erwartete. Das SprintGoal ist kein Funktionalitätsversprechen, sondern eine Schätzung. Schätzungen können daneben gehen, das Team kann und darf sich verschätzen. Wenn das Team sich verschätzt hat und die Funktionalitäten mehr Zeit brauchen, als der Sprint es zulässt, dann spart das Team in der Regel an der Qualität: es werden weniger Tests geschrieben, es wird weniger refaktorisiert, es wird weniger über die eigene Arbeit reflektiert. Es wird gespart an Abstimmungen zwischen den Kollegen. Das Team vernachlässigt sich selbst, tut sich selbst nichts mehr Gutes. Wie könnte es da jemand anderem, dem ProductOwner, etwas Gutes tun? Der ProductOwner bekommt seine Funktionalitäten, aber in einem miserablen Zustand.

Eine schlechte Qualität bei einer Punktlandung abzuliefern hat Konsequenzen: Die geplanten Funktionalitäten des nächsten Sprints werden auf schlechter Qualität aufbauen müssen. Das kostet Zeit, Zeit vom nächsten Sprint, und im Endeffekt werden weniger Funktionalitäten gebaut als im Sprint zuvor. Die Punktlandung des vorherigen Sprints suggeriert, dass der Sprint erfolgreich war. War er aber gar nicht: Es gab keine ausreichende Qualität.

Punktlandungen bei BurnDownCharts misstraue ich. Natürlich sollten SprintGoals erreichbar sein, und in der Regel landet ein eingespieltes Team in der Nähe der Nulllinie, knapp drüber oder drunter. Ein genauer Treffer der Nulllinie würde bedeuten, dass das Team beim Planen exakt wusste, was passieren wird. Keine Schätzung, sondern eine Prophezeiung, eine Zukunftsvision. Daran glaube ich nicht.

SprintGoals als Versprechen zu sehen ist unfair aus Sicht des Teams. Falls das Team sich verschätzt hat zu seinen Ungunsten, dann soll es dafür büßen mit Überstunden und 120%igem Einsatz. "Durch Schmerz lernen die schon" habe ich einen ScrumMaster sagen hören über ein Team. Und was ist, wenn das Team sich zu seinen eigenen Gunsten verschätzt? Was ist, wenn sie schneller das SprintGoal erreicht haben, also noch vor Sprint-Ende? Darf es den 5. Tag bezahlt frei machen, wenn es seine auf fünf Tage geschätzte Arbeit in vieren erledigt? Darf oder muss es dass tun, was jede Festpreis-Verträge eingehende Firma tut, also die Differenz einheimsen bzw. bezahlen? Habe ich noch nicht erlebt, dass dies einem Team erlaubt wurde... Warum eigentlich nicht? Wäre doch fair?!

Punktlandungen und SprintGoal-Versprechen passen auch nicht zu Scrum, denn sie setzen die Funktionalität fest, was auf Kosten der Qualität geht. Scrum will Qualität haben vom Team. Sollte der ProductOwner an seinen Funktionalitäten festhalten, so hat er einen Ziel- oder Prioritätenkonflikt: Will er alle Funktionalitäten, dafür aber Qualitätsverluste, oder will er Qualität, dafür aber weniger Funktionalität? Scrum setzt auf Funktionalitätenschwund statt Qualitätsverlust während der Projektlaufzeit. Aus den gleichen Gründen sollte das der ProductOwner auch während eines Sprints tun. Hier ist Projektlaufzeit und Sprint selbstsymmetrisch.

Wie verhält sich ein Team, dem eine Schätzung abgerungen wird und das ganz genau weiß, dass es diese Schätzung einhalten muss, notfalls mit Überstunden? Wird es dadurch pessimistischer Schätzen? Lernt es durch den Schmerz (aka Überstunden)? Nein, es schätzt nicht pessimistischer, und es lernt auch nicht in dem Maße, wie es erforderlich wäre, um realistischer zu schätzen. Mal angenommen, dass Team verschätzt sich zu seinen eigenen Ungunsten. Die Zeit wird nicht reichen, um die Funktionalität ordentlich (also qualitativ zufriedenstellend) bereitzustellen. Das Team wird versuchen, mit Überstunden gegenzusteuern. Dadurch wird das Ergebnis an Qualität einbüßen, denn Überstunden sind außerhalb der produktiven Zone, weil außerhalb einer nachhaltigen Arbeitsgeschwindigkeit. Und vielleicht reichen die Überstunden auch nicht zur Kompensation des Verschätzens. Spätestens jetzt wird die Funktionalität mit den sehr heißen Nadeln gestrickt: Qualität ade!

Unvorteilhaft an Qualität ist ihre große Feedbackschleife: Erst relativ spät erkennt man den Mangel an Qualität. So meint nun der ProductOwner bei einem Sprint mit Überstunden - der ja sehr erfolgreich war, weil das BurnDownChart eine Punktlandung anzeigt -, dass alles in Ordnung sei. Der ProductOwner meint, er könne wieder ein SprintGoal-Versprechen dem Team abringen. Hier schließt sich der Kreis. Nach ein paar Sprints verlangt das Team nach Aufräum-Sprints, in denen keine Funktionalität mehr produziert werden kann. Das Team ist gestresst aufgrund der Überstunden und des hohen Drucks durch das SprintGoal-Versprechen. Die Moral ist am Ende. Das Projekt bald auch.

Die Alternative? Wenn das Team sich überschätzt hat und nicht alle Funktionalitäten in diesem Sprint bereitstellen kann, dann wirkt sich das auf die Entwicklungsgeschwindigkeit aus und damit auf die Teamgeschwindigkeit, also auf die Anzahl der Stories/Features/Tasks/Idealen Stunden/Gummibärchen/Tomaten, die das Team in einem Sprint schafft. Per Wetter von gestern geht die Überschätzung des Teams in den nächsten Sprint ein: Das Team wird sich weniger Stories/... vornehmen. Aber unabhängig davon: Was das Team auch immer produzieren wird, das soll es in Ruhe und ohne Druck machen, damit es qualitativ hochwertige Arbeit abliefern kann. Eine Arbeit, auf die das Team selbst stolz ist. Dies darf bedeuten, dass am Ende des Sprints weniger Funktionalitäten für den ProductOwner herausspringen.

Ist das nicht sehr unkomfortabel für den ProductOwner, wenn nun das Team nun quasi abliefern kann am Ende des Sprints, was es will? Wo bleibt die Planbarkeit? Das Ziel sollte weiterhin sein, möglichst gute Vorhersagen treffen zu können, wie viel das Team während eines Sprints schafft. Das schafft Transparenz, die nicht zuletzt dafür benutzt werden kann um nachzuschauen, in welcher Zeit wie viel vom ProductBacklog abgearbeitet sein wird. Genau das aber wird nicht erreicht durch SprintGoal-Versprechen. Bei diesen Versprechen machen alle beteiligten die Augen zu und hoffen, den Wagen schon irgendwie auf der Straße halten zu können, während er langsam in die Böschung schlingert, weil keiner gegenlenkt! Nur durch ein selbstregulierendes System bei aufrechterhaltener Qualität kann eine realistische Prognose und damit Transparenz erzielt werden: "Wetter von gestern" und das Team in Ruhe arbeiten lassen.