In Scrum gibt es nur sehr wenige Rollen, in der ursprünglichen Fassung nur drei: das Team, den Product Owner und den ScrumMaster. Wenn wir in unseren Trainings die Rollen erklären, sind viele Teilnehmer eher verwirrt, wenn wir über die Wichtigkeit der einzelnen Rollen sprechen:

• das Team ist zuständig für die Erfüllung der Kundenwünsche
• der Product Owner betreut die Wünsche an das Produkt aus Kundensicht
• der ScrumMaster ist zuständig für die Überwachung der agilen Prozesseinhaltung und soll dem Team optimale Arbeitsbedingungen verschaffen

Diese zugegebenermaßen sehr vereinfachte Darstellung suggeriert, dass natürlich das Team der Star in diesem Dreigestirn ist. Nicht nur organisiert es sich selbst und darf über das technische und das Arbeitsdesign selbst entscheiden, es hat auch noch einen Full-Time-Helfer (den ScrumMaster), der scheinbar den ganzen lieben langen Tag nichts anderes zu tun hat als dem Team sämtliche Steine aus dem Weg zu räumen. Welch paradiesischer Zustand!

Wenn man zusätzlich noch unsere Klientel berücksichtigt, die hauptsächlich aus dem Konzernumfeld stammt, verwundert es nicht, dass die Rolle des Product Owner maßlos unterschätzt wird. Schließlich ticken große Unternehmen eher so, dass Konzepter (oft genug auch noch externe) mehrhundertseitige Pamphlete schreiben, die dann einem Dienstleister zur Implementierung über den Zaun geworfen werden, um sich dann erst wieder bei einem Meilenstein oder einer Zwischenlieferung mit dem Ergebnis zu befassen.

Sehr überrascht sind unsere Trainingsteilnehmer dann das erste Mal, wenn der Product Owner in unseren Trainings mit einer Krone dargestellt ist. Warum Krone?

• Der Product Owner entscheidet quasi als Alleinherrscher über den fachlichen Funktionsumfang des Produkts. Zugegebenermaßen mit einem Beraterstab, aber am Ende liegt die alleinige Entscheidung beim PO.
• Er entscheidet nicht nur am Anfang, sondern täglich! Die ständige Pflege der Anforderungen, das sogenannte „Backlog-Grooming“, erfordert ständiges Umpriorisieren und Verfeinern; Klarheit muss geschafft und Fragen des Teams müssen beantwortet werden.
• Am Ende eines Sprints entscheidet der Product Owner über die Abnahme der einzelnen Features. Wer sieht da nicht Nero im Circus Maximus mit seinem schicksalsbringenden Daumen vor dem geistigen Auge? ;-)
• Gerade bei Aufwandsprojekten hat der Product Owner die Entscheidung darüber, ob noch ein weiterer Sprint lohnenswert ist oder nicht. Übersteigt nämlich der finanzielle Aufwand eines Sprints den errechneten Business Value, sollte man das Projekt beenden.

All dies führt dazu, dass der Product Owner aus meiner Sicht der größte einzelne Erfolgs- oder Misserfolgsfaktor eines Projekts ist. Ist die Zusammenarbeit zwischen dem Team und dem Product Owner nicht optimal, weiß das Team nicht genau, was es tun soll und baut möglicherweise das Falsche. Hochperformante agile Teams sind inzwischen so schnell, dass sie von einem unsicheren oder entscheidungsunfreudigen Product Owner regelrecht ausgebremst werden.

Einzelne Entwickler im Team mit nicht optimaler Leistung können vom Gesamtteam aufgefangen werden, ein schwacher ScrumMaster fällt umso weniger auf, je selbstorganisierter und erwachsener das Team ist. Aber ein Product Owner, der seinen Job nur halbherzig macht, ist ein enormes Projektrisiko.

Darum, liebe Kunden, wenn Ihr ein agiles Projekt anfangt, nehmt zum Product Owner nicht irgendjemanden, der gerade frei ist, sondern nehmt den Besten, den Ihr finden könnt. Der Projekterfolg wird es euch danken.

Lang lebe der Product Owner!