Über kaum etwas wird so wenig gesprochen wie über das Inkrement.
Es dreht sich alles um Sprint-Retrospektiven, Daily Scrums und Sprint-Ziele.
Doch bei Scrum geht es letztendlich um das Inkrement.
Und obwohl selten darüber gesprochen wird, kursieren viele Irrtümer. Heute möchte ich diese klären, damit du bei deiner Arbeit den Blick für das Wesentliche nicht verlierst: den Kundenfokus.
Los geht's mit dem ersten Irrtum:
Irrtum 1: Der Product Owner kann nicht über den Zeitpunkt des Releases entscheiden
Die Gründe für diesen Irrtum sind vielfältig. Hier einige Beispiele:
- Es bestehen Abhängigkeiten zu anderen Teams, weshalb es einen Release-Manager gibt.
- Im Unternehmen müssen sich alle Teams an einen vorgegebenen Release-Plan halten.
- Es gibt technische Hürden, weshalb der Tech-Lead entscheidet, was ein Release machbar macht.
- Die Freigabe für ein Release ist nicht in der Rolle des Product Owners verankert; dafür gibt es den Release-Manager.
Die Auswirkungen sind immer die gleichen: Kann der Product Owner nicht über den Zeitpunkt des Releases entscheiden, kann er seine Arbeit nicht effektiv ausführen. Die Aufgabe des Product Owners besteht darin, den Wert des Produkts zu maximieren. Dieser Wert entsteht durch die Arbeit der Entwickler. Das Problem dabei ist jedoch, dass „Wert“ eine Annahme bleibt. Er bleibt eine Annahme, bis der Nutzer das Produkt verwendet. Erst dann bestätigt der Kunde den Wert. Um den Wert zu bestätigen, muss der Product Owner auch die Verantwortung über den Release haben.
Ohne Release kein Feedback, ohne Feedback kein Wert.
Irrtum 2: Das Inkrement entsteht erst am Ende des Sprints
Das Konzept eines Inkrements führt zu Verwirrungen.
In der Softwareentwicklung bezeichnet ein Inkrement einfach die nächste Version des Produkts. Der erste Product-Backlog-Eintrag, der im Sprint fertiggestellt ist, bildet die Grundlage für eine neue Version. Weitere fertige Einträge können zu dieser neuen Version hinzugefügt werden.
Da der Scrum Guide nicht nur für die Softwareentwicklung gilt, wird es dort neutraler beschrieben:
„In dem Moment, in dem ein Product-Backlog-Eintrag die Definition of Done erfüllt, wird ein Inkrement geboren.“
Leider wenden viele Teams die Definition of Done nicht einzeln auf jeden Eintrag des Product Backlogs an. Stattdessen beginnen sie alle Einträge im Sprint-Backlog gleichzeitig. Erst am Ende des Sprints führen sie alle notwendigen Aktivitäten durch, damit alle Einträge auch die Definition of Done erfüllen. Dieses Vorgehen bezeichnen wir als „Wasserfall im Sprint“.
Wenn Teams wirklich einen Eintrag „fertigbringen“ würden, bevor sie zum nächsten übergehen, hätte dieser Ansatz einen bemerkenswerten Nebeneffekt:
Er könnte es dem Team ermöglichen, das Produktinkrement tatsächlich noch vor dem Ende des Sprints zu veröffentlichen.
Was uns zum nächsten Irrtum bringt:
Irrtum 3: Das Release darf erst nach dem Sprint-Review freigegeben werden
Dieser Irrglaube hält sich hartnäckig.
Es vergeht kein „Professional Scrum Product Owner“-Training, in dem ich nicht danach gefragt werde, wann im Sprint-Review die User Stories abgenommen werden. Achtung: Das Sprint-Review ist kein Abnahme-Meeting. Der Product Owner oder die Business-Stakeholder nehmen dort nicht die User Stories der Entwickler ab und geben sie im Anschluss frei.
Da diese Annahme leider immer noch weit verbreitet ist, wird das Thema im Scrum Guide noch einmal aufgeführt:
„Ein Inkrement könnte jedoch auch schon vor Ende des Sprints an die Stakeholder geliefert werden.“
Und die Erklärung ist auch mit einer Warnung untermauert:
„Das Sprint-Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden.“
Wenn wir bisher über Releases gesprochen haben, meinten wir damit die Freigabe zum Kunden. Auch das versteht nicht jeder darunter.
Was uns zum nächsten Mythos bringt:
Irrtum 4: Release bedeutet, die Software an die Testabteilung zu übergeben
Im „Professional Scrum Master – Advanced“-Training bitten Marc und ich die Teilnehmer aufzuzeigen, was ihre Definition of Done alles umfasst.
In den letzten drei Jahren gab es kein Training, in dem es anders war. In jedem Training musste die Hälfte der Teilnehmer zugeben: „Done“ bedeutet für sie nicht zwangsläufig, dass etwas potenziell nutzbar durch den Kunden ist.
Für ihre Teams bedeutet „Fertig“, dass der Code geschrieben wurde oder die Software getestet ist. Das Problem dabei?
Die Definition of Done ist ein Werkzeug zur Risikokontrolle. Erst wenn „Done“ wirklich bedeutet, dass etwas nutzbar durch den Kunden ist, haben wir das Risiko reduziert.
Hier eine Grafik, die das veranschaulicht:
Wenn du mehr darüber erfahren möchtest, schau dir gerne diesen Artikel an. Es geht um „Risikomanagement in Scrum – Warum jedes Unternehmen einen Scrum Master braucht“. Du willst nicht nur darüber lesen? Sondern dich mit anderen fortgeschrittenen Scrum Mastern austauschen? Dann empfehle ich dir einen Besuch unseres „Professional Scrum Master – Advanced“-Trainings. Dort besprechen wir neben der Definition of Done auch Sprint-Ziele und wie du deinen Product Owner bei seiner Arbeit besser unterstützt.
Kommen wir zum letzten Irrtum:
Irrtum 5: Alle Team-Ergebnisse müssen Bestandteil des Inkrements sein
Um diesen Irrtum besser zu verstehen, betrachten wir ein Beispiel:
- Eine neue Funktion für ein Fahrerassistenzsystem im Auto ist erst dann Bestandteil des Systems, wenn sie die Qualitätsstandards des Produkts erfüllt. Diese Standards werden in der Definition of Done beschrieben.
- Die Ergebnisse einer Kundenbefragung werden niemals die Definition of Done erfüllen. Sie müssen es auch nicht, da sie nicht direkter Bestandteil des Fahrerassistenzsystems im Auto sind.
Allerdings können Arbeiten als Einträge im Product-Backlog formuliert sein. Deshalb gilt: Die Definition of Done bezieht sich nicht auf Einträge im Product-Backlog, sondern ist das Commitment zum Produkt.
Nur wenn ein Eintrag die Definition of Done erfüllt, kann er Teil des Produkts sein. Aber nicht jeder Eintrag muss Teil des Produkts sein.
Wenn du die eine oder andere Aussage nicht sofort als Irrtum erkennen konntest, dann wirf gerne einen Blick auf meine 19-teilige „Scrum im Selbststudium“-Reihe. Dort erkläre ich dir die Theorie, Regeln und Empfehlungen aus dem Scrum Guide im Detail.