Wann ist ein Product Owner gut?

Wann ist ein Product Owner eigentlich gut? Diese Frage habe ich bei vielen Gelegenheiten Kollegen und Besuchern von Scrumtischen gestellt. Ich wollte wissen in welcher Art und Weise ein guter Product Owner auf seine Umwelt, die Organisation und ins Team hinein wirkt. Die Perspektive bezieht sich also auf die Wirkung des Product Owners in seiner Rolle. Die gesammelten und leicht aufbereiteten Erkenntnisse möchte ich hier vorstellen, auch wenn keine abschließende Beantwortung möglich scheint. An der ein oder anderen Stelle widersprechen sich die Aussagen auch etwas aber ich möchte hier alles vorstellen, was ich gehört habe.

Die Antworten, die ich erhalten habe, lassen sich aus verschiedenen Perspektiven betrachten. Seine Wirkung lässt sich grob einteilen in die Wirkung in das Team und die Wirkung als Schnittstelle Team/Organisation. Darüber hinaus hat er als Person einige Fähigkeiten und Eigenschaften, die ihn besonders für die Rolle befähigen.

Ein guter Product Owner in Hinblick zum Team

• …hat mit dem Team gemeinsam eine Vision wohin die eigene Arbeit führen soll. Somit gibt es ein Gruppenverständnis über den Zweck und Sinn der eigenen Arbeit.
• …spielt mit dem Team zusammen und positioniert es innerhalb der Organisation. Es gibt keine Machtkämpfe mit dem Team sondern es findet echtes Teamplay statt.
• …schafft ein motiviertes Team, wodurch diese mit mehr Begeisterung an der eigenen Arbeit ihren Teil zur Produktentwicklung beitragen können. Eine mögliche Wirkung ist das begeisterte präsentieren durch Entwickler in öffentlichen Reviews. Gerade hier wird Stolz auf die eigene Arbeit schnell erkennbar.
• …vermittelt den Sinn der kleinen Aufgabe für das große Ziel, denn jede Story soll letztlich in das Produkt einzahlen. Wenn der Sinn nicht verstanden ist, kann von einem Mitarbeiter nicht erwartet werden, dass verantwortungsvoll gearbeitet werden wird.
• …wird als transparent und kommunikativ wahrgenommen, so dass das Team weiß was auf es zukommt und nicht von Themen oder Änderungen „überrumpelt“ wird. Ein Product Owner vermittelt seinem Team eben die Product Roadmap.
• …kann die Anforderungen gut priorisieren und ermöglicht einen geordneten Zustrom an Arbeit.
• …beherrscht sein Handwerkszeug (z.B. Schneiden von Anforderungen) und erleichtert dadurch die Arbeit des Teams.

Ein in die Umwelt agierender, guter Product Owner

• …ist eine gut funktionierende de facto-Schnittstelle des Scrumteams zur Umwelt (z.B. das eigene Unternehmen).
• …wird von der Umwelt als Vertreter gesehen und behandelt.
• …muss die Stakeholder des Produkts „im Griff“ haben und verhindert Durchgriffe sowie Störungen durch Stakeholder. Dabei wird er sicherlich von Scrum Mastern unterstützt, aber im Bezug auf Stakeholder fällt ihm eine besondere Relevanz zu.
• …sollte die Sprache der unterschiedlichen Stakeholder (z.B. Design, Entwicklung, Geschäftsführung, Marketing, etc.) sprechen und als Dolmetscher fungieren können. Dies ist nicht nur notwendig um die auf das Team zukommende Arbeit zu fokussieren, sondern auch damit die Erwartungen der Stakeholder synchronisiert sind.
• …kann die Erwartungen der STakeholder aufeinander abstimmen und ermöglichst so dem Team Produkte zu entwickeln, die die Stakeholder (inkl. Kunden) begeistern.

Ein guter Product Owner als Person

• …strebt mit „fast“ allen Mitteln den Erfolg des Produktes an. Um das zu erreichen ist er flexibel und passt sich den Situationen blitzschnell an um weiterzukommen.
• …hat keine Ausreden und versucht immer eine Lösung zu finden.
• …hat eine sehr gute Menschenkenntniss welcher er für seine Entwickler, Stakeholder, Kunden sehr stark benötigt.
• …hat den Kunden im Focus und bringt diesen zu den Stakeholdern und ins Team.
• …kann sehr gut zuhören und Bedürfnisse erkennen.
• …ist ein Meister in der Kommunikation.
• …treibt das Produkt und auch den ein oder anderen Kollegen mit an.
• …kennt das Unternehmen und die Unternehmensziele sowie den Markt sehr gut.
• …arbeitet zum großen Teil zahlenorientiert und misst und verbessert kontinuierlich.
• …vermittelt die Beherrschung seines Handwerkszeug (z.B. Schneiden von Anforderungen, Verständnis von Scrum, etc.) und ist in der Lage auch eine langfristige agile Planung durchzuführen.

Fazit

Wenn ein Product Owner für sein Produkt „brennt“ und mit Leidenschaft an die Entwicklung geht, ist das schon die halbe Miete. Diese Begeisterung wirkt sich auf die Wahrnehmung durch andere aus.

Es stellt sich aber noch die Frage, inwieweit ein Product Owner neben fachlicher Expertise auch die technische Expertise inne haben sollte und welche Skills dabei wünschenswert wären. Ich habe in den letzten Jahren gegensätzliche Stimmen gehört. Manche sagen, der Product Owner solle rein fachlich wirken, andere sagten, ein technischer Background sei unabdingbar. Persönlich sehe ich einen technischen Background als Vorteil, nicht aber als zwingende Voraussetzung. Ich würde aber behaupten, dass der Product Owner in seinem Themenbereich die Stakeholder fachlich herausfordern und hinterfragen sollte. Heißt, ist es ein technischer Product Owner, muss er zwingend technischen Background haben, ist es ein fachlicher Product Owner für eine App, sollte er von der mobilen Entwicklung einiges an Fachwissen besitzen, und so weiter.

Ein Punkt, den ich abschließend besonders hervorheben möchte: Ein guter Product Owner muss ein Teamplayer innerhalb des Scrum Teams sein. Es wird niemals funktionieren, wenn er nur seine Ideen durchsetzen möchte, das Dev-Team diese aber ablehnt. Er muss schauen, was das Team braucht und sich darauf einstellen, denn ohne das Team wird er nicht das bekommen, was das Produkt braucht. Das gleiche gilt auch für die Zusammenarbeit mit den Stakeholdern.

Abschließend möchte ich mich aufs Herzlichste bei all meinen Gesprächspartnern bedanken! Ich empfand die Gespräche mit euch als wertvoll und bereichernd.