Der Product Owner in agilen Softwareentwicklungsprojekten

Inhaltsverzeichnis

Abbildungsverzeichnis

1 Einführung in das Thema
1.1 Problemstellung und Zielsetzung
1.2 Aufbau dieser Arbeit

2 Grundlagen der agilen Softwareentwicklung nach Scrum
2.1 Das Scrum-Framework
2.2 Rollen
2.2.1 Product Owner
2.2.2 Scrum Master
2.2.3 Development Team
2.3 Ausgewählte Scrum-Artefakte
2.3.1 Product Vision
2.3.2 Product Roadmap
2.3.3 Product Backlog
2.3.4 Sprint Backlog

3 Anforderungen an den Product Owner für den Produkterfolg
3.1 Aufgaben und Herausforderungen des Product Owners
3.2 Eigenschaften eines erfolgreichen Product Owners

4 Zusammenfassung und kritische Reflexion

Quellenverzeichnis

Literaturverzeichnis

Verzeichnis der Internetquellen

Abbildungsverzeichnis

Abbildung 1: Das Scrum-Framework

Abbildung 2: Das Scrum Team bestehend aus Product Owner, Scrum Master und Development Team

Abbildung 3: Das Aufgabengebiet des Product Owners

1 Einführung in das Thema

1.1 Problemstellung und Zielsetzung

Die Entwicklung von Software ist ein hochkomplexes Vorhaben. Gleichzeitig ändern sich Kundenanforderungen, Kaufverhalten und Marktgegebenheiten unter anderem aufgrund der Digitalisierung immer schneller. Umso wichtiger ist es für Unternehmen, eine kürzere time-to-market zu erreichen sowie auf sich ändernde Marktbedingungen schnell reagieren zu können. Aus diesen Gründen haben agile Entwicklungsmethoden, insbesondere das Scrum-Framework, in den letzten Jahren zunehmend an Bedeutung gewonnen und werden in immer mehr Unternehmen eingesetzt. Anders als beim Wasserfallmodell (sequenzielles Vorgehensmodell nach Projektphasen) werden bei der agilen Softwareentwicklung nicht sämtliche Anforderungen vor Projektbeginn geplant.^[1] Bei agilen, iterativen (zu Deutsch: sich wiederholenden) Entwicklungsmodellen wird die Software durch regelmäßiges Feedback der Zielgruppe stetig verbessert und es kann sehr schnell auf Änderungen im Markt reagiert werden.

Die Rolle des Product Owners ist im Scrum-Framework eine der zentralsten und gleichzeitig herausforderndsten Rollen, da er alleine die Verantwortung für das Produkt trägt. Um zu vermeiden, dass der Erfolg des Produkts und / oder des Unternehmens gefährdet wird, Ressourcen verschwendet oder Kundenbedürfnisse nicht erfüllt werden, muss bei der Besetzung der Rolle genau darauf geachtet werden, welche Fähigkeiten die Person besitzt. Die richtige Auswahl des Product Owners ist ein wesentlicher Faktor für den Erfolg des Produkts.

Ziel dieser Arbeit ist es, zu untersuchen, durch welche Fähigkeiten der Product Owner in agilen Softwareentwicklungsprojekten den Erfolg seines Produktes positiv beeinflussen kann. Dazu gilt es, nach der Definition grundlegender Begrifflichkeiten, die Aufgaben und Herausforderungen von Product Ownern zu untersuchen. Auf Basis dieser Aufgaben und Herausforderungen sind Fähigkeiten zu erarbeiten, die dem Product Owner zu einer erfolgreichen Tätigkeit und somit zu einem erfolgreichen Product verhelfen.

1.2 Aufbau dieser Arbeit

In Kapitel 2 werden zunächst die zum Verständnis der Thematik notwendigen Grundlagen gelegt. Hierzu wird zuerst das Scrum-Framework im Allgemeinen erläutert. Anschließend wird auf die einzelnen Scrum-Rollen sowie auf die für diese Arbeit relevanten Scrum-Artefakte eingegangen. In Kapitel 3 wird dann darauf aufbauend untersucht, welche Aufgaben und Herausforderungen auf den Product Owner bei seiner täglichen Arbeit zukommen. Von diesen Aufgaben und Herausforderungen werden anschließend Fähigkeiten abgeleitet, die ein Product Owner benötigt, um mit seinem Produkt erfolgreich zu sein. Kapitel 4 bildet mit der Zusammenfassung und kritischen Reflexion den Abschluss dieser Arbeit.

2 Grundlagen der agilen Softwareentwicklung nach Scrum

2.1 Das Scrum-Framework

„Scrum [ist] ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.“^[2] So beschreiben Ken Schwaber und Jeff Sutherland das Scrum-Framework, welches sie Anfang der 1990er Jahre entwickelt haben, in ihrem Scrum-Guide.^[3] Dieser Aussage ist zu entnehmen, dass es sich bei Scrum nicht um einen standardisierten Prozess handelt, sondern um ein Rahmenwerk, in welchem Arbeit organisiert und durchgeführt werden kann, sowie Kreativität gefördert wird. Dem Scrum-Framework liegen eine Vielzahl an Werten, Prinzipien und Methoden zugrunde.^[4] Eines der wesentlichen Merkmale von Scrum ist das Ermöglichen von schnellem Feedback. Durch kurze Entwicklungszyklen (Sprints) und regelmäßiger Einbindung von Kunden und Stakeholdern (bspw. in Reviews) erhält das Scrum-Team wertvolles Feedback für die weitere Produktentwicklung. Das Produkt kann somit regelmäßig an die Bedürfnisse der Kunden sowie an sich ändernde Marktbedingungen angepasst werden. Im Vergleich zu traditionellen Entwicklungsmethoden wird der Umfang (Scope) des Produkts variabel gehalten. Es herrscht ein Verständnis dafür, dass der Umfang sich im Laufe der Entwicklungstätigkeit verändert. Eine weitere zentrale Eigenschaft von Scrum ist, dass die Menschen über Prozesse und Tools gestellt werden. Ein Scrum-Team ist ein selbstorganisiertes und lernendes Team, das crossfunktional aufgestellt ist. Das bedeutet, alle Fähigkeiten zur Fertigstellung des Produkts stehen im Team zur Verfügung, wodurch sequentielle Abarbeitung vermieden und eine schnellere time-to-market erreicht wird.^[5]

Das Scrum-Framework besteht aus einer Reihe von Aktivitäten, Artefakten und Rollen. In Abbildung 1 ist beispielhaft ein Sprint mit all seinen Aktivitäten und Artefakten dargestellt. Die für diese Arbeit maßgeblichen Rollen und Artefakte werden in den nächsten Abschnitten näher erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Das Scrum-Framework^[6]

2.2 Rollen

Ein Scrum-Team wird aus den drei Scrum-Rollen Product Owner, Scrum Master und Development Team gebildet. Alle drei Rollen sind Teil des Scrum-Teams, siehe Abbildung 2. Jeder Rolle kommen unterschiedliche Aufgaben und Verantwortlichkeiten zu, welche in den folgenden Abschnitten erläutert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Das Scrum-Team bestehend aus Product Owner, Scrum Master und Development Team^[7]

2.2.1 Product Owner

Der Product Owner übernimmt in Scrum die Verantwortung für das Produkt und ist für dessen Entstehung und (wirtschaftlichen) Erfolg verantwortlich.^[8] Der Product Owner ist immer eine einzelne Person, kein Lenkungskreis oder Komitee. Nur er ist für das Ergebnis verantwortlich und rechenschaftspflichtig.^[9] Er gibt im Scrum-Framework das „was“ vor, also welche Eigenschaften und Funktionalitäten entwickelt werden sollen. Dazu entwickelt er eine Product Vision, die er den anderen Mitgliedern des Scrum-Teams vermittelt.^[10] Um die Zufriedenheit der Kunden sicherzustellen, vertritt er im Scrum-Team die Interessen der Stakeholder außerhalb des Teams.^[11] Eine seiner Hauptaufgaben besteht im Management des Product Backlogs, das heißt dem Formulieren von Anforderungen sowie deren Priorisierung.^[12] Die Aufgaben des Product Owners werden in Kapitel 3 weiter vertieft.

2.2.2 Scrum Master

Der Scrum Master unterstützt als Teil des Scrum-Teams den Product Owner sowie das Entwicklungsteam. Dabei agiert er als Coach und Trainer, indem er die Scrum-Werte, -Prinzipien und -Methoden vermittelt sowie bei der Ausübung des Scrum-Frameworks unterstützt. Seine Tätigkeiten beziehen sich aber nicht nur auf das Scrum-Team. So vermittelt er auch den relevanten Stakeholdern oder in größeren Organisationen dem Management die Scrum-Prinzipien und hilft beim Umstieg von klassischen Projektmanagementmethoden auf Scrum. Im Team ist eine seiner wesentlichen Aufgaben das Beseitigen von Hindernissen, den sogenannten Impediments. Können einzelne Teammitglieder Probleme nicht lösen und wird dadurch die Produktivität des Teams gestört, so ist es am Scrum Master, bei der Lösung dieser Probleme eine führende Rolle einzunehmen. Darüber hinaus moderiert der Scrum Master wichtige Team Ereignisse, wie beispielsweise das Planning oder das Refinement.^[13]

[...]

^[1] Vgl. o.V. (2011), http://www.isicore.de/ (Stand: 05.08.2018)

^[2] Schwaber, K. / Sutherland, J. (2013), S. 3

^[3] Vgl. o.V. (o.J.), http://scrum-master.de/ (Stand: 13.07.2018)

^[4] Vgl. Rubin, K. (2014), S. 47

^[5] Vgl. Morris, D. (2017), S. 11 ff.

^[6] Enthalten in: Rubin, K. (2014), S. 51

^[7] Eigene Darstellung

^[8] Vgl. Pichler, R. (2014), S. 8

^[9] Vgl. Schwaber, K. / Sutherland, J. (2013), S. 5

^[10] Vgl. Rubin, K. (2014), S. 49

^[11] Vgl. Franken, M. (2014), S. 11

^[12] Vgl. Rubin, K. (2014), S. 49

^[13] Vgl. Rubin, K. (2014), S. 49 f.