Product Owner Skalierungsprobleme

Die Skalierung der Rolle des Product Owner (PO) ist eine heikle Angelegenheit. Wenn Sie innerhalb desselben Kontexts zu viel vergrößern, wird es schwerfällig. Wir wollen nicht dasselbe zentralisierte, angstbesetzte und ineffektive Klima der Entscheidungsfindung zurückbringen, das wir von Anfang an abzuschaffen versuchten. Wenn die Menschen so viel Zeit und Mühe aufwenden, um das Unternehmertum wiederzubeleben, wollen sie nicht Schicht um Schicht hierarchischer PO/CPO-Beziehungen schaffen. Wenn also das Risiko eines Rückfalls besteht, warum wollen wir dann überhaupt die PO-Rolle vergrößern?

Hier sind einige Gründe, die mir einfielen, als ich über den Projektkontext nachdachte(*) Der wahrgenommene Bedarf an Skalierung könnte als Reaktion auf den Umfang des vorliegenden Projekts entstehen. Im Rahmen von Projekten ist es durchaus üblich, dass man versucht, so viel wie möglich parallel zu entwickeln, und zwar in verschiedenen, voneinander getrennten Funktionsbereichen des Produkts. Das kommt der Art und Weise, wie ich früher Projekte verwaltet habe, recht nahe. Alles, was in der gleichen Zeitspanne parallel erledigt werden konnte, sollte es auch. Damals war ich sehr effizienzorientiert, aber ich wurde auch gelehrt und dazu angeregt, so zu denken. In diesem Paradigma wäre es wünschenswert, dass der PO eine Art Gruppe um sich herum hat, die ihm bei der Erstellung der User Stories hilft, für die er verantwortlich ist. Die Bildung großer Teams gibt uns mehr Kapazität, um mehr Arbeit in unserem Zeitfenster zu erledigen. Größere Teams und mehr Arbeit führen zu einem höheren Koordinationsbedarf, da die Kontrollspanne begrenzt ist. Ich glaube auch, dass wir immer noch sehr stark von dem Paradigma der Befehlskette geprägt sind. Es ist einfach bequem, wenn es jemanden gibt, der die schwierigen Entscheidungen für uns trifft und zwischen uns vermittelt, wenn es zu Interessenkonflikten kommt. Der Bedarf an zusätzlicher Koordination zwischen und über die PO's im gleichen Kontext passt daher ganz natürlich zu unseren Bedürfnissen in einem wachsenden Projektkontext. Wenn ich so darüber nachdenke, ist es vielleicht kein Zufall, dass die Person, die zum CPO ernannt wird, meistens der erste PO ist, der an dem Projekt beteiligt war. Wenn wir tief in uns gehen, würde dann nicht jeder PO wollen, dass seine ersten Projektschritte so erfolgreich sind, dass er die zusätzlichen Mittel erhält, um das Team zu vergrößern und folglich als CPO aufzusteigen? Und sollten wir dieser CPO sein, würden wir dann jemals einem anderen Kollegen die Arbeit anvertrauen, die wir sorgfältig vorbereitet und mit viel Schweiß und Tränen vergossen haben? Es wäre toll, wenn wir die anderen irgendwie überwachen könnten. So könnten wir sicherstellen, dass der Erfolg des Projekts und unsere harte Arbeit nicht im nächsten oder übernächsten Sprint zunichte gemacht werden. Die Skalierung mit einer CPO-Konstruktion würde uns die Möglichkeit geben, diese Bedürfnisse zu erfüllen. Natürlich können die oben genannten Gründe für eine Skalierung stichhaltig sein, aber sie haben auch ihre Schattenseiten. Auch wenn die parallele Arbeit effizient sein mag, zeigt die Validierung mit Ihren Kunden vielleicht, dass das Produktinkrement nicht die Bedürfnisse erfüllt, die Sie sich ursprünglich ausgedacht hatten. Da Sie viel parallel gearbeitet haben, ist auch das Risiko der Verschwendung größer. Sollten Sie Ihr Produkt radikal in eine andere Richtung lenken müssen, wird dies aufgrund des bereits großen Umfangs Ihres Unternehmens sehr viel schwieriger sein.Ich denke daher, dass eine Skalierung in Richtung der Arbeit verschiedener Teams am gleichen Backlog uns möglicherweise daran hindert, den validierten Geschäftswert zu maximieren, da Sie weniger wichtige Funktionen aus dem Backlog vorziehen, bevor Sie tatsächlich validiert haben und somit wissen, ob Sie mit Ihren Top-Produkten tatsächlich einen Wert geschaffen haben. Unter diesem Gesichtspunkt wäre es klug, nicht zu skalieren. Wenn wir aus dem Erfolg heraus skalieren, besteht die Gefahr, dass wir in einen Machtspielchen-Modus abrutschen und ein Team unter uns gründen, um Status und Kontrolle zu gewinnen, anstatt uns seitwärts zu verzweigen. Wenn das passiert, arbeiten wir nicht mehr auf eine gemeinsame Unternehmensbeteiligung hin, sondern wir versuchen, unsere eigenen Elfenbeintürme zu bauen. Wenn der CPO, der die PO's führt, in bestimmten Bereichen die Entscheidungsgewalt beansprucht, würden Sie meiner Meinung nach nicht das richtige unternehmerische Umfeld schaffen, in dem Entscheidungen auf Argumenten und dem Wert für den Kunden und das Unternehmen basieren. Wenn Sie als PO bereits wissen, dass Sie eine Entscheidung vom CPO brauchen, neigen Sie vielleicht dazu, andere Beeinflussungsmethoden als vergleichbare und weniger subjektive Maßnahmen wie z.B. Business Cases zu verwenden, was die Qualität der Entscheidungsfindung und damit den Erfolg des Produkts gefährdet.

Während meines Studiums wurde mir beigebracht: "Es gibt nicht den einen besten Weg zu organisieren". Ich halte diesen Satz für eine universelle Wahrheit, die meiner Meinung nach auch für die Skalierung der PO-Rolle gilt. Ich denke daher, dass die Form weniger wichtig ist als der Weg, der Sie dorthin führt. Zu wissen, dass die Skalierung mit Risiken verbunden ist, und bewusst damit umzugehen, hilft Ihnen auf diesem Weg, eine Form zu finden, die für Sie funktioniert. (*) Skalierung ist auch im Zusammenhang mit Produktlinien üblich (z.B. wenn ein CPO eine Gruppe von POs leitet, die eine Produktfamilie verwalten) oder innerhalb von Geschäftsbereichen, in denen Sie verschiedene strategische Themen haben, die der CPO im gleichen Zeitraum umsetzen möchte.