Der Product Owner als Scrum Master – Genie oder Wahnsinn?

Der Scrum Master in einem Entwicklungsteam wird auch gerne mit dem englischen Begriff “Servant Leader” übersetzt. Er besitzt Funktionen, die den Erfolg des Projektes entscheidend mitbestimmen.
Er hilft dabei,

• Hindernisse zu beseitigen
• das Team vor Störungen zu bewahren
• die verschiedenen Scrum-Meetings zu moderieren und zu planen
• dass die Werte und Prinzipien von Scrum gelebt werden können
• das Team durch Coaching und Führung zu einer selbstorganisierenden Einheit zu bilden
• das Backlog zusammen mit dem Product Owner zu pflegen

Aber was, wenn er diese Funktionen nicht erfüllt? Weil er zum Beispiel lieber selbst entwickelt als sich um solche Aufgaben zu kümmern oder er gar nicht Scrum Master sein möchte, diese Rolle aber für die organisationsinterne Weiterentwicklung benötigt? Ist dadurch das Projekt sofort zum Scheitern verurteilt oder können andere Rollen die Aufgaben eines Scrum Masters übernehmen?

Ein erfahrenes Scrum Team sollte dieses Problem in der Regel selbst lösen und den Scrum Master teamintern neu besetzen. Diese “Bottom-Up” Lösung wäre sicherlich der beste Weg für alle, die Realität sieht jedoch oft anders aus. Hier sind “Top-Down” Entscheidungen und gewachsene Strukturen an der Tagesordnung. Dies ist oft der Tatsache geschuldet, dass der Scrum Master und seine Funktion gar nicht oder unzureichend in der Organisation ernst genommen werden. Hinzu kommt, dass vorgesetzte Teamleiter im Zugzwang sind und schnell die Rolle neu besetzen müssen, um Kopfzahlen zu halten oder um einzelne Mitarbeiter zu “pushen”.

Sind andere in der Lage, die Rolle als Scrum Master zu “übernehmen”?

Schauen wir in den Scrum Guide, findet sich neben dem Scrum Entwicklungsteam auch noch der Product Owner (PO) als mögliche Option. Ist er wirklich eine Option?
Streng nach Scrum Guide sollten Product Owner und Scrum Master als Rollen von unterschiedlichen Personen wahrgenommen werden, da beide verschiedene Interessen verfolgen.

Der Scrum Master versucht durch sein Wirken, das Team bei der Entwicklung bestmöglich zu unterstützen. Der Product Owner hingegen ist verantwortlich für den wirtschaftlichen Erfolg des Produktes und er hat das Ziel, den Nutzen für den Kunden zu maximieren.
Bei genauerem Hinschauen sollte auch der Product Owner dafür arbeiten, das Agile Mindset weiterzutragen. Zwar auf Produkt-Level, aber warum nicht auch beim Entwicklungsteam?

Die Vorteile

Der sehr enge Kontakt zum Team sollte hier als erstes genannt werden. Auch wenn der Produkt Owner keinen Hintergrund als Entwickler hat, lernt er schnell wie das Team “tickt”. Gleichfalls lernt auch das Team den Product Owner besser kennen. Durch das bessere Verständnis kann das Team letztendlich effizienter entwickeln und die vielen Nachfragen entfallen.

Auch kann der Product Owner Ideen, die aus dem Team kommen, besser aufnehmen und verwerten. Oftmals haben die Entwickler eine bessere Vorstellung, wie sich ein Feature in der Praxis einsetzen lässt, und liefern somit wertvolle Hinweise, die der Product Owner ins Produkt zurückfließen lassen kann.
Oft wird der Scrum Master auch teamintern besetzt, das bedeutet allerdings auch, dass Ressourcen für die Entwicklung von Features gebunden werden. Auch dies würde ich in dieser Konstellation als Vorteil werten.

Die Nachteile

Nicht zu verachten ist natürlich der entstehende Mehraufwand. Ein “Servant Leader” braucht für seine Arbeit auch Zeit. Meetings müssen vorbereitet und moderiert werden. Für die Retrospektive empfiehlt es sich dennoch, einen externen Scrum Master zu organisieren. Hier hat der PO in der Regel keine Erfahrungswerte und ist meist Inhalt der Diskussion. Dasselbe gilt für das Sprint-Review Meeting. Hier kann und sollte eines der Teammitglieder die Moderation übernehmen. Andernfalls fällt es dem PO schwer, die Wünsche und Anregungen der Stakeholder festzuhalten oder zu diskutieren.

Oftmals ist der PO bereits ausgelastet mit seiner Arbeit. Hier sollte dann die Vernunft siegen und der fehlende Scrum Master nicht ersetzt werden, sondern das Thema eskaliert und somit in verantwortungsvolle Hände gelegt werden.

Der PO könnte auch dazu neigen, den Schutz, den das Team im Sprint genießt, aufzuweichen und doch noch grundlegende Änderungen von Features zu fordern. Gleiches gilt für die Stakeholder.
Ohne dedizierten Scrum Master fehlt dem Team eine Instanz, die sich um die vielen kleinen Störungen kümmert, die im Projektalltag lauern und das strukturierte und störungsfreie Arbeiten oft unmöglich machen.

Fazit

Auch wenn der Scrum Guide etwas anderes sagt, die Rolle des Product Owners ist durchaus auch als Interims Scrum Master geeignet. Bevor das Entwicklungsteam weitere Kapazitäten in Form von Mannstunden verliert, indem sich ein Teammitglied der Rolle des Scrum Masters annimmt, kann auch der PO diese Rolle ausfüllen. Vorausgesetzt er schafft es, den Interessenkonflikt aufzulösen, der normalerweise zwischen ihm und dem Entwicklungsteam herrscht.

Auf Dauer sollte diese Konstellation aber keine Lösung sein. Ein Scrum Master, der seine Aufgabe ernst nimmt, bietet nicht nur dem Team wertvolle Hilfe, er ist es auch der, der normalerweise dem Product Owner Paroli bieten sollte. Dieser gesunde Konflikt ist nicht zu verachten und sollte schnellstmöglich wiederhergestellt werden.