Wer Produkte iterativ nach SCRUM entwickelt, hat sich höchstwahrscheinlich auch schon einmal mit den unterschiedlichen Rollen des agilen Vorgehensmodells auseinandergesetzt. Besonders was das Anforderungsmanagement angeht, gibt SCRUM eine für den Projekterfolg außerordentlich wichtige Rolle vor: die des Product Owners (PO).

Klassische versus agile Vorgehensmodelle

Klassische und agile Vorgehensmodelle zur Umsetzung von Produkten unterscheiden sich in vielerlei Hinsicht voneinander. Einer der größten Unterschiede ist dabei der Umgang mit Anforderungen. Ganz gleich, ob das zu entwickelnde Produkt eine Software, eine materielle Ware oder eine Dienstleistung ist – der Unterschied liegt darin, in welcher Weise und vor allem zu welchem Zeitpunkt Anforderungen gestellt werden. Klassische Vorgehensmodelle wie das Wasserfallmodell stellen die Aufnahme der Anforderungen in der »Definitionsphase« allen Entwicklungen des Produktes voran. Erst wenn alle Anforderungen der Stakeholder an das Produkt feststehen, beginnt das Team mit der Produktentwicklung. Alle Anforderungen bereits zu Beginn zu kennen ist eine Herausforderung, die mit der Komplexität des Produktes steigt. Es besteht die Gefahr, dass unnötig Zeit und Geld verbraucht werden, sobald sich die Aufnahme der Anforderungen herausfordernder und langwieriger als geplant gestaltet.

In der agilen Produktentwicklung nach SCRUM hingegen wird dem Umstand Rechnung getragen, dass sich viele Anforderungen an ein Produkt erst im Laufe seiner Entwicklung ergeben. So sind grundsätzliche Anforderungen der Stakeholder an das Produkt zwar meist im Groben klar, konkrete Bedürfnisse der Kunden ergeben oder entwickeln sich jedoch häufig erst nach Auslieferung einzelner Features und mit Einsatz des Produkts.

Jemand muss im Projekt alles zusammenhalten

Damit das Produkt bestmöglich den Bedürfnissen der Kunden bzw. Nutzer entspricht und erfolgreich wird, sieht die agile Entwicklung vor, Funktionen sukzessive zu ergänzen, zu verproben und im Zweifel auch wieder herauszunehmen. Das Feedback – egal, ob durch externe oder interne Kunden – wird sehr wahrscheinlich Einfluss auf die initialen Anforderungen nehmen: Einige werden wichtiger werden, andere obsolet. In einer Welt der volatilen Anforderungen bedarf es zwingend einer Rolle, die einen Überblick über all das Feedback, die Ideen und Meinungen der Beteiligten behält:

Der Product Owner

Der PO bildet die Schnittstelle zwischen Stakeholdern, Kunden und Entwicklungsteam. Durch ihn spart das Entwicklungsteam wertvolle Zeit: Indem er die Anforderungen schärft und im Zweifel Fragen an Kunden und Stakeholder zurückspielt, wissen die Entwickler zu jedem Zeitpunkt, was genau mit welchem Ziel entwickelt werden soll. Außerdem sorgt der Product Owner für Ordnung im Product Backlog (der Sammlung aller Anforderungen, die sich im Entwicklungsverlauf ergeben), indem er alle User Stories (aus der Nutzerperspektive heraus formulierte Anforderungen) mit den für das Team wichtigen Informationen wie Erfolgskriterien, Beschreibungen und Zusatzinformationen versieht und priorisiert.

Doch was passiert, wenn diese Rolle im SCRUM-Team nicht oder nicht vollständig besetzt ist? Eine unvollständige Besetzung der Rolle tritt in der Praxis auf, wenn der PO nur einen Teil seiner Zeit im Projekt verbringt – beispielweise neben seiner Linienfunktion oder neben anderen Projekten, für die er die Verantwortung trägt.

Ein SCRUM-Projekt ohne richtigen Product Owner: ein Gedankenspiel

Werden die Aufgaben des Product Owners gar nicht, nur zum Teil oder ohne klare Aufgabenverteilung von unterschiedlichen Stellen erfüllt, dann steuert das Entwicklungsteam »blind« durch die Entwicklung des Produktes oder handelt nach bestem Wissen und Gewissen. Auch wenn erfahrene Entwickler oft ein gutes Gespür für Anforderungen haben, fehlt ein Entscheider, wenn es um die Klärung der konkreten Vorstellung des Kunden oder um Entscheidungsprozesse geht. Im schlimmsten Fall werden User Stories falsch umgesetzt oder Prioritäten verkannt. So kann es passieren, dass unwichtige User Stories direkt umgesetzt werden, während wichtige Themen herunterpriorisiert werden. Nimmt das Entwicklungsteam die Priorisierung selbst vor, kann es passieren, dass dies nicht aus Perspektive der Kunden, sondern aus ihrer eigenen heraus geschieht. Mit Gedanken wie »ach, das klingt doch leicht für mich, setze ich direkt im nächsten Sprint mit um« erreicht das Team zwar eine hohe Umsetzungsgeschwindigkeit – die Gefahr, dass dabei wichtige Funktionen des Produktes auf der Strecke bleiben, ist dafür umso höher.

Hinzu kommt, dass das Feedback zu umgesetzten Features unter Umständen nicht beim Entwicklungsteam ankommt, denn ohne den Product Owner fehlt eine wichtige Instanz in der Feedbackschleife. Ohne kontinuierliche Auswertung und Einarbeitung des Feedbacks fällt die Optimierung von Funktionen des Produktes für den Kunden nicht nur schwer, sie ist fast unmöglich. Der Erfolg des Produktes kann nicht sicher gewährleistet werden und schneller als gedacht wird aus einem agilen Vorgehensmodell wieder ein klassisches – zumindest im Hinblick auf das Anforderungsmanagement: Erst mit Fertigstellung des Produktes wird auf das Feedback der Stakeholder und Kunden reagiert und entsprechend (zu) spät gehandelt.

Der Herr des Backlogs

Neben fehlender Priorisierung und Optimierung der Features fehlt es ohne expliziten Product Owner auch an Informationen und Ordnung im Backlog. Getreu dem Motto »viele Köche verderben den Brei« kann es schnell passieren, dass Informationen für das Entwicklungsteam an falschen Stellen oder gar nicht auffindbar sind. Dies gilt besonders dann, wenn unterschiedliche Personen für die Pflege verantwortlich sind. Zusätzlich führt dies fast unweigerlich zu Streuverlusten von Informationen zwischen Stakeholdern, Kunden und Entwicklungsteam.

Übernimmt hingegen das Entwicklungsteam selbst die Pflege des Backlogs, stellt die richtige Priorisierung der User Stories erneut eine Herausforderung dar, denn der kontinuierliche Rückkanal hin zu den Stakeholdern fehlt. Außerdem werden die Kapazitäten der einzelnen Teammitglieder stark dezimiert, wenn sie zusätzlich für administrative/organisatorische Aufgaben verwendet werden müssen. Vor allem die Klärung von Detailfragen oder die Festlegung von Erfolgskriterien in Rücksprache mit den Stakeholdern bedarf einiges an Aufwand und Zeit.

Die Schlüsselrolle als Schlüssel zum Erfolg

Alle in SCRUM definierten Rollen erfüllen konkrete Aufgaben und Funktionen im Projekt. Der Product Owner nimmt dabei eine Schlüsselrolle ein. Sobald der Weg und das Ziel des Projektes klar definiert sind und jemand alle Fäden und Informationen zusammenhält, steigert dies die Chance auf einen erfolgreichen Projektabschluss. Außerdem lässt sich durch die Besetzung der PO-Rolle eine Dezimierung der Kapazitäten des Entwicklungsteams vermeiden. Das Team kann sich auf die Umsetzung des Produktes fokussieren und muss sich nicht um Themen rund um das Backlog oder die Informationsbeschaffung kümmern.

Fazit

Zusammenfassend lohnt es sich in jedem Fall, die Rolle des Product Owners in Projekten eindeutig und mit genug Kapazität zu besetzen. Auch für den Fall, dass dies manchmal aufgrund unterschiedlicher Faktoren (geringe Ressourcen, fehlende Qualifikation, Aufbau der Organisation) nicht mit Projektbeginn erfolgen kann, gibt es Lösungen – zum Beispiel in Form eines Proxy POs. Der Proxy PO stammt dabei nicht notwendigerweise aus der Organisation, sondern wird oftmals extern beauftragt. Er übernimmt (zeitweise) die Aufgaben des Product Owners bis alle internen Klärungen erfolgt sind. So hat das Team bereits von Beginn einen Ansprechpartner und Mittelsmann zwischen sich und den Stakeholdern und kann sich voll und ganz auf eine erfolgreiche Projektumsetzung konzentrieren.

Sie möchten Ihr Projekt durch externe Unterstützung beschleunigen und sicher zum Erfolg führen? Gerne unterstützen wir Sie in den Bereichen Projektumsetzung & Projektmanagement und entwickeln darüber hinaus ein individuelles Befähigungskonzept zu agiler Arbeit in Ihrem Unternehmen.

Vielleicht ist auch unser deep:dive Product Ownership Training für Sie interessant? Hier finden Sie Informationen zu unserem Product Ownership Training für Banken und Versicherungen:

Sie kommen aus einer anderen Branche? Kein Problem! Gemeinsam gestalten wir das Format zielgerichtet für Ihre Branche.