Scrum Teams und Feature Teams im IT-Projektgeschehen. Eine vergleichende Analyse

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung und Relevanz der Arbeit
1.2 Ziel der Arbeit

2 Grundlagen
2.1 Einführung in das agile Projektmanagement
2.1.1 Definition und Herkunft des agiles Projektmanagements
2.1.2 Arbeitsweise von Scrum in IT-Projekten
2.1.2.1 Die Grundsäulen von Scrum
2.1.2.2 Der Scrum-Prozess mit beteiligten Rollen leicht erklärt
2.1.3 Development Team - die wichtigste Rolle in Scrum
2.2 Agile Skalierungsframeworks am Beispiel Large Scale Scrum (LeSS)
2.2.1 Definition und Einführung von LeSS
2.2.2 Grundelemente und Arbeitsweise von LeSS
2.2.2.1 Prinzipien
2.2.2.2 Struktur des LeSS-Frameworks mit beteiligten Rollen
2.2.3 Feature Teams - eine wichtige Komponente des Frameworks
2.3 Informationen zum betrachteten Projekt

3 Methodik
3.1 Experteninterview
3.1.1 Beschreibung der Methodik
3.1.2 Erarbeiteter Leitfaden für die Befragungen
3.1.3 Auswahl der Experten
3.2 Durchführung der Interviews
3.3 Auswertung der Experteninterviews
3.4 Darstellung der Ergebnisse aus den Experteninterviews

4 Fazit
4.1 Zusammenfassung der Erkenntnisse

Anhang

Anlagen

Literaturverzeichnis

Zusammenfassung

Seit 2009 ist der Umsatz der IT-Branche in Deutschland stetig gestiegen. Wurde 2009 noch ein Umsatz von knapp 64 Mrd. Euro erreicht, so stieg er in den letzten zehn Jahren um fast 30 Mrd. auf 92,9 Milliarden Euro (Stand: 2019). Mit knapp 42 Milliarden verbuchte die IT-Dienstleistungsbranche dabei den größten Erlös. Aufgrund durchgehend steigender Umsatzzahlen und dem damit zusammenhängenden Erfolg der deutschen IT-Branche ist es für Unternehmen des IT-Dienstleistungssektors umso wichtiger, die Projektarbeit innerhalb des Unternehmens anhand geeigneter Managementstrategien und Methoden so zu organisieren, dass optimale Ergebnisse erreicht werden, um langfristig auf dem IT-Markt Erfolge verzeichnen zu können und sich dadurch von konkurrierenden Unternehmen abzuheben.

Die Intention dieser Arbeit ist, ein agiles Projekt eines führenden IT- Dienstleistungsunternehmens zu analysieren und dabei den Fokus auf die Arbeitsweise des Entwicklungsteams zu legen. Da das betrachtete Projekt sowohl mit Scrum als auch mit dem Skalierungsframework Large Scale Scrum (LeSS) das Projektgeschehen organisiert hat, werden beide Teamzusammenstellungen, genauer gesagt Scrum Teams mit Feature Teams, miteinander verglichen, um anhand gesammelter Ergebnisse und Kennzahlen die wesentlichen Unterschiede beider Teamkonstellationen festzustellen und die Abweichungen des theoretischen Prozesses im praktischen Projektgeschehen, vor allem in Bezug auf Kundenprojekte herauszufinden. Dazu wird folgende Forschungsfrage gestellt:

Welche wesentlichen Unterschiede weisen beide Teamausprägungen in der realen Projektumgebung auf? Welche Abweichungen vom theoretischen Prozess können im praktischen Projektgeschehen entstehen?

Um obengenannte Forschungsfragen zu beantworten, muss aus theoretischer Sicht ein Einblick in das agile Projektmanagement gegeben werden, sowie die Arbeitsweise von Scrum und Development Scrum Teams wissenschaftlich beleuchtet werden. Damit eingehend muss ebenfalls Large Scale Scrum mit seinen Richtlinien und Prinzipien ausführlich dargelegt werden, um auch die Organisation von Feature Teams im Projektgeschehen nachvollziehen zu können.

Um den theoretischen Aspekt zu erweitern werden im methodischen Teil der Arbeit anhand gemachter Experteninterviews mit Projektmitarbeitern, die sowohl in der Ausprägung der Scrum Teams, wie auch Feature Teams entwickelt haben, eigene Erkenntnisse gesammelt, verarbeitet und aufgezeigt damit oben gestellte Forschungsfrage anhand eigener Interviewleitfäden und darauf aufbauender Aussagen bestmöglich beantwortet werden kann.

Abstract

Since 2009, the turnover of the IT industry in Germany has risen steadily. While in 2009 sales of almost 64 billion euros were achieved, in the last ten years they have risen by almost 30 billion to 92.9 billion euros (as of 2019). At just under 42 billion euros, the IT services sector recorded the largest revenue. Due to continuously rising sales figures and the associated success of the German IT industry, it is all the more important for companies in the IT services sector to organise project work within the company using suitable management strategies and methods in such a way that optimum results are achieved in order to achieve long-term success on the IT market and thereby set themselves apart from competing companies.

The intention of this thesis is to analyze an agile project of a leading IT service provider and to focus on the working methods of the development team. Since the considered project organized the project events with Scrum as well as with the scaling framework Large Scale Scrum (LeSS), both team compositions, more precisely Scrum Teams with Feature Teams, are compared with each other in order to determine the essential differences of both team constellations on the basis of collected results and key figures and to find out the deviations of the theoretical process in the practical project events, especially with regard to customer projects. The following research question is asked:

What are the main differences between the two types of team in the real project environment? What deviations from the theoretical process can occur in the practical project environment?

In order to answer the above mentioned research questions, it is necessary to give an insight into the agile project management of IT companies from a theoretical point of view, as well as to scientifically examine the working methods of Scrum and Dev Scrum teams. Large Scale Scrum with its guidelines and principles must also be explained in detail in order to understand the organization of feature teams in a project. In the context of project work with customers, the difficulties and tensions between customer and company are also pointed out with the help of existing literature.

To extend the theoretical aspect the methodical part of the work is based on expert interviews with project members who have developed both Dev Scrum Teams and Feature Teams. In this way the above mentioned research question can be answered in the best possible way using our own interview guidelines and statements based on them.

Abbildungsverzeichnis

Abb.1: Grundbausteine des agilen Projektmanagements

Abb.2: Grundsäulen von Scrum

Abb.3: Scrum-Prozess mit seinen Abhängigkeiten

Abb.4: Die vier Phasen der Teamfindung nach Tuckman

Abb.5: Übersicht LeSS-Framework

Abkürzungsverzeichnis

bzgl. bezüglich

ca. circa

d.h. das heißt

LeSS Large Scale Scrum

o.g. oben genannte(r),(e),(s)

SaFE Scaled Agile Framework

1 Einleitung

Alle Wirtschaftsbereiche der Welt erleben unter dem Begriff Digitalisierung seit Jahren einen wesentlichen Wandel. Verschiedenste IT-Innovationen üben dabei einen erheblichen Einfluss auf Produkte, Dienstleistungen, Unternehmens - und Geschäftsprozesse oder auch Absatzkanäle aus. Die Innovationen dienen dabei schon lange nicht mehr als Unterstützung der Kernprozesse, sondern der fundamentalen Neugestaltung von Prozessen und Wertschöpfungsketten.¹ Alles was digitalisiert werden kann, wird heutzutage digitalisiert. Dasselbe gilt für die Vernetzung. Davon sind sowohl Mensch, Maschine, wie auch Produkte gleichermaßen betroffen. Die Software wird dabei immer mehr zum wichtigsten Produktionsfaktor, da all die vernetzten Maschinen gesteuert und digitale Daten gespeichert, verarbeitet und richtig ausgewertet werden müssen.²

Neben der Intensität des Wandels ist dabei auch die Geschwindigkeit der Veränderungen außergewöhnlich. Dies stellt IT-Unternehmen oft vor schwer zu erfüllenden Anforderungen. Sie müssen sich flexibler organisieren, um bestmöglich auf die ständigen Veränderungen des IT-Markts reagieren zu können. Aufgrund der durchgehend steigenden Komplexität und der enormen Kosten von Entwicklungsvorhaben in der IT-Branche wird die Umsetzung von Softwarethemen deshalb oftmals innerhalb eines Projektes durchgeführt. Geeignetes Projektmanagement und geeignete Projektmanagementmethoden sollen dabei helfen, die umfänglichen Aufgaben bei einer IT-Neuentwicklung flexibel zu koordinieren, funktions- sowie abteilungsübergreifend durchzuführen und selbstverständlich auch Kosten und Qualität der Software zu kontrollieren.³

In einer Vielzahl von IT-Unternehmen werden Softwareentwicklungsprozesse traditionell nach dem Wasserfallmodell organisiert.

Wie es die Definition des Wasserfallmodells vorschreibt, werden die Phasen der Entwicklung der Anforderungsaufnahme, der technischen und fachlichen Konzeption, der Implementierungs- und Testphase bis zur Liveschaltung der fertigen Software aufeinanderfolgend abgearbeitet. Der Fokus liegt dabei auf einer funktions- und technologieorientierten Entwicklung. Flexibilität und das schnelle Reagieren auf Veränderungen rücken hier in den Hintergrund. Somit ist das Wasserfallmodell als Projektmanagementmethode in Hinblick auf oben genannte Anforderungen der neuen, digitalen Welt nur bedingt geeignet.⁴

Ein weiterer Aspekt, der aktuell oftmals gegen traditionelle Projektmanagementmethoden spricht, ist der transformierte Anspruch der Arbeitnehmer an ihre Arbeitsstätte. Im Fokus aller digitaler Veränderungen steht am Ende der Mensch, sei es als Mitarbeiter, Führungskraft, oder auch Kunde. Ambitionierte Arbeitnehmer der neuen Generation Y und Z setzen heutzutage Herausforderungen und anspruchsvolle Tätigkeiten voraus, sowie ein zufriedenstellendes Gehalt und Aufstiegsmöglichkeiten in der Karrierelaufbahn. Ebenso fordern Arbeitnehmer flexible Arbeitszeiten mit der Möglichkeit der eigenständigen Arbeitsgestaltung und dem Ziel der eigenen Entfaltung. Entgegengesetzt dazu erwarten Kunden, dass Unternehmen den schnellen Wandel bestmöglich umsetzen, indem neue, ständig verbesserte Innovationen auf den Markt gebracht werden. Voraussetzungen, die mit klassischen Projektorganisationen nur schwer umsetzbar sind.⁵

Um die Anforderungen der Kunden und Arbeitnehmer, des digitalen Marktes, sowie die Flexibilität und die Geschwindigkeit von Veränderungen bestmöglich umsetzen zu können, wenden IT-Unternehmen in Softwareprojekten immer häufiger agile Projektorganisationen an. Im weiteren Sinne werden mit Agilität Begriffe wie Schnelligkeit, Flexibilität, Anpassungsfähigkeit, Vernetzung, sowie Selbstorganisation in Verbindung gebracht. Alles Begriffe, die auch auf die Anforderungen des heutigen IT-Marktes zutreffen.⁶ Dass die Einführung von agilen Methoden in der Softwareentwicklung und allgemein in der Projektorganisation erfolgreich sein kann, zeigt auch beispielsweise der CHAOS-Report der Standish Group, oder der sogenannte Agile Profiler Index. Bei beiden Reports wurde festgestellt, dass agil geführte Projekte eine Erfolgsquote bei der Projektdurchführung von 42 Prozent vorweisen können. Dies ist fast drei Mal so hoch wie bei Projekten mit klassischer Wasserfallorganisation.⁷

Wie oben bereits erwähnt, können agile Methoden zu Projekterfolg beisteuern, jedoch darf es nicht als selbstverständlich angesehen werden. Auch bei der Einführung agiler Methoden in IT-Projekten ist es wichtig genau zu analysieren, welche agile Methode oder welches Framework für ein Projekt am meisten geeignet ist. Zwar ist Scrum als bekanntestes Framework der agilen Softwareentwicklung mit 57% auch das meistgenutzte, jedoch stößt auch das klassische Scrum mit seinen Scrum Teams beispielsweise bei der Softwareentwicklung in großen und sehr komplexen Projekten auf seine Grenzen und bietet oftmals nicht den erwünschten Projekterfolg. In solchen Fällen ist die Einführung von Frameworks, wie dem Large Scale Scrum Framework und seinen Feature Teams oft notwendig, um den angestrebten Projekterfolg realisieren und die Organisation von komplexen und großen IT-Projekten handhaben zu können. Eine Tatsache, die häufig in der Planung und Einführung von agilen Methoden in der Softwareentwicklung unbeachtet bleibt.⁸

1.2 Problemstellung und Relevanz der Arbeit

Wie oben bereits erwähnt, sind agile Projekte mit 42% fast drei Mal erfolgreicher als Projekte mit einer klassischen Organisation. Dies spricht zwar für den erfolgreichen Einsatz agiler Methoden, jedoch wird bei dieser Prozentzahl ebenfalls klar, dass mehr als die Hälfte der IT-Projekte nach wie vor scheitern. Ein Ergebnis, welches Führungskräfte und Managementetagen der IT-Branche nicht zufriedenstellen kann. Besonders für IT-Unternehmen des Dienstleistungssektors ist es enorm wichtig, dass Projekte erfolgreich durchgeführt werden, um eine Vertrauensbasis zum Kunden und somit langjährig erfolgreiche Projekte für sich gewinnen zu können. Befürworter agiler Methoden sehen in der Agilität die Lösung zur Steigerung des Projekterfolgs, eine These, die auch durch den Agile Profiler Index oder den CHAOS Reports bestärkt wird. Würden mehr Unternehmen agile Methoden in Projekten einsetzen, würde dementsprechend auch die Prozentzahl erfolgreicher Projektabschlüsse in die Höhe gehen, so die Meinung der Fürsprecher.

In der Literatur gibt es bereits eine Vielzahl an Sachbüchern und Publikationen zum Thema Agilität und agile Methoden im Unternehmen.⁹ Besonders zu Scrum und Scrum Teams, wie auch zu Large Scale Scrum und Feature Teams, die in dieser Arbeit miteinander verglichen werden, gibt es eine Vielzahl von wissenschaftlichen Ausarbeitungen. Es gibt jedoch wenig bis keine Praxisbeispiele, die sich vor allem damit befassen, beide Teamausprägungen in der realen Projektarbeit und der Entwicklungsumgebung miteinander zu vergleichen und das in einem Projekt, das sowohl mit Scrum Teams wie auch Feature Teams die Softwareentwicklung organisiert hat. Dabei spielt vor allem auch der Dienstleistungssektor von Unternehmen eine wesentliche Rolle, da sich durch die Arbeit in Kundenprojekten oftmals Abweichungen von theoretischen Prozess ergeben können, um essenzielle, projektbezogene Arbeit durch zusätzliche Rollen abzudecken. Es gibt zwar Tipps, wie beispielsweise Scrum in der Praxis eingeführt werden kann, jedoch unterscheidet sich die reale Einführung meist noch einmal deutlich von der fiktiven. Wie in der Einleitung der Arbeit bereits erwähnt, ist die Einführung von Agilität nicht die größte Herausforderung für das Unternehmen.

Die komplette Umorganisation der Prozesse innerhalb des Projekts und die damit veränderte Arbeitsgestaltung der Projektmitarbeiter bringt oftmals die größten Schwierigkeiten zum Thema agile Projektorganisation mit sich. Führungskräfte und Mitarbeiter, die sich mit dem Thema Agilität intensiv befassen möchten, können sich zwar aufgrund der umfangreichen Literatur theoretisches Wissen zu diesem Thema aneignen, jedoch ist die Einführung in der Realität aufgrund von fehlendem Praxiswissen das sogenannte „Bottleneck".

Aufgrund obiger Problemstellung ist eine genauere Analyse der Thematik dieser Arbeit enorm vielversprechend für Führungskräfte und Unternehmen, welche den Schritt in Richtung Agilität mit der Einführung von Scrum oder Large Scale Scrum wagen wollen, da in vorliegender Arbeit vor allem der Vergleich von Scrum Teams und Feature Teams in einem existierenden IT-Projekt mit Kundenbindung gemacht wird. Somit werden sowohl die Vorteile und die wesentlichen Unterschiede von Scrum und Scrum Teams, sowie von LeSS und Feature Teams im Projektgeschehen dargelegt. Auch angesichts der Durchführung von Experteninterviews mit Mitarbeitern des analysierenden Projekts und den verschiedenen Perspektiven eines Projektleiters oder eines Entwicklers ist die Relevanz der Arbeit von hohem Belang, da Erkenntnisse und resultierende Ergebnisse der Themenstellung aus erster Hand gewonnen werden können und damit Abweichungen von der Theorie aufgezeigt werden können.

1.3 Ziel der Arbeit

Das Ziel der Arbeit ist daher, ein agiles Softwareprojekt des führenden IT- Dienstleistungsunternehmens Capgemini in Bezug auf die agile Projektorganisation zu analysieren, welches die Entwicklung zuerst nach Scrum und anschließend aufgrund der höher werdenden Komplexität des Projekts mithilfe von Large Scale Scrum und Feature Teams organisiert hat, um anhand gesammelter Ergebnisse die wesentlichen Unterschiede des Scrum Teams zu Feature Teams im Softwareentwicklungsprozess herauszuarbeiten und mittels Theorie und Befragung von Experten wesentliche Unterschiede des theoretischen Scrum und LeSS-Prozesses mit dem Prozess im realen Projektumfeld festzustellen. Dadurch soll der oben genannten Problemstellung entgegengewirkt werden, dass Führungskräfte und Befürworter beider agiler Methoden keine Praxisbeispiele in der Softwareentwicklung vorliegen haben, um möglicherweise die Vor- und Nachteile beider Teamprägungen im direkten Projektumfeld zu erkennen. Daher ergibt sich auch die Fragestellung der Arbeit:

Welche wesentlichen Unterschiede weisen beide Teamausprägungen in der realen Projektumgebung auf? Welche Abweichungen vom theoretischen Prozess können sich im praktischen Projektgeschehen ergeben?

Erarbeitete Ergebnisse sollen zum Ziel haben, dass anhand dessen genauere Vorhersagen über die Unterschiede der beiden Teamprägungen auf eigene Projekte aus verschiedenen Unternehmen angewendet werden können, um schon im Voraus zu wissen, ob die Einführung von Scrum Teams oder Feature Teams den gewünschten Projekterfolg mit sich bringen könnte.

Um die Forschungsfragen bestmöglich beantworten zu können, wird im Ersten Kapitel der Arbeit auf die Definition und die Herkunft von agilen Projektmanagement eingegangen, um einen Überblick darüber zu geben, welche Ziele agiles Projektmanagement verfolgt und auf welchen Grundbausteinen es basiert. Der Nächste größere Abschnitt der Arbeit beschäftigt sich mit der Arbeitsweise von Scrum in IT-Projekten. Wie auch in vorausgegangenem Kapitel wird zuerst beleuchtet, wie es zu der Entstehung des Frameworks kam, welche Absichten die Entwickler dabei hatten und auf welchen Grundsäulen das Framework aufgebaut ist. Im weiteren Verlauf des Kapitels wird detailliert auf die Arbeitsweise mit beteiligten Rollen, Artefakten und Events eigegangen, da der Scrum-Prozess die Basis weiterer Ausführungen auch im Kontext von Large Scale Scrum bildet. Um die Thematik der Arbeit aufzugreifen, wird in einem separaten Abschnitt noch einmal konkret der Fokus auf das Development Team von Scrum gelegt. Nach der Darstellung des Scrum-Prozesses wird im weiterführenden Kapitel der Grundlagen das agile Skalierungsframework LeSS vorgestellt. Um bereits aus theoretischer Sicht einen Vergleich beider Frameworks feststellen zu können, wird wie auch beim Scrum-Kapitel der LeSS-Prozess mit Rollen, Artefakten und Events dargestellt und besonders auch die Teamorganisation Feature Teams behandelt.

Der Methodikteil der Arbeit hat das Ziel, gesammelte Erkenntnisse aus der Theorie anhand praktischer Beispiele mithilfe von Experteninterviews zu überprüfen.

Dazu wird zuerst die Methode der Experteninterviews näher beschrieben, um dem Leser zu vermitteln, wie die Herangehensweise bei Experteninterviews funktioniert und welche Besonderheiten zu beachten sind. Im weiteren Verlauf wird auf die erstellten Interviewleitfäden eingegangen, da durch die Befragung verschiedener Rollen auch die Erstellung verschiedener Leitfäden notwendig ist, um die Perspektiven der befragten Rollen nachvollziehen zu können. Im nachfolgenden Kapitel werden die Ergebnisse der durchgeführten Interviews zusammengefasst und gesammelte Erfahrungen, Erkenntnisse und Wissen durch die Befragung der Experten gegenübergestellt.

Im Fazit der Arbeit werden gesammelte Erkenntnisse aus Theorie und Praxis zusammengefasst und wiedergegeben, um die Forschungsfrage anhand erarbeiteten Wissens beantworten zu können und damit obengenannter Problemstellung entgegenzuwirken.

2 Wissenschaftliche Grundlagen

2.1 Einführung in das agile Projektmanagement

2.1.1. Definition agiles Projektmanagement

Agilität und agiles Projektmanagement sind Begriffe, die vor allem in den letzten Jahren in der IT-Branche immer öfter im Tagesgeschäft der jeweiligen Unternehmen thematisiert wurden. Doch was ist unter dem Begriff agiles Projektmanagement zu verstehen? Um die Definition des agilen Projektmanagements besser näherbringen zu können, müssen auch die Entwicklungsstadien des gesamten Projektmanagements und der Agilität im Allgemeinen betrachtet werden. Generell ist der Einsatz von Projektmanagement, unabhängig von klassischem oder agilem Projektmanagement dann erforderlich, wenn es sich bei durchzuführender Aufgabe um ein geplantes Arbeitsvorhaben handelt, dessen Erfüllung bestimmte Zeit, Aufwand sowie Planung mit sich bringt und das Vorhaben durchgeführt wird, um vordefinierte Ziele bestmöglich umzusetzen. Oftmals spielt dabei auch der Budgetrahmen, sowie eine vorgegebene Zeitspanne eine wesentliche Rolle.¹⁰ Treffen oben genannte Eigenschaften auf das auszuführende Vorhaben zu, handelt es sich nach der einheitlichen Definition der DIN- Norm um ein Projekt und somit wird der Einsatz von Projektmanagement notwendig, um das Projekt im Gesamtbild zu führen und organisieren, sowie Techniken und Mittel für einen erfolgreichen Projektabschluss bereitzustellen.¹¹

Die Anfänge des Projektmanagements gehen bereits auf das frühe 20. Jahrhundert zurück, da die Arbeit in Projekten weltweit immer mehr Zuspruch bekam und erste Projektmanagementprozesse entwickelt wurden, um die Organisation innerhalb von Projekten besser steuern zu können. Die damals entwickelten Prozesse bilden die Grundlage der heutigen Wasserfallmethode, die als bekannteste Methode des klassischen Projektmanagements gilt. Im Laufe der Jahre wurden dabei die einzelnen Schritte und Phasen der Methode weiter verfeinert und perfektioniert.¹²

Die Wasserfallmethode und weitere klassische Projektmanagementprozesse blieben zur damaligen Zeit auch in der Softwareindustrie nicht unentdeckt und wurden vermehrt in Projekten eingesetzt, mit dem Hintergrund, die Projekte erfolgreicher abschließen zu können. Im Widerspruch dazu stand jedoch die Bewegung des „Software-Engineerings", die vor allem in den 1980er Jahren in der Softwareindustrie ausgeprägt zum Vorschein kam. Die Auswirkungen des Trends waren, dass Entwicklungsvorhaben immer größer und komplexer wurden und die Ziele immer weniger absehbar waren. Eigenschaften, die sich mit klassischem Projektmanagement kaum meistern ließen.¹³

Der „Software Engineering"-Ansatz hatte zur Folge, dass viele Projekte in den 80er und 90er Jahren aufgrund ihrer Komplexität kein erfolgreiches Ende fanden und somit die Notwendigkeit aufkam, neue Methoden zu entwickeln, nach denen alle Projektbeteiligten vorgehen und die Softwareprojekte auf die Komplexität und unvorhersehbare Zielsetzungen erfolgreich abstimmen.¹⁴ Anfangs wurde versucht, das Vorhaben mithilfe von Handbüchern und unterstützender Software umzusetzen. Das Ziel eingeführter Handbücher sollte sein, die Prozesseinhaltung zu bekräftigen, wie auch zu überwachen, jedoch hatte sie nicht den gewünschten Erfolg, da die in den Handbüchern beschriebenen Vorschriften an eine langfristige Planbarkeit, jedoch wieder nicht an die Flexibilität von Veränderungen ausgerichtet waren und somit die gewünschten Ergebnisse nur teilweise erreichten. Um dem Problem der Nichtplanbarkeit und fehlenden Flexibilität von Entwicklungsvorhaben entgegenzuwirken, wurde Mitte der 1990er Jahre der Startschuss für die heutigen agilen Methoden gegeben, als Prozesse wie Scrum oder Extreme Programming, auch Leichtgewichtprozesse genannt, ins Leben gerufen wurden. Bei diesen Methoden lag der Fokus auf weniger statt mehr Festlegungen, um die geforderte Flexibilität durch den Einsatz der „Leight Weight Processes" gewährleisten zu können.¹⁵

Um die weitere Zukunft der iterativen und inkrementellen Softwareentwicklung zu diskutieren wurde im Jahre 2001 ein Kongress mit erfolgreichen Softwareentwicklern aus aller Welt abgehalten, welche sich allesamt als Befürworter der „Leight Weight Processes" bekannten und bei der Entwicklung von Scrum, Extreme Programming oder Crystal maßgeblich beteiligt waren. Bei dem Kongress wurde das Augenmerk auf die Fragestellung gelegt, warum vor allem Unternehmen der Softwareentwicklung stets mit Problem bei der Umsetzung von Entwicklungsvorhaben zu kämpfen haben und wie die Unternehmen den Herausforderungen des Marktes mithilfe geeigneter Projektmanagementmethoden trotzen können. Die Lösung wurde in den neuen und schlanken Methoden erkannt, die im Gegensatz zu den klassischen Projektmanagementansätzen deutlich weniger komplex waren. Um die schlanken Methoden gezielt von klassischen Methoden abzugrenzen, wurde der Begriff „agil" ins Leben gerufen. Agil lässt sich laut der Agile Alliance, wie sich die beteiligten Softwareentwickler nannten, beschreiben als „Fähigkeit, Veränderungen einzuleiten und auf Veränderungen zu reagieren, um in einem unsicheren und turbulenten Umfeld erfolgreich zu sein". Den Mitgliedern der Agile Alliance war dabei besonders wichtig, dass Lösungen aus der Zusammenarbeit der selbstorganisierten, sowie flexiblen Projektteams erarbeitet werden, anstatt auf detaillierte Vorausplanungen zu setzen.¹⁶

Um der Welt einheitlich und detailliert präsentieren zu können, was die Agile Alliance genau unter dem agilen Konzept und der agilen Softwareentwicklung versteht, wurde im selben Jahr das sogenannte Manifesto for Agile Software Development entworfen, das bis heute das Fundament für agile Methoden und das agile Projektmanagement bildet. Das Dokument umfasst vier verschiedene Werte, die beispielsweise die Wichtigkeit einer funktionierenden Software, oder dem Eingehen auf Veränderungen ausdrücken, sowie 12 agile Grundprinzipien, die den vier Werten des agilen Manifests beistimmen und als mustergültige Vorlagen für Handlungsprinzipien innerhalb eines agilen Projekts gelten. Bis heute hat das Dokument weder an Aktualität, noch an Bedeutung im Bereich der Agilität verloren (vgl. ebd. S.26f.).

Wie oben bereits erwähnt, bildet das agile Manifest den Grundstein für agiles Projektmanagement. Somit kann gesagt werden, dass agiles Projektmanagement ebenfalls eine Antwort auf die zunehmende Geschwindigkeit von Entwicklungsvorhaben innerhalb von Projekten ist, sowie auf die Tatsache, dass anfangs definierte Pläne in IT-Projekten meist nicht eingehalten werden, besonders in Projekten, bei denen die Anforderungen an eine Software zu Beginn nicht gänzlich geklärt sind.17

Um zu verdeutlichen, was hinter dem Begriff des agilen Projektmanagements steht und welche Komponenten, in welcher Relation darin auftauchen, werden in Abb.1: Grundbausteine des agilen Projektmanagements agile Werte, Prinzipien, Techniken und Werte aufeinander aufbauend dargestellt. Die einzelnen Bausteine müssen dabei von unten nach oben betrachtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb.1: Grundbausteine des agilen Projektmanagements18

Agile Werte, die 2001 erstmalig im agilen Manifest verfasst wurden, bilden die Grundlage für agiles Projektmanagement, da sie Ideale wie Flexibilität, Anpassungsfähigkeit und Individualität verkörpern, die ebenfalls mit agilem Projektmanagement einhergehen und somit die Grundsätze des agilen Projektmanagements wiederspiegeln. Das nächsthöhere Level bilden agile Prinzipien, die wie bereits erwähnt auf die vier Werte abgestimmt sind und diese erweitern. Sie beschreiben im Wesentlichen mithilfe welcher Handlungsprinzipien agiles Projektmanagement erfolgreich gestaltet werden kann. So wird in den agilen Prinzipien beispielweise empfohlen, tägliche Zusammenarbeit zwischen Geschäftsleuten und Entwicklern zu pflegen, um eine funktionierende Software, wie auch technische Exzellenz in einem Projekt sicherzustellen, mit dem Ziel Agilität ganzheitlich zu fördern und natürlich alle Bereiche des agilen Projektmanagements erfolgreich umzusetzen. Der dritte Grundbaustein des agilen Projektmanagements umfasst agile Techniken. Im Gegensatz zu beiden bereits genannten Grundbausteinen handelt es sich bei folgendem Baustein um konkrete Methoden, die in das Projektmanagement implementiert werden können. Beispiele für agile Techniken sind sogenannte Daily Stand-Ups, bei denen täglich der aktuelle Stand des Projekts und weitere Aufgaben aus dem Tagesgeschäft mit allen Projektbeteiligten diskutiert werden, oder das Abhalten von Retrospektives, auf die im Kapitel 2.1.3 Arbeitsweise von Scrum in IT- Projekten näher eingegangen wird, um die Zusammenarbeit innerhalb des Projekts stetig zu verbessern. Aufgrund der Anzahl verschiedener agiler Techniken, muss im Gegensatz zu den agilen Werten und Prinzipien, die für einen erfolgreichen Projektabschluss in Summe umzusetzen sind, genauestens überlegt werden, welche agile Technik oder auch Techniken für das Projekt am besten geeignet sind. Der letzte und vierte Grundbaustein des agilen Projektmanagements sind agile Methoden. Sie bündeln agile Prinzipien und Techniken zu einem ganzheitlichen Prozess, der in das Projektmanagement integriert werden kann. Die bekanntesten agilen Methoden sind Scrum, Kanban oder auch Extreme Programming.¹⁷

Abschließend ist festzuhalten, dass die Definition des agilen Projektmanagements Lösungen umfasst, um Projektteams so zu organisieren, dass eine höhere Toleranz bezüglich Qualität, Umfang, sowie Zeit und Kosten im Projekt vorherrschen.

Ausschlaggebend für den Erfolg dabei ist der Fokus auf das zu liefernde Produkt und die Zusammenarbeit aller Projektbeteiligten, darunter fallen auch Stakeholder und besonders Auftraggeber. Durch die höhere Flexibilität und dem variablen Umfang werden Anforderungen, wie Kostentreue oder die Umsetzung eines vordefinierten Plans bei agilem Projektmanagement kaum bis gar nicht berücksichtigt.¹⁸ Da der Fokus dieser Arbeit auf dem analysierenden Vergleich von Scrum Teams und Feature Teams liegt, wird in folgenden Kapiteln die Arbeitsweise von Scrum in IT- Projekten näher beschrieben. Dabei wird besonders die Organisation des Entwicklungsteam, auch Dev Scrum Team genannt, detailliert erläutert, um dem Leser für den späteren Vergleich von Scrum Teams und Feature Teams ein grundlegendes Verständnis beider Organisationsformen vermitteln zu können.

2.1.2. Arbeitsweise von Scrum in IT-Projekten

Wer schon einmal den Begriff „agil" gehört hat, hat mit hoher Wahrscheinlichkeit in diesem Zusammenhang auch etwas von Scrum mitbekommen. Dies kommt nicht von ungefähr: Weltweit nutzen mehr als 12 Millionen Menschen Scrum als agile Projektmanagement Methode, sprich 90% agil arbeitender Projekte haben Elemente von Scrum integriert.¹⁹ Damit ist Scrum laut einer Studie der deutschen Gesellschaft für Projektmanagement (GPM) die bedeutendste Methode für IT-Projekte.²⁰ Doch auch wie bei agilem Projektmangement stellt sich hier die Frage: was bedeutet der Begriff „Serum“ überhaupt und worum handelt es sich dabei? Einen Prozess? Ein Tool für das Projektmanagement, oder doch etwas ganz anderes? Um die gesamte Organisation von Scrum, mit ihrer Arbeitsweise und den beteiligten Rollen zu verstehen, muss auf oben genannte Fragestellungen in folgendem Kapitel ebenfalls eingegangen werden.

Der Begriff „Serum“ im Kontext der Projektorganisation wurde 1986 von zwei japanischen Wirtschaftswissenschaftlern namens Nonaka und Takeuchi ins Leben gerufen.

In dem von ihnen verfassten Artikel „The New Product Development Game" vertreten beide Wissenschaftler die Annahme, dass einer der größten Erfolgsfaktoren von Produktentwicklungsteams die Nähe des Teams während der gesamten Entwicklungsarbeit ist.²¹ Analog dazu sahen beide Wissenschaftler ein Ereignis aus der Sportart Rugby, bei dem sich zwei Mannschaften in einem kreisförmigen Gedränge gegenüberstehen und durch Selbstorganisation in kleinen Einheiten versuchen, dem Gegner keinen Raumgewinn zu ermöglichen. Das beschriebene Gedränge wird im Rugbybereich auch „Scrum“ genannt.²²

1993 wurde o.g. Ansatz von den beiden Entwicklern Jeff Sutherland und Ken Schwaber aufgegriffen und weiterentwickelt. Dabei wurden bereits bestehende Veröffentlichungen und Methoden wie das Produktionssystem von Toyota, das auf eine kontinuierliche Verbesserung der Prozesse absah und als weltweites Vorbild für andere Unternehmen galt, oder auch Ansätze aus Lean, sowie Team - und Durchsatzoptimierung in die Entwicklung mit einbezogen. Das Ergebnis wurde 1995 als ein agiles Managementframework vorgestellt, also zu Deutsch ein Rahmenwerk für agiles Projektmanagement. Das Framework wurde, angelehnt an den Artikel von Nonaka und Takeuchi, in Scrum getauft.²³

Heutzutage ist Scrum aus der agilen Welt nicht mehr wegzudenken. Seit der Veröffentlichung ist Scrum zu dem erfolgreichsten agilen Managementframework zur Entwicklung von Software geworden, das aus klaren Regeln besteht, aber dennoch sehr einfach gehalten wird, da Scrum nur aus drei Rollen, fünf Meetings und drei Artefakten besteht. Als agiles Framework verkörpert Scrum die Werte und Prinzipien des agilen Manifests, das in letztem Kapitel bereits näher beschrieben wurde (vgl. ebd. S.69).

Die wissenschaftliche Grundlage von Scrum ist die Theorie eines empirischen Prozessstrukturrahmens, der besagt, dass erlangtes Wissen auf Erfahrungen basiert und damit verbundene Entscheidungen im Team auf Basis des bestehenden Wissens getroffen werden.

Damit ist gemeint, dass nicht eine umfangreiche und zeitintensive Vorplanung, die oft nur auf Annahmen basiert, den gewünschten Projekterfolg herbeiführt, sondern das Experimentieren und Adaptieren von empirischem Wissen und Erfahrungen, um dadurch besser und schneller Entscheidungen im Team zu treffen. Dies hat zur Folge, dass Risiken frühzeitig erkannt und somit reduziert werden, da mehr Erfahrung gleichzeitig mehr Wissen und bessere Entscheidungen mit sich zieht.^{24 25}

2.1.2.1 Die Grundsäulen von Scrum

Da Scrum auf Grundlage eines empirischen Strukturrahmens basiert, baut es auf drei wesentlichen Säulen auf, die in unten dargestellter Abb.2: Grundsäulen von Scrum zu entnehmen sind.

Abbildung in dieser Leseprobe nicht enthalten

Abb.2: Grundsäulen von Scrum2

Die drei Grundsäulen Transparenz, Inspektion sowie Adaption sind Basis der sogenannten empirischen Prozesskontrolle und werden auch oft als Dreisatz des „Inspect and Adapt"-Prozesses genannt. Durch Transparenz soll im Scrum-Umfeld eine Kommunikation zwischen allen Projektbeteiligten sichergestellt werden, mit dem Ziel durch Transparenz erarbeitetes Wissen teilen zu können.

Dadurch sollen idealerweise Schwachstellen und Fehler schneller aufgedeckt werden, da gemachte Fehler von den jeweiligen Teammitgliedern offen dargelegt und anschließend diskutiert werden, um aus gemachten Fehlern Wissen zu entwickeln.²⁶ Um die Transparenz im Projekt zu fördern ist ebenfalls wichtig, bereits im Anfangsstadium eines Projekts zu klären, welche Begriffe im Projektkontext wie verwendet werden, um alle Begriffe transparent zu machen und eine gemeinsame Sprache zu schaffen. Ein veranschaulichendes Beispiel dafür ist eine Einigung über die „Definition of Done", also bestimmte Kriterien, die erfüllt werden müssen, um ein Produkt, oder Software als fertiggestellt bezeichnen zu können. Ist die Transparenz im Projekt nicht gegeben, führt dies zu mangelnder Kommunikation und daraus resultierend zu einer höheren Anzahl an Fehlern.²⁷

Die Überprüfung oder auch Inspektion als zweite Grundsäule von Scrum beinhaltet, dass sogenannte Artefakte in regelmäßigen Abständen durch das Scrum-Team geprüft werden, ob die Artefakte zum Fortschritt des Sprint-Ziels beitragen oder Abweichungen aufgrund verwendeter Artefakte entstanden sind, die beseitigt werden müssen, um das Sprint-Ziel nicht zu gefährden. Unter Artefakten sind Elemente zu verstehen, die während des Entwicklungszyklus im Scrum-Projekt genutzt werden, wie zum Beispiel ein Product oder Scrum-Backlog. In Zusammenhang mit der Überprüfung ist besonders wichtig, dass diese so getaktet sind, dass das eigentliche Tagesgeschäft nicht beeinträchtigt wird, um den Mehrwert für das Projekt aufgrund durchgeführter Überprüfungen zu gewährleisten. Wenn Prozessabweichungen bei einer Überprüfung festgestellt werden, die außerhalb des akzeptierenden Limits liegen, ist die dritte Grundsäule Adaption gefragt. Durch Adaption sollen Gegenmaßnahmen vorgenommen werden, um ein Ziel wieder effizient erreichen zu können und weitere Abweichungen zu vermeiden, indem die Anpassungen schnell entschieden und implementiert werden (vgl. ebd. S.32).

Zusammenfassend zu den drei Säulen von Scrum ist zu sagen, dass die Grundlage für neu erlerntes Wissen in einem Projekt Transparenz ist, da Transparenz das Aneignen von neuem Wissen fördert.

Durch Transparenz und Kommunikation im Team wird das Wissen wiederum innerhalb des Teams geteilt sowie verstärkt und hat zur positiven Folge, dass Handlungen hinterfragt und überprüft werden, um die Ziele eines Sprints nicht zu gefährden und gegebenenfalls Anpassungen einzuleiten, um ein gesetztes Ziel zu erreichen.^{28 29} Der Scrum-Prozess im Tagesgeschäft bindet die drei Grundsäulen durch seine Abläufe mit ein und wird im nachfolgenden Abschnitt mit Einbezug der einzelnen Rollen näher dargelegt.

2.1.2.2 Der Scrum-Prozess mit beteiligten Rollen leicht erklärt

Wie bereits zu Anfang des Kapitels erwähnt, definiert Scrum drei Rollen, drei Artefakte und fünf Events. Um den interativen Scrum-Prozess mit seinen Rollen, Artefakten und Events sowie deren Abhängigkeiten zueinander besser verstehen zu können, wird in Abb.3: Scrum-Prozess mit seinen Abhängigkeiten die Arbeitsweise von Scrum mit Einbezug der Rollen, Artefakte und Events bildlich dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb.3: Scrum-Prozess mit seinen Abhängigkeiten31

Wie auf dem Bild zu erkennen ist, stehen die einzelnen Scrum-Rollen während des gesamten Prozesses in Interaktion. Auch auch die Events stellen einen in sich geschlossenen Kreislauf dar, wobei das eigentliche Sprint-Event, auch ContainerEvent genannt, die anderen Events beinhaltet.

Den Startschuss für die Entwicklung mit Scrum geben die Stakeholder, die nach der Definition des Scrum-Prozesses zwar nicht zu den drei Rollen von Scrum zählen, jedoch durch ihre Produktvision den Scrum-Prozess ins Rollen bringen und mithilfe der Produktvision einen gewünschten Zielzustand vorstellen, der als Referenz während der gesamten Entwicklung angesehen werden kann. Wurden die Anforderungen und die Produktvision durch die Stakeholder definiert, ist die Rolle des Product Owners gefragt. Dieser ist dafür verantwortlich, dass alle Anforderungen, die nach Gesprächen mit Stakeholdern definiert wurden, in das erste Artefakt, dem sogenannten „Product Backlog" aufgenommen werden. Unter dem „Product Backlog" ist eine detaillierte Zusammenfassung der Produktanforderungen mit einer eindeutigen Priorisierung der einzelnen Aufgaben zu verstehen. Wurde das „Product Backlog" vollständig erstellt, wird mit der Sprint-Planung das erste Scrum-Event in Gang gesetzt. Zu Beginn der Sprint-Planung stellt der Product-Owner dem Development-Team, der zweiten Rolle von Scrum, die von ihm priorisierten User-Stories vor und allein das Team entscheidet daraufhin, welche Produktanforderungen im nächsten Sprint umsetzbar sind und verpflichtet sich, vereinbarte Punkte innerhalb des kommenden Sprints umzusetzen. Durch Auswählen bestimmter User-Stories wird gleichzeitig ein Sprint-Ziel definiert und umzusetzende Punkte werden anschließend vom Development-Team zeitlich geschätzt und in das „Sprint Backlog", einem weiteren Artefakt von Scrum, übertragen. Während das „Sprint-Backlog" im Laufe des Sprints nicht mehr verändert werden darf, kann der Product Owner User-Stories im „Product-Backlog" nach Belieben um priorisieren, entfernen, oder auch neue User-Stories hinzufügen.³⁰ Nachdem die einzelnen User-Stories priorisiert und in das „Sprint Backlog" übertragen wurden, beginnt das Development-Team mit der Umsetzung, somit der eigentlichen Phase der Produktentwicklung, die in Scrum meist als zwei bis vier Wochen Sprint angesetzt ist. Durch Abhalten täglicher Stand-Up-Meetings, oder auch Daily Scrum genannt, wird jeweils der aktuelle Entwicklungsstatus, aufgetretene Schwierigkeiten, sowie die Umsetzungspläne für die nächsten 24 Stunden mitgeteilt.³¹

Am Ende des Sprints sollte das Development-Team die für den Sprint angesetzten Anforderungen umgesetzt sowie getestet und in das Produktinkrement, dem letzten Scrum Artefakt, implementiert haben. Unter einem Produktinkrement ist eine fertige Komponente des Gesamtprodukts zu verstehen, die während eines Sprints entwickelt wurde. Das fertige Produktinkrement wird dem Product Owner und gegebenenfalls auch den Stakeholdern im sogenannten „Sprint Review" präsentiert und durch die Beteiligten bewertet. Anpassungen und neue Anforderungen an das Produkt werden wieder in das „Product Backlog" aufgenommen und mit Einbezug der bereits vorhandenen User-Stories priorisiert. Damit ist die Bewertung des Produktinkrements abgeschlossen.

Im letzten Event des Scrum-Prozesses, der „Sprint Retrospektive" kommt auch die dritte Rolle von Scrum, der Scrum-Master zum Einsatz. Dabei liegt der Fokus nicht auf dem Produkt, sondern der Arbeitsweise im Sprint. Product Owner, Development Team, sowie Scrum-Master analysieren den Ablauf des aktuellen Sprints und konzipieren gemeinsam Verbesserungsvorschläge, um im nächsten Schritt noch effizienter zu sein und eine kontinuierliche Verbesserung während der einzelnen Sprints zu erzielen. Die Aufgabenbereiche des Scrum-Masters beinhalten, das Team bei der Organisation zu unterstützen, um die Produktivität zu steigern sowie die Einhaltung der Scrum-Werte und Prinzipien sicherzustellen. Das Ziel des Scrum- Masters ist, ein Team bestmöglich zu beraten und unterstützen, um stets die Kreativität sowie Produktivität des Teams zu fördern. Nach Abschluss der „Sprint-Retrospektive", ist auch der gesamte Sprint zu Ende und der neue Sprint beginnt analog zum vorherigen Ablauf. Für den jeweils zukünftigen Sprint wird während der Produktentwicklung bereits Vorarbeit geleistet, indem Product Owner und Development Team User-Stories für den nächsten Sprint bezüglich zeitlichen Aufwands schätzen. Das sogenannte „Product Backlog Refinement" wird zwar nicht als offizielles Scrum-Event angesehen, ist jedoch mittlerweile häufig in IT-Projekten vorzufinden.³²

Aufgrund der Tatsache, dass in dieser Arbeit vor allem das Development Team von Scrum und LeSS im Fokus stehen, wird in nachfolgendem Abschnitt das Development Team von Scrum noch einmal ausführlich analysiert.

2.1.3 Development Team - die wichtigste Rolle in Scrum

Das Development Team in Scrum, auch Entwicklungsteam genannt, wird als Team von Spezialisten für das zu entstehende Produkt angesehen. Das ist nicht unbegründet, da einzig das Development-Team für das „Wie" im gesamten Prozess verantwortlich ist. Mit dem „Wie" ist gemeint, dass das Team alle Arbeiten ausführt, die zur Umsetzung der Anforderungen in die jeweiligen Produktinkremente nötig sind und auch die gelieferte Qualität des Produkts verantwortet. Dies funktioniert nur, da die Softwareentwicklung in Scrum teambasiert ist. Das bedeutet, dass sowohl Softwareentwickler, Tester, Datenbankspezialisten als auch andere wichtige Rollen alle an einem Strang ziehen und gemeinsam Ergebnisse liefern.³³

Eines der wesentlichen Ziele von Scrum ist, die kontinuierlich hohe Produktivität im Team sicherzustellen. Daher ist es besonders wichtig, dass die Mitglieder eines Entwicklungsteams bestimmte Verantwortlichkeiten an den Tag legen, um erfolgreich im Team zu sein oder allgemein in Scrum-Projekten arbeiten zu können. Auch durch Selbstreflektion sollen sich Mitarbeiter darüber im Klaren sein, ob sie sich selbst als Individuum in einem Scrum-Projekt entfalten könnten und die geforderten Regeln und Prinzipien von Scrum einhalten können. Um einen Überblick darüber zu haben, welche Eigenschaften ein Development-Team mit sich bringt, wurden im Laufe der letzten Jahre mehrere Teameigenschaften definiert, die ein Entwicklungsteam in Scrum zu eigen hat. Durch definierte Teameigenschaften soll ein Development-Team das Ziel erfüllen, stets die festgelegten Anforderungen an das Produkt während eines Sprits mit bestmöglicher Qualität umzusetzen.³⁴

Die erste Eigenschaft eines Entwicklungsteams ist die hohe Befugnis des Teams während des gesamten Scrum-Prozesses. Wie bereits im letztem Kapitel 2.1.2.2 erwähnt, entscheidet allein das Entwicklungsteam, welche Anforderungen aus dem Product-Backlog im kommenden Sprint umgesetzt werden können und legt somit fest, welcher Arbeitsumfang innerhalb eines Sprints möglich ist, um die Anforderungen zuverlässig zu realisieren.

[...]

---

¹ Vgl. Urbach, Nils, Ahlemann, Frederik, „Die IT-Organisation im Wandel: Implikationen der Digitalisierung für das IT-Management", 2017, S.4

² Vgl. Abolhassan, Ferri, „Was treibt die Digitalisierung?", 2016, S.5

³ Vgl. Burghardt, Manfred, „Projektmanagement - Leitfaden für die Planung, Überwachung und Steuerung von Projekten", 2012, S.12

⁴ Vgl. Urbach, Nils, Ahlemann, Frederik, „Die IT-Organisation im Wandel: Implikationen der Digitalisierung für das IT-Management", 2017, S.8

⁵ Vgl. Olbert, Sebastian, Prodoehl, Hans-Gerd, Worley, G., Christopher, „Agilität als Wettbewerbsvorteil - Der Agile Performer Index", 2017, S.5

⁶ Vgl. Jungtäubl, Marc, „(Gestaltung von) Arbeit, Organisation und Führung in komplexen und widersprüchlichen Systemen", 2019, S. 12.

⁷ Vgl. Schwaber, Ken, Sutherland, Jeff, „Software in 30 Tagen", 2014, S.7.

⁸ Vgl. Thiel, Marc, „Welche agile Methoden kann was?! Eine Übersicht zu Scrum, Kanban & Co", 2019, S.1

⁹ Vgl. Olfert, Klaus, „Projektmanagement", 2010, S.8

¹⁰ Vgl. Layton, Mark C., Ostermiller, Steven J., „Agiles Projektmanagement für Dummies", 2018, S.29.

¹¹ Vgl. Kusay-Merkle, Ursula, „Agiles Projektmanagement im Berufsalltag", 2017, S.11.

¹² Vgl. Layton, Mark C., Ostermiller, Steven J., „Agiles Projektmanagement für Dummies", 2018, S.30.

¹³ Vgl. Mathis, Christoph, Wintersteiger, Andreas, „Agile Developer Skills", 2011, S.23.

¹⁴ Vgl. Pfeffer, Joachim, „Grundlagen der agilen Produktentwicklung", 2019, S.25.

¹⁵ Vgl. Mathis, Christoph, Wintersteiger, Andreas, „Agile Developer Skills", 2011, S.23.

¹⁶ Vgl. Rose, Doug, „Das agile Unternehmen für Dummies", 2019, S.26.

¹⁷ Vgl. Preußig, Jörg, „Agiles Projektmanagement", 2015, S.9f.

¹⁸ Vgl. Kusay-Merkle, Ursula, „Agiles Projektmanagement im Berufsalltag", 2017, S.27.

¹⁹ Vgl. Simschek, Roman, Kaiser, Fabian, „Scrum - Das Erfolgsphänomen einfach erklärt", 2018, S.15.

²⁰ Vgl. Komus, Ayelt, Kuberg, Moritz, „Status Quo Agile 2016/2017", 2017, S.9.

²¹ Vgl. Simschek, Roman, Kaiser, Fabian, „Scrum - Das Erfolgsphänomen einfach erklärt", 2018, S.29.

²² Vgl. Gloger, Boris, „Scrum - Produkte zuverlässig und schnell entwickeln", 2016, S.6.

²³ Vgl. Pfeffer, Joachim, „Grundlagen der agilen Produktentwicklung", 2019, S.66.

²⁴ Vgl. Simschek, Roman, Kaiser, Fabian, „Scrum - Das Erfolgsphänomen einfach erklärt", 2018, S.31.

²⁵ Vgl. Eigene Darstellung in Anlehnung an Byland, Ari, „Kann ein Scrum-Team an mehreren Projekten arbeiten?", 2019, S.1.

²⁶ Vgl. Rose, Doug, „Das agile Unternehmen für Dummies", 2019, S.55.

²⁷ Vgl. Simschek, Roman, Kaiser, Fabian, „Scrum - Das Erfolgsphänomen einfach erklärt", 2018, S.32.

²⁸ Vgl. Simschek, Roman, Kaiser, Fabian, „Scrum - Das Erfolgsphänomen einfach erklärt", 2018, S.32f.

²⁹ Vgl. Eigene Darstellung in Anlehnung an Pfeffer, Joachim, „Grundlagen der agilen Produktentwicklung", 2019, S.72.

³⁰ Vgl. Pfeffer, Joachim, „Grundlagen der agilen Produktentwicklung", 2019, S.72.

³¹ Vgl. Eid, Patrick, „Agiles Projektmanagement und Scrum", 2019, S.32.

³² Vgl. Pfeffer, Joachim, „Grundlagen der agilen Produktentwicklung", 2019, S.75.

³³ Vgl. Pichler, Roman, „Scrum - Agiles Projektmanagement erfolgreich einsetzen", 2018, S.13.

³⁴ Vgl. Gloger, Boris, „Scrum - Produkte zuverlässig und schnell entwickeln", 2016, S.64.