Product Owner: König ohne Land
Der Product Owner (PO) ist die wohl missverständlichste Rolle in der agilen Welt. Je nachdem, wen man fragt, ist der PO mehr oder weniger stark autonom, verantwortlich oder führend. Ich glaube ja: Die meisten POs sind faktisch keine. Aber wieso?
Das ehrwürdige Cambridge Dictionary beschreibt to own something als “to have something that legally belongs to you”. Merriam-Webster fügt hinzu: “To have or hold as property” (Besitz) und “to have power or mastery over” (Einfluss). Ein Product Owner sollte im Wortsinn also Einfluss auf ein Product ausüben können, es besitzen.
Scrum beschreibt mit dieser Rolle einen Menschen, der/die das Produktziel entwickelt und kommuniziert, über die Richtung der Weiterentwicklung entscheidet und ganz allgemein dafür verantwortlich ist, den maximalen Nutzen des Produktes für die Anwender herzustellen. Das macht der PO, indem er (steuernd) die Ressourcen seines Teams einsetzt: Arbeitskraft und Zeit, Geld, Ideen…
Jetzt könnte man annehmen, dass ein erfolgreicher PO also möglichst viele Kundenwünsche einsammeln und mit seinem Team umsetzen sollte - fertig ist das nützliche Produkt. Leider ist das nicht so: Was der eine sich dringend wünscht, hält den anderen auf. Wünsche an das Produkt sind nicht selten widersprüchlich. Damit der PO die Vision vertreten und den Nutzen für alle maximieren kann, muss er zwangsläufig “Nein” sagen: Meistens sogar. Sven Sester von 42he in Köln (nebenbei: Bestes CRM, unbedingt anschauen!) beschreibt das unter “Der Kunde ist König - doch ohne Berater ahnungslos” so:
Meistens sage ich Nein. Nein, wenn ein Kunde fragt, ob wir eine bestimmte Funktion in unsere Software einbauen können. Wir nennen das “Produktentwicklung mit Haltung” - oder: “Opinionated Software”. […] Das Finden der Lösung auf den Kunden abzuwälzen, funktioniert eben nicht. Der ist schließlich König und kein Diener.
Nochmal: Man dient dem Kunden im Zweifel nicht dadurch am besten, dass man stets genau das tut, was der Kunde sagt. Kunden suchen eine Lösung, aber beschreiben einen Weg. Beides gehört nicht zwangsläufig zusammen.
Product Owner bedeutet Vertrauen
In kleinen Organisationsformen (Startups, Mittelstand) ist es durchaus nicht so selten, echte Product Owner zu finden: Menschen, denen die Verantwortung für ein Produkt, einen Service komplett übertragen ist, schon weil sich sonst niemand darum kümmern kann. Was man diesen Menschen bereitstellt, ist nicht zuletzt Geld - wenn man sich persönlich kennt, ist Vertrauen leichter herzustellen. Mit dem Geld kommt Entscheidungsfreiheit, die in solchen kleinen Organisationen auch selten an Regeln, Compliance und Prozesse stößt.
In großen Organisationen ist das anders: Der Kunde des Projekts ist nicht selten selbst Stellvertreter des wirklichen Kunden, in Form einer Fachabteilung. Geld kommt via Zentralbudget, dessen Verteilung Gegenstand von Grabenkämpfen im Projekt-Board ist. Da man im Controlling die Idee liebt, Geld zweckgebunden zu verwalten, schreibt man es der Fachabteilung zu - das Projekt und der PO befinden sich nicht selten in der IT. Verantwortung ist zwar delegiert, gerne wird aber immer noch von oben herein regiert: Wenn der Fachbereich nicht bekommt, was man sich wünscht, dann geht man halt zum Vorstand. Der zur Geschäftsführung, die zum Bereichsleiter. Und bis die Weisung dann beim PO ankommt, ist sie so derart aufgeladen mit “kinetischer Energie”, dass Widerstand unmöglich wird.
Nur: Ein PO, der nicht mehr Nein sagen kann, kann seiner ursprünglichen Rolle nicht mehr gerecht werden. Er oder sie ist dann nur noch Verwalter von Gottes Gnaden. Agilität fußt aber auf zwei wichtigen Säulen: Die Transparenz, den Erfolg einer Maßnahme jederzeit ehrlich zu bestimmen, und die Freiheit, den Kurs anzupassen, wenn andere Maßnahmen mehr Erfolg versprechen. Empirik, inspect and adapt.
Agilität funktioniert also nur mit echten Product Ownern.