Durchführung eines Projekts mit der agilen Methode Scrum

Inhaltsverzeichnis

I. Hinweis zur gendergerechten Sprache

II. Abbildungsverzeichnis

III. Abkürzungsverzeichnis

1. Einleitung
1.1 Ausgangssituation und Problemstellung der Fallstudie 3
1.2 Aufbau der wissenschaftlichen Arbeit

2. Durchführung des Projekts mit der agilen Methode Serum
2.1 Rollenverteilung in Serum
2.2 Planung der Kapazitäten
2.3 Erstellung des Projektplans nach Serum

3. Serum Artefakte
3.1 Product Backlog
3.2 Sprint Backlog
3.3 Sprint Burndown Chart
3.4 Product Increment
3.5 Serum Board

4. Serum Events
4.1 Sprint Planning
4.2 Daily Serum
4.3 Sprint Review
4.4 Sprint Retrospektive

5. Projektergebnis undZielerreichung

6. Zusammenfassung und Ausblick

IV. Glossar

V. Literaturverzeichnis

VI. Anlagenverzeichnis

I. Hinweis zur gendergerechten Sprache

Aus Gründen der besseren Lesbarkeit wird bei Personenbezeichnungen und personenbezogenen Hauptwörtern in dieser wissenschaftlichen Arbeit die männliche Form verwendet. Entsprechende Begriffe gelten im Sinne der Gleichbehandlung grundsätzlich für alle Geschlechter. Die verkürzte Sprachform hat nur redaktionelle Gründe und beinhaltet keine Wertung.

II. Abbildungsverzeichnis

Abbildung 1: Darstellung derProjektkapazitäten. Quelle: Eigene Darstellung (2022)

Abbildung 2: Ausschnitt aus dem Projektplan nach Serum in Microsoft Excel. Quelle: Eigene Darstellung (2022)

Abbildung 3: Darstellung derAnforderungen im Product Backlog in Jira. Quelle: Jira. kostenlose Testversion von https://de.atlassian.com/software/jira (2022)

Abbildung 4: Darstellung des Sprint Burndown Charts in Jira. Quelle: Jira. kostenlose Testversion von https://de.atlassian.com/software/jira (2022)

Abbildung 5: Darstellung des Serum Boards in Jira. Quelle: Jira. kostenlose Testversion von https://de.atlassian.com/software/jira (2022)

Abbildung 6: Rollenverteilung in Serum Quelle: Eigene Darstellung (2022)

Abbildung 7; Darstellung derRessourcen des Serum Teams. Quelle: Eigene Darstellung(2022)

Abbildung 8: Darstellung derScrum Team Normen. Quelle: Eigene Darstellung (2022)

Abbildung 9: Darstellung des Projektplans I. Quelle: Eigene Darstellung (2022)

Abbildung 10: Darstellung des Projektplans II. Quelle: Eigene Darstellung (2022).

Abbildung 11: Darstellung des Product Backlogs in Jira. Quelle: (Jira. Kostenlose Testversion von https://de.atlassian.com/software/jira 2022)

Abbildung 12:Anforderungen an die "Definition ofDone". Quelle: Eigene Darstellung in Anlehnung an Leading Agile (2022)

Abbildung 13: Darstellung des Vorgangs zurLieferung eines Increments. Quelle: Agile Methodology stigasoft.com/agile-scrum-methodology (2022)

Abbildung 14: Darstellung des Release Burndown Charts in Jira. Quelle: Jira. Kostenlose Testversion von https://de.atlassian.com/software/jira (2022)

Abbildung 16: Hinzufügen von Product BacklogAnforderungen in den Sprint Backlog. Quelle: Jira. Kostenlose Testversion von https://de.atlassian.com/software/jira (2022)

III. Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

In diesem Teil der Arbeit wird die Situation des fiktiven Software-Unternehmens "Waterfall" der vorliegenden Fallstudie 3: Durchführung eines Projekts mit der agilen Methode Serum beschrieben. Anschließend folgt eine Vorstellung derweiteren Struktur derArbeit.

1.1 Ausgangssituation und Problemstellung der Fallstudie 3

In der Fallstudie 3 wird das fiktive Unternehmen "Waterfall" behandelt. Das renommierte und traditionell ausgerichtete Unternehmen ist in der Software-Entwicklung tätig und stellt ihre Produkte für B2B Kunden zur Verfügung. Die bisherige Arbeitsweise weist für die Durchführung der Software­Entwicklungs-Projekte einen Mangel an Flexibilität auf. Um den Anforderungen der Projekte in einem sich schnell ändernden Umfeld gerecht zu werden, hat sich das Unternehmen dafür entschieden, zukünftig die Serum-Methode zu verwenden.

Serum ist ein Rahmenwerk, welches von Schwaber und Sutherland in den 1990er-Jahren entwickelt wurde und mit dessen Hilfe komplexe adaptive Aufgabenstellungen gelöst werden können. Durch Serum werden Nutzer in die Lage versetzt, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern (vgl. Schwaber, Sutherland 2020, S. 1). Das Unternehmen hat sich entschieden, den erfahrenen Scrum Master Christopher Knoll zur Durchführung des Projekts zu berufen.

1.2 Aufbau der wissenschaftlichen Arbeit

In der Einleitung wurde ein Überblick über die Problemstellung der Fallstudie gegeben. In dem anschließenden Hauptteil erfolgt die Durchführung des Projekts mithilfe des Serum Prozesses. In Kapitel zwei wird die Planung des Projekts dargestellt, die sich u.a. aus der Planung der Kapazitäten, sowie der Formulierung eines Projektplans zusammensetzt. Der neue Prozess soll ermöglichen, dass zukünftige Projekte auf Basis der Erfahrungen im Anschluss durchgeführt werden können. Im darauffolgenden dritten Kapitel werden die dafür notwendigen Hilfsmittel erstellt. Im vierten Kapitel wird ein Einblick in die Meetings gegeben, welche eine effiziente Zusammenarbeit des Scrum Teams ermöglichen. In Kapitel fünf wird das Projektergebnis und die Zielerreichung dargestellt. Im letzten Kapitel folgt eine Zusammenfassung der Inhalte, sowie einem Ausblick für das Unternehmen.

2. Durchführung des Projekts mit der agilen Methode Serum

2.1 Rollenverteilung in Serum

Das Projektteam der agilen Methode Serum ist für die Lieferung des Produkts, sowie deren Qualität und Umfang verantwortlich. Das Team besteht aus verschiedenen Rollen, die in enger Zusammenarbeit für den Erfolg des Projekts verantwortlich sind (vgl. Pichler 2008, S. 13 ff.). Anlage 1 stellt diese Rollen grafisch dar.

Product Owner

Der Product Owner Pedro Produ ist ergebnisverantwortlich für die Maximierung des Wertes, der sich aus der Arbeit des Scrum Teams in Form des Produkts ergibt. Pedro Produ war in der Vergangenheit als Produktmanager im Unternehmen "Waterfall" tätig. In seiner neuen Verantwortung als Product Owner fokussiert er seine Anstrengungen auf die Software-Entwicklung. Dabei agiert er in enger Zusammenarbeit mit unterschiedlichen Stakeholders Die Anforderungen der Kunden an das Produkt werden im Unternehmen durch den Bereich Marketing ermittelt und durch den Product Owner im Product Backlog verwaltet. Weiterhin liegt das Erreichen der Projektziele in der Verantwortung des Product Owners, er entscheidet während des Entwicklungszeitraums über Zeitpunkt der Auslieferung, sowie den Umfang der Funktionalitäten. Dabei vermittelt er dem Serum Team ein Verständnis der Anforderungen, indem er es durchgehend mit detaillierten Informationen versorgt.

Serum Master

Der Serum Master Christopher Knoll hat in seiner Rolle als laterale Führungskraft die Aufgabe, dass Team bei der richtigen Anwendung der Serum-Methode zu unterstützen und Hindernisse, die im Laufe des Entwicklungszeitraums auftreten und die Effizienz gefährden, zu beseitigen. Weiterhin unterstützt er die Teammitglieder in ihrem Selbstmanagement und der Zusammenarbeit im Team. Jedoch besitzt er keinen Einfluss auf die Tätigkeiten wie der Festlegung der Anforderungen noch deren Umsetzung. Er fungiert daher überwiegend als Moderator und Coach, dessen Aufgabengebiet auch die Einführung von Serum im Unternehmen beinhaltet. Diese Aufgabe ist gerade in Organisationen, in denen das agile Modell neu implementiert wird, von großer Bedeutung (vgl. Pichler2008, S. 19ff.).

Scrum Team

Das Scrum Team ist verantwortlich für die Tätigkeiten, die zum Erreichen der Anforderungen in auslieferbare Produktinkremente notwendig sind. Das Scrum Team kann aus einer interdisziplinären Gruppe von Mitarbeitern bestehen und neben den Entwicklern auch aus Mitarbeitern anderer Unternehmensbereiche stammen. In dem Fall von "Waterfall" besteht das Scrum Team aus den Entwicklern Bea Backender, Lina Lux und Dennis Data. Die Teammitglieder Bea Backender und Dennis Data haben bereits Erfahrung mit der Serum-Methode, Lina Lux arbeitete bisher nur in plangesteuerten Projekten.

Im Vergleich zur bisherigen Arbeitsweise nach dem Wasserfall-Prinzip organisieren sich die Mitarbeiter des Scrum Teams eigenständig und entscheiden, welche Anforderungen aus dem Backlog in der nächsten Iteration bearbeitet werden. Damit ein Team effektiv zusammenarbeitet, ist es erforderlich, dass es sich auf gemeinsame Normen einigt. Viele dieser Normen werden typischerweise von dem Team selbst formuliert. Anlage 2 zeigt die formulierten Normen, die das Scrum Team vor Start des Projekts definiert hat.

2.2 Planung der Kapazitäten

Während des Projekts stehen drei Entwickler zur Verfügung, diese sind räumlich nicht voneinander getrennt. Während die Entwickler Dennis Data und Bea Backender Vollzeit zur Verfügung stehen, (40 Std./ Woche) ist die Entwicklerin Lina Lux begrenzt (32 Std./ Woche) verfügbar. Der Abwesenheitstag der Mitarbeiterin findet zur vereinfachten Planung jeden Freitag einer Woche statt (vgl. Anlage 3).

Der Zeitraum für die Projektentwicklung wird durch die Dauer von Sprints determiniert. Ein Sprint bezeichnet ein Event mit fester Länge, um Einheitlichkeit zu wahren. Laut dem offiziellen Serum Guide kann sich der Zeitraum bis zu einem Monat erstrecken. Während des Sprints werden alle Tätigkeiten zur Erfüllung des Produkt-Ziels geleistet. Laut den Projektzielen und den daraus ermittelten Anforderungen, soll die Sprintdauer für das Projekt 14 Tage betragen. Die Kunden erhalten dadurch in zweiwöchigen Zyklen Produktupdates in Form von Software geliefert. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Darstellung der Projektkapazitäten. Quelle: Eigene Darstellung (2022)

Aus Abbildung 1 lassen sich die Kapazitäten für das Entwicklerteam entnehmen. Es ergeben sich für das Gesamtprojekt 280 Personentage, die auf insgesamt 10 Sprints aufgeteilt werden. Diese Gesamtzeit verringert sich jedoch aufgrund unvorhersehbarer Unterbrechungen, wie z.B. das Auftreten von Tätigkeiten aus dem erweiterten Aufgabenfeld des Projektteams, welche keinen Bezug zu dem Projekt haben. Unterbrechungen dieser Art sollten vermieden werden, treten in der Realitätjedoch häufig auf.

Um trotz dieser Unterbrechungen eine erfolgreiche Terminplanung festzulegen, wird eine Pufferzeit einberechnet.

Aufder Basis von Erfahrungen aus vorherigen Projekten, geht man davon aus, dass in klassischen Projektorganisationen ein Puffer von ca. 50% in den Aufwänden einberechnet ist. Dies ergibt eine Kapazität von insgesamt 140 Personentagen.

Die reale Verfügbarkeit ist abhängig von der Erfahrung des Projektteams, in Organisationen, die auf Erfahrungen mit Serum zurückblicken können, kann der Puffer auch weniger ausgeprägt sein. Da

3 im Fall von "Waterfall" das agile Vorgehen erstmalig in Verwendung ist, wird trotz der Serum Erfahrung einiger Teammitglieder mit einem Puffer von 50% geplant. Dieser Puffer kann während des Projektverlaufs an sich veränderte Bedürfnisse angepasst werden (vgl. Pichler2008, S. 14 ff.).

2.3 Erstellung des Projektplans nach Serum

Auf Basis der neuen Arbeitsweise nach Serum, wird ein Projektplan für das Projekt mit dem Titel "Softwarelieferung NoFall" erstellt, als Projektstart wird der 01.03.2021 festgelegt. Im Vergleich zu den bisherigen plangesteuerten Maßnahmen beinhaltet das Projekt eine Abfolge von 10 Sprints, dabei führt das Ende eines Sprints zum Start der neuen Iteration. Abbildung 2 beinhaltet einen Ausschnitt aus dem Projektplan, welcher in Anlage 4 vollständig abgebildet wurde.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Ausschnitt aus dem Projektplan nach Serum in Microsoft Excel. Quelle: Eigene Darstellung (2022)

3. Serum Artefakte

Während der Durchführung eines Projekts mithilfe der Serum-Methode, stehen der Projektleitung unterschiedliche Mittel zur Gestaltung der Prozessdokumentation zur Verfügung, diese Hilfsmittel werden als Artefakte bezeichnet. Die Artefakte ermöglichen es, den Projektverlauf nachvollziehbar zu gestalten und zu visualisieren. Dies ermöglicht eine strukturierte Arbeitsweise und einen stetigen Informationsfluss gegenüber den jeweiligen Stakeholdern (vgl. Hevner et al. 2004, S.75 ff.).

3.1 Product Backlog

Das Product Backlog ist das zentrale Dokument in Serum und fungiert als Speicher für alle priorisierten Anforderungen, die zur Zielerbringung des Projekts benötigt werden. Der Product Ownerfügt neueAnforderungen hinzu und entfernt nicht weiter benötigte (Backlog Grooming). Das Product Backlog ist weiterhin ein dynamisches Dokument und obliegt während der Durchführung

4 des Projekts dauerhaft Änderungen und Anpassungen. Die Anforderungen werden mithilfe von kurzen Geschichten in Anwenderform (User-Stories) definiert, der Verzicht von fachspezifischen Ausdrücken ermöglicht ein eindeutiges Verständnis bei allen Stakeholders Neben den Anforderungen an das Produkt, enthält das Product Backlog auch Aufgaben zur Verbesserung der Projektprozesse, der Reduzierung und dem Abbau von technischen Schulden, die aufgrund mangelhafter Umsetzung entstehen können (vgl. Schwaber, Sutherland 2020, S. 11). In den frühen Phasen der Verwendung von Serum wird in Unternehmen oft auf Excel zurückgegriffen, um in einer Liste die Anforderungen einzupflegen. Da sich bei "Waterfall" direkt um die Software Jira bemüht wurde, wird während des Projekts die Funktionalität des Backlogs verwendet. Anlage 5 gibt einen Einblick in die Auflistung derAnforderungen an das Produkt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Darstellung derAnforderungen im Product Backlog in Jira. Quelle: Jira. kostenlose Testversion von https://de.atlassian.com/software/jira (2022)

Die Abbildung 3 zeigt beispielhaft, welche in welcher Form die Anforderungen erstellt werden. Eine Anforderung wird im Backlog anhand einer priorisierten Rangordnung (Very High/ High/ Medium/ Low) aufgelistet und mit einer eindeutigen "ID" versehen. Das Feld "Rolle" beschreibt welche Anwendersicht die Anforderung nach der Umsetzung vertritt. Die Auswahl "Funktionalität" oder "Feature" beschreibt in kurzer Form den Inhalt des zu umsetzenden Wertes. Das "Ziel" stellt eine Begründung für die Umsetzung der Funktionalität dar, hier wird auf die Zweckerfüllung eingegangen.

Als "Akzeptanzkriterien" werden zuvor definierte Regeln bezeichnet, anhand derer eine Anforderung als erfüllt bezeichnet werden kann. Diese werden im Rahmen von Serum auch als "Definition of Done" bezeichnet und dienen als Standard der Organisation. Da "Waterfall" zum ersten Mal mit der agilen Methode arbeitet wird dieser Organisationsstandard erstmalig durch das Scrum Team in Anlage 5 festgelegt (vgl. Anlage 5). Die "Priorität" beschreibt die Notwendigkeit der Anforderung, um die Einschätzung anhand von quantifizierbaren Merkmalen bewerten zu können, wird eine Risiko­Wert-Matrix verwendet. Durch diese erhält das Projektteam einen Indikator, bis wann die Umsetzung vollzogen werden soll. Der Ersteller ("Erstellt von") der Anforderung ist der jeweilige Stakeholder, der diese festgelegt hat, zwar pflegt nur der Product Owner Herr Produ alle Anforderungen, jedoch kann so bei notwendigen Rückfragen auf den Verfasser zurückgegriffen werden. Als Story Points bezeichnet man eine Bewertung des Aufwands der Anforderung, auf Basis der Fibonacci-Zahlen­Reihe kann eine Gewichtung der Komplexität der Umsetzung klassifiziert werden (vgl. Sutherland & Schwaber2020, S. 13).

3.2 Sprint Backlog

Das Sprint Backlog wird durch das Entwicklerteam erstellt und beinhaltet alle Anforderungen, die während eines Sprints abgearbeitet werden. Das Sprint Backlog wird zu Beginn einer Iteration formuliert und an jedem Arbeitstag aktualisiert. Damit wird eine genaue Verfolgung der Sprintaktivitäten ermöglicht. Das Vorgehen beinhaltet dabei zuerst die Auswahl der User-Stories aus dem Product Backlog, welche in dem Sprint umgesetzt werden sollen (vgl. Anlage 10). Anschließend wird bei hoher Komplexität die User-Story in einzelne Tasks rationalisiert (vgl. Schwaber 2004, S. 136ff.).

3.3 Sprint Burndown Chart

Durch das Sprint Burndown Chart wird der Arbeitsfortschritt während eines Sprints grafisch dargestellt. Es visualisiert, wie sich die Aufwände des Sprint Backlogs in Schritten von jeweils einem Tag entwickeln. Mithilfe dieses Tools wird die Projektleitung bei Überprüfung von Risiko und Projektfortschritten unterstützt. Somit können Stakeholder über die Fortschritte während eines Sprints informiert werden (vgl. Pichler2008, S 117ff.).

[...]