Ich lese zurzeit das sehr spannende Buch „Product Mastery: From Good to Great Product Ownership“ von Geoff Watts. Nach Geoff sollte ein großartiger Product Owner DRIVEN sein:

• Decisive: Willing and able to make decisions with incomplete information, and to allow others to make decisions too.
•  Ruthless:  Maintaining a relentless drive to maximise value and minimise risk while staying focused on the vision.
• Informed:  Cultivating a voracious appetite to know the most possible about your product’s domain while being prepared to act with incomplete information.
• Versatile:  Being responsive to changing circumstances, both in terms of product development techniques and also leadership style.
• Empowering:  Creating a sense of shared ownership amongst all stakeholders and bringing people along with you on the journey.
• Negotiable:  Having faith in one’s vision while also being open to feedback and change.

Ein ermächtigter Produt Owner, der kollaborativ mit einem ermächtigten Development Team iterativ und inkrementell Ergebnisse liefert, ist das Gütesiegel eines jeden agilen Produktentwicklungsprozesses. Als Product Owner solltest du immer darauf hinwirken, deine eigene Autonomie stetig auszuweiten, um die Autorität zu haben, schnell Entscheidungen zu treffen. Gleichzeitig solltest du daran arbeiten, die Autonomie des Entwicklungsteams zu fördern, damit dieses nicht zu sehr von dir abhängig ist und selbst kreative Lösungen findet. Wenn du es schaffst, dass Development Team zu mehr Eigenverantwortung und Selbstorganisation zu ermächtigen, wirst du die Zeit, die du mit dem Team verbringst, für einen wesentlich wertvolleren Austausch nutzen können. 

Beobachte einmal für dich, ob du immer wieder bestimmte Entscheidungen von den Stakeholdern oder dem Management absegnen lassen musst oder einige Entscheidung ganz ohne deine Teilhabe getroffen werden. Sollte dies so sein, dann spreche das einmal direkt an. Sei bestrebt das Vertrauen der Personen zu gewinnen, damit sie dir so viel Entscheidungsbefugnis wie möglich direkt übertragen. Du könntest argumentieren, dass die Person nach kurzen Interration von ein bis zwei Sprints anhand deiner Ergebnisse sehen wird, dass du vertrauenswürdig mit den erweiterten Befugnissen umgehst. Erkläre im Voraus, wie du zusammen mit dem Team Entscheidungen triffst und wie du bei Priorisierungen vorgehst, um Risiken zu minieren und schnell Lernerfahrungen zu sammeln. So kannst du Stakeholder und das Management davon überzeugen, dass du mit Bedacht handelst. Du kannst auch eine Runde Delegation Poker (Praktik aus dem Management 3.0) mit den bisherigen Entscheidern spielen, damit ihr euch auf ein neues Delegation Level einigt. 

Es gibt sieben unterschiedliche Delegation Level. Für jeden Typ von Entscheidung könnt ihr euch auf ein bestimmtes Level einigen und damit experimentieren.

1. Tell: Der Entscheider teilt dir die Entscheidung mit.
2. Sell: Der Entscheider bringt Argumente und versucht dir seine feststehende Entscheidung schmackhaft zu verkaufen.
3. Consult: Der Entscheider fragt dich nach deiner Meinung und entscheidet dann.
4. Agree: Der Entscheider berät sich mit dir und ihr einigt euch kollaborativ auf eine Entscheidung.
5. Advise: Der Entscheider gibt dir einen Ratschlag, aber du entscheidest dann selbst.
6. Inquire: Du entscheidest von vorneherein und informierst im Anschluss den bisherigen Entscheider.
7. Delegate: Du entscheidest komplett alleine und brauchst auch niemanden über deine Entscheidung zu informieren.

Findet auch für dich und das Team heraus, welche Entscheidungen, dass Team selbst treffen kann und welche du als Product Owner treffen musst oder möchtest. Teste für einen Sprint folgendes: Immer, wenn das Team eine Frage nach einer Entscheidung an dich richtet, gibst du ihm die Antwort zusammen mit einer Rückmeldung ob

1. das Team die Entscheidung exakt so umsetzen muss,
2. deine Rückmeldung lediglich Rahmenbedingungen enthält und das Team die Lösung selbst bestimmen kann oder
3. das Team völlig frei ist, wie es verfährt.

Der Scrum Master versucht anhand der Ergebnisse Muster zu erkennen, um zu bestimmen, welche Typen an Entscheidungen direkt an das Team übertragen werden könnten. Startet im nächsten Sprint ein Experiment, indem du von vorneherein einige Entscheidungen an das Team überträgst und besprecht in der folgenden Retrospektive die Ergebnisse.

Wenn es um die Ermächtigung von Teams geht, ihre eigenen Entscheidungen zu treffen, ist eine der größten Herausforderungen die Angst vor dem Loslassen. Du fragst dich vielleicht: „Ist das Team vertrauenswürdig genug, um ihm Entscheidungen zu übertragen?“. Die Antwort erhältst du nur, wenn du anfängt zu vertrauen und beobachtest was passiert. Der amerikanische Politiker Henry Stimson sagte einst: “The only way to make a man trustworthy is to trust him.” Der Lean-StartUp Zyklus aus Build-Meassure-Learn funktioniert auch hier. Nach jedem Sprint kannst du in der Retrospektive besprechen, ob du den Spielraum des Teams ausweiten oder wieder etwas zurück justieren möchtest. Fehlentscheidungen des Teams können im nächsten Sprint revidiert werden. 

Damit du vertrauensvoll Entscheidungen an das Team übertragen kannst, sei sehr darum bemüht, dass keine formelle Kunde-Lieferanten-Beziehung zwischen euch entsteht. Baue stattdessen eine positive, partnerschaftliche und respektvolle Beziehung auf. Pflege hierzu einen verbindenden Führungsstil (siehe Blogbeitrag „Versatile – Als Product Owner anpassungsfähig und flexible sein“). Dies wird dem Team helfen sich transparent zu zeigen, um Empfehlungen, Fragen und Bedenken auszusprechen.

Eine solch positive Beziehung kann davon beeinträchtigt werden, dass noch unerfahrene Entwickler, welche die enge Zusammenarbeit mit einem Businessvertreter nicht gewöhnt sind, so etwas wie Lampenfieber gegenüber dem „Kunden“ entwickeln. Solche Teammitglieder meiden es eher persönliche Aussagen zu treffen, stellen Fragen erst sehr später oder gar nicht, halten sich im Daily Scrum und in Retrospektiven gerne zurück. Gehe empathisch auf diese Personen ein und schaffe einen sicheren Raum, in welchem sie sich trauen sich zu äußern. Danke ihnen für ihre Ehrlichkeit und Offenheit und zeige, dass auch du eine verletzliche Seite hast.

Beteilige dich auch am Recruiting Prozess, wenn es darum geht, neue Mitglieder in das Development Team aufzunehmen. Neue Mitglieder müssen auch mit dir harmonieren. Wie Wahrheit ist, wenn jemand außerhalb des Teams die Recruiting Entscheidung trifft und unpassende Leute in das Team holt, kann dies den bisherigen Vertrauensaufbau stark negativ beeinflussen. Sollte dies passieren und du merkst nach den ersten Sprints, dass Personen nicht vertrauenswürdig oder nicht qualifiziert sind, dann arbeite daran, dieses Problem zu lösen. Dies kann auch bedeuten, dafür zu sorgen, diese Personen aus dem Team wieder zu entfernen. 

Finde eine Balance darin wie viel Zeit du mit dem Development Team verbringst. Ist es zu wenig, wird das Team anfangen von sich aus Annahmen zu treffen, wenn es seine Fragen mit dir nicht geklärt bekommt. Ist es zu viel Zeit und es wird von dir erwartet, je kleinste Entscheidung zu treffen, unterminiert dies ihre Unabhängigkeit und Kreativität.

Gute Product Owner schreiben gute Storys. Großartige Product Owner erzählen gute Geschichten. Wenn du das nächste Mal ein User Story vorstellst, dann versuche einmal diese mit Leben zu füllen. Erzähle warum der Nutzer gerne das Ergebnis erzielen möchte, welche Sorgen und Ängste oder Wünsche ihn dazu antreiben und welchen Einfluss das neue Feature auf sein Leben haben wird. Wenn es sinnvoll ist, dann erstelle vorher eine Persona, die du dann in den User Stories nutzen kannst. So werden alle Beteiligten viel besser verstehen, wo das Problem des Nutzers liegt und welche Lösung benötigt wird. Das Team wird sich auch emotional viel verbundener mit dem Produkt fühlen, wenn sie verstehen, für wen sie entwickeln. Auch wird es ihnen helfen übertragene Entscheidungen während des Entwicklungsprozesses besser zu treffen, z.B. bezüglich dem Frontenddesign.

Oft wirst du als Product Owner gebeten möglichst detailliert die Akzeptanzkriterien zu beschreiben. Doch User Stories waren nie dazu gedacht, eine umfassende Anforderungsspezifikation zu sein. Sie sollen den Problemkontext beschreiben und als Impuls dienen, kollaborativ zu klären, was die beste Lösung ist. Gebe auch hier dem Team mehr Spielraum, damit sie selbst Teile der Akzeptanzkriterien und damit der Lösung festlegen. Oder ihr schreibt die Akzeptanzkriterien im Refinement direkt gemeinsam auf. Denn sind nicht die besten Geschichten, die die gemeinsam geschrieben werden? 

• Was würdest du sagen, verbringst du eher zu viel Zeit mit dem Team oder zu wenig? Was würde Team wohl sagen?
• Wie sehr glaubst du dein Team? Wie sehr vertraust du ihm?
• Wenn das Team von „wir“ spricht, hört es sich dann so an, also ob du als Product Owner darin inkludiert oder ausgeschlossen bist?
• Spricht das Team darüber, Features für dich zu liefern oder mit dir als ein Team?
• Wenn du am Daily Scrum des Teams teilnimmst, welche Mehrwert kannst du zu diesem Event beisteuern?
• Hast du einmal mit dem Team explizit geklärt, welche Entscheidungen du guten Gewissens delegieren magst und welche du lieber selber triffst?
• Von wie vielen Personen brauchst du eine Zustimmung, wenn du für dich entschieden hast, was als nächstens zu tun ist? Was ist das Risiko für die Produktentwicklung, wenn deine Entscheidungen überstimmt werden können?
• Wie sehr helfen deine Produktanforderungen dem Team den Produktnutzer zu verstehe und sich in diesen hineinzuversetzen?
• Wie gut verstehst du, welche Personen dein Produkt nutzen, wie sie es nutzen bzw. ob sie es falsch nutzen?
• Welche Teile der Welt deiner Nutzer kennst du am wenigsten? Wie könntest du dein Verständnis und Wissen über diesen Bereich verbessern?
• Was könnten dir Vorteile sein, wenn du dich selbst einmal aus deiner Komfortzone bewegst? Für dich? Für das Team? Für das Produkt?