Anwendung von agilen Methoden nach Scrum im Projektumfeld eines globalen Unternehmens aus der Finanzbranche

Inhaltsverzeichnis

I. Inhaltsverzeichnis

II. ABKÜRZUNGSVERZEICHNIS

III. ABBILDUNGSVERZEICHNIS

1. EINLEITUNG

2. GRUNDLAGEN VON AGILEN METHODEN NACH SCRUM
2.1 HISTORISCHE BETRACHTUNG
2.2 ZIELE UND PRINZIPIEN VON SCRUM
2.3 ABLÄUFE UND VORGEHEN IN SCRUM
2.4 WERKZEUGE UND METHODEN IN SCRUM
2.4.1 Implizite Planungswerkzeuge 9
2.4.2 Burndown Chart 10
2.4.3 Burnup Chart 11
2.4.4 Scrum / Kanban Board 13
2.4.5 Zusammenfassung 13

3. ANWENDUNG VON SCRUM IN GRÖßEREN MAßSTÄBEN
3.1 FRAGESTELLUNGEN
3.2 MERKMALE DES SCALED AGILE FRAMEWORK
3.3 ROLLEN UND AUFBAU DES SCALED AGILE FRAMEWORK
3.3.1 Team Level 18
3.3.2 Program Level 20
3.3.3 Portfolio Level 21
3.3.4 Large Solution Level 22
3.4 ZUSAMMENFASSUNG UND BEWERTUNG DES SCALED AGILE FRAMEWORK
3.5 METHODEN UND EIGENSCHAFTEN VON LARGE-SCALE SCRUM
3.5.1 Allgemeines und Aufbau von Large-Scale Scrum 26
3.5.2 Principles 27
3.5.3 LeSS Framework 29
3.5.4 LeSS Huge Framework 33
3.5.5 Guides und Experiments 35
3.6 ZUSAMMENFASSUNG UND BEWERTUNG VON LARGE-SCALE SCRUM
3.7 VERGLEICH UND BEURTEILUNG VON SCALED AGILE FRAMEWORK UND LARGE-SCALE SCRUM

4. EIGNUNG VON SCALED SCRUM FÜR PROJEKTE DER FINANZBRANCHE
4.1 BESONDERHEITEN VON PROJEKTEN IN DER FINANZBRANCHE
4.2 ANWENDUNGSMÖGLICHKEITEN UND GRENZEN FÜR SCALED SCRUM IN PROJEKTEN DER FINANZBRANCHE
4.2.1 Anwendungsm ö glichkeiten f ü r das Scaled Agile Framework 47
4.2.2 Grenzen des Scaled Agile Framework 49
4.2.1 Anwendungsm ö glichkeiten f ü r Large-Scale Scrum 51
4.2.1 Grenzen von Large-Scale Scrum 54
4.3 ZUSAMMENFASSUNG UND BEWERTUNG DER EIGNUNG FÜR DIE FINANZBRANCHE

5. BEURTEILUNG UND GESAMTKONZEPTION EINER AGILEN METHODIK

Inhaltsverzeichnis

6. FAZIT

IV. ANHANG V

V. LITERATURVERZEICHNIS

II. Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

III. Abbildungsverzeichnis

Abbildung 1: Grundprinzipien des Agilen Manifests

Abbildung 2: Ablauf und Rollen in Scrum

Abbildung 3: Burndown Chart

Abbildung 4: Burnup Chart

Abbildung 5: Schematisches Beispiel eines Scrum Boards

Abbildung 6: House of Lean

Abbildung 7: SAFe DevOps

Abbildung 8: Essential SAFe - Team Level und Program Level

Abbildung 9: SAFe Portfolio Level

Abbildung 10: SAFe Large Solution Level

Abbildung 11: Vergleich der SAFe-Level

Abbildung 12: Bestandteile von Large-Scale Scrum

Abbildung 13: LeSS Principles

Abbildung 14: LeSS Framework

Abbildung 15: LeSS Huge Framework

Abbildung 16: Vergleich SAFe-LeSS

Abbildung 17: Herausforderungen im Bankensektor

Abbildung 18: Eignung Skalierter agiler Modelle im Bankensektor

Abbildung 19: Gesamt-Framework mit Elementen aus LeSS und dem SAFe

1. Einleitung

Das Vorgehen nach agilen Methoden genießt zurzeit große Aufmerksamkeit. Innerhalb der letzten Jahre hat sich aus einer Idee ein handfester Trend entwickelt, der in immer mehr Unternehmen jeglicher Größe und Branche Anklang findet. Auch die Methodik hat sich stetig weiterentwickelt und wird oft an die spezifischen Bedürfnisse des Anwenders angepasst.

Man verbindet mit agilen Methoden wie Scrum eine schnelle Reaktionsfähigkeit auf Probleme, flexible Anpassungen an wechselnde Anforderungen und die Loslösung von starren Projektplänen, die nach ein paar Monaten unter Umständen nicht mehr aktuell sind. Gerade für kleine Unternehmen und kreative Branchen klingt dies nach einem echten Mehrwert. Doch wie kann Scrum in größeren Maßstäben angewandt werden? In großen Unternehmen und Projekten scheint es nicht möglich zu sein, von umfangreicher, langfristiger Planung abzusehen. Welche Methodiken gibt es für Scrum im „large-scale“- Umfeld und wie gehen diese mit dem vermeintlichen Widerspruch um? Eine weitere Herausforderung stellt die Anwendung in vermeintlich konservativen, starren Branchen wie dem Bankensektor dar.

Die oben genannten Kriterien harmonieren nicht mit kurzfristigen, reaktionsfreudigen Plänen, wechselnden Erwartungen und unklaren Fertigstellungsterminen.

Welche Anwendungsmöglichkeiten gibt es also für Scrum und skalierte Versionen von Scrum in diesem Spannungsfeld? Wo liegen Potentiale und welche Grenzen bilden diese Rahmenbedingungen? Welche Abläufe, Werkzeuge und Methoden aus skalierten Versionen von Scrum sind hier sinnvoll und welche lassen sich nur schwer in die Praxis übertragen? Ist es möglich und sinnvoll, Scaled Scrum in großen Unternehmen der Finanzbranche anzuwenden?

Im Rahmen dieser Arbeit sollen diese Punkte näher beleuchtet und beurteilt werden. Anschließend wird eine Gesamtkonzeption erarbeitet, wie Scrum in globalen Unternehmen aus der Finanzbranche angewendet kann. Als Basis dient Fachliteratur aus den Disziplinen Agile Methoden, Scrum und Projektmanagement sowie aktuelle Beiträge aus dem Finanzsektor.

2. Grundlagen von agilen Methoden nach Scrum

2.1 Historische Betrachtung

„ Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestm ö gliche Software unter Ber ü cksichtigung der Kosten, der Funktionalit ä t, der Zeit und der Qualit ä t. “ ¹

Da es in der Anfangszeit der Software-Entwicklung nur wenige wissenschaftliche Phasenmodelle gab, wurden bekannte Vorgehensweisen aus anderen Branchen adaptiert. Vor allem das Wasserfall-Modell, welches ursprünglich aus dem produzierenden Gewerbe stammt, erlangte sowohl durch Herbert D. Benington als auch durch Dr. Winston W. Royce große Bekanntheit.² Mit zunehmender Bedeutung von Software in der Unternehmenswelt entwickelten sich auch die dazugehörigen Modelle weiter. Es entstanden beispielsweise das auf Iterationen basierende Spiralmodell oder auch das V-Modell, die beide auf dem klassischen Wasserfall-Modell aufbauen.³

Der Begriff Scrum tauchte zum ersten Mal bereits 1986 im Harvard Business Review auf. Hirotaka Takeuchi und Ikujiro Nonaka, Autoren eines Artikels der Januar-Ausgabe, übernahmen den Begriff aus dem Rugby, wo er für die Anhäufung und das Gedränge von Spielern steht. Schon in ihren Ausführungen lässt sich erkennen, dass sie eine andere Idee vom Projektablauf und den Rollen haben.⁴ Lernende Teams ohne strenge Führung und Organisation von außen sowie mehrere Entwicklungsphasen, die sich iterativ einem Ziel annähern, sollen zu einer höheren Erfolgsquote von Projekten führen.⁵

In den 1990er Jahren kamen neue Ansätze im Projektmanagement auf, welche die klassischen Rollen anders definierten. So sollte beispielsweise nach der Idee von Jeff Sutherland der Projektmanager statt eines kontrollierenden Managers eher als Moderator agieren. Das Entwickler-Team organisiert sich somit stärker selbst und bezieht diesen Projektmanager aktiv bei Problemen mit ein.⁶ Gleichzeitig bildeten sich auch in anderen Bereichen konträre Ansichten zu den bisherigen Modellen. Ein auf Monate und Jahre festgelegtes Vorgehen, das nicht genug Raum für gewollte oder ungewollte Änderungen hat, führt nach den Vorstellungen von Ken Schwaber zu vermeidbaren Mehraufwänden. Vielmehr sollten Pläne besser auf die sich ständig verändernden Anforderungen reagieren können - denn bei aller ausführlichen Planung bleibt die Zukunft doch unvorhersehbar.⁷

Die eingangs dieses Kapitels zitierte Passage formulierte der Softwareentwickler Ken Schwaber 1996 auf einer Fachkonferenz. Schwaber ließ sich bei seiner Definition von Scrum interessanterweise auch von der Chemie inspirieren. Dort wird zwischen definierten und empirischen Prozessen unterschieden: Wenn ein chemischer Vorgang vollständig erforscht ist, kann er in einem definierten Produktionsprozess ablaufen. Andernfalls nähert man sich mit empirischen Prozessen dem Ergebnis an.⁸ Übertragen auf die Softwareentwicklung bedeutet das, dass für Schwaber eine vollständig vorab planende Methodik wie das klassische Projektmanagement nur bei absoluter Klarheit über das Endergebnis und alle beeinflussenden Parameter Sinn macht.

Zusammen mit Jeff Sutherland, der seine Ideen von einer neuen Rollendefinition auch in Projekten schon erfolgreich getestet hatte, und seinem Kollegen Mike Beedle baut Schwaber in den darauffolgenden Jahren ein gemeinsames Verständnis von Scrum auf. Im Jahr 2001 verfassen sie gemeinsam mit 14 Kollegen das Agile Manifesto.⁹ Dort werden Ideen und Grundsätze einer zukünftigen Softwareentwicklung auf einen gemeinsamen Nenner gebracht und unter dem Begriff „agile Methoden“ gesammelt. Neben Scrum fließen auch Ansätze anderer, sich gleichzeitig entwickelnder neuartiger Methoden wie eXtreme Programming¹⁰, Rapid Application Development¹¹ oder Continuous Delivery¹² mit ein.

In den darauffolgenden Jahren setzt vor allem Ken Schwaber mit seinen drei Werken „Agile Software Development with Scrum“ (2001), „Agile Project Management with Scrum“ (2003) und „The Enterprise and Scrum“ (2007) viele Akzente für die weitere Entwicklung.

Auch Mike Cohn entwickelt Scrum im Jahr 2005 mit seinem Buch „Agile Estimation and Planning“ einen Schritt weiter, indem er sich explizit den Möglichkeiten von Scrum als Projektmanagement-Methode widmet. Gerade durch die sich zunehmend in der Literatur etablierende Rolle von agilen Methoden und Scrum wird auch das Interesse der Praxis stärker. Mittlerweile zählt die 2001 gegründete Nonprofit-Organisation Scrum Alliance mehr als 500.000 zertifizierte Mitglieder.¹³ Agile Projekte gehören in Unternehmen vieler Größen und Branchen zum Alltag und große IT-Dienstleister wie IBM fokussieren sich stark auf die Unterstützung und Durchführung von agilen Projekten. Vor allem Scrum hat sich bis zum heutigen Tag als weit verbreitete Praxis etabliert.¹⁴ Doch was genau macht Scrum aus und welche Werkzeuge werden dort verwendet?

2.2 Ziele und Prinzipien von Scrum

Der Begriff Agilität lässt bereits vermuten, dass es in agilen Projekten und damit auch in Scrum um Schnelligkeit geht. Diese Schnelligkeit bezieht sich dabei auf mehrere Aspekte des Projektes. Es wird in kürzeren Zeitabständen ausgeliefert, validiert und reagiert. Das erfordert von allen Beteiligten die Bereitschaft, schneller zu entscheiden, zu handeln und zu denken.¹⁵ Die Zusammenarbeit zwischen allen Projektmitgliedern wird durch diese kürzeren Abstände zwischen Auslieferungen umso wichtiger. Gleichzeitig ist auch eine häufigere und intensivere Beteiligung des Auftraggebers (d.h. des Kunden) die Folge. Dieser kann nach jedem ausgelieferten Stand Anpassungen durchführen. Das Agile Manifest basiert auf diesen vier Grundprinzipien:

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 1: GRUNDPRINZIPIEN DES AGILEN MANIFESTS¹⁶

Der Fokus liegt also erkennbar auf den Werten des linken Abschnitts. Die Werte auf der rechten Seite werden allerdings nicht vollständig ignoriert. Auch in Scrum gibt es Dokumentation und Planung. Gegenüber den Prinzipien links stehen sie dennoch im Hintergrund.¹⁷

Der Grund für die Auswahl bzw. die Abstufung liegt in dem Mehrwert, den die Aspekte zum Projekterfolg beitragen. Nach mehreren Studien ist die mangelnde Kooperation zwischen allen Projektbeteiligten der Hauptgrund für das Scheitern von Projekten.¹⁸ Gleichzeitig geben die Befragten das Silo- und Bereichsdenken als hindernd an.¹⁹ Mit der Anwendung von Scrum dagegen sehen 86% der Befragten einer dieser Studien einen relevanten oder gar entscheidenden Vorteil bei der besseren Einbindung aller Beteiligten. Weiterhin belegen 84% eine bessere Motivation der Mitarbeiter.²⁰ Somit sind die Individuen und Interaktionen und auch die Zusammenarbeit mit dem Kunden als kritisch für den Projekterfolg zu bewerten.

Darüber hinaus ist für knapp drei Viertel der Befragten die vorgegebene Projektplanung nicht realistisch und mehr als die Hälfte bemängeln gar eine komplett fehlende Zieldefinition.²¹ Die Priorität von Scrum liegt daher auf einer funktionierenden Software, die auf Veränderungen schnell reagieren kann, statt einem starren Plan zu folgen. 88% der Studienteilnehmer sehen die Kundenbedürfnisse besser abgebildet und fast ebenso viele bescheinigen Scrum realistischere Ziele.²²

2.3 Abläufe und Vorgehen in Scrum

Das dauerhafte, iterative Annähern an ein Ergebnis in Scrum findet in so genannten Sprints statt. Dies sind meist ein- bis vierwöchige Phasen, in denen das Projektteam die für diesen Zeitraum festgelegten Ziele umsetzt. Am Ende jedes Sprints wird ein Inkrement eines Produktes erzeugt, welches direkt an den Kunden ausgeliefert werden kann (potentially shippable product increment - PSPI).²³ Dies kann beispielsweise eine neue Funktionalität einer Software sein (neue Inhalte auf einer Oberfläche, neue Schnittstellen zu anderen Systemen).

Vor dem Beginn eines Sprints müssen die fachlichen Anforderungen definiert und priorisiert werden. Das ist die Aufgabe des Product Owners. Er hat die Vision der Lösung und entscheidet über die Gestaltung, Eigenschaften und Inhalte des Produktes. In sogenannten User Stories, die sehr anwenderbezogen formuliert sind und eher kurze, abschließbare Anwendungsfälle umfassen, dokumentiert der Product Owner seine Spezifikationen.²⁴ Jede User Story durchläuft dabei einen Qualitätssicherungsprozess, indem sie in regelmäßig stattfindenden Groomings oder Product Backlog Refinements (PBR) mit den Entwicklern besprochen wird.²⁵ Dort findet auch eine Aufwandsschätzung, Sortierung und Detaillierung der einzelnen Einträge statt. Darüber hinaus werden im PBR neue Einträge hinzugefügt oder veraltete gelöscht.²⁶ In Features können User Stories zum gleichen Themenkomplex zusammengefasst werden . Alle Features zusammengenommen bilden als Product Backlog die Gesamtheit der Features, die die Software beinhalten soll. Die einzelnen Einträge des Product Backlogs werden Product Backlog Items (PBI) genannt. Bevor der Sprint startet, entscheidet der Product Owner, welche User Stories bzw. PBIs in den nächsten Wochen umgesetzt werden sollen. Diese wandern aus dem Product Backlog in das Sprint Backlog des nächsten Sprints.²⁷

Bevor die Umsetzung im Sprint startet, werden im Sprint Planning verfügbare Kapazität und geschätzter Aufwand gegenübergestellt.²⁸ Der Product Owner priorisiert zwar im Vorfeld schon seine User Stories und stellt sie in das Sprint Backlog ein, was davon aber realistisch umgesetzt werden kann (u.a. auf Grund von Urlaub, Krankheit, anderen Tätigkeiten), wird erst im Sprint Planning von allen Beteiligten entschieden. Mit Start des Sprints übernimmt dann das Development Team, bestehend aus drei bis neun Mitgliedern, die Umsetzung der User Stories aus dem finalisierten Sprint Backlog .²⁹ Wie bereits vorgestellt agiert das Development Team selbstorganisiert und entscheidet frei über die Art und Weise, wie die Vorgaben des Product Owners aus den User Stories umgesetzt werden.³⁰ Im Verlauf des Sprints finden täglich kurze Treffen, Daily Scrums, statt. Hier gibt jedes Mitglied des Development Teams einen Einblick, woran man gerade arbeitet und ob dabei Probleme aufgetreten sind. So kann zum einen schneller auf Hindernisse reagiert werden, zum anderen werden auch Wissen und Erfahrung transparent innerhalb der Gruppe verteilt.³¹

Nach dem Abschluss eines Sprints werden die erzielten Ergebnisse im Sprint Review dem gesamten Projekt inklusive Stakeholdern vorgestellt.³² Auch hier steht die Transparenz im Vordergrund: Zum einen gegenüber dem gesamten Projektteam, zum anderen aber auch in Zusammenarbeit mit den Auftraggebern. So erhalten diese regelmäßige Einblicke in den aktuellen Stand der Software und können gezielt und frühzeitig eingreifen. Als Feedback- Forum dient die Sprint Retrospektive, in der die bisherige Arbeitsweise des Development Teams und auch die Zusammenarbeit mit dem Product Owner hinterfragt werden.³³

Eine weitere Rolle im Scrum, der Scrum Master, ist verantwortlich für die Einhaltung dieses Prozesses. Er ist auch der erste Ansprechpartner des Development Teams bei auftretenden

Problemen. Als „servant leader“ gibt er allerdings keine inhaltlichen Vorgaben, sondern tritt eher als Moderator auf. Die Einhaltung der Rollen und Methoden gehört zu seinen Hauptaufgaben. Somit lässt sich auch die These aufstellen, dass der Scrum Master in einem perfekt laufenden Scrum-Projekt wohl überflüssig wäre. Da dieser Idealfall in der Praxis aber nicht anzutreffen sein wird, kommt dem Scrum Master die wichtige Rolle des facilitators zu.³⁴

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 2: ABLAUF UND ROLLEN IN SCRUM³⁵

An einen Sprint schließt immer unmittelbar der nächste an, sodass sich die hier dargestellten Phasen überlappen. Es handelt sich also nicht um einen einmaligen Prozess, sondern um immer wiederkehrende Tätigkeiten. Während eines Sprints muss der Product Owner schon die Features für den nächsten Sprint vorbereiten und im PBR bzw. Sprint Planning mit dem Development Team und dem Scrum Master abstimmen.

2.4 Werkzeuge und Methoden in Scrum

2.4.1 Implizite Planungswerkzeuge

Die umfassende Dokumentation und starre Befolgung eines Plans wird in Scrum als weniger wichtig eingestuft - vor allem im Vergleich zum klassischen Projektmanagement.³⁶ Trotzdem gibt es eine Vielzahl von Tools und Methoden, mit denen der Ablauf eines ScrumProjektes geplant und geprüft werden kann. Wie wird also in agilen Projekten Übersicht und Verbindlichkeit geschaffen?

Zum einen gibt es typische Abläufe in Scrum, die bereits einen planerischen Anteil beinhalten. Das vor jedem Sprint stattfindende Sprint Planning spielt hier eine wichtige Rolle. Hier wird fachlich für die nächsten ein bis vier Wochen vorgegeben, welche Funktionalitäten am wichtigsten sind. Doch darüber hinaus findet durch den Abgleich zwischen geplantem Aufwand und tatsächlich verfügbarer Kapazität auch eine realistische Abschätzung dessen statt, was erreicht werden kann. Dabei kommt dem Product Owner eine wichtige Rolle zu. Er muss sicherstellen, dass die seiner Einschätzung nach wichtigsten Spezifikationen auch umsetzungsbereit sind. Gleichzeitig muss er Abhängigkeiten zu anderen Spezifikationen berücksichtigen und somit immer das Gesamtbild vor Augen haben. Nach dem gemeinsamen Erstellen des Sprint Backlogs ist dieses fix und nicht mehr veränderbar. Sollten trotzdem Änderungen notwendig sein (beispielsweise durch kurzfristige personelle Ausfälle oder unerwartete hoch priorisierte Fehlerbehebungen), wird dies wiederum gemeinsam zwischen Product Owner und Development Team vereinbart. Der Scrum Master nimmt hier wiederum die Rolle des Vermittlers und Problemlösers ein.

Es lässt sich festhalten, dass das Ergebnis des Sprint Plannings eine Art kurzfristiger, realistischer und dafür sehr genauer und verbindlicher Projektplan ist.³⁷ Betrachtet man einen Sprint in der Zukunft, ist dort das Bild noch variabler. Der Product Owner sollte inhaltlich schon wissen, was zukünftig umgesetzt werden sollte. Änderungen und neue Priorisierungen sind aber noch denkbar. Je weiter man sich schließlich in die Zukunft begibt, desto unpräziser

und skizzenhafter werden die Anforderungen. Dennoch bietet das Product Backlog eine erste Übersicht dessen, was bis zur Fertigstellung des Produktes noch umgesetzt werden muss.³⁸

2.4.2 Burndown Chart

Das Burndown Chart veranschaulicht den Fortschritt eines Scrum-Projektes. Es hilft den Projektmitgliedern, auf einen Blick eine Übersicht über den aktuellen Stand zu bekommen. Während im Daily Scrum der Fortschritt einiger Tätigkeiten kommuniziert wird, kann auf dem Burndown Chart dieser Fortschritt auch dokumentiert werden.³⁹

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 3: BURNDOWN CHART⁴⁰

Als zweidimensionales Koordinatensystem wird hier Soll- und Ist-Aufwand über den Zeitverlauf miteinander verglichen. Die Ordinate bildet den Gesamtaufwand in Tagen ab, auf der Abszisse werden die Tage dargestellt. Der Gesamtaufwand zu Beginn des Sprints setzt sich aus der Summe der Aufwände für die einzelnen User Stories zusammen. Durch die vorgegebene Reihenfolge und das geplante Abschlussdatum entsteht so die Soll-Linie. Der tatsächliche Fortschritt lässt sich als Ist-Linie täglich dokumentieren. Das schafft Transparenz und zeigt auf, wenn Unterstützung beispielsweise durch den Scrum Master notwendig ist.

Das Burndown Chart lässt sich darüber hinaus auch auf die Bedürfnisse des Projektes anpassen. So kann man bei mehreren Development Teams auch ein teamübergreifendes Burndown Chart erstellen, um eine Art Gesamtprojekt-Status pro Sprint zu erhalten. Oder man erweitert die Darstellung auf mehrere Sprints, was den Detaillierungsgrad wiederum verringert und einen langfristigeren Überblick schafft. Je größer jedoch die Dimensionen des Burnup Chart werden, umso mehr geht dessen Übersichtlichkeit verloren. Es fehlt zudem bei Sprints, die weit in der Zukunft liegen, an Genauigkeit bei der Planung. Änderungen am Gesamtprojekt können so nur eingeschränkt abgebildet werden.⁴¹

2.4.3 Burnup Chart

Im Gegensatz zum Burndown Chart fokussiert sich das Burnup Chart mehr auf die Annäherung an ein gesetztes Ziel. So ist der Einsatz des Burnup Charts auch dafür geeignet, wenn es parallel mehrere Release-Stufen gibt. Der aktuelle Status des jeweiligen Releases kann am Burnup Chart auf einen Blick abgelesen werden.⁴²

Auch das Burnup Chart wird als zweidimensionales Koordinatensystem dargestellt. Statt des Gesamtaufwands werden auf der Ordinate die abgeschlossenen Arbeitspakete abgebildet (delivered items). Auf der Abszisse bleibt der Zeitverlauf die Messgröße, sie wird allerdings aus Gründen der Übersichtlichkeit meist in Sprints statt in Tagen gemessen. Anschließend wird in das Koordinatensystem die für das Release benötigte Anzahl der abgeschlossenen Arbeitspakete als Horizontale eingetragen. Anhand von Schätzungen können nun zwei weitere Begrenzungen erfasst werden:

Die maximale und die minimale Anzahl abgeschlossener Arbeitspakete pro Sprint. Es entsteht ein Trichter, der über den Verlauf von mehreren Sprints bis zum Abschluss des Releases führt. Zur Fortschrittskontrolle wird dann nach jedem Sprint die tatsächliche Anzahl der delivered items vermerkt.

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 4: BURNUP CHART⁴³

Auch nachträgliche Erweiterungen des Funktionsumfangs können als Scope-Erweiterung berücksichtigt werden. Neben der Kontrollfunktion kann man durch die Fixierung einer Skala am Burnup Chart noch zwei weitere Informationen ablesen: So wird beispielsweise nach 9 Sprints der Funktionsumfang zwischen 50 und 80 delivered items liegen. Möchte ein Stakeholder wissen, wann das Projekt 20 Arbeitspakete abgeschlossen hat, wäre die Antwort zwischen Sprint 3 und Sprint 4.⁴⁴

2.4.4 Scrum / Kanban Board

Das Scrum Board (auch als Kanban Board bezeichnet) ist eine physische oder digitale Tafel, an der einzelne Aufgaben als Zettel angebracht sind. Je nach Auslegung hat das Scrum Board drei bis fünf Status-Spalten. Zeilenweise wird jedes Teammitglied genannt. Das Scrum Board gibt also einerseits einen Überblick über den aktuellen Stand der jeweiligen Aufgabe, zum anderen zeigt es den Verantwortlichen. Während des Daily Scrums kann das Development Team den Status einer Aufgabe durch Verschieben der Zettel aktualisieren. Dadurch wird erreicht, dass jedes Teammitglied genau über die wesentlichen anstehenden Aufgaben Bescheid weiß. Darüber hinaus wird die Selbstorganisation gefördert.⁴⁵

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 5: SCHEMATISCHES BEISPIEL EINES SCRUM BOARDS⁴⁶

2.4.5 Zusammenfassung

Es lässt sich festhalten, dass es auch in Scrum eine Vielzahl von Planungs- und Kontrollwerkzeugen gibt. Der Eindruck, dass durch die geringere Wertschätzung von Planung und Dokumentation Ordnung und Nachvollziehbarkeit fehlen, wird so entkräftet. Statt ein vollständiges Projekt von Start bis Ende zu betrachten, beschränken sich die Methoden in Scrum aber meist auf einen kürzeren Zeitraum. Sie sind also an den iterativen Prozess der schrittweisen Erweiterung von Scrum angepasst und können auch auf Änderungen reagieren.

3. Anwendung von Scrum in größeren Maßstäben

3.1 Fragestellungen

Das Vorgehen nach Scrum mit einem Scrum Master, einem Product Owner und einem Development Team erhöht die Team-Produktivität, verkürzt die Produkteinführungszeit und eignet sich für wechselnde Priorisierungen von Aufgaben.⁴⁷ Die Methodik, die in Kapitel 2 vorgestellt wurde, ist auf den ersten Blick unkompliziert und eingängig. Isoliert in einem kleinen Unternehmen bzw. Projekt oder auf der berühmten „grünen Wiese“ betrachtet scheint Scrum ideal anwendbar zu sein.

In der Realität findet man diese Situation nur selten vor. Viele Unternehmen haben bereits eine bestehende IT-Landschaft. Gerade im Zuge der Digitalisierung bauen Firmen branchenübergreifend IT-Systeme und -Know-How auf.⁴⁸ Neben der bestehenden IT setzt auch die vorgegebene und teilweise über Jahre gewachsene Organisation und Struktur eines Unternehmens Rahmenbedingungen. Auch die Größe des Projektes und des Unternehmens selbst übersteigt meist das, was ein einzelnes Scrum Team leisten könnte.⁴⁹ Trotzdem hat Scrum für die Mehrheit der Unternehmen zentrale Bedeutung in der Softwareentwicklung und im IT-nahen Umfeld.⁵⁰

Es stellen sich also mehrere Fragen:

- Wie kann Scrum in größeren Maßstäben angewendet werden?

- Wie lässt es sich in die bestehenden Strukturen eines Unternehmens einfügen?

- Welche Voraussetzungen sind durch umliegende Systeme und Projekte gegeben?

- Wie werden teamübergreifende Abhängigkeiten und Risiken bewältigt?

- Bleiben die Modelle trotz Skalierung noch agil?

Anwendung von Scrum in größeren Maßstäben 15

Im folgenden Kapitel werden zwei Ansätze vorgestellt, die sich mit der Skalierung von Scrum auseinandersetzen. Es wird untersucht, inwieweit sie die oben genannten Fragen beantworten können.

3.2 Merkmale des Scaled Agile Framework

“As Scrum is to the Agile team, SAFe is to the Agile enterprise.”⁵¹

Das 2007 in einem Buch von Dean Leffingwell vorgestellte Scaled Agile Framework (SAFe) ist ein Konzept zur unternehmensweiten Umsetzung von agilen Methoden. In regelmäßigen Abständen wird eine neue Ausgabe des SAFe veröffentlicht, die neue Aspekte berücksichtigt oder bestehende anpasst. Die aktuelle Version 4.5 wurde im Juni 2017 publiziert und ist wie alle Inhalte des SAFe frei im Internet verfügbar.⁵² Das Scaled Agile Framework gibt für verschiedene Ebenen der Organisation Prozesse, Rollen und Strukturen vor. Es bedient sich dabei bestehender Methoden und Konzepte wie Scrum, Lean Management⁵³ und DevOps⁵⁴ und setzt diese zu einem Gesamtbild zusammen.

Essentiell für eine Anwendung agiler Methoden im gesamten Unternehmen ist ein gemeinsames Verständnis von Werten und Arbeitsweisen. SAFe setzt hier auf das so genannte lean-agile mindset. Das besteht zum einen aus den Grundprinzipien des Agilen Manifests, wie sie in Kapitel 2.2 erläutert wurden. Darüber hinaus sind die Werte aus dem so genannten „House of Lean“ Bestandteil. An der Bezeichnung lässt sich erkennen, dass dieses House of Lean stark an das Lean Management angelehnt ist. Dieses in den 1990er Jahren in der Automobilbranche entstandene Produktionskonzept fokussiert sich ausschließlich auf für die Wertschöpfung relevante Prozesse und Tätigkeiten und lässt Überflüssiges außen vor.⁵⁵

Seitdem wurde Lean häufig auf andere Branchen übertragen, unter anderem auch die Softwareentwicklung allgemein⁵⁶ und eben das Scaled Agile Framework speziell.

Das Leitbild von Lean im SAFe ist ebenfalls, den Mehrwert für den Kunden stets als Ziel zu sehen. Getragen wird dieses Leitbild von vier Säulen: Respekt für Menschen und Kultur, um Vertrauen und langfristige Partnerschaften aufzubauen, die Optimierung der Abläufe, um einen fortlaufenden Wertschöpfungsprozess zu gewährleisten und laufende Aufgaben (Work In Progress (WIP)) zu minimieren, das Schaffen von Freiräumen zur Stärkung von Innovation und schließlich eine dauerhafte Verbesserung des Produktes durch Hinterfragen des Status Quo. Als Basis dient eine Führung, die die Prinzipien des Lean Management unterstützt und auch die Werte des Agilen Manifests vorlebt.⁵⁷

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 6: HOUSE OF LEAN⁵⁸

Daneben sind im SAFe auch Elemente aus DevOps vorhanden. Der Begriff setzt sich aus Development und Operations zusammen und beschreibt eine Philosophie der engen Zusammenarbeit zwischen den entwickelnden Teams und dem IT-Betrieb. Im Normalfall gibt es zwischen diesen beiden Einheiten im Unternehmen einen Interessenskonflikt: Während die Entwicklung möglichst schnell und oft neue Features einer Software

veröffentlichen will, bedeutet für den IT-Betrieb jedes Release einer neuen Version ein potentielles Problem- und Ausfallrisiko. Über schnellere und dafür kleinere Releases und den Einsatz von automatisierten Lösungen (beispielsweise im Test) soll dieser Konflikt beseitigt werden. Im Fehlerfall wird durch entsprechende Architektur, Infrastruktur und Ressourcenkonzentration auf das Problem das schnelle Beheben oder Rückgängigmachen des Fehlers beschleunigt. Mit dem Einsatz von DevOps sind deutlich geringere Fehlerraten und schnellere Fehlerbehebungen möglich.⁵⁹

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 7: SAFE DEVOPS⁶⁰

Die Philosophie aus DevOps lässt sich auch an der im Scaled Agile Framework so genannten Continuous Delivery (CD) Pipeline erkennen. Durch wiederkehrende Validierung des fachlichen Nutzens, regelmäßige Integration der neuen Funktionalitäten und fortwährende Auslieferungen soll der Mehrwert mehr auf den Endanwender ausgelegt und ihm schneller zur Verfügung gestellt werden.⁶¹ Damit orientiert sich sowohl DevOps als auch das Scaled Agile Framework an einem iterativen Ansatz, wie er in Scrum zu finden ist. Die Kombination mit anderen Grundsätzen soll dazu führen, dass trotz deutlich höherer Auslieferungen die Stabilität der Software nicht gefährdet wird.

Zusammenfassend listet das Scaled Agile Framework neun Prinzipien auf, die als Ausgangspunkt für die Rollen- und Aufgabendefinition gelten.

1. Nimm eine wirtschaftliche Sicht ein

2. Denke systemisch

3. Gehe von Änderungen aus und behalte Optionen bei

4. Liefere inkrementell in schnellen, integrierten Lernzyklen

5. Baue Meilensteine auf die objektive Bewertung von funktionierenden Systemen

6. Visualisiere und beschränke laufende Aufgaben (WIP), verringere Losgrößen und steuere die Länge von Warteschlangen

7. Arbeite im Rhythmus und synchronisiere mit übergreifender Planung

8. Erschließe die intrinsische Motivation der Mitarbeiter

9. Dezentralisiere Entscheidungen⁶²

Mit diesen Vorstellungen, Werten und Einstellungen werden grundlegende Leitlinien definiert, die für eine erfolgreiche Anwendung des Scaled Agile Framework wichtig sind.

3.3 Rollen und Aufbau des Scaled Agile Framework

3.3.1 Team Level

In der aktuellen Version des SAFe gibt es vier Ebenen. Je nach Ebene sind strategische, taktische oder operative Planungs- und Detaillierungsgrade im Fokus. Im folgenden Abschnitt werden die einzelnen Level näher beleuchtet.

[...]

---

¹ Zitat von Ken Schwaber, gefunden in: Gloger: Scrum. Produkte zuverlässig und schnell entwickeln, S. 19.

² Vgl. Benington: Production of Large Computer Programs, S. 350-361; Royce: Managing the Development of Large Computer Systems, S. 328ff.

³ Vgl. Anhang 1 (Wasserfallmodell), Anhang 2 (V-Modell) und Anhang 3 (Spiralmodell)

⁴ Vgl. Takeuchi und Nonaka: Harvard Business Review. https://hbr.org/1986/01/the-new-new-product-deve- lopment-game

⁵ Vgl. ebd.

⁶ Vgl. Gloger: Scrum. Produkte zuverlässig und schnell entwickeln, S. 21.

⁷ Vgl. ebd., S. 19.

⁸ Vgl. ebd., S. 20.

⁹ Vgl. Beck et al: Manifesto for Agile Software Development. http://agilemanifesto.org/history.html

¹⁰ Auf best practices basierendes, iteratives Modell zur schrittweisen Entwicklung von Software.

¹¹ Auf dem Spiralmodell aufbauende Vorgehensweise, die mit frühen Prototypen schnell Erkenntnisse sam- melt.

¹² Durch kurze Auslieferungszyklen und automatisiertes Testen charakterisiertes Modell der Softwareent- wicklung.

¹³ Vgl. Scrum Alliance Webseite. https://www.scrumalliance.org/about-us

¹⁴ Vgl. GPM: Status Quo Agile, S. 6ff.

¹⁵ Vgl. Canty: Agile for Project Managers, S. 1; Kuster et al: Handbuch Projektmanagement, S. 35.

¹⁶ Quelle: Eigene Darstellung, nach Beck et al: Manifesto for Agile Software Development. http://agileman- ifesto.org/; Canty: Agile for Project Managers. S. 9-11.

¹⁷ Vgl. Beck et al: Manifesto for Agile Software Development. http://agilemanifesto.org/

¹⁸ Vgl. Hays, PAC: Von starren Prozessen zu agilen Projekten, S. 15; GPM: Erfolg und Scheitern im Projektmanagement, S. 8ff.

¹⁹ Vgl. Vgl. Hays, PAC: Von starren Prozessen zu agilen Projekten, S. 11; GPM: Erfolg und Scheitern im Projektmanagement, S. 8ff.

²⁰ Vgl. Hays, PAC: Von starren Prozessen zu agilen Projekten, S. 16.

²¹ Vgl. ebd., S. 15.

²² Vgl. Hays, PAC: Von starren Prozessen zu agilen Projekten, S. 16.

²³ Vgl. Schwaber und Sutherland: The Scrum Guide, S. 6.

²⁴ Vgl. ebd. , S. 5.

²⁵ Vgl. ebd., S. 14.

²⁶ Vgl. ebd., S. 14f.

²⁷ Vgl. Schwaber und Sutherland: The Scrum Guide, S. 15f.

²⁸ Vgl. ebd., S. 9.

²⁹ Vgl. ebd., S. 6f.

³⁰ Vgl. ebd., S. 6.

³¹ Vgl. ebd., S. 11.

³² Vgl. ebd., S. 12f.

³³ Vgl. ebd., S. 13.

³⁴ Vgl. Schwaber und Sutherland: The Scrum Guide, S. 7f.

³⁵ Quelle: Eigene Darstellung, nach Schwaber und Sutherland: The Scrum Guide, S. 3ff.

³⁶ Vgl. Beck et al: Manifesto for Agile Software Development. http://agilemanifesto.org/; Murthy: Agile in Software Projects: Where Does it fit? Where Doesn’t it? What about Hybrid Models?, S. 2.

³⁷ Vgl. Schwaber und Sutherland: The Scrum Guide, S. 9-11.

³⁸ Vgl. Schwaber und Sutherland: The Scrum Guide, S. 14f.

³⁹ Vgl. Schwaber: Agile Project Management with Scrum, S. 11f; Crowder und Friess: Agile Project Management: Managing for Success, S. 43.

⁴⁰ Quelle: Eigene Darstellung, nach Schwaber: Agile Project Management with Scrum, S. 12.

⁴¹ Vgl. Canty: Agile for Project Managers, S. 34; Crowder und Friess: Agile Project Management: Managing for Success, 2015, S. 43.

⁴² Vgl. Benefield, The Little Book of Scrum, S. 124.

⁴³ Quelle: Eigene Darstellung, nach Benefield, The Little Book of Scrum, S. 126.

⁴⁴ Vgl. Benefield, The Little Book of Scrum, S. 124ff.

⁴⁵ Vgl. Crowder und Friess: Agile Project Management: Managing for Success, S. 43.

⁴⁶ Quelle: Eigene Darstellung

⁴⁷ Vgl. Rigby et al: Agile innovation, S. 2.

⁴⁸ Vgl Bitcom Research: Digitalisierung der Wirtschaft, S. 5; Hays, PAC: Von starren Prozessen zu agilen Projekten, S. 6.

⁴⁹ Vgl. GPM: Status Quo Agile, S. 8.

⁵⁰ Vgl. ebd., S. 9ff.

⁵¹ Zitat von Dean Leffingwell, gefunden auf braintime.de. https://www.braintime.de/methoden/ueberblick- scaled-agile-framework-beratung/safe-grundlagen-kompakt/

⁵² Vgl. Cleveland: Scaled Agile, Inc. Releases SAFe® 4.5. http://www.prweb.com/re-

leases/2017/06/prweb14450991.htm; Leffingwell et al: Scaled Agile Framework. http://www.scaledagile- framework.com/

⁵³ Siehe dazu nächster Abschnitt, S. 15f.

⁵⁴ Siehe dazu S. 16f.

⁵⁵ Vgl. Womack et al: The Machine That Changed the World: The Story of Lean Production, S. 56.

⁵⁶ Vgl. Poppendieck: Implementing Lean Software Development: From Concept to Cash, S. 17ff.

⁵⁷ Vgl. Leffingwell et al: Scaled Agile Framework. http://www.scaledagileframework.com/lean-agile-mindset/

⁵⁸ Quelle: Eigene Darstellung, nach Leffingwell et al: Scaled Agile Framework. http://www.scaledagileframe- work.com/lean-agile-mindset/

⁵⁹ Vgl. Puppet Labs et al: 2015 State of DevOps Report, S. 3f.

⁶⁰ Quelle: Eigene Darstellung, nach Leffingwell et al: Scaled Agile Framework. http://www.scaledagileframe- work.com/devops/

⁶¹ Vgl. Leffingwell et al: Scaled Agile Framework. http://www.scaledagileframework.com/continuous-deliv- ery-pipeline/

⁶² Vgl. Leffingwell et al: Scaled Agile Framework. http://www.scaledagileframework.com/safe-lean-agile- principles/