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.
Ich sehe das etwas anders, Bernd.
AntwortenLöschenAm Anfang mag es OK sein, dass das Team sein Commitment reißt und sich oft überschätzt, aber das muss sich nach ein paar Sprints einigermaßen regulieren und es sollten die meisten Sprints eher mit Übererfüllung enden. Nur so kann ich Planbarkeit erreichen.
Und bedeutet es mal Überstunden? Vielleicht ja, aber dann mit einem zusätzlichen Lerneffekt, dass man es nur mit Überstunden geschafft hat, und sich das Team für den nächsten Sprint auf weniger einlässt.
Bei jedem Team oszilliert die Geschwindigkeit am Anfang stärker und pendelt sich dann irgendwann ein. Sobald sie sich eingependelt hat, hat man eine Planbarkeit erreicht. Warum geht das Deiner Ansicht nach nur dann, wenn die meisten Sprints mit Übererfüllung enden?
AntwortenLöschenIch glaube nicht an einen Lerneffekt durch Überstunden. Aber das ist ein anderes Thema.
Aber unabhängig davon: Überstunden bedeuten niedrigere Qualität. Qualität ist eine Invariable in Scrum, Funktionsumfang ist die einzige Variable in Scrum. Wie passt das aus Deiner Sicht zusammen?
Weniger Qualität in diesem Sprint bedeutet weniger Features im nächsten Sprint. Das wollen die Stakeholder nicht. Wie passt das aus Deiner Sicht zusammen?
Überstunden beißen sich mit "Wetter von Gestern": Hast Du durch Überstunden in diesem Sprint soundsoviel Stories geschafft, dann bekommst Du nach "Wetter von Gestern" eben soviel Stories in den nächsten Sprint - was Du, nach dem "Wetter von Gestern"-Prinzip, wieder nicht schaffen wirst, es sei denn, Du machst wieder Überstunden. Wie kommst Du aus dieser Tretmühle wieder raus?
Mal angenommen, Überstunden brächten etwas. Überstunden kann man nicht in jedem Sprint machen, irgendwann kommt der BurnOut, aber Du weißt nicht, wann das ist. Vielleicht kommt der kurz vor Projektende, kurz vorm Release. Wie erreichst Du damit Planbarkeit?
Bernd, ich bin kein Überstundenfan.
AntwortenLöschenMein Punkt ist, dass es eben im Einzelfall mal zum Reißen kommen darf, aber wenn es nach der initialen Einschwingphase immer noch dauernd dazu kommt, dann ist was falsch.
So wollen wir ja letztlich besser sein als klassiche plangetriebene Verfahren, die meist sehr spät Überraschungen erleben, weil die Pläne nicht eingehalten werden können. Wir wollen dem realistische kürzere Pläne mit häufiger Planüberprüfung und -anpassung entgegensetzen.
Wenn wir aber generell ablehnen, dass das Commitment irgendeinen wert hat, dan brauchen wir damit nicht loslegen.
Ich glaube, dass wir uns einig sind, dass es in der initalen Phase eines Scrum-Projektes viel öfter zum Nichterreichen des SprintGoals kommen kann, als das im späteren Verlauf des Projektes der Fall sein wird.
AntwortenLöschenIch sehe das auch so wie Du, dass wenn im späteren Projektverlauf immer noch dauernd das SprintGoal verfehlt wird, dass dann ein Defekt vorliegt, den man behandeln sollte.
Das bedeutet aber aus meiner Sicht nicht, dass das Team nicht ab und an das SprintGoal verfehlen darf, sogar dann, wenn das Team schon sehr eingespielt und erfahren ist.
Ich arbeite mit dem Team als ScrumMaster darauf hin, dass es mit der Zeit schneller und besser wird. Das erreichen wir durch die Retrospektiven, in dem das Team sein Vorgehen entsprechend anpasst. Eine Anpassung kann den erwarteten Erfolg bescheren, und dann ist das Team schneller und besser und erfüllt oder übererfüllt das SprintGoal. Die Anpassung kann aber auch daneben gehen, das weiß man ja vorher noch nicht so genau, und dann reißt man halt die Latte und das SprintGoal wird nicht erreicht. Das passiert. Wenn ich also vom Team erwarte, dass es Risiken eingeht, damit es besser wird, dann darf ich es aus meiner Sicht nicht verhaften, wenn es mal daneben greift und ein SprintGoal nicht schafft. Risiken können eben auch Verluste bedeuten.
Ich bin mir nicht sicher, ob wir in diesem Punkt einer Meinung sind.
Commitments im Allgemeinen sind für mich viel umfassender, als dass man sie auf ein SprintGoal reduzieren könnte. Wenn Du hier aber vom Commitment sprichst, und damit das SprintGoal meinst, dann hat das sehr wohl für mich einen Wert. Das SprintGoal ist das angepeilte Ziel und dafür eine wunderbare Markierung. Es steckt den Rahmen aller, die sich in einem Scrum-Projekt bewegen. Das ist mir sehr viel wert. Es aber, wenn einmal festgelegt, als unverrückbar und auf jeden Fall zu halten anzusehen - Überstunden hin oder her -, wie ich das von Dir verstehe, entspricht nicht meiner Sicht von Flexibilität.
Ich vermute, dass wir in dem Punkt auch nicht einer Meinung sind. Sofern ich den Punkt richtig verstanden habe...?!
Ich denke, die meisten Scrum-Projekte sind weit davon entfernt, am Sprintende _Shippable Code_ zu haben. Selbst wenn das Team die notwendige Qualität erreicht, schafft es der Product Owner meistens nicht, seine Wünsche so klein zu definieren, das nach jedem Sprint an die Benutzer geliefert werden kann.
AntwortenLöschenIch glaube, für Sprint-Goal und Commitment macht das einen relevanten Unterschied.
Wenn ich liefern will/muss, bedeutet das reißen des Commitments mitunter einen deutlichen Schaden für das Unternehmen. Und dann können Überstunden _für diesen einen Sprint_ ein adäquates Mittel sein, um das Commitment zu erreichen.
Meistens geht es in einem Sprint aber nicht um das Liefern an die Kunden. Dann bedeutet das Reißen des Commitments für einen Sprint keinen direkten Schaden für das Unternehmen. Wenn das Team das Commitment mit Hilfe von Überstunden hält, ist es für das Gesamtprojekt ein Taschenspielertrick. Im nächsten Sprint wird das Team entsprechend langsamer sein - wg. Abbummeln von Überstunden, Regeneration etc. Die Überstunden führen sogar zu stärkeren Schwankungen in den Velocity-Kurven und die Planbarkeit wird eingeschränkt.
Wenn Überstunden für das Team die Schmerzen verursachen, die zur Selbsterkenntnis und Verbesserung führen, dann los.
Der normale Weg dazu wäre aus meiner Sicht allerdings anders: Wenn das Commitment gerissen wird, _muss_ das Team in der Retrospektive darüber sprechen und Verbesserungsmaßnahmen ableiten. Und wenn das Team seine Commitments nicht erfüllt, obwohl es in den Retrospektiven ständig drüber spricht, dann deutet das auf ein viel größeres Problem hin.
Henning,
AntwortenLöschenich gebe Bernd zu 150% Recht: Wenn man das Ganze mal statistisch sieht, ist bei Yesterday's Weather die Chance, das Ziel zu erreichen 50%, d.h. in der Hälfte der Fälle wird das Team die Latte reißen. Simon Roberts hat mir übrigens bestätigt, dass das Committment in Scrum sich darauf bezieht, sich zu bemühen, das Ziel zu erreichen, nicht darauf, es wirklich zu erreichen. Anders gesagt: Planung ist ein Blick in die Zukunft und der ist bestenfalls unscharf, meistens aber falsch.
Hey Jens, das finde ich eine sehr schöne Sicht aufs SprintCommitment: "Sich bemühen, das Ziel zu erreichen."
AntwortenLöschen"Sich bemühen, das Ziel zu erreichen." finde ich von der Wortwahl zu schwach. Wenn im Arbeitszeugnis steht, man habe sich bemüht, bedeutet das nichts Gutes.
AntwortenLöschenIch würde eher sagen, dass das Team alles in seiner Macht stehende tun muss, um das Commitment zu halten, ohne dabei die durchhaltbare Geschwindigkeit (Sustainable Pace) zu opfern.
Hey Jens, das finde ich eine sehr schöne Sicht aufs SprintCommitment: "Sich bemühen, das Ziel zu erreichen."
AntwortenLöschen