Projektmanagement mit SCRUM. Der Schlüssel zur Effizienz?

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Theoretische Grundlagen von Scrum
2.1 Die Scrum-Rollen
2.2 Die 3 Scrum-Artefakte
2.3 Aktivitäten eines Sprints
2.3.1 Sprint Planning
2.3.2 Daily Scrum
2.3.3 Sprint Review
2.3.4 Sprint Retrospective

3 Empirische Forschung
3.1 Voranalyse
3.2 Beschreibung der Literaturrecherche

4 Schlussfolgerung
4.1 Potenziale von Scrum
4.1.1 Agile Produktentwicklung
4.1.2 Lerneffekte
4.1.3 Risikominimierung
4.2 Grenzen von Scrum
4.2.1 Prozessabwicklung
4.2.2 Personelle Risiken
4.2.3 Risikomanagement

5 Zusammenfassung und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Scrum-Prozess und Sprint im Überblick

Abbildung 2: Potenziale und Risiken bei Scrum (eigene Darstellung)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Die Digitalisierung ist wohl die größte Revolution, welche die Industrie jemals erlebt hat. Bei dem Begriff Digitalisierung handelt es sich um einen Wandel, der von einem analogen hin zu einem elektronisch gestützten Prozess mittels Informations- und Kommunikationstechnik vollzogen wird. Daraus resultiert, dass die Flexibilität eines Unternehmens immer mehr an Bedeutung gewinnt, da sich die Geschäftswelt zunehmend schneller verändert. Agile Methoden erleben in den letzten Jahren deshalb einen deutlichen Aufwärtstrend.¹

Laut Studien setzen 75% der Großunternehmen auf agile Projekte, da diese häufig erfolgreicher sind als klassische Projekte.² Die mit Abstand am meisten verbreitete agile Methode des Projektmanagements ist Scrum. Diese Methode wird unter anderem auch von bekannten Großkonzernen wie Google, Siemens sowie Bosch angewandt.³ Hierbei handelt es sich um ein Rahmenwerk, welches vorrangig bei komplexen Softwareentwicklungen zum Einsatz kommt. Es basiert auf den Annahmen zur empirischen Prozesssteuerung mit den drei Säulen Transparenz, Überprüfung (Inspektion) und Anpassung (Adaption).⁴

Diese Arbeit befasst sich mit der Untersuchung unserer Forschungsfrage, ob Scrum der Schlüssel zur Effizienz ist. Um die Relevanz des Themas zu verdeutlichen, werden sowohl die Potenziale als auch die Grenzen von Scrum erarbeitet und bewertet.

2 Theoretische Grundlagen von Scrum

Der Ursprung des Wortes Scrum kommt aus dem Rugby-Sport und bedeutet übersetzt so viel wie „Gedränge“. Es stellt eine Analogie für besonders erfolgreiche Produktentwicklungsteams dar, bei denen die Teams als kleine, selbstorganisierte Einheiten agieren.⁵ Ähnlich ist es auch bei der Projektmanagementmethode Scrum, deren Ablauf und Bestandteile im Folgenden näher erläutert werden.

2.1 Die Scrum-Rollen

Das Scrum Rahmenwerk verwendet lediglich drei zentrale Rollen: Product Owner, Entwicklungsteam und Scrum Master. Zusammen bilden sie das Scrum Team, unter denen alle Management-Funktionen mit bestimmten Verantwortlichkeiten eines agilen Projektes zugewiesen werden.⁶

Man soll zwar im agilen Projektmanagement immer flexibel sein, aber die Differenzierung der Rollen muss strikt eingehalten werden und ist von fundamentaler Bedeutung, um einen erfolgreichen Projektverlauf zu gewährleisten. Neben den zentralen Rollen existieren noch weitere Beteiligte wie Anwender, Stakeholder und das Management.⁷ Diese werden aber nicht als fester Bestandteil eines Scrum Teams gewertet und werden hier nur nebensächlich erwähnt.

Product Owner

Der Product Owner ist für den wirtschaftlichen Erfolg und die Qualität des Produktes verantwortlich. Dabei vertritt er die Interessen der Anwender und Kunden im Scrum-Projekt, die er bei der Gestaltung des Produktes im weiteren Sinne repräsentiert, in dem er sich bspw. am Umsatz eines Unternehmens orientiert und an der Nutzenwertmaximierung festhält.

Der Produktverantwortliche besteht aus einer Person und nicht aus einem Komitee. Er allein ist für das Product Backlog Management zuständig, welches das Sortieren und Priorisieren von Anforderungen umfasst in Abhängigkeit des höchsten wirtschaftlichen Wertes. D.h. er bestimmt die Produktentscheidungen wie die Eigenschaften oder die Reihenfolge der Implementierung für den nächsten Sprint, die das Entwicklungsteam umsetzen soll. Dabei bleibt er jedoch durch die aktive Mitgestaltung am Entwicklungsprozess rechenschaftspflichtig.⁸

Entwicklungsteam

Es besitzt mind. drei und maximal neun Teammitglieder, die für die Erfüllung der Produktfunktionalitäten und die Einhaltung der Qualitätsstandards verantwortlich sind. Zudem soll am Ende eines jeden Sprints ein einsatzbereites (Teil-)Inkrement, auch Increment of Potentially Shippable Functionality genannt, entstehen, welches im Sprint Review Meeting präsentiert wird und Feedback erhält.

Das Entwicklungsteam agiert selbständig und benötigt keinen Projektleiter im traditionellen Sinne. Das Team erledigt seine Backlogeinträge (projektbezogene Aufgaben, die sie erledigen müssen) wie sie es für richtig halten und lassen sich auch nicht vom Scrum Master beeinflussen.⁹

Scrum Master

Hierbei handelt es sich um einen Projektmanager, der als Moderator zwischen den verschiedenen Rollen vermittelt. Er nimmt die Position einer dienenden Führungskraft ein, die für das Gelingen des Projektes verantwortlich ist. Dabei arbeitet er eng mit dem Entwicklungsteam zusammen, gehört aber nicht dazu.¹⁰ Folglich gibt er keine Anweisungen und beurteilt das Team auch nicht. Seine Aufgaben liegen lediglich in der kommunikativen und vermittelnden Rolle zwischen PO¹¹ und Entwicklungsteam. Dazu gehören vor allem die Kontrolle und Betreuung des Prozesses im Falle von Störungen oder Hindernissen. Aufgrund dessen muss sich der Scrum Master durch starke Kommunikationsfähigkeiten auszeichnen, um bei mangelnder Kommunikation oder persönlichen Konflikten zwischen den Parteien vermitteln und schlichten zu können.¹² Neben den gut ausgeprägten kommunikativen Fähigkeiten, werden aber auch Teamfähigkeit, Engagement und situatives Führen vorausgesetzt.¹³

Bei der Integration von Scrum ist der Scrum Master häufig zu Beginn eine Vollzeitstelle, denn die Umstellung der Abläufe auf agile Prozesse, das Unterweisen in die jeweiligen Rollen, sowie das Teambuilding erfordert viel Zeit. Sobald die agile Methode jedoch einmal etabliert ist, hat der Scrum Master genügend Zeit und die nötige Erfahrung, um Scrum im kompletten Unternehmen bekannt zu machen. Dadurch kann er seine eigentliche Rolle als Change-Manager wahrnehmen und die Akzeptanz von Scrum im Unternehmen steigern.¹⁴

2.2 Die 3 Scrum-Artefakte

Product Backlog

Der PO pflegt das Product Backlog. Dieses stellt eine Liste mit allen funktionalen und nicht-funktionalen Anforderungen an einem Projekt dar, welche permanent weiterentwickelt werden. Idealerweise sollte jeder Eintrag wertvoll für den Benutzer des Produktes bzw. den Kunden sein. Ebenso kann es auch Ergebnisse, wie z.B. Bugfixes¹⁵ oder Testergebnisse, aber keine Aufgaben, enthalten. Diese obliegen einzig und allein dem Sprint Backlog.

Beim Product Backlog handelt es sich nicht um ein Lastenheft im klassischen Sinne, sondern um eine dynamische Liste, die kontinuierlich weiterentwickelt wird. Das bedeutet die Liste mit Anforderungen wird während der gesamten Projektlaufzeit gepflegt, wodurch immer neue Anforderungen innerhalb eines Sprints erledigt und hinzugefügt werden.¹⁶

Sprint Backlog

Aus den Anforderungen des Product Backlogs, welche der PO aufstellt, werden diejenigen priorisiert, die das Team innerhalb eines Sprints für realisierbar hält. Daraus ergibt sich eine Liste aller im laufenden Sprint durchzuführenden Aufgaben. Ein Sprint ist ein Arbeitszyklus, der zwischen zwei und maximal vier Wochen dauert und die Projektlaufzeit des Scrum Prozesses sinnvoll aufteilt. Jedoch muss der Sprint immer eine feste Länge haben und sollte nicht unterschiedlich lang sein. Nach Abschluss eines jeden Sprints sollte ein funktionsfähiges Produkt dem Auftraggeber vorgelegt werden. Das kommt zustande, in dem innerhalb eines Sprint Backlogs einzelne Aufgaben bearbeitet werden, welche als Ticket fungieren. Hierfür muss jedes Mitglied des Teams die Verantwortung für ein Ticket übernehmen. Zur besseren Visulisierung eines Sprint Backlogs werden meist Kanban-Boards¹⁷ verwendet. Ziel dabei ist die Vorhersage einer Prognose über das nächste funktionstüchtige Inkrement, welches im nächsten Kapitel erläutert wird.¹⁸

Product Inkrement

Am Ende eines jeden Sprints entsteht ein funktionsfähiges Zwischenprodukt, welches als Product Inkrement bezeichnet wird. Dieses verkörpert den Fortschritt in Richtung eines Zieles oder einer Vision und stellt die Summe aller Product Backlog Einträge dar, die während eines Sprints entstehen. Es zeigt von Sprint zu Sprint, wie man einen inkrementell wachsenden Wert für eine Zielgruppe aufbaut. Schlussendlich zählt der Zustand des Inkrements, denn dieser muss dem „Definition of Done“¹⁹ entsprechen, um in die Produktionsphase zu gelangen.²⁰

2.3 Aktivitäten eines Sprints

Scrum ist ein iterativer Prozess mit festen Terminierungen, auch Timeboxing²¹ genannt, die aufeinander aufbauen. Diese Timeboxen legen eine Dauer und Zeitrahmen für eine Arbeit fest, die bei Scrum als Sprints bezeichnet werden.²² Ziel eines jeden Sprints ist das Erreichen eines potenziell auslieferbaren Inkrements bzw. die Schaffung eines Mehrwerts für den Kunden und das innerhalb maximal 90 Tagen.²³ Jedoch muss immer die Möglichkeit der Flexibilität garantiert werden, sodass man zeitnah Anpassungen am Projekt vornehmen kann.

Der Aufbau eines Sprints besteht aus 4 Phasen: Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospektive.

2.3.1 Sprint Planning

Zu Beginn eines Sprints wird ein Sprint Planning Meeting abgehalten, bei dem die umzusetzenden Anforderungen für den kommenden Sprint ausgewählt werden. Dabei wird der PO vom Entwicklungsteam befragt, um eine realistische Einschätzung zu bekommen, wie viele Anforderungen sie realisieren können.

Infolgedessen stellt der PO dem Team das Product Backlog Item mit der höchsten Priorität vor, d.h. das Item mit den aktuell wichtigsten Anforderungen an das Produkt. Währenddessen schätzt das Team den dazugehörigen Aufwand für die Umsetzung des Items. Im Anschluss an diesen Schritt entscheidet das Team selbständig darüber, ob sie in der Lage sind innerhalb des nächsten Sprints noch weitere Product Backlogs zu bearbeiten bzw. legen die zu erfüllende Anzahl der Product Backlogs fest. Die Reihenfolge der Anforderungen bleibt jedoch dem PO allein überlassen.²⁴ Im Gegenzug berät das Team den PO bei möglichen Kostenersparnissen der priorisierten Anforderungen. Schlussendlich entsteht eine Liste mit allen eingeplanten Anforderungen für den nächsten Sprint.²⁵

2.3.2 Daily Scrum

Beim zweiten Schritt handelt es sich, wie auch schon der Name verrät, um ein tägliches Treffen bzw. „Gedränge“ zwischen den Teammitgliedern. Es dürfen auch gerne Scrum Master und PO anwesend sein. Das Daily Scrum ist ein ca. 15-minütiges Stand-Up Meeting, wo jedes Teammitglied kurz resümiert was es seit dem letzten Daily Scrum erledigt hat, welche Aufgaben noch ausstehen oder welche Arbeitshemmnisse existieren. Dieses Vorgehen dient lediglich einem informativen Austausch aller Mitglieder, hierbei sollen keine Problemlösungen erarbeitet werden.²⁶ Mit Hilfe des Scrum Masters soll das gewährleistet werden, da er entstehende Diskussionen verhindert und zur Klärung in eine neue Besprechung einlädt.²⁷

2.3.3 Sprint Review

Im Sprint Review präsentiert das Entwicklungsteam seine Ergebnisse aus dem laufenden Sprint und der PO übernimmt die Prüfung der Erfüllung des “Definition of Done”. Das bedeutet er prüft, ob die einzelnen Product Backlog Items, die man sich in dem Sprint als Ziel setzte, auch erledigt wurden. Im Vergleich zum vorangegangenen Daily Scrum dürfen beim Sprint Review alle interessierten Stakeholder teilnehmen. Sie sind sogar sehr erwünscht, da sie Rückmeldungen geben sollen hinsichtlich der erarbeiteten Lösung des Teams und ihrer Übereinstimmung mit den Bedürfnissen der Nutzer, Kunden und der Zielgruppe.²⁸

2.3.4 Sprint Retrospective

Die letzte Aktivität eines Sprints ist das Sprint Retrospective Meeting. Dabei werden die bisherigen Sprints vom Team nochmals genauer betrachtet und es wird nach Optimierungspotenzialen gesucht.²⁹ Im Vordergrund dieser Retroperspektive steht vor allem die offene und ehrliche Kritik eines jeden Teammitglieds, weshalb dieses Meeting ausschließlich für das Entwicklungsteam und ihren Scrum Master, der das ganze moderiert, gedacht ist. Sollte in bestimmten Situationen die Anwesenheit eines Stakeholders erforderlich sein, dann muss dieser ausdrücklich zum Sprint Retrospective eingeladen werden.³⁰

Alle Schritte im Scrum-Prozess werden abschließend in folgender Abbildung zusammengefasst, um das Konzept grafisch zu verdeutlichen.

Die Abbildung wurde aus urheberrechtlichen Gründen von der Redaktion entfernt

Abbildung 1 : Scrum-Prozess und Sprint im Überblick

Quelle: www.business-wissen.de

3 Empirische Forschung

3.1 Voranalyse

Zu Beginn der wissenschaftlichen Forschungsarbeit haben sich die Autoren mit Hilfe des Scrum-Guides von den Scrum-Erfindern das Grundwissen zu dieser agilen Projektmanagementmethode aufgebaut. Anschließend wurden weitere Quellen, die das Thema Scrum kritisch betrachten, gesichtet. Die Forschungsfrage „Scrum-Schlüssel zur Effizienz?“ formulierten die Autoren auf Basis der intensiven Betrachtung von teils widersprüchlichen Aussagen zu Potenzialen und Risiken von Scrum.³¹

3.2 Beschreibung der Literaturrecherche

Um die aufgestellte Forschungsfrage beantworten zu können, entschieden sich die Autoren für eine Literaturrecherche. Das Forschungsthema wurde auf den Bereich Potenziale und Risiken bei Scrum eingegrenzt. Eine Generierung von Wissen über Interviews war aus Sicht der Autoren nicht zielführend, da Scrum in Einzelfällen sowohl sehr gute als auch sehr schlechte Ergebnisse hervorbringen kann. Somit sind Interviews einzelner Schlüsselnutzer von Scrum nicht repräsentativ für andere Anwendungen von Scrum. Die Literaturrecherche hingegen deckt ein größeres Feld von Scrum-Erfahrungen ab und erzeugt somit ein repräsentatives Bild. Des Weiteren wurde auf die Aktualität der verwendeten Quellen geachtet, sodass aktuelle Entwicklungen, wie die Digitalisierung, abgebildet werden. Nachfolgend werden Potenziale und Risiken relevanter Literaturquellen aufgezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 : Potenziale und Risiken bei Scrum (eigene Darstellung)

4 Schlussfolgerung

Um die Forschungsfrage „Scrum – Schlüssel zur Effizienz“ im letzten Teil der Arbeit beantworten zu können, werden im Folgenden die Erkenntnisse, welche aus dem Kapitel 2 „Theoretische Grundlagen von Scrum“ gezogen und im Kapitel 3 empirisch ausgearbeitet wurden, aufgeführt. Dafür wird zuerst auf die Potenziale von Scrum und anschließend auf seine Grenzen eingegangen.

[...]

---

¹ Vgl. Jacob 2016, online

² Vgl. Lutz 2018, online

³ Vgl. Hammerstein 2009, S.29

⁴ Vgl. Das Scrum Team (Hrsg.) o.J., online

⁵ Vgl. Staudacher, Langenbacher 2008, online

⁶ Vgl. Schwaber, Sutherland 2017, S.6

⁷ Vgl. Visual Minds (Hrsg.) o.J., online

⁸ Vgl. Schwaber, Sutherland 2017, S.6

⁹ Vgl. Schwaber, Sutherland 2017, S.7

¹⁰ Vgl. Petersen 2017, online

¹¹ Product Owner

¹² Vgl. Canditt et al. 2013, S.5

¹³ Vgl. Foegen 2014, S.62f.

¹⁴ Vgl. Gloger 2011, S. 88ff.

¹⁵ Beseitigung eines Softwarefehlers

¹⁶ Vgl. Staudacher, Langenbacher 2008, online

¹⁷ japanische Adaption der klassischen To-Do-Liste

¹⁸ Vgl. Rassek 2017, online

¹⁹ Definition of Done ist eine Liste von Fertigstellungskriterien, die das Entwicklungsteam zur Erstellung des Inkrements zu beachten hat.

²⁰ Vgl. Canditt et al. 2013, S.9

²¹ Timeboxing ist eine Technik zur Terminierung von Projekten, Vorgängen und Aktivitäten. Sie definiert einen Zeitrahmen und gewichtet den Faktor Zeit höher als die Faktoren Ressourcen und Inhalte

²² Vgl. t2informatik (Hrsg.) o.J., online

²³ Vgl. Wiegand 2015, online

²⁴ Vgl. Walter 2017, online

²⁵ Vgl. Trivadis (Hrsg.) o.J., online

²⁶ Vgl. Walter 2017, online

²⁷ Vgl. Trivadis (Hrsg.) o.J., online

²⁸ Vgl. Walter 2017, online

²⁹ Vgl. Trivadis (Hrsg.) o.J., online

³⁰ Vgl. Walter 2017, online

³¹ Risikomanagement