Der Begriff Proxy Product Owner (PO) ist ziemlich verbrannt. Fast jeder hat eine schlechte Erfahrung mit dem Proxy PO Konzept gemacht. Die negativen Erfahrungen resultieren meistens auf eine schlechte Abgrenzung zwischen Auftraggeber und Auftragnehmer. Ich glaube trotzdem, dass in gewissen Situationen ein Proxy Product Owner bei der Digitalisierung helfen kann. Daher erläutere ich in diesem Artikel einen sinnvollen Einsatz vom Proxy Product Owner. Zusätzlich stelle ich das Proxy Product Owner Konzept vor inklusive einer genauen Abgrenzung der Aufgabengebiete.
Die agile Welt und damit auch Scrum ist aktuell moderner denn je und immer mehr Unternehmen setzen diese Methodik ein. Wann immer ein Unternehmen ein digitales Produkt entwickeln möchte, ist ein guter Product Owner gefragt. Die Rolle des Product Owners ist ein wesentlicher Bestandteil von Scrum. In der Praxis ist der Product Owner meistens fest angestellt beim Auftraggeber und der Rest vom Scrumteam mit externen Dienstleistern besetzt.
Da ich selbst lange als Product Owner gearbeitet habe, kann ich nur sagen, dass Product Owner einer der besten Jobs der Welt ist. Richtig gelebt, ermöglicht es Menschen, die eigene Kreativität auszuleben und sich voll einzubringen. Aber was macht eigentlich ein Product Owner so den ganzen Tag? Schauen wir uns dazu zunächst die Theorie an:
Scrum Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
Ein Product Owner ist also vor allem dafür da, den Produktnutzen zu maximieren. Um diese Aufgabe zu erfüllen, muss sich ein Product Owner viel mit der Produktvision, Produktstrategie und der Produktroadmap beschäftigen. Zusätzlich wird im offiziellen Scrumguide noch erwähnt, dass der Product Owner vor allem für das Backlog Management verantwortlich ist. Dazu gehören beispielsweise die Priorisierung der Backlogthemen, Kommunikation der Backlogaufgaben und Sicherstellung, dass das Scrum Team das Produktziel und den Backlog versteht.
Im Praxisalltag ist der Product Owner immernoch für den maximalen Produktnutzen verantwortlich. Allerdings beinhaltet das Aufgabengebiet deutlich mehr Themen, als in der Theorie vorgesehen. Daher eine Auflistung an üblichen Aufgaben eines Product Owners in der Praxis:
Natürlich sieht der exakte Arbeitsalltag in jedem Unternehmen anders aus. Allerdings ist zu erkennen, dass der Product Owner in vielen Fällen zusätzliche Tätigkeiten hat. Das wiederum sorgt dafür, dass die Produktqualität leidet oder weniger Produkte entwickelt werden können.
Viele Unternehmen sehen den Bedarf an Digitalisierungsinitiativen und sind sich darüber bewusst, dass viel aufgeholt werden muss. Allerdings brauche ich gerade für die Entwicklung von digitalen Produkten oder auch digitalen Geschäftsmodellen fähige Product Owner. Ohne einen fähigen Product Owner, welche sich wirklich auf die Arbeit konzentrieren kann, wird der Wandel scheitern. Da hilft auch kein zusätzliches Budget, da auch externe Kapazitäten und Kompetenz effizient eingesetzt werden müssen. Zusammenfassend sehe ich die folgenden Gründe, warum der Product Owner das Bottleneck der Digitalisierung ist.
Natürlich ist eine Lösung des Problems mehr Personal. Allerdings müssen dafür erst interne Stellen geschaffen werden, geeignetes Personal gefunden und eingearbeitet werden. Das kostet sehr viel Zeit. Dabei ist Zeit genau das, was viele Unternehmen im Rahmen der Digitalisierung nicht haben.
Der Begriff Proxy Product Owner beschreibt eine Mittelsmannfunktion zwischen dem eigentlichen internen Product Owner und dem Scrum Team. Das Ziel ist es, dass die Aufgaben auf zwei unterschiedliche Rollen aufgeteilt wird. Während der "richtige" Product Owner sich mit Produktvision, Produktstrategie, Roadmap und internen Stakeholdermanagement beschäftigt, steht der Proxy Product Owner dem Scrum Team im Daily Business zur Verfügung. Mit anderen Worten kann der Proxy Product Owner die operativen Tätigkeiten übernehmen. In den meisten Fällen ist der Proxy Product Owner ein erfahrener Product Owner, welche extern beauftragt wird. In der Realität ist das Scrum Team und der Proxy Product Owner vom gleichen Unternehmen.
Für ein besseres Verständnis habe ich eine grafische Visualisierung erarbeitet. Es kann angenommen werden, dass der Product Owner intern beim Auftraggeber beschäftigt ist. Der Proxy Product Owner wiederum ist extern beim gleichen Unternehmen wie das Scrum Team beschäftigt. Mit dem Scrum Team sind vor allem die SW-Entwickler gemeint.
Wie die Darstellung zeigt, ist der Hauptansprechpartner für das Scrum Team der Proxy Product Owner. Die Rolle übersetzt die langfristige Produktvision, Produktstrategie und Roadmap in User Storys, welche vom Entwicklungsteam verstanden werden. Weiterhin beinhaltet das Konzept, dass die Sprintabnahme vom Proxy Product Owner durchgeführt wird. Daraus resultiert, dass die aufwendigen Testtätigkeiten beim Scrum Team und Proxy Product Owner sind. Die fachliche Abnahme erfolgt durch den Product Owner.
Das Konzept zeigt ebenfalls, welche Kompetenzen vor allem ein Proxy Product Owner benötigt. Die Rolle erfordert eine enge Abstimmung mit dem Product Owner, als auch mit dem Scrum Team. Es benötigt sowohl betriebswirtschaftliche als auch technische Kompetenzen. In der Regel sind hier kommunikationsstarke Wirtschaftsinformatiker gefragt, welche die Sprache von beiden Welten beherrschen.
Das Ziel hinter dem ganzen Konzept ist es, den Product Owner von seinen operativen Aufgaben zu entlasten. Damit erreiche ich mehr Kapazität für Produktvision oder Produktstrategie. Durch die Aufteilung der Arbeitsaufgaben kann ich mit der gleichen Anzahl an internen Mitarbeitern es schaffen, mehr Produkte zu entwickeln. Das ermöglicht mir auch temporären Lücken zu schließen und trotzdem die Geschwindigkeit zu halten.
Des Weiteren kann der Proxy Product Owner eine Starthilfe sein. Das gilt insbesondere für junge Unternehmen, welche noch sehr wenig Mitarbeiter haben, aber auch für mittelständische Unternehmen, welche die ersten Schritte Richtung digitale Produktentwicklung gehen. Der Vorteil hier ist, dass nicht nur temporäre Kapazitäten geschaffen werden. Viel mehr kann der Proxy Product Owner das Wissen über agile Softwareentwicklung in die Organisation bringen.
Ein Nachteil, welche sofort ersichtlich wird, ist der zusätzliche Aufwand. Die Rolle des Proxy Product Owners ist üblicherweise eine einzelne Person, welche natürlich bezahlt werden muss. Kritiker des Konzeptes nennen dies einen zusätzlichen "Wasserkopf".
Ein weiterer Nachteil ist, dass wichtige Informationen über die Produktvision und Produktstrategie verloren gehen. Jeder, der schon mal stille Post gespielt hat, kennt das Phänomen. Daher ist es sehr zu empfehlen, einen regelmäßigen Austausch zwischen dem gesamten Scrum Team und dem Product Owner zu ermöglichen. Der Proxy PO vertritt vielleicht nicht mit dem gleichen Hintergrundwissen und der gleichen Leidenschaft das Produkt, wie es der Product Owner tun würde. Daher ist es nicht verwunderlich, dass Proxy PO oftmals auch als technischer Projektleiter bezeichnet wird. Die Rolle ist für die operative Umsetzung verantwortlich und nicht für die Nutzenmaximierung des Produktes.
Im Gegensatz zu anderen Meinungen habe ich keine schlechten Erfahrungen mit einem Proxy PO gemacht. Natürlich ist der Idealzustand, dass es viel mehr interne Product Owner gibt oder die anfallenden Aufgaben anders verteilt werden. Leider sind beide Situationen oft Wunschszenarien und nicht einfach umsetzbar. Daher ist der temporäre Einsatz von einem Proxy PO hilfreich. Das gilt insbesondere für Unternehmen, welche bisher gar keine Erfahrungen mit der Entwicklung von digitalen Produkten gemacht haben. Gerade in solchen Situationen hilft eine erfahrene Person beim Aufbau von Strukturen. Meiner Meinung nach ist das Konzept eine Hilfe für Unternehmen. Allerdings ist das keine langfristige Lösung.
Erzähle uns in einem kostenlosen Erstgespräch mehr über dein individuelles Projekt. Wir helfen dir bei den nächsten Schritten und teilen unser Wissen.
Nachricht schreiben