Agile Transformation II: Die Product-Owner-Klemme

Mein Lieblingsbeispiel für die Abwesenheit von fachlicher Führung in agilen Umgebungen ist die „Product-Owner-Klemme“: Eine Gruppe oder eine Einheit aus verschiedenen Teams wird von mehreren Stakeholdern belagert, die Umsetzungswünsche an die Mitglieder herantragen. Nehmen wir beispielsweise ein Reporting-Team in der IT, das unternehmensweit Dashboards erstellt: Finance möchte etwas, der Vertrieb wünscht etwas anderes, die IT selbst hat natürlich auch Interessen. Ach ja, und das Marketing würde gerne den Erfolg seiner Maßnahmen besser monitoren können.

Der Product Owner der belagerten Einheit ist nicht in der Lage, eine Entscheidung zu treffen, ohne viele Stakeholder zu enttäuschen. Also steht er vor dem klassischen Dilemma: Was tun, um aus der Klemme zu kommen?

1. Eins nach dem anderen

Mit diesem Ansatz liefert die Einheit am schnellsten. Der Product Owner muss aber dem Druck der anderen Stakeholder gewachsen sein. Dafür braucht es ein entsprechendes Empowerment des Product Owners durch die Organisation und damit auch von oben – das habe ich in der realen Welt jedoch selten erlebt.

2. Alles gleichzeitig

Hier ist die Liefergeschwindigkeit sehr gering. Die Teams wechseln ständig zwischen den Aufgaben hin und her und liefern sowohl durch die Parallelität als auch durch den zeitlichen und qualitativen Verlust durch Context Switching spät – in vielen Fällen zu spät. Der Product Owner muss die Stakeholder ständig vertrösten. Seine Position verliert kontinuierlich an Gewicht und Kraft – von seiner Motivation ganz zu schweigen.

3. Immer für den, der am lautesten schreit

Dieses Modell tritt vermutlich in der Praxis am häufigsten auf. Aber auch hier kommt es zu langsamen Lieferungen und viel Context Switching bei den Teams, was die Unzufriedenheit bei den Stakeholdern steigert. Ebenfalls wahrscheinlich ist eine sehr schlechte Qualität, weil immer etwas „hingefrickelt“ wird, um den aktuell lautesten Stakeholder schnell zum Schweigen zu bringen.

Was passiert hier? Der Konflikt über die Priorität wird an eine Stelle abgegeben, ich schreibe hier explizit nicht „delegiert“, die ihn nicht lösen kann. Es entsteht eine Lose-Lose-Lose-Situation – eine Niederlage für die Organisation (Business Value wird nicht entsprechend geliefert), eine für den Product Owner (Frustration in seiner Rolle) und eine für das Team (Erfolgserlebnisse stellen sich nicht ein). In dieser Situation ist der Product Owner Getriebener statt Treiber des Produktes. Er wird instrumentalisiert für Konflikte, die auf einer höheren Ebene ablaufen.

Und genau in dem Moment, wenn der Stakeholder den Product Owner anruft und Druck ausübt, fällt der Satz: „Wir sind doch jetzt agil.“

Agil Entscheidungen treffen

Doch genau das ist nicht agil. Ein Credo der Agilität ist, dass Entscheidungen an der Stelle in der Organisation getroffen werden, wo das beste Wissen um die Entscheidung besteht. Wenn es also um strategische übergreifende Entscheidungen geht, müssen diese auch auf der strategischen und übergreifenden Ebene getroffen werden. Selbstverständlich mit Informationen aus den darunter liegenden Ebenen – also beispielsweise im Hinblick auf den zu erwartenden Aufwand oder auf Umsetzungsrisiken. Aber die Entscheidung, selbst zu delegieren – besser gesagt, den Konflikt zu verlagern – ist eher ein Anzeichen von zu wenig gelebtem Leadership.

Stakeholder zur Entscheidung bringen

Also was tun? Ein befreundeter Coach hat mir einst erzählt, er würde alle Stakeholder in einen Raum sperren und sie erst raus lassen, wenn sie die Entscheidungen getroffen haben, welche Aufgaben mit welchen Prioritäten umgesetzt werden. Grundsätzlich ein guter Vorschlag, aber nicht wirklich praktikabel. Doch auch die etablierten Frameworks bieten Lösungen an: SAFe mit dem Lean Portfolio Management, Scrum@scale mit dem Executive MetaScrum. Die Methoden der Frameworks sind gut und können auch funktionieren. Es sind jedoch nur Methoden – sie erfordern, dass sie wirklich gelebt werden und für die umsetzenden Teams einen gewissen Grad an Verlässlichkeit bringen. Scrum@scale schweigt sich ein wenig darüber aus, wie es am Ende genau umzusetzen ist. Daher kann ich nur empfehlen, sich die Methoden aus SAFe anzusehen und sich das zu nehmen und zu adaptieren, was in die eigene Organisation passt.

Beispiele für methodisches Vorgehen

In der Praxis kenne ich das System eines Stakeholder-Boards, das für die Priorisierung zuständig ist. Methodisch kann man hier unterschiedlich vorgehen. Zwei Beispiele:

Eine Mischung aus MuSCoW (Must, Should, Could, Would) und WSJF:

Die Anforderungen werden auf Epic-Ebene zusammengetragen, dann wird unterschieden nach Betriebs-, Change- und Pflichtthemen (z. B. aus regulatorischen Gründen). Über die Change-Themen wird transparent auf Basis von Wert, Kosten, Risiko beispielsweise nach WSJF (Weighted Shortest Job First) verhandelt. Die Stakeholder treffen gemeinsam eine Entscheidung hinsichtlich der Umsetzungsreihenfolge mit Beratung durch die Product Owner über einen gewissen Zeitraum.

Investitionspoker:

Die Stakeholder erhalten entsprechend ihrer finanziellen Beteiligung eine gewisse Menge an virtuellem Geld. Dieses Geld setzen sie auf die umzusetzenden Themen. Dabei wird deutlich, welcher Stakeholder wieviel Geld für sein Thema auf den Tisch legen würde. Durch die Transparenz kann gemeinsam zu einer Priorisierung gefunden werden.

Zusätzlich kann der Product Owner mit dem Delegation Poker aus Management 3.0 seinen Entscheidungsspielraum abstimmen. So weiß er, wann er in die Klärung mit den Stakeholdern muss und wann nicht. Vielleicht der wichtigste Punkt ist aber, dass die Stakeholder wirklich in die Verantwortung gehen, Entscheidungen zu treffen. Gleichzeitig ist es auch die größte Challenge, Entscheidungen in einer Hierarchie einzufordern. Hier hilft die Klarstellung: Wenn die Entscheidung von den Stakeholdern nicht getroffen wird, ist der Product Owner berechtigt, die Entscheidung selbst zu treffen.

Er geht dann in die Geschäftsführung ohne Auftrag der Stakeholder, aber im Sinne der Organisation. Es hat sich sehr erfolgreich erwiesen, dies als einen Diskussionspunkt im Delegation Poker einzubauen.

„Ihr seid ja nun selbstorganisiert.“ Wenn euch also dieser Satz begegnet, dann könnt ihr:

• mit euren Stakeholdern einen Delegation Poker machen bezüglich der Fragestellung, was ihr als PO entscheiden dürft und wobei ihr in welcher Weise involviert werden möchtet.
• euch klar darüber werden und kommunizieren, wer die Entscheidung im Sinne des Unternehmens trifft, wenn keine Priorisierung durch die Stakeholder gegeben ist.
• eure Stakeholder auffordern, eine Priorität zu nennen – und wenn ein neues Thema reinkommt, könnt ihr fragen: „An welche Stelle in der Liste schieben wir das nun?“
• ein einfaches Priorisierungsvorgehen etablieren (z. B. WSJF), das nicht nur eure Aufgabe, sondern auch die Diskussion zwischen den Stakeholdern vereinfacht und standardisiert.
• immer, wenn ihr euch in der Klemme fühlt, für Transparenz sorgen und offensiv eine Lösung im offenen Austausch mit allen Beteiligten suchen. Dabei die Konsequenzen transparent machen.

Quelle Titelbild: AdobeStock/ltummy