Product Owner

Überforderte Product Owner

Eine der wesentlichen Tugenden des agilen Vorgehens ist die Nachhaltigkeit. Alle Teammitglieder sollen auf eine Art und Weise arbeiten in der sie das Tempo prinzipiell beliebig lange durchhalten können. Das unterscheidet das agile Vorgehen sehr wesentlich von den meisten anderen Vorgehensweisen.

Doch die Erfahrung zeigt, besonders dass eine Person oftmals an der Belastungsgrenze arbeitet wenn sie ihre Aufgabe ernst nimmt – der PO. Hier wurde im Scrum-Framework eine Rolle geschaffen, die sehr viele wichtige und komplexe Aufgaben auf sich vereint.

Aus meiner Sicht hat ein Product Owner (mindestens) folgende Aufgaben:

  • Er (oder sie) hat jederzeit eine klare Vision des Produktes und seines Einsatzzwecks.
  • Das Backlog ist gepflegt. Das heißt insbesondere:
    • Es existiert eine klare Priorisierung der Stories (bzw. Epics)
    • Stories für den nächsten Sprint sind so weit ausdetailliert wie das Team es für den Beginn der Arbeiten benötigt
    • Stories für die zwei folgenden Sprints sind in wesentlichen Zügen durchdacht
  • Die Stories im Backlog werden regelmäßig mit dem Team durchgesprochen und ihr Aufwand geschätzt
  • Das Management ist über den aktuellen Stand der Entwicklung und die Pläne für die Zukunft informiert
  • Die Anforderungen aller Stakeholder für das Produkt sind in das Backlog eingeflossen
  • Bei Rückfragen des Teams zu inhaltlichen Details der Stories steht der Product Owner jederzeit zur Verfügung

Wie an dieser Aufzählung schon deutlich wird, ist der Product Owner kaum zu beneiden. Alle diese Aufgaben sind wichtig damit das Team (oder, noch schlimmer, mehrere Teams) effizient arbeiten können. In dieser Rolle laufen alle Fäden zusammen.

Kann eine einzelne Person diese Erwartungen überhaupt erfüllen? Kaum. Auf jeden Fall aber gebührt diese Rolle dem besten Mitarbeiter oder der besten Mitarbeiterin. Es ist keine Rolle die jemand Unerfahrenes ausfüllen kann.

Doch die Erfahrung zeigt, dass genau das viel zu oft passiert, und die Rolle des PO mit der bekannten Rolle des PMO (Project Management Office) verwechselt wird. Immerhin hat PMO ja sogar noch einen Buchstaben mehr als PO. Die Stories werden also mehr verwaltet als gestaltet, bei Rückfragen des Teams muss erst Rücksprache mit Anforderern gehalten werden, und richtungsweisende Entscheidungen bezüglich der Produktfeatures werden über Lenkungskreise ausdiskutiert. Am Ende zeigt sich dann, dass Scrum nicht funktioniert – was so mancher ja schon immer geahnt hat.

Daher ist es wichtig, die Rolle des PO zu verstehen, und den besten Mitarbeiter/die beste Mitarbeiterin mit dieser Rolle zu betrauen. Dann sind vielleicht auch das Vertrauen und die Aufmerksamkeit des Managements sicher gestellt.

Wenn man etwas zusagt …

Ein wesentlicher Begriff im Scrum ist der des Commitment, also einer Verpflichtungserklärung. Hiermit verpflichtet sich das Team, die zu Beginn eines Entwicklungszyklus – des Sprints – angenommenen Tätigkeiten auch tatsächlich bis zum Ende des Zyklus vollständig und in der zugesagten Qualität abzuschließen. Doch in welcher Form und mit welchen Konsequenzen kann und soll eine solche Verpflichtungserklärung abgegeben werden?

Und warum ist es überhaupt wichtig ein Commitment abzugeben? Kann man nicht einfach dem Artikel 2 des Rheinischen Grundgesetzes folgen: “Et kütt wie et kütt”?

Nein!

Letztendlich wird mit Beginn eines Sprint ein Pakt zwischen dem PO und dem Team geschlossen: Der PO verspricht dem Team den Umfang und die Priorität der Anforderungen für die Zeit des Sprint fix zu halten (und dies auch gegenüber dem Management zu vertreten), dafür bekommt er von dem Team die Zusage, dass die geplanten Inhalte auch tatsächlich geliefert werden. Nur wenn beide Seiten dieses Paktes eingehalten werden, dann können sich die die Beteiligten auf ihre Aufgaben konzentrieren. Hält der PO das Versprechen nicht und ändert die Anforderungen während des Sprint, dann wird das Team nur Stückwerk geringer Qualität abliefern können. Hält das Team das Versprechen nicht, dann verliert der PO das Vertrauen in die Planbarkeit des Verfahrens und wird zunehmend ins Mikromanagement verfallen.

Aus diesem Grund ist ein Commitment zu Beginn eines Sprints sehr wichtig, und sollte vom Team entsprechend ernst genommen werden. Das Team sollte ein Commitment nur dann abgeben wenn es sich sicher ist, dass die Realisierung der Anforderungen in der gegebenen Zeit auch realistisch ist. Gleichzeitig sollte das Team aber vom Wunsch getrieben werden möglichst viel umzusetzen (“viel Feature, viel Ehr’”) – im Zweifel wird ein guter PO aber auch versuchen das Mögliche aus dem Team herauszukitzeln.

Weil das Vertrauensverhältnis zwischen Team und PO so wichtig ist, halte ich die vor einiger Zeit im Scrum Guide von Ken Schwaber und Jeff Sutherland vorgenommene Anpassung des Begriffs Commitment in den sehr viel relativeren Begriff Forecast für kritisch. Ein unverbindliches “na ja, wir werden mal sehen was sich so machen lässt” führt zur Erosion des Willens im Team, das gesteckte Ziel auch wirklich zu erreichen. Das klassische Commitment macht die Entscheidung des Teams, die Herausforderungen des vor ihm liegenden Sprints anzunehmen, zu einer bewussten Willenserklärung.

Aber ist ein Commitment nicht genau so wenig oder viel Wert wie ein Forecast, da die Konsequenzen einer “Verfehlung” die gleichen sind? Und was sind überhaupt die Konsequenzen.

In einem idealen Team ist die wesentliche Konsequenz tatsächlich die Enttäuschung des PO und des Teams selbst über das nicht erreichte Ziel. Insbesondere sollte dem Team klar sein, dass es den PO in eine unangenehme Situation gebracht hat. Dieser muss nämlich dem Management eine Verschiebung des betroffenen Features mitteilen. Und auf lange Sicht ist die tragische Konsequenz der geschilderte Vertrauensverlust zwischen Team und PO sowie der daraus folgende Herauswurf aus dem Paradies der ungestörten Entwicklung.

Wenn das Team aber kein ideales Team ist? Nun, dann ist es die Aufgabe des ScrumMaster, mittel- bis langfristig aus dem Team ein ideales zu formen, das Stolz auf die eigene Leistungsfähigkeit ist und ein starkes Ehrgefühl entwickelt.

Gefährlich ist es allerdings, das Commitment in eine Metrik zu wandeln (“wir zählen, wie oft das Commitment nicht eingehalten wurde”) und im Extremfall disziplinarische Konsequenzen zu fordern. Das Team wird in diesem Fall schnell dazu übergehen die Gründe für das Versagen nicht bei sich selbst, sondern in den – ohne Frage immer vorhandenen – externen Einflussfaktoren zu suchen, möglichst wenig in einem Sprint zuzusagen, und darüber hinaus bei der Qualität zu schummeln um die gesetzten Ziele zu erreichen.

Und damit ist letztendlich niemandem gedient.

Nach oben