Dein erster Tag als Scrum Product Owner? Okay, ich zeige dir die wichtigsten Herausforderungen, damit du bei deinen ersten Schritten als Product Owner nicht stolpern musst. Schliesslich ist die der Product Owner die wohl anspruchstvollste Rolle in Scrum.
Das Unternehmen macht neuerdings Scrum. Das Entwicklungsteam entspricht dem vorherigen Entwicklerteam? Als Scrum Master verpflichtet man den engagiertesten Entwickler und als Product Owner den fachlich breitesten Business Analysten? Das perfekte Scrum Team ist also nun geschaffen? Sprint 1 kann starten?
Und so startet Sprint 1. Der Product Owner ist motiviert, spezifiziert User Stories in Perfektion, priorisiert angemessen und besonnen. Das Entwicklungsteam implementiert, testet; liefert rechtzeitig das erforderliche Inkrement. Der Scrum Master wacht, moderiert die Zeremonien, zitiert ab und an den Scrum Guide. Alle sind zufrieden.
Der erste Sprint scheitert. Das Scrum Team hat sich überschätzt. Das Inkrement ist nicht ausreichend getestet. Die Lösungsspezifikation ist nicht ihrer Nachhaltigkeit würdig. Die Tests sind nicht automatisiert. Der Product Owner hat sich in Anforderungsdetails versteigt. Der Scrum Master beschränkt sich als Zeremonienmeister. Was nun?
Der Scrum Guide erklärt unmissverständlich, was die Aufgaben des Product Owners sind. Dazu zählen:
Fünf Aufgaben, nicht viele eigentlich.
Dennoch habe ich fast noch keinen Product Owner kennengelernt, der diese fünf Aufgaben gleichzeitig beherrscht. Ok, ein Product Owner mag eventuell noch alle seine Product Backlog Einträge erklären können, schliesslich ist's sein Produkt, seine Domäne, sein Bereich, und er arbeitet bereits seit Jahrzehnten in diesem Kontext.
Doch dann misslingt ihm gleichzeitig, dass das Entwicklungsteam "seine" Product Backlog Einträge auf der richtigen Abstraktionsstufe versteht. Entweder mischt der Product Owner sich zu sehr in die Arbeit des Entwicklungsteams ein - oder er versteht sie überhaupt nicht, tut es als "IT-Umsetzung" ab, die ihn nicht zu interessieren braucht.
Ebenso steht ein Product Backlog selten wirklich allen Beteiligten transparent zur Verfügung. Zwar benutzt der Product Owner ein zeitgemässes IT-Werkzeug, vielleicht auch JIRA, aber dennoch ist sein Product Backlog chaotisch, nicht strukturiert. Für Beteiligte ist es undurchsichtig, was geplant ist und was sich im "internen" Refinement-Zyklus des Product Owners versteckt.
Die Königsdisziplin eines jeden Product Owners ist es, den Wert des Produktes zu maximieren. Dies mittels der Priorisierung. Priorisieren, damit die Ziele bestmöglich erreicht werden können. Bis zum dritten Sprint ist man als Product Owner noch geschützt. Doch danach wollen alle möglichen Stakeholder eingreifen, mitreden, mitentscheiden.
Schliesslich können die wenigsten Product Owner Nein sagen. Vor allem nicht, wenn sie Business Analysten waren, welche die Organisation jahrelang konditionierte, Anforderungen möglichst penibel zu dokumentieren und ja nicht zu hinterfragen. Der Product Owner wird zum Gehetzten, Getriebenen.
Er wird vom Gestalter zum Manager.
Leider, niemand will Manager sein, wir wollen gestalten, insbesondere der Product Owner. Beeinflussen, formen, designen, Kunden begeistern, ja. Und nicht Excel-Tabellen schubsen.
Ich schule, coache Product Owner mit Agile Requirements Engineering, damit sie erfolgreicher werden. Damit sie den Wert ihrer eigenen Arbeit, aber auch ihres Produktes maximieren können. Ich gestehe aber, dass die Arbeit anspruchsvoll ist. Ein Product Owner muss auf unterschiedlichsten Levels diskutieren können. Er muss sowohl Netzwerker wie auch Ingenieur sein. Er muss die Autonomie seines Teams respektieren, gleichzeitig sein Team ausrichten. Er muss den aktuellen Sprint beantworten, aber auch die nächsten vier vorausplanen können. Er muss das alles in einer ausgeglichenen Person vereinen.
Gewisse Praktiken kann man erlernen - hier unterstützen wir mit unserem Fokusthema Agile Requirements Engineering. Doch den Rest muss man tagtäglich praktizieren, idealerweise begleitet mit dot.coaching. Und so reift man innerhalb von mindestens zehn Sprints zum perfekten Product Owner. Der Weg zum Nordstern auch hier.
Zusammen mit der ZHAW haben wir ein CAS Agile Requirements Engineering entwickelt, das Interessierte auf die agile Königsrolle Product Owner zweckmässig vorbereitet.
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.