Scrum 707 E-Book

Afra Berk

• Herausgeber: epubli
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 194

Veröffentlichungsjahr: 2024

Beschreibung

Scrum. Kaum ein anderes Wort prägt das Thema Projektmanagement der letzten Jahre wie dieses. Im Rahmen einer akademischen Ausarbeitung haben Studierende dieses Buch zur Scrum-Theorie verfasst. Basierend auf dem Scrum-Guide wurden theoretische Grundlagen erarbeitet und angewendet. Doch was unterscheidet dieses Buch von den anderen Sachbüchern? Berechtigte Frage, welche sich mit der nachstehenden Gegenfrage beantworten lässt. Hast Du schonmal ein Buch über die Scrum-Theorie gelesen, welches im Rahmen eines Scrum-Projektes erstellt wurde? Nein? Dann hast Du mit Scrum 707 nun die Möglichkeit. Tauche gemeinsam mit den Studierenden in die Welt von Scrum ein. Lerne die agile Projektmethode Sprint für Sprint kennen und erhalte die Chance Dein nächstes Projekt mit Scrum zukunftsorientiert zu gestalten.

Leseprobe

Scrum 707

– Lizenz zur Agilität

Afra Berk, Carl Geißler, Roshini Kalkatte, Hai Trien Le, Niclas Luther, Thuy Duong Vu, Markus Waltz

Scrum 707

– Lizenz zur Agilität

Afra Berk, Carl Geißler, Roshini Kalkatte, Hai Trien Le, Niclas Luther, Thuy Duong Vu, Markus Waltz

Provadis School of International Management and Technology AGFrankfurt, Deutschland

© Copyright by Afra Berk, Carl Geißler, Roshini Kalkatte, Hai Trien Le, Niclas Luther, Thuy Duong Vu, Markus Waltz

Erstpublizierung: September 2024

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung der Autoren. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder die Autoren noch die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen.

Druck und Vertrieb:epubli – ein Service der Neopubli GmbH, Berlin

Vorwort

„Scrum“ ist ein bekannter Begriff, insbesondere für die Personen, die bereits mit Projektmanagement zu tun hatten. Wer zuvor schon auf der Arbeit oder in der Universität/Hochschule ein Projekt hatte, kam sicherlich an diesem Begriff nicht vorbei. Diese Methode für eine agile Projektarbeit präsentierten die Erfinder Jeff Sutherland und Ken Schwaber im Jahr 1995 auf einer Konferenz (J. Sutherland, 2015). Aber wie funktioniert diese Methode und kann sie auch in einem Hochschule-Projekt angewendet werden? Genau das, haben wir Studenten von der Provadis Hochschule uns gefragt. Wir haben uns als eine Gruppe aus sieben Studenten zusammengesetzt und dieses Buch über Scrum mit der agilen Projektmanagement Methode Scrum geschrieben. Daraus möchten wir den Lesern einen Einblick geben, wie dieses Buch entstanden ist und wie erfolgreich wir die Methode anwenden konnten. Mit 7 unerfahrenen Studenten, dennoch 0 Rückschlägen, haben wir in 7 Sprints dieses Buch geschrieben.

Die Verfasser dieses Buches waren hauptsächlich die fünf Developer und zwei weitere übernahmen, wie in einem Scrum-Projekt üblich, die Rolle des Product Owners und des Scrum Masters. Alle sieben Mitglieder des Teams verfassten in den Teilen der eigenen Erfahrungen ihren individuellen Einblick, sodass der Leser aus jeder Perspektive einen Eindruck gewinnen und das Gelernte für sich umsetzen kann. Die Idee zu diesem Buch stammte von unserem Dozenten im Modul „Agile Projektarbeit“. Daher ist auch dieses Buch an unseren Dozenten Kay Schulz gewidmet, der uns Studenten in den Vorlesungen nicht nur spielerisch in die Theorien mit Lego, Papierfliegern und Tennisbällen einbringen konnte, sondern auch bei den Sprint Reviews (als Kunde und Dozent) hilfreichen Input gegeben hat, um nicht nur den Inhalt dieses Buches zu entwickeln, sondern auch uns zu helfen, selbst zu reflektieren. Wir danken dir Kay, für deine ermutigenden Worte, deine sehr persönlichen Einblicke und auch deine kritischen Gedanken!

Mit diesen Worten möchten wir euch, den Lesern, unsere Learnings mitgeben, damit ihr sie auch für euer Projekt anwenden könnt. Das Ziel dieses Buches ist es, euch die Lizenz zur Agilität mit unseren Praxiserfahrungen beim Schreiben dieses Buches zu geben. Wir wünschen euch eine bereichernde Leseerfahrung, Spaß und hoffen, dass ihr neue Einsichten und Inspirationen erhaltet.

Eure Autoren,Afra Berk, Carl Geißler, Roshini Kalkatte, Hai Trien Le, Niclas Luther, Thuy Duong Vu und Markus Waltz

Hinweis zur gendergerechten Formulierung

Im folgenden Sachbuch wird aus Gründen der besseren Lesbarkeit das generische Maskulinum verwendet. Dies impliziert keine Benachteiligung des weiblichen Geschlechts, sondern soll im Sinne der sprachlichen Vereinfachung als geschlechtsneutral zu verstehen sein. Weibliche und anderweitige Geschlechteridentitäten werden dabei ausdrücklich mitgemeint, soweit es für die Aussage erforderlich ist.

Abkürzungsverzeichnis

Abb.

Abbildung

AgileGPT

Agile Generative Pretrained Transformer

Bspw.

Beispielsweise

Bzw.

Beziehungsweise

ChatGPT

Chat Generative Pretrained Transformer

DevOps

Development Operations

DoD

Definition of Done

DoR

Definition of Ready

Evtl.

Eventuell

GenAI

Generative Artificial Intelligence

Ggfs.

Gegebenenfalls

Inkl.

Inklusive

KI

Künstliche Intelligenz

N. d.

Nicht definiert

O. D.

Ohne Datum

Vs.

Versus

Z. B.

Zum Beispiel

Inhaltsverzeichnis

Vorwort

Hinweis zur gendergerechten Formulierung

Abkürzungsverzeichnis

Abbildungsverzeichnis

1Rollenkonzept von Scrum

1.1Product Owner

1.1.1Theorie zum Product Owner

1.1.2Vorgehen und gelernte Praxis zum Product Owner

1.1.3Individuelle Erfahrungsbeschreibung zum Product Owner

1.2Scrum Master

1.2.1Theorie zum Scrum Master

1.2.2Vorgehen und gelernte Praxis zum Scrum Master

1.2.3Individuelle Erfahrungsbeschreibung zum Scrum Master

1.3Developer

1.3.1Theorie zu Developer

1.3.2Vorgehen und gelernte Praxis zum Developer

1.3.3Individuelle Erfahrungsbeschreibung zum Developer

2Scrum Theorie und Prozess

2.1Aufbau von Scrum

2.1.1Säulen von Scrum

2.1.2Scrum Werte

2.1.3Scrum-Prinzipien

2.1.4Scrum Prozess

2.1.5Einführung Sprint

2.2Scrum-Artefakte

2.2.1User Story

2.2.2Definition of Ready

2.2.3Definition of Done

2.2.4Product Backlog

2.2.5Sprint Backlog

2.2.6Increment

2.3Scrum Events

2.3.1Sprint Planning

2.3.2Daily Scrum

2.3.3Sprint Review

2.3.4Sprint Retrospective

2.3.5Backlog Refinement

2.4Planung der Kapazitäten

2.4.1Velocity vs. Kapazität

2.4.2Schätzmethoden

2.4.3Kapazitätsplanung

2.5Vorgehen und gelernte Praxis zu Scrum

2.5.1Allgemeine Informationen

2.5.2Planung der Kapazitäten

2.5.3Scrum Events

2.6Individuelle Erfahrungsberichte zu Scrum

3Zukunftsaussichten und Handlungsempfehlungen zu Scrum

3.1Einsatzmöglichkeiten GenAI

3.2Handlungsempfehlung

3.2.1Zusammenstellen eines geeigneten Teams

3.2.2Klärung der Definition of Done

3.2.3Aufbau und Ordnung des Product Backlogs

3.2.4Planung der Sprints

3.2.5Daily Scrum

3.2.6Bereitschaft für Iteration und kontinuierliche Verbesserung

3.3Individuelle Erfahrungsbeschreibung zu Zukunftsaussichten und Handlungsempfehlungen

4Zusammenfassung

4.1Zusammenfassung der Theorie

4.2Vorgehen und gelernte Praxis zu Scrum

4.3Individuelle Erfahrungsberichte zu Scrum

Glossar

Literatur

Autorenvita

Abbildungsverzeichnis

Abb. 1: Der Scrum Prozess101

Abb. 2: Priorisierter Product Backlog Prozess107

Abb. 3: Task in Azure DevOps135

1 Rollenkonzept von Scrum

In Scrum gibt es insgesamt drei Rollen. Ein Scrum-Team besteht aus einem Product Owner, einem Scrum Master und mehreren Developern. Für welche Aufgaben diese Rollen verantwortlich sind, wird in den nachfolgenden Kapiteln thematisiert.

1.1 Product Owner

Der Product Owner stellt in Scrum eine natürliche Person dar. Er besitzt im besten Fall die fachlichen Kenntnisse vom Projekt und steht im Austausch mit den Stakeholdern, um die Anforderungen vom Projekt zu besprechen. Zudem ist er verantwortlich für das Ergebnis des Projektes (Schwaber & Sutherland, 2020).

1.1.1 Theorie zum Product Owner

Der Product Owner ist im Scrum-Projekt für die Maximierung des Produktwertes verantwortlich. Der Produktwert ergibt sich aus der Arbeitsleistung des Teams. Abhängig von der Organisation, den Scrum-Teams, sowie den einzelnen Projektteilnehmern kann der maximale Wert durch verschiedene Methoden unterschiedlich sichergestellt werden (Scrum.org, n.d.).

Die Aufgaben und Verantwortungen des Product Owners sind sehr divers. Zusätzlich zur Wertmaximierung ist auch die Kommunikation eine weitere Hauptaufgabe. Die Sicherstellung einer transparenten Arbeitsatmosphäre genießt in der Kommunikation mit dem Projektteam eine hohe Priorität. Produktziel und -vision werden regelmäßig und transparent kommuniziert. Im gleichen Zuge stellen diese auch Richtwerte für die Priorisierung in der Produktion dar, sodass das Produkt allen internen, sowie externen Stakeholdern einen Mehrwert bietet. Zusammenfassend misst, identifiziert und maximiert der Product Owner den Produktwert und betrachtet dies vollumfassend während des gesamten Produktlebenszyklus (Scrum.org, n.d.).

Welche Aufgaben besitzt der Product Owner?Die Aufgaben des Product Owners sind sehr vielfältig und erfordern verschiedene Fähigkeiten. Aus den Tätigkeiten des Product Owners ergeben sich sechs Hauptaufgaben (Kooijman, 2024b).

Zusammenarbeit mit dem Developer-Team und dem Scrum Master

Kommunikation und Zusammenarbeit zwischen den drei Rollen im Scrum-Projekt nehmen eine essenzielle Rolle ein. Im Gegensatz zu einem Projektleiter entscheidet der Product Owner nur welche Aufgaben in welchem Sprint (Zeitabschnitt) bearbeitet werden sollen. Die Methodik und Didaktik obliegt den Developern und wird nicht vorgeschrieben (Kooijman, 2024b). Diese Art der Kommunikation ist so nicht im Scrum Guide beschrieben worden. Die Erfahrungen aus der Praxis haben jedoch gezeigt, dass die Kommunikation und Zusammenarbeit zwischen den Rollen ausschlaggebend für den Erfolg des Projektes sind.

Vertretung der Interessen des Kunden

Im Rahmen seines Verantwortungsbereiches vertritt der Product Owner alle Stakeholder und stellt die Maximierung des Produktwertes sicher. Der sicherzustellende „Wert“ wird häufig an den Einsparungen gemessen, welche sich durch Prozessanpassungen ergeben oder an der Steigerung des Nutzens des Produktes zeigen (Kooijman, 2024b).

Entwicklung einer Vision des Endproduktes

Gemeinsam mit den Stakeholdern erarbeitet der Product Owner eine Vision des Endproduktes, welche den Nutzen aus Sicht der definierten Personas beinhaltet. Zu diesem Zweck muss der Product Owner kontinuierlich den Markt beobachten und analysieren (Kooijman, 2024b). Mit diesem Verhalten stellt er den Kunden in den Mittelpunkt des Projektes, welches gleichzeitig einer der wichtigsten Werte im Scrum darstellt (Me & Company, o. D.).

In einem überarbeiteten Scrum Guide wurde im Jahr 2020 auch ein „Product Goal“ definiert. Das Product Goal besteht neben der Produktvision aus den unterschiedlichen fachlichen und wirtschaftlichen Perspektiven der anstehenden Produktentwicklungen (Kooijman, 2024b).

Abschließend können die Aufgaben des Product Owner auf drei Hauptaufgaben eingegrenzt werden. Die Hauptaufgaben bestehen aus der fachlichen Führung, sowie dem Stakeholder- und Backlogmanagement (Kooijman, 2024b). Der Product Owner ist dementsprechend keine hierarchische Führungskraft für das Team, da sein Fokus auf dem Produkt und der damit verbundenen Wertsteigerung liegt (Me & Company, o. D.).

Ergänzt werden diese Aufgabenfelder durch die kontinuierliche Beobachtung des Marktes und des Wettbewerbs, sowie der Verantwortung für den Return on Investment des Produktes (Kooijman, 2024b).

Das Produktziel entwickeln und explizit kommunizieren

Erstellung der Product Backlog Items und klare Kommunikation zu den Developern über die Product Backlog Items

Bestellen von Product Backlog Items

Sicherstellen, dass das Product Backlog transparent, sichtbar und verständlich ist (Kooijman, 2024).

Darüber hinaus können Produktanpassungen nur durch den Product Owner erfolgen, weshalb Änderungsvorschläge mit dem Product Owner diskutiert werden müssen. Das Privileg der Produktänderung bzw. -anpassung obliegt somit nur dem Product Owner. Um diesen Anpassungsprozess möglichst effizient durchzuführen ist das Feedback der Kunden unerlässlich (Scrum.org, o.D.).

Im Optimalfall muss das Product Backlog sehr transparent miteinander kommuniziert werden. Dies gilt auch für die Kommunikation mit dem Team. Sowohl auf einer strategischen als auch auf einer operativen Ebene muss auf eine offene Kommunikation Wert gelegt werden (Kooijman, 2024b).

Verwaltung des Product Backlogs

Das Erstellen und Pflegen des Product Backlogs stellt eine weitere Hauptaufgabe des Product Owners dar. Er legt fest, mit welcher Priorität die Aufgaben (Items) erarbeitet werden sollten. Die wichtigsten Arbeitspakete besitzen immer die höchste Priorität und stehen somit an oberster Stelle des Product Backlogs. Items müssen so präzise wie möglich beschrieben werden, sodass die Aufgabenstellungen vom Scrum-Team verstanden und von den Developern bearbeitet werden können. Abschließend muss sichergestellt werden, dass der Product Backlog vollständig ist. Dementsprechend müssen alle für das Endprodukt relevanten Items in diesem Backlog enthalten sein (Kooijman, 2024b).

Aus diesem Absatz könnte sich berechtigterweise die Frage ergeben „Was ist eine präzise Beschreibung eines Items?“. Eine präzise Beschreibung eines Items enthält alle erforderlichen Informationen, welche zur Fertigstellung des Items benötigt werden. Beschrieben an einer Montageanleitung für einen Kleiderschrank von Ikea muss diese vollständig sein, sodass der Kleiderschrank, wie vom Kunden erwünscht, funktionsfähig ist. Sollte die Montageanleitung unvollständig sein, da der Schritt des Verschraubens der Exzenter fehlt, so kann der Schrank dennoch fertig aufgebaut werden. Im Anschluss führt dieser Fehler jedoch dazu, dass der Schrank nicht belastbar ist, da die Exzenter für die Stabilität verantwortlich sind. Aufgrund dessen muss der Schrank nochmal zerlegt und neu aufgebaut werden. Analog zu einem unvollständigen Item in Scrum könnten die Folgen einer unvollständigen Item-Beschreibung zu gravierenden Fehlern im finalen Produkt führen.

Präsentation der Fortschritte

Das Sprint Review ist für den Product Owner ein sehr wichtiges Meeting. In diesem Termin werden die Fortschritte und aktuellen Arbeitsstände präsentiert. Entsprechend legt der Product Owner mit dem Scrum Master den Zeitraum, sowie den Teilnehmerkreis des Termins fest. Im Idealfall erfolgt bereits vor dem Review eine bilaterale Vorstellung, sodass der Product Owner die gelieferten Items „abnehmen“ bzw. „genehmigen“ kann. Die beschriebene bilaterale Abstimmung zwischen Product Owner und Developer vorab zum Review ist zwar kein Bestandteil des Scrum Guides, aber eine Empfehlung. Dieser Austausch kann die Kommunikation zu den Developern positiv beitragen, weshalb dieser Punkt zu diesem Buch aufgenommen wurde. Inhalt des Reviews ist die Live-Vorstellung der erstellten Increments, sodass direkt im Meeting ein Feedback gegeben werden kann. Somit dient das Meeting nicht nur als Feedbackrunde, sondern liefert auch Input für das nächste Sprint Planning (Kooijman, 2024b).

1.1.2 Vorgehen und gelernte Praxis zum Product Owner

Wie bereits im Vorwort erwähnt, haben die Autoren dieses Scrum-Buch mit der Projektmanagement Methode Scrum geschrieben. Im nachfolgenden Abschnitt und in den weiteren Kapiteln, werden die Praxiserfahrungen der Studenten erklärt und wie sie Scrum beim Erstellen des Buches umgesetzt haben.

Zu Beginn des 1.Sprints war die erste Aufgabe des Product Owners die Suche nach einem geeigneten Tool für das Sprint Planning und das Product Backlog. Nach der Recherche entschied sich der Product Owner für das Tool Azure DevOps. Das Tool ermöglicht eine visuelle und einfach zu bedienende Übersicht für das Sprint Planning mit Boards. Die Product Backlog Items können effizient, transparent verwaltet und priorisiert werden. Daraufhin wurde das Tool den Developern und dem Scrum Master in einem Kick-off-Meeting vorgestellt. Der Product Owner hat den Produktwert kontinuierlich maximiert, in dem für jeden Sprint Produktziele festgelegt wurden, um sicherzustellen, dass nach jedem Sprint das Endziel des Buches schrittweise und kontinuierlich erreicht wird.

Außerdem war die effektive Kommunikation ein zentraler Aspekt der Arbeit, dass auch von Anfang an eine sehr wichtige Rolle gespielt. Da das Team zum ersten Mal in dieser Konstellation gearbeitet hat, hat es etwas länger gebraucht, bis das Team effektiv und offen miteinander kommuniziert hat. Nach der Tuckman Theorie kam das Team erst nach drei bis vier Wochen in die Performing Phase, bei dem sie sehr offen, im Team miteinander und auch mit dem Product Owner kommuniziert haben. Der Product Owner wurde immer zu den Meetings eingeladen, weil alle Developer sich trotz Anwesenheit des Product Owner‘s wohl gefühlt haben, wodurch eine offene Arbeitsatmosphäre geschaffen. Dies wurde auch öfters als positives Feedback aus den Retrospectiven festgehalten. Einmal die Woche fand ein Weekly statt, weil alle im Scrum-Team neben der Vorlesung berufstätig sind. Ergänzend dazu fand ein regelmäßiger Kontakt per WhatsApp statt. Die klare Absprache für die Verwendung der Kommunikationskanäle sorgte dafür, dass alle über den Projektfortschritt und über ihre User Stories informiert waren. Falls aus Zeitgründen ein Teammitglied nicht an einem Meeting teilnehmen konnte, wurde sichergestellt, dass das fehlende Teammitglied über die besprochenen Themen durch den Product Owner informiert wurde. Diese zusätzliche Maßnahme stellte sicher, dass alle Teammitglieder trotz Abwesenheit auf dem neuesten Stand blieben und ihre Aufgaben effektiv weiterführen konnten.

Eine wichtige Aufgabe des Product Owner‘s war, die Reihenfolge der Tasks sinnvoll zu gestalten, um den größten Mehrwert zu generieren. Die Product Backlog Items des Projektes waren eine Mischung aus Recherche-, Schreib- und Validierungsitems. Daher war es essenziell die Tasks zu priorisieren. Denn im dreiwöchigen Sprint war es wichtig, dass die Developer anhand der Priorisierung wussten, dass die Items, die von anderen Items abhängig waren, zuerst erledigt werden sollten, damit z. B. der Validierer und Product Owner genügend Zeit zur Korrektur hatten. Die Abnahme der User Story erfolgt auch durch den Product Owner, weil er die Anforderungen des Kunden besser versteht und diese bei der Validierung berücksichtigt. Dadurch lernten die Developer, ihren Stil besser anzupassen und den Anforderungen zu entsprechen Ein wichtiger Aspekt bezüglich der Priorisierung war, dass in den ersten zwei Sprints der Fokus auf die Recherche gelegt wurde. Dies führte zu einer Steigerung der Qualität und einer intensiven Beschäftigung mit den Themen. Die Rückmeldung der Developer aus der Retrospective im 2. Sprint hat gezeigt, dass Recherche und Schreibtasks gemeinsam vergeben werden sollten, da sich die Produktivität der Developer erhöht und die Developer dadurch effizienter arbeiten. Diese Anpassung basierte auf den praktischen Erfahrungen des Teams und führte zu einer effektiven Arbeit, die im nächsten Sprint umgesetzt wurde. Dies wurde auch vom Product Owner ab dem nächsten Sprint im Product Backlog umgesetzt.

Einmal in der Woche fand ein Meeting zwischen Product Owner und Scrum Master statt. Da es keine Konflikte zwischen beiden Rollen gab, konnte offen über das Product Backlog und Hindernisse kommuniziert werden. Durch die enge Zusammenarbeit konnte sichergestellt werden, dass die Reihenfolge der Aufgaben sinnvoll und die Prioritäten für die Developer nachvollziehbar waren. Sowohl der Scrum Master als auch der Product Owner waren jederzeit bereit, die Developer auch außerhalb der Meetings bei Fragen zu unterstützen. Dies wurde auch aus den Retrospectiven von den Developern als positive Rückmeldung gegeben und führte im Team zu einer positiven Stimmung und höheren Motivation.

Nachdem ein Developer die Texte validiert hat, überprüfte der Product Owner erneut, somit wurde das Vier-Augen-Prinzip für das Validieren durchgeführt. Der Grund für dieses Vorgehen war, die Qualität der Texte aus verschiedenen Perspektiven zu sichern. Die Developer prüften die inhaltliche Korrektheit, während der Product Owner die kundenorientierte Sicht einbrachte. So wurden Fehler minimiert und stellte sicher, dass die Kundenanforderungen qualitativ erfüllt wurden. Ein Nachteil dieses Vorgehens war, dass es vor allem in den ersten Sprints dazu geführt hat, dass ein paar Validierungen nicht rechtzeitig zum Sprintende geschafft wurden. Ab dem 3. Sprint verbesserte sich jedoch das Zeitmanagement und durch die bessere Kommunikation untereinander hatte der Product Owner genügend Zeit, die Items zum Schreiben durchzulesen und dann die User Story abzunehmen.

Der Product Owner stellte im Laufe des Projektes fest, dass ein enger Kontakt mit dem Kunden ausschlaggebend ist. Nach dem Sprint Review am 08.06.2024 (2. Sprint) und dem Versenden der Leseprobe (nach dem 4 Sprint), war das Kunden Feedback sehr erforderlich und unerlässlich, um festzustellen welche Aspekte das Developer-Team noch nicht berücksichtigt hat, um den Wert des Produktes zu steigern. Die schnelle und geplante Entscheidungsfindung wurde in der Retrospective des 4. Sprints von den Developern als positive Eigenschaft des Product Owners geäußert.

1.1.3 Individuelle Erfahrungsbeschreibung zum Product Owner

Product Owner – Roshini

Im ersten Schritt haben wir gemeinsam als Team entschieden, wer welche Scrum-Rolle einnimmt. Meine Person agierte in diesem Projekt als Product Owner.

Meine Aufgaben als Product Owner haben bereits vor dem ersten Sprint begonnen, denn ich musste die Vorbereitungen für das Product Backlog und die Toolauswahl für das Sprint Planning und Product Backlog tätigen. Mein Ziel war es ein gemeinsames, visuelles, einfach bedienbares und kostenloses Tool zu finden. Außerdem war mir wichtig, dass auch Developer jederzeit eine Übersicht ihrer Items und den Fortschritt des Sprints sehen können. Nach Recherche und Vorstellung im Team haben wir das Azure DevOps Tool in Einsatz genommen.

Da ich zum ersten Mal in einem Scrum-Projekt tätig war und auch zum ersten Mal die Rolle Product Owner übernahm, habe ich mir im Vorhinein viele Gedanken gemacht, wie ich das Projekt am besten strukturieren soll, damit es agil läuft. In meiner bisherigen beruflichen Karriere habe ich bereits ein paar klassische Projekte geleitet, aber in der Rolle der Projektleiterin. Daraufhin war für mich die erste Aufgabe zu verstehen und auch zu Beginn eine Herausforderung zu differenzieren, was die Unterschiede zwischen Projektleitung und Product Owner sind. Damit ich im ersten Sprint nicht wie eine „typische Projektleiterin“ mit Autoritätsrolle agiere, habe ich den Developern sehr viel Freiraum gelassen. Nach diesem Sprint habe ich festgestellt, dass ich trotz des Pull-Prinzips und des Selbstmanagements der Developer die Items klar priorisieren muss, damit die Items erledigt werden und das Sprint- und Produktziel erreicht werden.

Außerdem lernte ich die Wichtigkeit der Produktvision in den Scrum Events besonders zu betonen, damit die Developer Bescheid wissen, was der Kunde erwartet, um die Anforderungen bestmöglich umzusetzen. Zusätzlich stellte ich den Mehrwert fest, vor jedem Sprint immer ein Sprintziel zu entwickeln und diese klar mit den Developern zu kommunizieren, damit auch hier die Developer Bescheid wussten, welchen Schwerpunkt sie in dem Sprint setzen mussten und somit auch die Qualität der Sprints immer besser wurden. Die Änderung meiner Einstellung, dass ich meinen Fokus auf den Produktwert gelegt habe, hat mir auf der folgenden Weise geholfen: Erstens flexibler auf Änderungswünsche vom Kunden zu reagieren. Zweitens ohne komplexe Umplanung, Änderungswünsche umzusetzen und drittens eine stärkere Kundenorientierung zu haben, da die ganze Konzentration auf das Produkt bzw. dessen Wert liegt und nicht parallel typische Projektleitungsaufgaben tätigen muss.

In meinen beruflichen Projekten waren die Teammitglieder bereits vor Projektstart festgelegt und bis zum Ende des Projektes gab es keine Personaländerungen. In unserem Projekt haben wir im 2.Sprint ein neues Teammitglied hinzubekommen, dass die Rolle des Developers übernahm. Hier stellte ich fest, dass ich in der Lage sein muss, schnelle und fundierte Entscheidungen zu treffen. Denn es war wichtig dem neuen Teammitglied eine Projekteinführung, Teamvorstellung, Product Backlog erläutern, bereits geleistete Arbeit, und den aktuellen Fortschritt vorzustellen. Im Nachhinein ist mir das meiste auch gelungen, jedoch realisierte ich anhand der Fragen, dass ich z. B. keine ausführliche Einführung in das verwendete Tool „Azure DevOps“ gegeben habe und ich manchmal auch aktiv nachfragen musste, ob Probleme bestehen, um diese Hindernisse schnellstmöglich zu erkennen und zu lösen. Durch diese Erfahrung adaptierte ich das Vorgehen die Developer in den Scrum Events oder per WhatsApp zu fragen, ob die Items inhaltlich verständlich sind bzw. ob es während der Umsetzung inhaltliche Probleme aufgetaucht sind, damit dieses keinen negativen Einfluss auf den Produktwert haben. Außerdem habe ich festgestellt, wie wichtig es ist, dass die Developer sehen, dass ihre Arbeit direkt zum Erfolg des Produkts beiträgt und selbst reflektieren, um eine kontinuierliche Verbesserung zu ermöglichen.

Ich hatte nicht jede Woche Kontakt mit dem Kunden, dies hat jedoch aus meiner Sicht gereicht, da der Kunde in entscheidenden Momenten eingebunden war. Beispielweise war es mir wichtig, dass nach dem Schreiben der Theorie und nach der Rückmeldung von der Leseprobe mit dem Kunden die Punkte persönlich zu besprechen. Durch die direkte Kommunikation, wo die Developer auch im Termin waren, hat es mir geholfen Missverständnisse zu klären und durch die wertvolle Rückmeldung, auf die Wünsche im Product Backlog schnell zu agieren, um die Qualität des Buches zu verbessern.

Außerdem würde ich empfehlen, wenn man zum ersten Mal als Product Owner tätig ist eine Schulung bzw. das Product Owner-Zertifikat zu machen, damit man ein Grundverständnis von Scrum-Projekten hat und somit von Anfang an die Scrum Mentalität hat.

Scrum Master – Hai Trien

Bevor unsere Sprints beginnen konnten, haben wir als Scrum-Team unseren Product Owner ausgewählt. Demnach haben wir Roshini als unser Product Owner gewählt. Sie hatte zu Beginn des Projektes sehr viele Aufgaben gehabt, bevor der 1. Sprint richtig anfangen konnte. Zuerst hat unser Product Owner sich überlegt mit welchem Tool wir arbeiten sollten und nach der gemeinsamen Entscheidung für das Tool Azure DevOps, hat sie die ersten Epics, basierend auf den Anforderungen des Kunden erstellt. Anschließend hat sie daraus die Items und User Stories heruntergebrochen. Durch die gute Vorbereitung und Erstellung der User Stories konnten die Developer direkt zu Beginn des 1. Sprints mit dem Sprint Planning anfangen. Bei Fragen stand unser Product Owner immer zur Seite und konnte die Herausforderungen direkt lösen.

Unser Product Owner war immer sehr hilfsbereit und vorbereitet für das Sprint Planning. Dadurch, dass sie immer sehr offen auf neue Ideen und Meinungen war, waren alle Developer damit einverstanden, dass sie zu den Meetings, die nur die Developer betrifft, dazu kommt.