Lesedauer 2 Minuten
Produkte, Produkte, Produkte – das zentrale Objekt der Begierde in der agilen und auch sonstigen Welt. In Scrum verantwortet der/die Product Owner welche und in welcher Reihenfolge neue Funktionen in ein Produkt einfließen oder eben nicht. Das ursprünglich auf eine einzelne Person zentrierte System schwächelt, wenn die Anzahl der Stakeholder größer und Anforderungen komplexer werden. Eine mögliche, vielleicht bessere Alternative zeigen wir im Blogartikel auf.
Product Owner sind die Dreh- und Angelpunkte jedes Scrum-Teams und verantwortlich für die Erhebung und Definition der funktionalen Anforderung inkl. deren Priorisierung. Dokumentiert und gepflegt wird das ganze im Product Backlog. So weit, so normal und mittlerweile üblich.
In vielen unserer Kundenprojekte zeigen sich jedoch die Grenzen dieses Konzepts. Product Owner stehen buchstäblich zwischen Team, ScrumMaster, Linienmanagement und Stakeholdern aka Business. Sie sollen bei Kunden und dem Team sein, das Management im Zaum halten und neue Aufträge an Land ziehen. Selbstverständlich alles gleichzeitig und jederzeit für alle erreichbar. Eigentlich eine Herkulesaufgabe, die praktisch kaum seriös und professionell machbar ist. An dieser Stelle hat sich eine Erweiterung des ursprünglichen Scrum-Rollenkonzepts bewährt. Die Trennung zwischen INTERNEM und EXTERNEM Product Owner.
Voraussetzungen dafür sind verfügbare und exzellente Mitarbeiter, die sich gleichzeitig auf professioneller Ebene (noch besser natürlich auch persönlich) sehr gut verstehen und ergänzen. Der iPO ist dabei näher an der Technik – umgekehrt ist der ePO näher am Markt und kommerziellen Anforderungen. Missverständnisse und Konflikte können so vermieden werden.
Unterschiede interner Product Owner vs. externer Product Owner
Der INTERNE PO (iPO) ist für User Stories, Akzeptanzkriterien und generell der Kommunikation zum Team verantwortlich. Der EXTERNE Product Owner (ePO) ist für die Kommunikation zum Markt, den Kunden, der Priorisierung von neuen Features bzw. Epics und der Kommunikation mit der Außenwelt zuständig. Sie teilen sich also die Verantwortung für das Produkt und die Aufgaben der PO-Rolle – auf verschiedenen Ebenen. Es liegt auf der Hand, dass durch ein solches System alle Seiten bestmöglich bedient werden können.
Die spezifischen Vor- und Nachteile eines solchen Systems zeigen wir euch hier:
Vorteile:
+ Workload wird auf mehrere Mitarbeiter verteilt
+ Deutlich erhöhte Kundenorientierung durch ePO
+ Interner PO ist jederzeit für Team verfügbar und kann Fragen zu User Stories beantworten
+ Externer PO ist jederzeit für Kunden verfügbar und nimmt Anforderungen des Marktes auf
+ Weniger Missverständnisse PO <> Team, da iPO mehr Zeit für sein Team zur Verfügung hat
+ Rückfragen zu User Stories können schnell gelöst werden
+ ePO ist Experte auf funktionaler Produkt-Ebene, iPO ist Experte auf technischer Produkt-Ebene
Nachteile:
– Insgesamt höherer Personalaufwand (wird durch Kundenzufriedenheit kompensiert)
– Höhere Transaktionskosten (laufender Austausch/Koordination innerhalb des PO-Teams)
– Potentielles „Highlander“-Entscheidungsproblem – wer hat die finale Entscheidungskompetenz?
– Informationsverlust zwischen ePO und iPO – in beide Richtungen
– Unterschiedliche Interessen / Prioritäten im PO-Team
– Interner Product Owner übernimmt (unbeabsichtigt) die informelle Teamleitung
Fazit
Aus unserer Sicht und den gemachten Erfahrungen im echten Leben, überwiegen die Vorteile einer solchen Organisation deutlich die möglichen Nachteile. Punkto Personalaufwand geben wir zu bedenken, dass es in dieser Konstellation nicht notwendigerweise eine 1:1 Zuordnung von iPO + ePO + Team geben muss! Das PO-Team kann aufgrund der geteilten Kompetenzen durchaus mehrere Produkte / Teams betreuen.
