Kann ein Proxy Product Owner bei der Digitalisierung helfen?

Proxy Product Owner Konzept

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.

Agile Projektteams als Beschleunigung für die Digitalisierung

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.

Was sind die Aufgaben eines Product Owners in der Theorie?

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.

Scrum.org – https://www.scrum.org/resources/what-is-a-product-owner

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.

Wie sieht der Arbeitsalltag in der Praxis aus?

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:

  • Abstimmung der Produktvision und Produktroadmap mit gefühlt jeder Abteilung im Unternehmen
  • Erstellung der User Storys inklusive Akzeptanzkriterien
  • Definition vom MVP
  • Stakeholdermanagement
  • Kommunikation der User Storys in Scrum Events
  • Teilnahme an Scrum Events
  • Diskussion mit dem Scrum Team über Implementierungsentscheidungen
  • Erstellung von Schulungsunterlagen
  • Unterstützung beim Produktlaunch
  • 3rd Level Customer Support
  • Durchführung von Kundenbefragungen
  • Abnahme der User Storys
  • Abnahme des Gesamtsystems
  • Bereitstellung von Testprotokollen
  • Dokumentationen
  • Abstimmungen, Abstimmungen, Abstimmungen
  • Releasemanagement
  • und vieles mehr…

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.

Product Owner – das Bottleneck der Digitalisierung?

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.

  • Es gibt zu wenig interne Product Owner und es werden keine neuen eingestellt (u.a. wegen des Fachkräftemangels)
  • Aktuelle Product Owner sind überlastet mit internen Abstimmungen und gelähmt durch interne Strukturen
  • Die Abstimmungen mit dem Entwicklungsteam inklusive Testaufgaben sind zeitraubend
  • Es gibt zu wenig erfahrene Product Owner auf dem Markt
  • Ein völlig neues Unternehmen hat keinen internen Product Owner
  • Ein Product Owner kann meistens nicht mehr als ein Produkt verantworten

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 Proxy Product Owner als Starthilfe für die Digitalisierung

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.

Wie ist die Abgrenzung zwischen Product Owner und Proxy Product Owner

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.

Proxy Product Owner Konzept

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.

Welche Vorteile bietet das Proxy Product Owner Konzept?

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.

Welche Nachteile hat ein Proxy Product Owner?

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.

Zusammenfassung

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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.