noteDem Product Owner kommt die Rolle zu, die Anforderungen von Kunden oder internen Fachabteilungen einzuholen. In der Zusammenarbeit mit einem Kunden ist das kein Problem, da es in aller Regel nur eine Partei gibt, deren Wünsche und Anforderungen berücksichtigt werden müssen. Bei einem Inhouse-Projekt wird die Sache wesentlich schwieriger. Der Product Owner steht zwischen Marketing, SEO, Geschäftsleitung, Data Analyse und noch weiteren Personen, deren Feature Requests berücksichtigt werden müssen. Dabei stehen Product Owner oft vor der schwierigen Situation, dass alle Interessenvertreter gleichzeitig Wünsche äußern, die selbstverständlich alle der höchsten Priorität unterliegen.

Wie verhält sich also der Product Owner in diesem Fall?

Ich habe in einigen Unternehmen bereits die Erfahrung gemacht, dass sich Product Owner in diesem Fall zerreißen, allen Beteiligten Zusagen machen und dann mit ihrem Team absprechen, dass man doch die eine oder andere Extraschicht einschiebt, während der Scrum Master zusieht und alles abnickt. Dann kann man sich Scrum auch komplett sparen. In anderen Unternehmen gilt auch der Grundsatz, dass die Geschäftsleitung immer Recht hat. Auch das ist kein tragfähiges Prinzip.

Ich habe die besten Erfahrungen damit gemacht, in solchen Konfliktfällen als Product Owner alle Betiligten an einen Tisch zu setzen und eine konsensfähige Lösung zu erarbeiten. Wichtig sind dabei jedoch zwei Dinge:

Zum einen muss die Geschäftsleitung bereit sein, auch die eigenen Anforderungen hinterfragen zu lassen. Ein selbstherrlicher Chef, der immer Recht hat, wird sich vielleicht auf ein solches Meeting einlassen, dann aber alle Argumente abschmettern, um seinen eigenen Plan durchzusetzen.

Zum zweiten sollte der Product Owner sehr gut vorbereitet in ein solches Meeting gehen und für die kritischen Anforderungen bereits umfangreiche Daten eingeholt haben. Dabei ist natürlich die Mithilfe der betroffenen Fachabteilungen notwendig. Es sollte geklärt sein, welche Risiken mit den einzelnen Anforderungen angesprochen werden, und wie kritisch diese sind. Auch sollte man sich über den Business Value der Massnahmen im Klaren sein.

Beim Treffen der Interessenvertreter ist nun das Moderationsgeschick des Product Owners gefragt. Schließlich muss er zwischen Personen vermitteln und einen konsensfähigen Beschluss erwirken. Alternativ kann dieses Treffen auch vom Scrum Master geleitet werden. Grundsätzlich ist jedoch darauf zu achten, dass diese Gespräche in einem möglichst kleinen Kreis stattfinden und bei möglichst gelöster Atmosphäre. Je besser die Laune der Beteiligten ist, desto kompromissbereiter sind sie in aller Regel. Schließlich versuchen wir in dieser Runde, die Vernunft aller Beteiligten anzusprechen und die für das Unternehmen beste Lösung zu finden, und nicht das Ego des Einzelnen zu befriedigen.

Wichtig ist in diesem Gespräch die Visualisierung der Risiken und Benefits der einzelnen Features. Ich rate jedoch davon ab, aufwändige PowerPoint-Präsentationen zu erstellen. Fassen Sie sich kurz und bleiben Sie in ihren Visualisierungen kompakt. Bewährt haben sich einzelne Flipchart-Blätter, die nebeneinander aufgehängt werden, um den direkten Vergleich zu gewährleisten. Ein Down-to-Earth-Ansatz ist in diesem Fall unbedingt angebracht, auch wenn eventuell die Geschäftsleitung anwesend ist.

Der Product Owner hat in diesem Treffen eine besondere Rolle. Nicht nur, weil er das Meeting leitet und moderiert, sondern weil er die einzige neutrale Person ist. Das sollte er sich stets bewusst machen. Dennoch darf der Product Owner nicht meinungsfrei bleiben. Wenn sich die Beteiligten nicht einigen können, muss er die Entscheidung fällen und vertreten.

twitterrssyoutube
Facebooktwitterredditpinterestlinkedintumblr