Es haben sich grundlegende Rahmenbedingungen geändert. Das Team stellt überraschend fest, dass das Sprintziel bei näherer Ansicht nicht mehr zu erreichen ist. Drei Tage vor Ende des Sprints ist deutlich sichtbar, dass der Forecast nicht annähernd erreicht werden kann.
Für das Team ist die Sache klar: Unter diesen Bedingungen kann man nicht mehr die Verantwortung für den Sprint übernehmen. Ähnlich sieht es der Scrum Master – so ist es nicht möglich, den Sprint weiterzuführen, er muss abgebrochen werden. Also trifft man sich in der Mitte des Sprints in einer spontan einberufenen Retro und bricht den Sprint offiziell ab, weil es ja nicht anders geht.
Sprintabbruch laut Scrum Guide
Doch damit handelt man im Widerspruch zum Scrum Guide. Dort steht nämlich schon seit der ersten Version klar und deutlich, dass nur eine einzige Person den Sprint abbrechen darf: der Product Owner. Natürlich darf das Team ihn bitten, natürlich darf der Scrum Master auf ihn einreden – aber die Entscheidung für einen Sprintabbruch dürfen sie nicht treffen.
Diese Regelung widerspricht dem intuitiven und einfachen „das Team fragen“, und deshalb wird in der Praxis gerne von ihr abgewichen.
Warum ist es im Scrum Guide trotzdem so geregelt?
Scrum Guide vs. Praxis?
Weil die Arbeit des Teams, die Arbeit des Scrum Masters und die Arbeit des POs nur einem Ziel dient, nämlich durch die eigene Arbeit den maximalen Wert zu Kundennutzen und Produkt beizutragen.
Solange man im Sprint und im Backlog arbeitet, ist die Sache klar: Die nützlichsten Aufgaben stehen im aktuellen Sprint an, die wichtigsten oben auf der Liste. Und der Sprint-Abbruch, ist er auch das Nützlichste, was ein Team zu Kundennutzen und Produkt beitragen kann?
Abbrechen darf nur der Product Owner
Die Antwort ist offensichtlich: Meist können die Teams gar nicht beurteilen, welche Wirkung der Abbruch auf Kundennutzen und Wertsteigerung des Produktes hat. Sie sehen die akuten Probleme in ihrer Arbeit, und dort brauchen sie Abhilfe. Der Effekt auf Kundennutzen ist schwer vorhersehbar.
Deshalb ist der Product Owner hier die maßgebliche Kraft. An der Schnittstelle zwischen Team und Kunde hat er die Informationen, die die beste Prognose zum Effekt des Abbruches erlauben. Deshalb liegt die Entscheidung über einen Sprintabbruch bei ihm.
[smartblock id=“7056″]Unsere Serie Agile Missverständnisse
Agile Missverständnisse
Agile Methoden haben eine klare Intention: Sie wollen die Wertschöpfung bei der Entstehung von Software steigern. Sie bieten zu diesem Zweck gleich einen ganzen Stapel von Werten, Prinzipien und Methoden an, die dabei unterstützen.
In der Praxis sind die Intentionen hinter diesen Werkzeugen oft nicht mehr so klar, und manchmal gehen sie ganz verloren; die Methode bleibt, mit ihren Umständlichkeiten und Haken, nur ohne den erwünschten Effekt. Über diese Art von agilen Missverständnissen will ich hier berichten – und darüber, wie man mit ihnen umgeht.
Schreibe einen Kommentar