Ein Produkt für Kunden verfügbar zu machen ist der einzige Weg für ein Unternehmen, mit diesem Produkt Wert zu generieren. Erst wenn ein Produkt am Markt verfügbar ist, sind Kunden bereit, Geld dafür zu bezahlen.
Gleichzeitig ist ein Release die effektivste Massnahme, den vermuteten Wert eines Produktes zu validieren. Es stellen sich bspw. folgende Fragen, die es zu beantworten gilt:
- Hat das Produkt den erhofften Markterfolg?
- Lohnt es sich weiter in die Produktentwicklung zu investieren?
- Wie werden die verschiedenen Funktionalitäten genutzt?
- Müssen wir allenfalls pivotieren und das Produkt neu ausrichten?
Releases sind also wortwörtlich wert-voll für ein Unternehmen und es lohnt sich, häufige Releases anzustreben. Damit ein Release jedoch überhaupt in Betracht gezogen werden kann, muss zwingend ein releasefähiges Produkt vorliegen.
Im Kontext von Scrum wird dies „releasefähiger Produktinkrement“ genannt, wobei sich ein Inkrement aus den Ergebnissen aller vorhergehenden Sprints zusammensetzt. Als „releasefähig“ wird ein Inkrement dann bezeichnet, wenn er einer strengen Qualitätskontrolle unterzogen wurde. Dieser angestrebte Qualitätsstandard wird im Kontext von Scrum „Definition of Done (DoD)“ genannt. Der Anspruch eines Scrum Teams muss also sein, spätestens am Ende eines Sprints über einen solchen releasefähigen Produktinkrement zu verfügen.
Ist diese Voraussetzung erfüllt, liegt es im Ermessen des Product Owners (PO), das Produkt für die Kunden verfügbar zu machen, d.h. zu releasen. Dabei wird ein PO neben den vorgängig erwähnten Aspekten verschiedene weitere Faktoren berücksichtigen:
- Marktrhythmen: Gibt es Rhythmen im Markt, die die Kaufentscheide der Kunden beeinflussen? Bspw. werden neue Gadgets häufig vor dem Weihnachtsgeschäft lanciert.
- Regulatorien: Gibt es regulatorische Rahmenbedingungen, die für das Produkt relevant sind? Bspw. müssen GDPR-Richtlinien rechtzeitig in einem Produkt berücksichtigt werden.
- Konkurrenzsituation: Wie wollen wir unser Produkt in Bezug auf die Konkurrenz positionieren? Gewichten wir bspw. umfangreiche Features höher als eine rasche Time-To-Market (oder vice-versa).
Es gehört zur Disziplin Product Management, diese Aspekte bei einem Releaseentscheid zu berücksichtigen. Grundlage, ob der Entscheid überhaupt getroffen werden kann ist jedoch in jedem Fall, dass das Produkt releasefähig ist. Die Verantwortung einen releasefähigen Produktinkrement zu erstellen obliegt dem Development Team.
Die Verlockung, ein nicht releasefähiges Produkt auf den Markt zu bringen kann gross sein, vor allem in einem kompetitiven Umfeld. Dies hat jedoch unkalkulierbare Konsequenzen auf die weitere Produktentwicklung. Beispielsweise frustriert ein fehlerhaftes Produkt die Kunden und das Lösen von Defects wird die Weiterentwicklung signifikant beeinträchtigen. Ganz zu schweigen von möglichen rechtlichen Konsequenzen.
Eine gute Produktarchitektur ermöglicht jedoch auch nur „teilweise“ Releases:
- Feature Toggles macht gewisse Funktionalitäten unsichtbar für die Kunden, obwohl die Funktionalität bereits im Produkt enthalten ist, also released wird.
- Canary Releases sind Releases, die nur einer eingeschränkten Anzahl Kunden zur Verfügung gestellt werden. Dies ermöglicht beispielsweise das Validieren von Nutzungshypothesen.
- Entkopplung von Releaseelementen ermöglicht, dass verschiedene Lösungsbestandteile unabhängig voneinander released werden können.
Auch diese Praktiken setzen jedoch eine strenge DoD voraus. Wird diese nicht eingehalten, liegt auch mit diesen Praktiken kein releasefähiges Inkrement vor, ist ergo die Voraussetzung für einen Releaseentscheid nicht gegeben.
Für Product Owner ist es wichtig, diese Voraussetzung zu verstehen. Es ist unprofessionelles Product Management, ein unfertiges Produkt releasen zu wollen.
Erreicht ihr in euren Teams einen releasefähigen Produktinkrement spätestens am Ende jedes Sprints?
Interessiert daran, euer Team in solchen Fragen besser unterstützen zu können?
Jetzt für den nächsten Scrum Master-Kurs anmelden