Leseprobe
Inhaltsverzeichnis
I. Hinweis zur gendergerechten Sprache
II. Abbildungsverzeichnis
III. Abkürzungsverzeichnis
1. Einleitung
1.1 Ausgangssituation und Zielsetzung des Projekts
1.2 Zielsetzung
2. Darstellung der Projektplanung
2.1 Definition der Stakeholder
2.2 Definition der Anforderungen und Projektdokumentation
2.3 Auswahl einer geeigneten agilen Methode
2.4 Darstellung der Risikoanalyse
2.5 Erstellung der Terminplanung
2.6 Planung der Projektkapazitäten
2.7. Vorstellung der Zwischenergebnisse und Managemententscheidung
3. Anpassung der Organisation an Scrum
3.1 Anpassung der Projektstrukturen an die agile Methode Scrum
3.2 Anpassung der Organisationsstruktur und Rollen
3.3 Anpassung der Managementartefakte an Scrum
3.4 Anpassung der Projekt-Meetings an Scrum
3.5 Durchführung der Schulungsmaßnahmen der Mitarbeiter
3.6 Durchführung des ersten agilen Durchlaufs nach Scrum
3.7 Abschluss des Projekts
4. Zusammenfassung und Ausblick
IV. Literaturverzeichnis
V. 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 7: Projektplan des Projekts K-3849. Quelle: Eigene Darstellung (2022)
Abbildung 8: Abbildung der Sprint Durchläufe 1 und 2. Quelle: Eigene Darstellung (2022)
Abbildung 13: Eigene Darstellung des Product Backlogs in Jira. Quelle: Jira. kostenlose Testversion von https://de.atlassian.com/software/jira (2022)
Abbildung 14: Eigene Darstellung des Sprint Backlogs in Jira. Quelle: Jira. kostenlose Testversion von https://de.atlassian.com/software/jira (2022)
Abbildung 16: Darstellung des Scrum Boards in Jira. Quelle: Jira. kostenlose Testversion von https://de.atlassian.com/software/jira (2022)
Abbildung 17: Darstellung des Ausschnitts der Sprint Retrospective Protokolls. Quelle: Eigene Darstellung
Abbildung 1: Ausschnitt aus der Stakeholder Analyse des Projekts K-3849. Quelle: Eigene Darstellung (2022)
Abbildung 2: Agenda des LCS Workshops. Quelle: Eigene Darstellung (2022)
Abbildung 3: Ergebnisse der Brainstorming Runde. Quelle: Eigene Darstellung (2022)
Abbildung 4: Ergebnisse der agilen Methodenbewertung. Quelle: Eigene Darstellung (2022)
Abbildung 5: Ergebnisse der Risikoanalyse. Quelle: Eigene Darstellung (2022)
Abbildung 6: Darstellung der Projektkapazitäten. Quelle Eigene Darstellung (2022)
Abbildung 9: Darstellung der ursprünglichen Organisationsstruktur LCS. Quelle Eigene Darstellung (2022)
Abbildung 10: Darstellung der geplanten Organisationsstruktur LCS. Quelle: Eigene Darstellung (2022)
Abbildung 11: Darstellung der Rollen in Scrum. Quelle: Eigene Darstellung (2022)
Abbildung 12: Darstellung der Normen des Scrum Teams. Quelle: Eigene Darstellung (2022)
Abbildung 15: Darstellung der Definition of Done. Quelle: Eigene Darstellung
Abbildung 18: Darstellung des Vorgangs zur Lieferung eines Increments. Quelle: Agile Methodology stigasoft.com/agile-scrum-methodology (2022) xiv
III. Abkürzungsverzeichnis
c.a circa
et al. et alii
ff. fortfolgend
Std. Stunden
S. Seite
u.a unter anderem
vgl. vergleiche
z.B. zum Beispiel
1. Einleitung
1.1 Ausgangssituation und Zielsetzung des Projekts
In dem vorliegenden Projektbericht wird das fiktive Unternehmen Getränke-Maschinen AG behandelt. Die Getränke-Maschinen AG ist ein deutscher börsennotierter Hersteller von Anlagen und Maschinen für die Herstellung, Abfüllung und Verpackung von Getränken und flüssigen Nahrungsmitteln in PET- und Glasflaschen sowie Getränkedosen mit Sitz in Neutraubling. Neben der Herstellung der Anlagen und Maschinen ist ein Hauptaugenmerk des Unternehmens der After-Sales-Bereich, auch Getränke-Maschinen-Lifecycle Service genannt. In der Vergangenheit wurden Produktupdates für die Maschinen manuell während der jährlichen Überholung durch Servicepersonal durchgeführt (vgl. Getränke-Maschinen AG 2022). Durch die technologischen Veränderungen haben sich auch die Anforderungen der Kunden an die Leistungen ihrer Maschinen und Produktionslinien verändert. Kunden fordern daher regelmäßige Softwareupdates für ihre Produkte und die Getränke-Maschinen AG wird mehr denn je unter Druck gesetzt. Auch der Wettbewerb kann aufgrund seiner schnellen Entwicklungszyklen in regelmäßigen Abständen Neuheiten für die Kunden bieten. Die Entwicklungsprojekte im Bereich Lifecycle Service wurden bisher mithilfe von plangesteuerten Projektmanagementmethoden der Wasserfall-Methode abgewickelt, um die Position als Marktführer weiterhin verteidigen zu können, sieht das Management die Notwendigkeit, die Entwicklung auf eine Agile Methode umzustellen.
1.2 Zielsetzung
Um den terminlichen Anforderungen der Kunden gerecht zu werden, sollte den Kunden in iterativen Vorgehensmodell in vierwöchigen Abschnitten Produktupdates für ihre Maschinen geliefert werden. Das Management des After-Sales-Bereichs der Getränke-Maschinen AG entschied sich dafür, dass dieses Ziel bestmöglich mit der Umstellung von der Wasserfall- auf eine agile Methode sei. Dafür musste ein passendes iteratives Vorgehensmodell ausgewählt, die Meetings und Projektmanagement Hilfsmittel angepasst werden. Bisher wurden Produktupdates aus den Abteilungen New Machine, Digital Products, sowie Line Experts entwickelt und bereitgestellt. Um eine strategische Steuerung der Entwicklung Produktupdates zu gewähren, wurde eine Veränderung der Organisationsstruktur beschlossen. Die Entwickler aus den genannten Abteilungen sollten in die Organisation Product Management Lifecycle Service versetzt werden.
2. Darstellung der Projektplanung
Zur Umsetzung des Projektes wurde eine gründliche Planung vorausgesetzt. Die Getränke-Maschinen AG hatte für alle Projekte unternehmensweite Rahmenbedingungen bestimmt, die erfüllt werden mussten. So wurden bei den Vertretern des Managements die Themen Termin und Budgetplanung, sowie die Berücksichtigung der Risiken vorgelegt. Erst dann konnte der weitere Projektverlauf eingeleitet werden. Von einer Machbarkeitsstudie wurde in dem vorliegenden Projekt aufgrund der strategischen Bedeutung des Projekts abgesehen. Im Unternehmen wurde vor dem Projektstart die Abteilung Operational Excellence etabliert. Diese beschäftigte sich mit der Analyse, sowie Transformation bestehender Abteilungen und deren Arbeitsweisen. Die zuständigen Experten waren neben anderen Aufgaben auch Agile Coaches und wurden für das Projekt zur Unterstützung einberufen.
2.1 Definition der Stakeholder
Unternehmen befinden sich in einem Geflecht aus Personengruppen mit verschiedenen Interessen, diese werden Stakeholder genannt. Gerade in Kundenprojekten gibt es unterschiedliche Personen, sowohl intern als auch extern, die von der Umsetzung des Projekts betroffen sind und deshalb ihre Meinung im Verlauf vertreten wollen. Zu den typischen Stakeholdern gehören daher neben der Geschäftsleitung eines Unternehmens auch Kunden, Mitarbeiter oder Lieferanten (vgl. Baptist, 2008, S. 8ff).
Das Ergebnis war eine Stakeholder Tabelle, welche die Interessen, Motivation und Aktivitäten zur Bedürfnisbefriedigung beinhaltete. In Anlage 1 ist ein Ausschnitt aus der Tabelle zu sehen.
2.2 Definition der Anforderungen und Projektdokumentation
Während der Projektphasen war das Projektteam aufgrund der pandemischen Lage weitgehend auf virtuelle Kommunikationsmittel angewiesen. Einige Meetings konnten jedoch vor Ort abgehalten werden, um in Workshops projektbezogene Aufgabenstellungen zu erarbeiten (vgl. Anlage 2). Durch die zur Hilfenahme von unterschiedlichen Lösungsansätzen wie Befragungen, Brainstorm/- und Kreativitätstechniken konnte durch eine effektive Zusammenarbeit des Projektteams und der Stakeholder eine Ergebnislage für die nächsten Schritte erzielt werden. Die Projektleitung dokumentierte die Ergebnisse und verfasste geeignete Lasten/- und Pflichtenhefte nach den Anforderungen des Unternehmens.
2.3 Auswahl einer geeigneten agilen Methode
Während eines Stakeholder Workshops konnte, bereits in einer Brainstorming Runde der Beitrag der betroffenen Interessensvertreter eingeholt. Anlage 3 verdeutlicht die Ergebnisse der Bewertung durch die Teilnehmer. Die Experten der Abteilung Operational Excellence übernahmen in dem Workshop eine präsentierende und moderierende Rolle. Aufgrund ihrer Erfahrung konnten sie den Teilnehmern detaillierte Informationen über die Methoden, sowie die Umsetzbarkeit in dem vorliegenden Projekt näherbringen.
Kanban
Kanban ist ein beliebtes Mittel für die Umsetzung der agilen Softwareentwicklung. Es findet häufig Anwendung in Optimierung von Workflows in der Produktion von Automobilherstellern, wo sie auch seinen Ursprung. Gerade die Stakeholder, die in der Produktion der Maschinen tätig waren, schätzten dieses Konzept als sehr sinnvoll ein. Es erfordert die Kommunikation von Kapazitäten in Echtzeit und volle Transparenz der Arbeit. Die Arbeitsaufgaben werden visuell auf einer Kanban-Tafel dargestellt, so dass die Teammitglieder jederzeit den Stand jeder Arbeit sehen können (vgl. Atlassian 2022).
Lean
Lean ist definiert als eine Reihe von Managementpraktiken zur Verbesserung von Effizienz und Effektivität. Das Kernprinzip von Lean ist die Reduzierung und Beseitigung von nicht wertschöpfenden Tätigkeiten und Verschwendung.
Es verbessert die traditionellen Produktentwicklungsprozesse, indem es die Kommunikationssilos beseitigt, die normalerweise die Abteilungen trennen (vgl. Refa Lexikon 2022).
Extreme Programming
Extreme Programming (XP) zielt darauf ab, eine höhere Produktqualität zu erreichen. XP ist das spezifischste der und agilste Form der bekannten Frameworks in Bezug auf geeignete technische Praktiken. Von den Entwicklern und den Stakeholdern wird ein hoher Erfahrungsschatz zur Umsetzung benötigt (vgl. Agile Heroes 2022).
Scrum
In Scrum werden die Lieferzyklen als "Sprints" bezeichnet und dauern im Allgemeinen eine bis vier Wochen. Die Arbeit erfolgt schrittweise und baut auf der vorherigen Arbeit auf. Scrum-Teams sind in der Regel klein und bestehen aus drei bis neun Personen, darunter ein Scrum Master und ein Product Owner. Die Kommunikation mit den Teammitgliedern und den Interessenvertretern erfolgt kontinuierlich, so dass ein ständiges Feedback erfolgt und entsprechende Änderungen vorgenommen werden können (vgl. Schwaber, Sutherland 2020, S. 1 ff.). Auf Basis der Anforderungen durch das Kundenumfeld und den Wettbewerbern, sowie den Erkenntnissen aus den Stakeholder Meetings, wurde beschlossen die Scrum-Methode zu verwenden. Ein weiterer Grund für die Wahl von Scrum war die Vorerfahrung einiger zukünftiger Teammitglieder mit Scrum, sowie die Unterstützung der Agilen Coaches aus der Abteilung Operational Excellence.
2.4 Darstellung der Risikoanalyse
Nach erfolgreicher Auswahl der agilen Methode, wurde im nächsten Schritt eine Analyse der Risiken durchgeführt. Risiken können den Erfolg des Projektes bedrohen, daher ist eine Risikoanalyse ein fester Bestandteil des Projektmanagements. Bei der Risikoanalyse wurde eine Einschätzung, Bewertung und Priorisierung der möglichen Risiken durchgeführt. Die Analyse ist eine wiederkehrende, iterative Arbeit, die während des Projekts fortgeführt wird, sobald nicht vorhergesehene Probleme auftreten. Zur Bewertung wurde auf die Hilfsmittel der Abteilung des Projektmanagements zurückgegriffen (vgl. Anlage 4).
Da vereinzelte Mitarbeiter bisher noch keine Erfahrung mit Scrum hatten, stellte ein Risiko den Verzug der Produktupdates aufgrund Ineffizienz dar. Dies konnte sich negativ auf die Kundenzufriedenheit auswirken. Ein weiterer Aspekt war der mögliche Ausfall des Projekts. Aufgrund der agilen Entwicklungszyklen von Scrum sollte eine möglichst zügige Rückkehr zur bewährten Arbeitsweise offengehalten werden. Deshalb konnten die potenziellen Kosten bei einer erneuten Umstellung in Kauf genommen werden.
Durch die geplanten Organisationsveränderungen mussten einige betroffene Mitarbeiter die Abteilung wechseln. Aufgrund der Veränderungen wurde mit Widerständen und Unzufriedenheit bei einigen Mitarbeitern gerechnet. Ein interner Wechsel oder gar ein Ausstieg aus dem Unternehmen hätte einen besonderen Verlust dargestellt. Eine frühzeitige und offene Kommunikation mit den Mitarbeitern wurde daher als besonders wichtige Maßnahme bemessen.
2.5 Erstellung der Terminplanung
In der Getränke-Maschinen AG werden Projekte durch einen Titel mit einer einheitlichen Beschreibung bezeichnet. Das Projekt „Entwicklung der Produktupdates mit Scrum“ erhielt den Titel K-3849.
Für das Projekt wurde ein Terminplan erstellt, welcher in zwei Phasen aufgeteilt wurde. Die erste Phase beinhaltete die bisherige Planungsphase, die zweite Phase enthielt die Umsetzungsphase mit einem Go-Live Termin am 01.03.2021. Im Rahmen der Terminplanung wurde zusätzlich eine Kalkulation der möglichen Projektkapazitäten nach der Umstellung auf die agile Methode durchgeführt (vgl. Anlage 5).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7: Projektplan des Projekts K-3849. Quelle: Eigene Darstellung (2022)
2.6 Planung der Projektkapazitäten
Für das Projekt K-3849 entstanden sowohl interne als auch externe Kosten. Der Großteil der Kosten stellte dabei die internen Aufwände dar. Mithilfe der Terminplanung konnte eine Abschätzung der Aufwände dokumentiert werden. Alle Mitarbeiter, die Leistungen im Rahmen des Projekts erbrachten, haben ihre Aufwände auf das Projekt verbucht. Somit konnte nach Abschluss des Projekts eine Bewertung des Erfolgs des Projektes durchgeführt werden. Neben den internen entstanden auch externe Kosten. Um die Updates der Maschinen der Kunden durchführen zu können, mussten diese über ein verschlüsseltes Global Remote System übermittelt werden. Für die Implementierung den Betrieb des Systems wurde bereits vor einigen Jahren ein externer Dienstleister zur Unterstützung beauftragt. Von einer Darstellung der Kostenstruktur des Projekts wird in diesem Bericht abgesehen.
2.7. Vorstellung der Zwischenergebnisse und Managemententscheidung
Bevor die Durchführungsphase des Projekts K-3849 eingeleitet werden konnte, wurden die bisherigen Ergebnisse vor einer Managementrunde präsentiert. Der Teilnehmerkreis bestand aus dem Projektleiter, dem Head of Product Management, Head of International Field Service, Head of Sales LCS Global, Head of New Machine und dem zuständigen Mitglied des Vorstands.
In dem Meeting wurden die bisherige Budgetplanung, die Analyse der Risiken des Projekts und die weiteren Schritte der Terminplanung besprochen und von allen Teilnehmern bestätigt.
Die notwendige Veränderung der organisationalen Strukturen führten zu größeren Diskussionen. Wie in Anlage 6 und Anlage 7 dargestellt wird, sollte der Bereich von dem Head of Product Management einen Zuwachs von fünf Mitarbeitern erhalten, welche die Entwicklungstätigkeiten im zukünftigen Scrum Team übernehmen. Bisher bestand die Abteilung aus zwei Produktmanagern, einer der Produktmanager wird in seiner neuen Rolle als Product Owner das Team unterstützen. Die fünf Entwickler waren zuvor in den Bereichen New Machine Digital Products, sowie Line Experts tätig, wo sie bisherige Entwicklungstätigkeiten vollzogen.
Personalveränderungen gehen meist mit Widerständen auf Seiten der zuständigen Stakeholder, sowie der betroffenen Mitarbeiter einher. Im Rahmen der Managementrunde wurde die Bedeutung einer transparenten Kommunikation mit den Mitarbeitern bekräftigt und Maßnahmen zur bestmöglichen Integration der Mitarbeiter beschlossen.
3. Anpassung der Organisation an Scrum
3.1 Anpassung der Projektstrukturen an die agile Methode Scrum
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8: Abbildung der Sprint Durchläufe 1 und 2. Quelle: Eigene Darstellung (2022)
3.2 Anpassung der Organisationsstruktur und Rollen
Das Wasserfall-Prinzip ist einlineares Vorgehensmodell, das Entwicklungsprozesse in aufeinanderfolgende Projektphasen unterteilt. Dagegen erfolgt die Organisation des Teams nach dem Scrum Prinzip eigenständig. Das Scrum Team entscheidet, welche Anforderungen aus dem Product Backlog in der nächsten Iteration (Sprint) bearbeitet werden. Das Projektteam in Scrum ist verantwortlich für die Lieferung, Qualität und Umfang des Produkts. Das Team setzt sich dabei aus verschiedenen Rollen zusammen (vgl. Kaltenecker 2013, S. 44 ff.). Anlage 8 stellt diese Rollen grafisch dar.
Product Owner
Die Verantwortung des Produkts liegt in der Hand des Product Owners. Seine Aufgabe ist es den maximalen Wert des Produkts, welche sich durch die Erarbeitung des Scrum Teams ergeben. Dabei agiert er in enger Zusammenarbeit mit den Stakeholdern, um die Anforderungen für die Produktupdates der Kunden zu definieren. Diese Anforderungen werden im Product Backlog gesammelt und verwaltet. Durch den Product Owner wird alleinig entschieden, wann Funktionalitäten ausgeliefert werden und in welchem Umfang. Dabei hat er die Aufgabe, dem Scrum Team ein Verständnis der Anforderungen zu vermitteln.
Das Aufgabengebiet des Product Owners umfasste in der Vergangenheit die Betreuung von Produkten aus dem After-Sales-Bereichs. Mit der Verantwortung von Softwareprodukten und deren Entwicklung, sowie der Verwendung agiler Methoden, hatte er noch keine Vorerfahrungen. Daher wurde beschlossen, durch intensive Schulungsmaßnahmen und Unterstützung durch die agilen Coaches, den Product Owner über einen Zeitraum von sechs Monaten bestmöglich zu begleiten und auszubilden.
Scrum Master
Der Scrum Master hat die Aufgabe, das Scrum Team in ihrer Tätigkeit zu unterstützen und mögliche Hindernisse zu beseitigen. Weiterhin schult er das Scrum Team in Selbstmanagement und der Zusammenarbeit. Dabei hat er keinen Einfluss auf die Bestimmung der Anforderungen, oder die darauffolgende Umsetzung. Seine Funktion ist daher mit der eines Moderators und Coaches zu vergleichen (vgl. Pichler 2008, S. 18 ff.).
Da das Projekt mit einem begrenzten zeitlichen Horizont geplant war und im Unternehmen derzeit kein Scrum Master für die Rolle verfügbar war, musste eine Übergangslösung gefunden werden. Während der Projektumsetzung und der Durchführung der ersten Sprints, wurde hier auf die Ressourcen der Abteilung Operational Excellence in Form eines Interim-Scrum-Masters zurückgegriffen. Währenddessen wurde durch die Personalabteilung ein Auswahlverfahren in die Wege geleitet, um einen erfahrenen Scrum Master für das Team gewinnen zu können.
Scrum Team
Das Scrum Team ist verantwortlich für die Umsetzung der Anforderungen, welche in Form von fertigen Funktionalitäten ausgeliefert werden. Das Scrum Team ist ausgestattet mit den erforderlichen Kompetenzen und organisiert sich in den festgelegten Zeiträumen selbst.
Um für eine effektive Zusammenarbeit zu sorgen, ist es notwendig, sich auf gemeinsame Normen zu einigen. Diese Normen können als Unternehmensstandard in einem Unternehmen fest verankert sein. Im Fall der Getränke-Maschinen AG entwickelte das Scrum Team mit der Unterstützung der Abteilung Operational Excellence eigene Normen, die die zukünftige Zusammenarbeit bestimmt wurde (vgl. Anlage 9).
3.3 Anpassung der Managementartefakte an Scrum
Bei der Durchführung eines Projekts nach Scrum griff die Projektleitung auf verschiedene Hilfsmittel zur Erstellung der Prozessdokumentation zurück, diese werden als Artefakte gekennzeichnet. Mithilfe der Artefakte ist eine nachvollziehbare Darstellung des Projektverlaufs sowie eine Visualisierung der Projektstände für Stakeholder möglich. Gerade bei der hohen Anzahl von Stakeholdern in dem Projekt K-3849 war dies zwingend notwendig (vgl. Kaltenecker 2013, S.73 ff.).
Product Backlog
Unter dem Product Backlog versteht man einen zentralen Speicher für alle Anforderungen in priorisierter Reihenfolge, die zur Erfüllung des Produkterfolgs benötigt werden. Der Product Owner verwaltet die Anforderungen in dem Product Backlog, dies wird auch als Backlog Grooming bezeichnet. Um für ein einheitliches Verständnis der Anforderungen zu schaffen, wird von fachspezifischen Ausdrücken abgesehen. Weiterhin werden die Anforderungen als User-Stories in Anwenderform formuliert. Auch Verbesserungen von bestehenden Teilprojektprozessen und der Reduktion von technischen Schulden sind in dem Product Backlog enthalten. Die bestehenden Vorlagen und Dokumente, sowie Prozesse und Abläufe wurden von dem Product Owner in Zusammenarbeit mit der Abteilung Operational Excellence an die Bedürfnisse der Scrum Artefakte angepasst. Dabei wurde auch das Product Backlog mit Anforderungen an das Projekt und die Produktupdates durch den Input der Stakeholder befüllt. Auch die Tätigkeiten, die während der Umstellung auf Scrum nicht vorab geklärt werden konnten, wurden als Arbeitspakete in das Product Backlog integriert. Abbildung 13 zeigt einen Ausschnitt aus dem Product Backlog, welches durch Getränke-Maschinen in Jira aufgesetzt wurde. Da in anderen Bereichen des Unternehmens das Tool bereits seit längerer Zeit in Verwendung war, konnte ohne Mehrkosten auf bestehende Lizenzen zurückgegriffen werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 13: Eigene Darstellung des Product Backlogs in Jira. Quelle: Jira. kostenlose Testversion von https://de.atlassian.com/software/jira (2022)
[...]