Die Schlüsselrolle im Scrum-Team

Was einen guten Product Owner ausmacht

Scrum ist aus dem Alltag einer agilen Software-Entwicklung nicht mehr wegzudenken. Das Projekt-Management-Framework von Ken Schwaber und Jeff Sutherland wird mittlerweile millionenfach eingesetzt und ist auch bei expeso erste Wahl. Ein besonderer Vorteil von Scrum ist die klare Rollenverteilung im Entwicklungsteam.

Die Erfahrungen zahlreicher Scrum-Entwicklungsprojekte bei expeso zeigen, welche große Verantwortung der Product Owner für das Gelingen der Entwicklung trägt. Er ist die Person, die die Entwicklungsziele und -schritte über das Product Backlog maßgeblich beeinflusst. Sein Ziel ist es, bei der Entwicklung den Kundennutzen zu maximieren. Sein Einsatz, seine Erfahrung und sein Geschick wirken sich daher besonders stark auf den Projekterfolg aus. https://www.scrumguides.org/

Die einzelnen Scrum-Rollen

Ein Scrum-Team besteht neben dem Product Owner aus den Entwicklern und einem Scrum-Master:

Entwickler-Team

Das Entwickler-Team sollte interdisziplinär aus Profis besetzt sein. Es gibt keine Hierarchie und keine Titel im Team. Es organisiert sich selbst und entscheidet auch selbst, welche Aufgaben es innerhalb eines Sprints erledigen kann.

Scrum Master

Der Scrum Master ist dafür verantwortlich, Scrum entsprechend des Scrum Guides zu fördern und zu unterstützen. Scrum Master tun dies, indem sie allen Beteiligten helfen, die Scrum-Theorie, Praktiken, Regeln und Werte zu verstehen und sie zu beraten.

Product Owner

Der Product Owner ist für die optimal auf das Kundenbedürfnis ausgerichtete Produkt-Entwicklung verantwortlich. Er ist die Person, die das Product Backlog managt, priorisiert, und dafür sorgt, dass die Einträge im Product Backlog klar und verständlich formuliert sind.

Damit der Product Owner erfolgreich sein kann, müssen alle im Unternehmen seine Entscheidungen respektieren und davon absehen, an ihm vorbei Aufträge ins Entwickler-Team zu geben. 

6 Tipps für erfolgreiche Product Owner

Aus unserer Praxis wissen wir, dass es einige Knackpunkte gibt, die sich entscheidend auf die Software-Entwicklung auswirken können. Auf sie sollte man besonders achten:

1. Klare Kundenorientierung und Nutzenmaximierung

Was will der Kunde wirklich? Was sind seine Motive für das aktuelle Entwicklungsprojekt? Für den Product Owner ist es besonders wichtig, zu verstehen, was das neue Produkt beim Kunden verändern und besser machen soll. Nicht die eigene Vorstellung, was ein gelungenes Produkt sein sollte, sondern die Wünsche des Kunden und der Anwender, die damit arbeiten, müssen im Vordergrund stehen. Hierbei helfen das Feedback und die User-Akzeptanz, die er nach jedem Sprint abfragen sollte.

Der Product Owner sollte alle „Nice-to-Have“-Features ausblenden und den Nutzen für den Kunden maximieren. Wir wissen, dass das nicht leichtfällt, aber es ist besonders wichtig, sich auf den Kundennutzen zu fokussieren, um sich nicht zu verzetteln und an den Bedürfnissen vorbei zu entwickeln. Dafür ist eine intensive Kommunikation mit dem Kunden und den zukünftigen Anwendern wichtig.

2. Verständliche, transparente User Stories schreiben

Die User Stories im Backlog müssen klar und verständlich formuliert sein. Vor jedem Sprint ist es wichtig, sicherzustellen, dass die Entwickler die Aufgaben vollständig verstanden haben. Wenn ein Satz wie „Ihr wisst schon, was ich meine“ fällt, ist klar, dass das Verständnis fehlt und jeder etwas anderes verstehen kann und wird. Müssen die Entwickler sehr viel nachfragen, ist die User Story nicht ausreichend beschrieben.

Wir erleben es immer wieder, dass Product Owner den Entwicklern am liebsten vorgeben wollen, wie die Lösung umgesetzt werden soll. Über das „wie“ entscheidet aber allein das Entwicklungsteam. Die Aufgaben im Backlog heißen deswegen „User Story“, weil sie das Ergebnis der Entwicklung aus Sicht des Kunden und Anwenders beschreiben – so wie er sich eine optimale Lösung vorstellt. Dabei haben wir die Erfahrung gemacht, dass es nützlich sein kann, in einer User Story auch festzuhalten, was explizit nicht gewünscht ist, um eine klare Abgrenzung zu schaffen.

3. Mit Eigenverantwortung des Entwicklungsteams motivieren

Im Entwicklungsteam arbeiten Profis und Experten. Sie wissen am besten, wie sie eine optimale Lösung erarbeiten und welche Methoden und Techniken dafür zum Einsatz kommen sollen. Auch die Abschätzungen, wieviel Zeit bestimmte Aufgaben erfordern, müssen sie selbst treffen. Oft setzen sie sich selbst ehrgeizige Ziele – was motivierend wirkt. Dieses “an der Ehre packen”-Gefühl entsteht aber nur, wenn die Ziele erreichbar sind. Wer dem Team zu viel auflädt, demotiviert und erzeugt Frust.

Deshalb: Lieber das Team zuerst entscheiden lassen! Der richtige Ort und Zeitpunkt, kritisch über den Ablauf zu sprechen, ist der Sprint Review und die Sprint Retrospektive. Vorher sollte sich der Product Owner zurückhalten und die Details dem Team überlassen.

4. Die Scrum-Vorgaben ernst nehmen und nicht aufweichen

Scrum funktioniert gut, wenn alle Beteiligten möglichst alle Regeln und Festlegungen befolgen. Wir haben bei Scrum-Initial-Projekten öfter gesehen, dass einzelne Personen dazu neigen, leichtfertig einige Vorgaben mit einem „das brauchen wir nicht“ weglassen zu wollen. Das gilt insbesondere auch für die Zeitvorgaben von Dailys, Sprints und Reviews oder die klare Rollenverteilung.

Wer wie expeso Scrum schon länger einsetzt, weiß, wie gut Scrum vom Regelwerk her austariert ist. Es ist geradezu überlebenswichtig, sich an die Vorgaben zu halten und einen erfahrenen Scrum Master einzusetzen, der aktiv coacht. Der Product Owner sollte seine Tipps, Hilfen und Hinweise akzeptieren und darauf vertrauen, dass Scrum funktioniert.

5. Nicht auf Reviews verzichten, sondern als Chance begreifen

Manchmal sehe ich, dass Product Owner das Wort “agile” so auffassen, dass man ständig alles ändern und umwerfen kann – das ist aber falsch. “Agile” bedeutet, dass sich das Team zusammen mit dem Kunden ständig selbst reflektiert, Fehlentwicklung schnell aufdeckt und darauf aktiv reagieren und agil gegensteuern kann.

Als Product Owner sind daher der Sprint Review (der sich inhaltlich auf die Umsetzung der User Stories in dem Sprint konzentriert) und die Sprint Retrospektive (die die Zusammenarbeit als Scrum-Team im Fokus hat) besonders wichtig und sollten als Chance begriffen werden, die effektive Zusammenarbeit immer weiter zu verbessern und Fehlentwicklungen frühzeitig aufzudecken und zu beheben.

6. Scrum Master und Product Owner sind zwei Personen

In Gesprächen bei der Einführung von Scrum erleben wir es immer wieder, dass Abteilungsleiter auf die Idee kommen, den Scrum Master und Product Owner in einer Person einzusetzen. Lassen Sie das als Product Owner nicht zu! Der Scrum Master berät auch das Entwicklungsteam, der Product Owner sollte das tunlichst vermeiden. Es entstehen viele Konflikte, wenn die beiden Rollen nicht sauber getrennt sind.

Wer Scrum erstmalig einführt, setzt am besten auf einen externen Scrum Master, der über viel Erfahrung mit Scrum-Projekten verfügt.

Fazit

Unsere Erfahrung aus zahlreichen Kundenprojekten zeigt: Eine Scrum-Entwicklung steht und fällt mit den Fähigkeiten des Product Owners, klar zu kommunizieren, den Kundennutzen immer im Blick zu behalten und sich an die Vorgaben der agilen Software-Entwicklung nach Scrum zu halten. Wenn sie mit uns eine Software-Entwicklung starten, können Sie sich darauf verlassen, dass wir die typischen Stolpersteine einer Scrum-Entwicklung kennen, als Product Owner den Kundennutzen über alles stellen und auch kurzfristig hohe Qualität liefern können.

Stehen Sie am Anfang eines innovativen Projekts? Wir unterstützen Sie gerne mit Workshops und Beratungsleistungen bei der Vorbereitung, der Anforderungsanalyse und Zieldefinition sowie der Entwicklung und Umsetzung. Nehmen Sie gerne Kontakt über unsere Webseite, per Telefon +49 621 66 988 988 oder E-Mail auf.

Weitere Blog-Beiträge zum Thema: