✁
digitalien.org — Stefan Knecht
Der Product Owner definiert das WAS
Im Vergleich zu Produktmanagern hat ein PO als Produktverantwortlicher während der gesamten Projektlaufzeit eine aktivere und prominente Rolle.
Der Product Owner ist proaktiv
Der Produktverantwortliche oder PO …
- ist eine einzelne Person und kein Kommitee
- ist der ‘single wringable neck‘ mit sowohl der Fähigkeit wie Autorität zu entscheiden. Nur so kann sichergestellt werden, daß es konsistente Antworten und eindeutige Priorisierung gibt
- kennt umfassend die Probleme, die das Produkt für seine Nutzer löst
- weiß somit, welche Themen höchste Priorität haben und konkreten Nutzen stiften
- setzt laufend Prioritäten für Anforderungen
- führt das ➚ Product Backlog und stellt sicher, dass das Team wertstiftende Arbeit leisten kann,
- hilft Überbeanspruchung zu vermeiden und damit Qualität und Inhalt der Inkremente hoch zu halten
Der geborene 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 Umsetzungsteam braucht einen Product Owner.
Häufig 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 nützliche 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.
Mehr dazu: ➚ Was Agile Coaches können sollten.
Mit Risiko und Unsicherheiten umgehen
Zum Projektstart ist das Wissen strukturell geringer, damit die Unsicherheit und das Risiko hoch.
Es ist unwahrscheinlich dass zum Start eines Vorhabens alle Anforderungen unveränderlich und vollständig definiert sind.
Unter guten Bedingungen stehen gerade ausreichend viele Anforderungen für die Umsetzung in ersten Sprints bereit.
Die Illusion, in einem umfangreichen Anforderungsdokument könnten alle Randbedingungen und Anforderung erschöpfend erfasst sein, ist ein starkes Motiv für agile Methoden. Im Kern agilen Handelns steckt, dass Vieles sich erst im Fluss, durch Inspektion und Adaption ergeben kann — das wird anerkannt und integriert.
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.
4 Risikotypen
Vier Risikotypen können vereinfacht unterschieden werden:
- Geschäftsrisiken: Entwickeln wir das richtige Produkt? Bauen wir, was Nutzer wirklich brauchen und wollen — oder starten wir mit vagen, ungeprüften Annahmen?
- Soziales Risiko: Kann dieses Team das Produkt bauen? Haben wir die richtigen Leute, Fähigkeiten und wird zusammen gearbeitet?
- Technisches Risiko: Wird es funktionieren, auf der Plattform skalieren?
- Kosten und Zeitplan: Können wir es in der gegebenen Zeit und mit dem vorhandenen Budget bauen?
Die wichtigste Aufgabe des PO ...
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 niemandem. Weder einem Anforderungsgeber, stakeholder — noch dem Umsetzungsteam.
Aufgaben des Produktverantwortlichen
Der/die/das 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 wie 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: ein PO betreibt ein Projekt in Vollzeit — ebenso wie das Umsetzungsteam in Vollzeit zur Verfügung steht. Nur auf einer Hochzeit tanzen. Alles andere wird ‘nichts Rechtes und nichts Ganzes’.
Nicht auflösbare Linienaufgaben aus anderen Rollen müssen, wenn sie nicht delegiert werden können, zurücktreten oder notfalls und wenn es wirklich nicht anders geht: simultan erfüllt werden.
Der Grund ist klar: die kognitiven Rüstzeiten, sich von einem auf einen weiteren Kontext umzustellen sind wie hohe Transaktionskosten. Sich mehrfach in einen anderen Kontext einzudenken, wieder zu erkennen, was dort gerade wesentlich ist … nimmt Aufmerksamkeit, Konzentration und Energie.
POs tanzen mit dem System
Für diesen ständigen Tanz zwischen Ausgang und Ergebnis ist es besser, den Umfang von features zu reduzieren, als die (Liefer-)Zeit zu verlängern — kleine Inkremente in kurzen Zyklen liefern.
Für Scrum als agiles Framework 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 Behinderungen, impediments ausserhalb des Team und im umgebenden System des Unternehmens liegen