5 Lektionen, die ich im ersten Jahr als Product Owner gelernt habe, die Dir viel Zeit und Frust ersparen können

Anfang 2016 übernahm ich das erste Mal Verantwortung für ein Produkt.

Noch bevor ich meine erste Product-Owner-Schulung absolvierte, hatte sich die Anzahl der Entwickler im Team, und damit meine Verantwortung, bereits verdoppelt. Die natürliche Folge meiner Unerfahrenheit waren Fehler und Lektionen, die mir in meinem ersten Jahr mehr über Product Ownership und Scrum beibrachten als die darauf folgenden Jahre zusammen.

Hier die 5 wichtigsten Lektionen aus dieser Zeit, die meine Einstellung, wie Produkte agil entwickelt werden sollten, am nachhaltigsten geprägt haben:

Bild von Austin Distel auf Unsplash

Lektion 1: Scrum Master und Product Owner in einem zu sein, schmälert den Teamerfolg

Zu Beginn hatten wir noch keinen Scrum Master im Team.

Nach dem ersten Sprint waren die User Stories entweder nicht abgeschlossen oder die Umsetzung erfüllte nicht meine Qualitätsansprüche. Mir war bewusst, dass wir das im nächsten Sprint verbessern mussten. Der beste Ort, um damit zu beginnen, war die Retrospektive. Deshalb übernahm ich bereitwillig die Verantwortung des Scrum Master, um den Termin zu moderieren. Bis zum Ende der Retrospektive konnten wir uns auf keine Verbesserung einigen.

Ich hatte versagt.

Als Scrum Master war mir wichtig, eine Atmosphäre zu schaffen, in der wir die Probleme offen und respektvoll ansprechen konnten. Als Product Owner war mir wichtig, dass wir im nächsten Sprint zwingend etwas Nützliches bereitstellen, was den Ansprüchen der Nutzer genügt. Beides zu vereinen war mir unmöglich.

Seither verstehe ich, warum in Scrum bewusst die Verantwortung des Product Owner und des Scrum Master auf zwei Schultern verteilt werden sollte. Wenn wir davon abweichen, werden wir damit wahrscheinlich den Erfolg unseres Teams schmälern.

Lektion 2: Unerfahrene Product Owner brauchen einen erfahren Scrum Master, um zu lernen, wie Scrum umgesetzt wird

Als Product Owner ist man verantwortlich, den Wert des Produkts zu maximieren. Das klingt einleuchtend, aber wie mache ich das konkret?

Ich wurde nicht als Product Owner geboren, sondern ich musste es lernen. Ich musste lernen, wie ich User Stories formuliere und diese mit den Entwicklern bespreche, sodass sie jeder verstanden hatte. Ich wusste auch nicht, welchen Personen man in das Sprint Review einladen sollte. Mir war auch fremd, wie ein gutes Sprint Review aufgebaut ist. Welche Punkte unbedingt auf der Agenda sein sollten und welche nicht. Alle diese Dinge habe ich Schritt für Schritt von unserem Scrum Master gelernt. Als mein Mentor hat er mich an die Hand genommen und mir Praktiken gezeigt, mit welchen er bereits gute Erfahrungen gemacht hat.

Seitdem ich einen erfahrenen Mentor als Scrum Master hatte, verstehe ich, warum es Scrum „Master“ heißt. Jeder Product Owner sollte jemanden im Team haben, der Scrum bereits gemeistert hat. Jemand von dessen Erfahrungen er lernen kann, wie man beginnt, Scrum umzusetzen.

Lektion 3: Was nützlich und somit wertvoll ist, entscheidet nicht der Product Owner, sondern die Nutzer

Nach einigen Sprints hatte unser Team die anfänglichen Schwierigkeiten überwunden.

Wir hatten einen Scrum Master, die meisten Entwickler arbeiteten Vollzeit für unser Team und wir hatten bis zum Sprint Review funktionierende Software, die wir potenziellen Nutzern jederzeit bereitstellen konnten. Bestärkt durch diese Erfolge luden wir im nächsten Sprint Review das erste Mal zukünftige Nutzer ein. Sie sollten die aktuelle Version des Produkts ausprobieren und uns Feedback geben.

Eine Stunde später war alles vorbei und ich am Boden zerstört.

Das Feedback war vernichtend. Wäre das Feedback eine Bewertung im App-Store gewesen, hätten wir wahrscheinlich gleich wieder dichtmachen können. Wir bekamen Rückmeldung, dass die Lösung nicht zu verwenden sei, da sie nicht den aktuellen Arbeitsprozess unterstützt, umständlich zu bedienen sei und die Verwendung mehr Zeit kostete als bei der aktuellen Bestandssoftware.

Was war passiert?

Bis dato hatte ich als Product Owner die User Stories abgenommen. Ich hatte angenommen, dass mein Problemverständnis ausreichend sei, um zu bewerten, ob unsere Lösung dem Benutzer wirklich Zeit erspart oder nicht. An diesem Tag lernte ich, die Meinung der Nutzer von Beginn an für Entscheidungsfindungen einzubeziehen.

Lektion 4: Zeit in Schätzungen zu investieren, kann auf lange Sicht Zeit sparen

Nach 6 Monaten lagen wir weit hinter dem ursprünglichen Zeitplan.

Das die nächsten Meilensteine immer weiter in die Ferne rückten, bleibt auch der Projektleitung nicht verborgen. Um eine bessere Übersicht über Situation zu erhalten, forderten Sie mich auf, eine Aufwandsabschätzung für den nächsten Meilenstein zu erstellen. Nachdem ich den Umfang für die Erreichung dieses Meilensteins im Product Backlog zusammengetragen hatte, musste der Arbeitsaufwand geschätzt werden. Da es sich um weit mehr als 50 Einträge handelte, fürchtete ich, dass das Schätzen — das Team schätzte zu diesem Zeitpunkt mit Planning Poker — mehrere Tage in Anspruch nehmen würde und somit den Sprint gefährden würde.

Hier rettet mich wieder mal unser Scrum Master.

Er zeigt den Entwicklern eine Schätzmethode, mit welcher sie in weniger als einem Nachmittag das ganze Backlog schätzten. Es ging so schnell, dass es wie Magie wirkte, daher ist der Name diese Methode auch „Magic Estimation“. In Kombination mit der bisherigen Velocity ermöglichten mir diese Schätzungen, die mögliche Erreichung des nächsten Meilensteins zu prognostizieren. Das nachfolgende Gespräch mit den Projektleitern lief besser als erhofft. Ich glaube, der Erfolgsfaktor bestand darin, dass wir konkrete Daten zur Verfügung hatten. Im Nachgang verstand ich besser, worauf die aktuelle Priorität liegen sollte und unser Team bekam sogar weitere Verstärkung zugesichert.

Nach dem Gespräch realisierte ich, dass Schätzen nicht immer im Sinne der Lean-Philosophie, als Zeitverschwendung zu betrachten ist.

Manchmal hilft Schätzen auch langfristig Zeit zu sparen, da es eine Diskussion über Aufwände ermöglicht, sich wieder auf das Wichtige zu fokussieren. Davon bin ich immer noch so überzeugt, dass ich nach wie vor Product Owner „Magic Estimation“ erkläre, die mein Professional Product Owner Training besuchen.

Lektion 5: Business Cases haben ein Problem, über das keiner spricht: Unbekannte

Wann sollte man im besten Fall eine Entscheidung treffen?

Wenn man die verlässlichsten Informationen hat. Gibt es hingegen Unbekannte, wie in der Produktentwicklung, dann ist dieser Zeitpunkt niemals am Anfang des Projekts. In meinem ersten Jahr als Product Owner wurde mir schnell bewusst, dass ein Strategieplan, der auf ein Viertel oder gar ein ganzes Jahr ausgerichtet ist und auf Annahmen beruht zum Scheitern verurteilt ist. Denn wie viel Zeit und Geld das Entwicklungsvorhaben kosten wird und wie viel Geld oder Geschäftswert es stiften wird sind immer nur Annahmen. Wir können nicht Wissen wie viel Geld wir verdienen werden, da es davon abhängt, wie gut sich unsere Lösung im Vergleich zu anderen Lösungen am Markt verhält. Ebenso können wir nicht wissen, welche Kosten die Erstellung und der Betrieb verursachen werden. Dies ist ohne Kenntnis der konkreten Lösung fast unmöglich.

Versteht mich nicht falsch, ich bin ein Befürworter von Business Cases.

Unternehmen sollten genau bewerten, in welche Vorhaben sie investieren und in welche nicht. Nur aus meiner Erfahrung ist der Erfolg dieser Vorhaben niemals garantiert und erfolgreiche Product Owner tun gut daran, ihre „Wetteinsätze“ so klein wie möglich zu wählen.

Konkret habe ich gelernt, dass am Anfang eines Vorhabens die Investitionen pro Sprint getätigt werden sollten. Erst wenn man mehr Vertrauen gesammelt hat, dass die Lösung wirklich ein Problem löst und es dafür auch einen Absatzmarkt gibt, sollte man längerfristig in die Umsetzung investieren.