Die Product Owner Rolle

Der Product Owner ist proaktiv

Im Vergleich zu traditionellen Auftraggebern oder Produktmanagern hat ein PO als Produktverantwortlicher während der gesamten Projektlaufzeit eine aktivere und prominente Rolle.

Der Produktverantwortliche …

  • ist eine einzelne Person und kein Kommitee
  • ist der ‘single wringable neck’ mit sowohl der Fähigkeit wie Autorität zu entscheiden: um sicherzustellen, daß es konsistente Antworten und eine eindeutige Priorisierung gibt
  • kennt umfassend die Probleme, die das Produkt für seine Nutzer löst
  • weiß damit, welche Themen die höchste Priorität haben und Nutzen stiften
  • setzt laufend Prioritäten für Anforderungen im Verlauf des Projektes
  • führt das Product Backlog und stellt sicher, dass das Team wertstiftende Arbeit leisten kann, hilft Überbeanspruchung zu vermeiden und Qualität und Inhalt der Inkremente hoch zu halten

Der ideale Product Owner ist …

  • Kommunikator, Vermittler und Teamplayer
  • Visionär und Macher
  • handlungsfähig und engagiert
  • erreichbar und qualifiziert

Besondere Umstände in großen Umgebungen

Jedes Team braucht einen Product Owner, aber oft hat ein Product Owner mehrere Teams.

In größeren Projekten kann die Rolle durch unterstützende Spezialisten oder ein Product Owner Team erweitert werden. Gibt es mehrere Entwicklungsteams mit jeweils dediziertem Product Owner, dann ist ein Chief Product Owner (CPO) für die Integrität und Qualität des Gesamtprodukts verantwortlich.

Dennoch hat auch in Skalierung jedes Umsetzungs-/Entwicklungsteam genau einen Product Owner als primären Ansprechpartner, der relevante Entscheidungen über Anforderungsdetails und deren Priorität zügig trifft.

Es ist nicht ungewöhnlich, dass ein Linienvorgesetzter der Teammitglieder die PO-Rolle übernimmt. Der erste und unbedingt notwendige Lernschritt ist dann, dass der PO die Selbstorganisation des Umsetzungsteams respektiert und fördert und persönliche oder Ziele seines Herkunftsbereiches oder -abteilung nicht im Widerspruch zu den Projektzielen stehen. Das ist schwierig — kann aber gelingen, wenn der Agile Coach/Trainer/Master aufmerksam auf Verhaltensmuster achtet und sie anspricht.

Der PO präzisiert und steht zur Verfügung

Während Softwareingenieure und -architekten an den ersten Iterationen arbeiten, muss der Product Owner mit Unterstützung des Teams und gespeist von den formulierten Bedürfnissen aller Stakeholder die nächsten Anforderungen präzisieren.
 
Stakeholder sind alle, die von einem Produkt in irgendeiner Weise betroffen oder beeinflusst sind.

Gleichzeitig muss der PO für Fragen und Klärungen während Sprints ständig zur Verfügung stehen. Latenz bedeutet Zeit- und damit Reibungsverlust und macht die Umsetzung weniger effizient.

In der Praxis wird es immer Unklarheiten und Rückfragen geben, da sich sinnvolle Anpassungen aus den Erfahrungen während der Umsetzung ergeben.

Direkte Kommunikation und Präsenz

Auch an der Schnittstelle ‘Anforderer-Entwickler’ ist direkte 1:1-Kommunikation besser als umfangreiche schriftliche Dokumentation und Spezifikation.

Die Konkretisierung von Anforderungen ist also eher das Resultat von Gesprächen und ständigen Verhandlungen. Dies gilt ebenso für die Präsenz des PO idealerweise im Teamroom: das verkürzt Wege, unproduktive Warte- und kognitive Rüstzeiten und schafft Transparenz und Informationsfluss.

Das WAS definiert der Product Owner, das WIE als technisches Wissen zur Umsetzung kommt vom Umsetzungsteam: gemeinsam können sie das beste Resultat erreichen. Es hilft also sehr, wenn ein PO fachliche Expertise, Domänenwissen und Erfahrung mitbringt und sie nicht erst im Projekt erwirbt.

Zur Abrundung und weil es hier gut passt:

In mit Scrum organisierten Vorhaben hilft der Agile Coach/Scrum Master allen BESSER zu werden, effektiver und effizienter zu kommunizieren, nicht wertstiftende Praktiken sein zu lassen und mit guten Experimenten Neues auszuprobieren. Auch wenn Scrum nicht die Form ist — es hilft immer und überall, sich beim Lernen helfen zu lassen.

Mit Risiko und Unsicherheiten umgehen

Es ist unwahrscheinlich dass zum Start eines Vorhabens alle Anforderungen unveränderlich und vollständig definiert sind.
Unter guten Bedingungen stehen ausreichend viele Anforderungen für die ersten Sprints bereit. Die Illusion, in einem umfangreichen Anforderungsdokument könnten alle Randbedingungen und Anforderung erschöpfend erfasst sein, ist einer der Gründe für agile Methoden, die beobachten und anerkennen, dass Vieles sich erst im Fluss, durch Inspektion und Adaption ergeben kann.

Zum Projektstart ist das Wissen strukturell geringer, damit die Unsicherheit und das Risiko hoch.

Ein PO erwirbt mit dem Team Wissen um Unsicherheit und Risiko zu reduzieren indem die Product Backlog Items kontinuierlich weiter detailliert werden.

 
Mit jeder weiteren Detaillierung, mit jedem refinement werden Aspekte klarer, Unsicherheit verringert und damit Risiken geringer.

Vier Risikotypen können vereinfacht unterschieden werden:

  • Geschäftsrisiken: Entwickeln wir das richtige Produkt?
  • Soziales Risiko: Können dieses Team es bauen?
  • Technisches Risiko: Wird es funktionieren, auf der Plattform skalieren?
  • Kosten und Zeitplan: Können wir es in der Zeit und mit dem Budget bauen? 

Aufgaben des Produktverantwortlichen

Der/die PO …

  • entwickelt eine klare Vision mit dem Team, Stakeholdern und Kunden/Nutzern (Tools: Lean Canvas, Vision Board)
  • optimiert den Kundennutzen
  • konsolidiert und priorisiert laufend, mindestens vor jedem Sprint, den Product Backlog nach geschäftlichem Wert (business value) und Risiko
  • spricht häufig und regelmäßig mit Kunden/Nutzern, Entwicklern und operativ Verantwortlichen, nimmt deren Bedürfnisse wahr um damit stories schärfen zu können
  • betreibt aktiv realistisches Erwartungsmanagement in Richtung der Stakeholder und ist jederzeit in der Lage für die obersten 15% der Backlog Items Nutzen und Kontext zu erklären
  • identifiziert und formuliert Produkt-Features und kann sich dabei natürlich helfen lassen (Tools: Persona, Story Maps, Design Thinking, Impact Mapping)
  • und beantwortet Fragen von Stakeholdern und Umsetzungsteam zur Funktionalität und Kreuzbedingungen
  • führt Machbarkeitsstudien oder spikes durch oder beauftragt sie
  • entscheidet über Zeitpunkte und Umfänge von Releases
  • akzeptiert Ergebnisse aus Inkrementen als done … oder weist sie zurück, wenn sie den zuvor festgeschriebenen Akzeptanzkriterien nicht entsprechen
  • plant, koordiniert und implementiert die strategische Produktplanung und die Produkt-Roadmap, den Lebenszyklus des Produktes bzw. seiner Komponenten und bestimmt Produktverbesserungen, deren Umfang und Zeitpunkt
  • optimiert den Return on Investment (ROI) und die Gesamtbetriebskosten (TCO, total cost of ownership)

Aus der Breite und Tiefe der Aufgaben ergibt sich fast zwingend, dass ein PO einem Projekt, ebenso wie das Umsetzungsteam in Vollzeit zur Verfügung steht. Nicht auflösbare Linienaufgaben müssen, wenn sie nicht delegiert werden können, zurücktreten oder notfalls und wenn es wirklich nicht anders geht: simultan erfüllt werden.

Die wichtigste Aufgabe des PO ...

.. ist zu entscheiden, was nicht implementiert wird.
Das ist schwierig.

Der Wortschatz des PO zur Verwaltung des Backlog ist damit überschaubar klein:
»Ja/Nein« — oder freundlicher: »Nein danke, noch nicht.« 

Ein »Vielleicht« hilft weder einem Anforderungsgeber, Stakeholder — noch dem Umsetzungsteam.

POs tanzen mit dem System

Für diesen ständigen Tanz zwischen Ausgang und Ergebnis ist es in der Regel besser, den Umfang von features zu reduzieren, als die (Liefer-)Zeit zu verlängern — kleine Inkremente in kurzen Zyklen liefern.

Für Scrum als Methode kommen als Aufgaben des PO hinzu …

  • beim Sprint Planning dabei sein, diskutieren, Fragen beantworten, stories schneiden, Testszenarien identifizieren
  • im Sprint Review Ergebnisse akzeptieren oder zurückweisen und Feedback in den Product Backlog und relevante PBIs integrieren
  • Stakeholder zu Meetings einladen: Planning, Reviews, Retros
  • gleichberechtigt mit dem Team an Retrospektiven teilnehmen
  • den Scrum Master unterstützen, wenn impediments ausserhalb des Team scope und im umgebenden System des Unternehmens liegen