Product Owner (PO), Scrum Master und Development Team: Scrum definiert klare Rollen mit gut abgegrenzten Verantwortungsbereichen. Dabei geht der Scrum Guide jedoch grundsätzlich davon aus, dass das gesamte Scrum Team Teil ein- und derselben Organisation ist. Hierarchien oder die Bildung von Sub-Teams sind nicht vorgesehen, und schon gar nicht ein Auftraggeber-Auftragnehmer-Verhältnis.
Bei slashwhy entwickeln wir individuelle Software im Kundenauftrag – als Dienstleistung. An unseren agilen Entwicklungsprojekten sind also zwei Unternehmen beteiligt: Zum einen das auftragegebende Unternehmen mit dem Bedarf, der Produktidee, dem Zugang zu den Stakeholdern etc., zum anderen wir als Dienstleister mit der Expertise, diese Produktidee Realität werden zu lassen. In dieser Konstellation ist die Verteilung der Rollen und Aufgaben im gemeinsamen Scrum-Projekt schon nicht mehr so eindeutig. Das Development Team setzt sich typischerweise aus slashwhy-Kolleg:innen zusammen. Auch der Scrum Master des Projektes kommt in der Regel von slashwhy; es sei denn der Kunde verfügt bereits über viel Erfahrung im Bereich der agilen Softwareentwicklung und möchte lieber selbst den Scrum Master stellen. Vor allem aber stellt sich die Frage, wer die außerordentlich wichtige PO-Rolle übernimmt: Der Kunde? slashwhy? Oder beide?
Was beinhaltet die Rolle Product Owner?
Um als Dienstleister eine agile Produktentwicklung mit einem Kunden erfolgreich zu gestalten, ist die PO-Rolle von zentraler Bedeutung. Der PO ist eine der drei im Scrum Guide definierten Rollen innerhalb des Scrum-Teams. Er oder sie trägt die Verantwortung für die Produktvision, die Priorisierung der Aufgaben und letztlich für die Arbeitsergebnisse des Scrum-Teams und die daraus generierte Wertschöpfung.
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”
Scrum Guide 2020
In einem Softwareentwicklungsprojekt nach Scrum gibt es eine Reihe von PO-Aufgaben, die erfüllt werden müssen und die einen erheblichen Einfluss auf den Projekterfolg haben. Das beginnt schon damit, allen Beteiligten eine klare Orientierung zu geben und zu entscheiden, wohin die Reise mittel- bis langfristig gehen soll. Der oder die PO muss entscheiden, zu welchem Zeitpunkt an welchen Stories gearbeitet werden soll, indem die Frage beantwortet wird: Was schafft gerade den größten Wert oder reduziert ein wesentliches Risiko? Um dies tun zu können, ist ein tiefes Verständnis der Produktanwender:innen, des Marktes, der Projektdomäne und des Business Case erforderlich. In Zusammenarbeit mit dem Scrum Team werden kontinuierlich die nächsten Themen vorbereitet und verfeinert. Iterativ kann der Workflow immer wieder angepasst werden, um gemeinsam maximal erfolgreich die Ziele zu erreichen. Zur PO-Rolle gehört auch eine effektive Stakeholder-Kommunikation und -Beziehungspflege, das Managen von Risiken, das Treffen richtungsweisender Entscheidungen und die Abnahme der Arbeitsergebnisse der Entwickler:innen.
Wer übernimmt die PO-Rolle im Dienstleistungsprojekt?
Idealerweise hat das auftragegebende Unternehmen Erfahrung mit Entwicklungsprojekten nach Scrum und als Organisation einen hohen agilen Reifegrad. Der Kunde überträgt die PO-Rolle intern an eine Person, die das entsprechende Know-how und Mindset mitbringt, stattet sie mit Budget und Entscheidungsspielräumen aus, stellt sie von sämtlichen anderen Aufgaben frei und befähigt sie, die verantwortungsvolle PO-Rolle vollumfänglich wahrzunehmen. Das wäre die beste Lösung.
Die Realität sieht aber häufig anders aus. Als Softwareentwicklungsdienstleister wissen wir, dass nicht alle unsere Kunden alle wesentlichen PO-Aufgaben selber wahrnehmen wollen oder können. Manchmal reichen die zeitlichen Ressourcen einfach nicht aus, weil die Person in der PO-Rolle parallel in mehrere Entwicklungsprojekte eingebunden ist, bzw. andere Aufgaben (noch) nicht vollständig abgeben kann. Ein anderer Grund kann sein, dass sie bisher wenig Erfahrung mit agiler Softwareentwicklung und den PO-Aufgaben hat und zunächst in diese Rolle hineinwachsen muss. In solchen Fällen schauen wir gemeinsam, wie wir hierbei unterstützen können und eventuell auch, welche PO-Aufgaben wir als Dienstleister übernehmen können. Um diese Aufgaben kümmert sich dann ein:e Kolleg:in von slashwhy in der Rolle "/y-PO" (slashwhy Product Owner).
Wichtig ist jedoch: Es gibt erfolgskritische Aufgaben, die zwingend beim beauftragenden Unternehmen verbleiben müssen. Dazu gehören das grundsätzliche Vertreten der Produktvision sowie die formale Abnahme der umgesetzten Stories. Diese Aufgaben müssen von einem Mitarbeiter oder einer Mitarbeiterin des Kunden mit der Rolle PO wahrgenommen werden. Alle anderen PO-Aufgaben müssen zwar gewissenhaft erledigt werden, um den Projekterfolg sicherzustellen, aber es gibt durchaus Spielraum bei der Aufgabenverteilung zwischen Kunde und Dienstleister.
In dem folgenden Video erklären wir, welche Aufgaben das sind und welche Lösungen wir bei slashwhy haben, um diese gemeinsam mit unseren Kunden zuverlässig und gut zu erledigen.
Fazit
Agile Entwicklungsmethoden verändern das Verhältnis zwischen Auftragnehmer und Auftraggeber in Richtung einer Partnerschaft auf Augenhöhe. Dazu haben wir verschiedene Best Practices für die Zusammenarbeit verprobt. Eine wichtige Grundlage für erfolgreiche Kundenprojekte ist, dass der Kunde die PO-Rolle bzw. -Aufgaben versteht, akzeptiert und idealerweise auch selbst wahrnimmt. Dabei können wir ihn bedarfsabhängig auf verschiedene Weise unterstützen - bishin zur Übernahme einiger PO-Aufgaben.
