Laut Scrum-Theorie soll der Product Owner Visionär für das von ihm verantwortete Produkt sein. Er entscheidet über die Eigenschaften und damit über den Erfolg des Produkts. Die Realität sieht oft noch anders aus. Der Product Owner bekommt die Vision einschließlich eines groben Produktkonzepts vorgegeben und kann sich nur noch innerhalb eines eng abgestecken Rahmens bewegen. In solchen Fällen ist der Product Owner eher ein Business Analyst, dessen Verantwortung sich auf die Formulierung von User Stories beschränkt. Dieses Phänomen wird häufig als Proxy-Product Owner bezeichnet.

Aber verharmlost dieser Begriff nicht das eigentliche Problem? Es klingt doch so, als könne man durch Magie dem Product Owner die Verantwortung für das Produkt übertragen und dann ist alles gut. Ich habe den Eindruck, dass die Ursache für ein solches Problem häufig tiefer liegt, nämlich darin, dass die Produktentwicklung nur teilweise agil erfolgt. Oft vergeht viel Zeit von der Entstehung einer Produktidee bis zum Beginn der Softwareentwicklung, wobei Scrum als Vorgehensmodell erst dann ins Spiel kommt, wenn die Softwareentwicklung startet. Und so wird auch erst dann ein Product Owner benannt, für den dann nur noch die Detail-Konzeption und die Begleitung der Softwareentwicklung bleiben.

Dieses Vorgehen hat Auswirkungen auf das entwickelte Produkt. Ein wesentliches Prinzip agilen Vorgehens basiert darauf frühzeitig Feedback vom Markt einzuholen und in das Produkt einfließen zu lassen, um so das optimale Produkt zu schaffen. Ein Proxy-Product Owner hat oft gar keinen Kontakt zum Markt und kann gar kein Gespür dafür bekommen, wie das Produkt optimiert werden kann. Er erhält das Feedback gefiltert durch die ihm vorgesetzte Stelle im Unternehmen. Aber nicht nur das Markt-Feedback ist entscheidend. Typischerweise entstehen viele Ideen in der Interaktion zwischen Product Owner und Team. Weil aber der Product Owner weder Ideengeber noch Treiber der Produktidee ist und nicht frei über das Produkt entscheiden kann, muss er diese Ideen umständlich mit der ihm vorgesetzten Stelle abstimmen. Alles in allem ist ein Proxy-Product Owner in seiner Kreativität deutlich eingeschränkt, mit den entsprechenden Auswirkungen auf seine Motivation und das entwickelte Produkt.

Möglicherweise ist die Ursache dafür darin zu suchen, dass das agile Vorgehen aus der Softwareentwicklung heraus entstanden ist und andere an der Produktentwicklung beteiligte Bereiche, also etwa das Produktmanagement, weiterhin wasserfallartig aufgestellt sind. Mary Poppendieck stellt in ihrem Vortrag über “Design Thinking” sogar die These auf, dass mit Scrum der “falsche” Teil der Produktentwicklung optimiert wurde. Es hilft aus ihrer Sicht nicht, wenn die Software iterativ entwickelt und kontinuierlich ausgeliefert werden kann, wenn der Prozess von der Idee bis zum Beginn der Softwareentwicklung nicht agil ist.

Um die genannten Probleme zu lösen, muss das agile Vorgehen die IT-Abteilung verlassen und in der gesamten Organisation etabliert werden. Nur so kann Produktentwicklung auch über Bereichsgrenzen hinweg iterativ-inkrementell erfolgen. Ein echter Product Owner, der für das Produkt und seinen Erfolg verantwortlich ist, hat dann die Aufgabe Entwicklung der Produktidee, Softwareentwicklung, Marketingaktivitäten, etc. im Gleichschritt miteinander zu koordinieren. Nur so kann es gelingen ein “minimum viable product” zu entwickeln, frühes Feedback einzuholen und dieses in das zu entwickelnde Produkt zu integrieren.

Ich halte die Rolle des Product Owners für den Schlüssel zum Erfolg bei der agilen Produktentwicklung und wünsche mir, dass diese Rolle viel stärker in den Fokus gerückt wird.