Erarbeitung eines Vorgehensmodells zur Einführung von Scrum in Großunternehmen

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Motivation und Zielsetzung
1.3 Methodisches Vorgehen bei der Erstellung des Modells

2 Theoretische Grundlagen
2.1 Traditionelle Vorgehensmodelle zur Software-Entwicklung
2.2 Agile Vorgehensmodelle zur Software-Entwicklung
2.3 Agiles Management-Framework Scrum
2.3.1 Sprint Planning
2.3.2 Sprint Run
2.3.3 Sprint Review
2.3.4 Sprint Retrospektive
2.4 Organisationsstrukturen in Unternehmen
2.5 Change Management

3 Das Enterprise Transition Model von Schwaber

4 Selektion eines Change Management Modells als Basis zur Integration des Enterprise Transition Model von Schwaber
4.1 Der Drei-Phasen-Ansatz von Lewin
4.2 Das 3W-Modell nach Krüger
4.3 Eight-Stage Process von Kotter
4.4 Die Modelle im Vergleich

5 Das integrative Vorgehensmodell
5.1 Phase 1: Wandlungsbedarf analysieren und Wandlungsbereitschaft initialisieren
5.2 Phase 2: Transitionsteam gründen
5.3 Phase 3: Umsetzungsweg entwickeln und Umsetzungsteams besetzen
5.4 Phase 4: Wandlungsfähigkeit herstellen und Transparenz erhöhen
5.5 Phase 5: Wandlungsbedarf umsetzen
5.6 Phase 6: Wandlungsqualität sichern und Wandlungsgeschwindigkeit erhöhen
5.7 Phase 7: Organisationsstruktur anpassen und Kultur verankern

6 Schlussbetrachtung
6.1 Ergebnisbetrachtung
6.2 Kritische Würdigung
6.3 Ausblick

7 Quellenverzeichnis

Abbildungsverzeichnis

Abbildung 1: Integration des Scrum Transition Process in ein Veränderungsmanagement-Modell

Abbildung 2: Envisioning und Sprintphasen in Scrum

Abbildung 3: Detailausschnitt der Phase: Sprint Planning

Abbildung 4: Detailausschnitt der Phase: Sprint Run

Abbildung 5: Detailausschnitt der Phase: Sprint Review

Abbildung 6: Detailausschnitt Sprint Retrospective

Abbildung 7: Formen der Primärorganisation

Abbildung 8: Beispiel einer einfachen funktionalen Organisationsstruktur

Abbildung 9: Beispiel einer divisionalen Organisationsstruktur

Abbildung 10: Beispiel einer einfachen Matrixorganisationsstruktur

Abbildung 11: Beispiel einer Projekthierarchie

Abbildung 12: Prozess und Prozesskette

Abbildung 13: Prozessmanagement als Primär- und Sekundärorganisation

Abbildung 14: Enterprise Transition Project Organization

Abbildung 15: Scrum Rollout Process

Abbildung 16: Der modellierte Scrum Adaption Process nach Schwaber

Abbildung 17: Die fünf Phasen des 3W-Modells

Abbildung 18: Modellierung des Eight-Stage Process

Abbildung 19: Beispielphase

Abbildung 20: Beispielaktivität

Abbildung 21: Gesamtmodellausschnitt mit Fokus auf Phase 1

Abbildung 22: Detailansicht Phase 1

Abbildung 23: Gesamtmodellausschnitt mit Fokus auf Phase 2

Abbildung 24: Detailansicht Phase 2

Abbildung 25: Stellenbesetzung des Transitionsteams

Abbildung 26: Gesamtmodellausschnitt mit Fokus auf Phase 3

Abbildung 27: Detailansicht Phase 3

Abbildung 28: Entscheidungsbaum zur Ableitung der Strategie

Abbildung 29: Prozess zur Realisierung des Wandlungsbedarfs

Abbildung 30: Darstellung von beispielhaften Scrum Rollout Teams

Abbildung 31: Gesamtmodellausschnitt mit Fokus auf Phase 4

Abbildung 32: Detailansicht Phase 4

Abbildung 33: Gesamtmodellausschnitt mit Fokus auf Phase 5

Abbildung 34: Gesamtmodellausschnitt mit Fokus auf Phase 6

Abbildung 35: Detailansicht Phase 6

Abbildung 36: Gesamtmodellausschnitt mit Fokus auf Phase 7

Abbildung 37: Detailansicht Phase 7

Abbildung 38: Beispielausschnitt einer funktionalen Organisationsstruktur mit Abbildung eines virtuellen Teams

Abbildung 39: Beispielausschnitt einer divisionalen Organisationsstruktur mit konsequenter Ausrichtung nach Scrum

Abbildung 40: Beispielhafte Hierarchisierung von Product Ownern in der Linienorganisation

Abbildung 41: Von der Unternehmensvision zur Produktanforderung

Abbildung 42: Beispielausschnitt einer Matrixorganisation mit Ausrichtung nach Scrum

Abbildung 43: Gegenüberstellung der Unterschiede zwischen Scrum und einer prozessorientierten Organisation

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Seit etlichen Jahren schon analysieren Wissenschaftler sowie Praktiker zugleich, wie es gelingen kann IT-Projekte so erfolgreich und effizient wie möglich abzuwickeln. Als Erfolg wird dabei ein Projekt gewertet, welches seine geplanten Projektziele innerhalb seines zuvor definierten Zeit- und Kostenrahmes erfüllt. Die ‚Standish Group’ hat seit 1994 schon mehr als 50.000 beendete IT-Projekte bzgl. ihrer Resultate beobachtet und statistisch erfasst. Davon wurden lediglich 32% aller durchgeführten und von der Stan- dish Group registrierten Projekte in ihrem ‚Chaos Report 2009‘ als erfolgreich gewertet. Der Erfolg von Projekten ist also auch heute noch keine Selbstverständlichkeit, sondern eher eine Ausnahme.¹

Die Untersuchungen des US amerikanischen Unternehmens belegen, dass die Software- krise der 1960er Jahre auch weiterhin nicht überstanden ist. Der damalige Ansatz, Soft- ware nach den Regeln der traditionellen Ingenieursdisziplinen zu entwickeln, führte zwar zu vielen ausgefeilten Vorgehensmodellen der Softwareentwicklung, jedoch nicht zum erhofften Erfolg.

Einen völlig anderen Ansatz bietet hierbei die ‚Agile Softwareentwicklung’, deren Fun- dament das agile Manifest bildet, welches sich durch folgende Prinzipien darstellen lässt:

“Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan”²

Diese Wertebasis wurde im Jahre 2001 von insgesamt 18 Autoren verfasst, ohne dabei jedoch in der Konsequenz weiterführende Methoden, Werkzeuge oder Rollen zu definieren, so dass sich in den Folgejahren verschiedene agile Vorgehensmodelle entwickelten. Eine der bekanntesten agilen Vorgehensmodelle ist ‚Scrum‘.

Die vorliegende Diplomarbeit zeigt die Herausforderungen, die Großunternehmen bei einer unternehmensweiten Einführung von Scrum derzeit haben und soll durch ein ei- gens entwickeltes Vorgehensmodell, eine zielgerechte Risikominimierung des Scheiterns anbieten.

1.1 Problemstellung

Der Übergang zu Scrum ist schwieriger als es viele Unternehmen vermuten und wird demzufolge häufig unterschätzt.³ Dies könnte vor allem daran liegen, dass das Regel- werk im Vergleich zu schwergewichtigen Prozessen zwar einfach zu erlernen ist, jedoch kaum Aussagen zur konkreten Implementierung in Unternehmen getroffen werden können.

Die notwendigen Änderungen zum Ausschöpfen des umfassenden Potentials welches Scrum zweifelsohne bietet, sind sehr weitreichend und verlangen nicht nur von der je- weiligen Entwicklungsabteilung tiefgreifende Verhaltensänderungen, sondern fordern auch von fast allen anderen Mitarbeitern eine Umstellung in ihren Denkmustern und Gewohnheiten.

Allein die Tatsache, dass Scrum selbstgesteuerte Teams voraussetzt, verlangt von Füh- rungskräften ein massives Umdenken ihrer eigenen Führungsrolle und ihres Führungs- verhaltens. Die typischen Managementaufgaben wie planen, koordinieren und kontrol- lieren werden beim Einsatz von Scrum nicht mehr durch einen sonst üblichen Linien- Manager oder Projektleiter durchgeführt, sondern durch das Team selbst übernommen. Aber das Team muss sich ebenfalls den Herausforderungen stellen, seine Arbeit selb- ständig teamintern zu managen und letztlich für seine Arbeitsergebnisse auch die Ver- antwortung übernehmen.

Der organisatorische Wandel von traditionellen Vorgehensweisen im Bereich des Soft- ware-Engineering hin zu Scrum und die damit notwendigen Änderungen von Gewohn- heiten und Arbeitsweisen werden höchstwahrscheinlich bei vielen Mitarbeitern auf Wi- derstand stoßen.

Für den Erfolg eines solchen Änderungsvorhabens ist der Umgang mit Widerständen - diese rechtzeitig zu erkennen und richtig zu beantworten - von entscheidender Bedeutung. Schafft man es nämlich in dem Zuge nicht, mit den Widerständen konstruktiv umzugehen, so ist das gesamte Änderungsvorhaben gefährdet.⁴

Der Scrum Miterfinder Ken Schwaber hat in seinem Werk ‚The Enteprise and Scrum‘ auf wenigen Seiten dargestellt, wie Scrum in Unternehmen eingeführt werden kann, al- lerdings keinen Ansatz mitgeliefert, wie die notwendige Umstellung der möglicherweise problematischen Denkhaltungen stattfinden und sinnvoll verankert werden soll.⁵

Auf der anderen Seite existieren sehr wohl verschiedene Transformationsmodelle, um kulturelle Änderungen im Unternehmen zu implementieren und durchzuführen. Ein integratives Vorgehensmodell, welches beide Aspekte berücksichtigt, existiert jedoch aktuell nicht.

1.2 Motivation und Zielsetzung

Aktuell existiert kein integratives Vorgehensmodell, welches eine Einführung von Scrum in Großunternehmen beschreibt und zeitgleich einen organisatorischen Wandel berück- sichtigt, so dass hier Nachholbedarf besteht. Da bislang 70-80% aller Änderungsvorha- ben ihr Ziel verfehlen, ist das Ziel der vorliegenden Diplomarbeit, ein integratives Vor- gehensmodell zu entwickeln, wodurch das Risiko eines Scheiterns signifikant minimiert werden kann.⁶

Dieses Modell soll Aufschluss über die Aktivitäten bei der Einführung von Scrum, de- ren zeitliche Abfolge und die Art und Weise der Ausführung geben. Zudem sollen die Artefakte, die während des Änderungsvorhabens entstehen, beschrieben werden. Das zu definierende Vorgehensmodell soll speziell für Großunternehmen >= 1000 Mitarbeiter zugeschnitten sein, welche ihren Hauptumsatz durch Softwareentwicklung generieren.

1.3 Methodisches Vorgehen bei der Erstellung des Modells

„Culture eats strategy for breakfast“⁷ ist ein häufig zitierter Spruch des Autors Peter Drucker. Glaubt man seiner These und möchte man ein Modell in ein Anderes integrieren, so kann es nur richtig sein, das strategische Modell in das Kulturändernde einzubetten und nicht umgekehrt.

Dazu werden zuerst verschiedene Veränderungsmanagement-Modelle analysiert und hinsichtlich ihrer Anwendbarkeit für das eigens zu entwickelnde Modell verglichen. Wird ein passendes Modell gefunden, so wird dieses speziell auf die Einführung von Scrum in Großunternehmen angepasst und der von Schwaber beschriebene ‚Scrum Transition Process‘⁸ darin integriert, so dass beide Modelle ineinander greifen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Integration des Scrum Transition Process in ein Veränderungsma- nagement-Modell

Quelle: Eigene Abbildung

Die Prozessmodellierung soll mit Hilfe der standardisierten, grafischen Spezifikationssprache für Geschäftsprozesse und Arbeitsabläufe ‚Business Process Modeling Notation’ (BPMN) erfolgen.⁹

2 Theoretische Grundlagen

Um die nachfolgenden Abhandlungen und Untersuchungen bzgl. der Einführung von Scrum in Großunternehmen in Gänze nachvollziehen zu können, sind zunächst die in diesem Zusammenhang relevanten und bedeutsamsten wissenschaftstheoretischen Grundlagen erklärungs- und erläuterungsbedürftig. Zu diesem Zweck sollen sie nun im folgenden Abschnitt grundlegend skizzierend erörtert werden.

Um die grundsätzlichen Unterschiede zwischen traditionellen und agilen Vorgehens- modellen zur Software-Entwicklung zu verstehen, werden die Charakteristika beider Typen vorgestellt. Da Scrum das konkrete Vorgehensmodell ist, welches in Unterneh- men eingeführt werden soll und auch die Kernkomponente des zu integrierenden Scrum Transition Process von Schwaber bildet, wird der gesamte Scrum-Prozess mit seinen Rollen, Artefakten und Meetings skizziert. Eine konsequente Einführung von Scrum, bei der das gesamte Potential ausgeschöpft werden soll, bedeutet für Mitarbeiter die Veränderung Ihrer Einstellungen und für Unternehmen die Veränderung ihrer Organi- sationsstruktur. Um diesen organisatorischen Wandel zu begleiten und zu unterstützen wird die Managementdisziplin Change Management angewendet und deren Ziele und Inhalte kurz umrissen. Zur Darstellung, wie Scrum in eine bestehende primäre Organi- sationsstruktur implementiert werden kann und welche Auswirkungen auftreten könn- ten, werden die Unterschiede der in der Literatur befindlichen Primärorganisationsstruk- turen vorab erklärt.

Damit wären die wesentlichen, für diese Arbeit relevanten Theoriekonzepte angeführt, die im Zusammenhang mit der Einführung von Scrum von Bedeutung sind.

2.1 Traditionelle Vorgehensmodelle zur Software-Entwicklung

Ein Vorgehensmodell in der Software-Entwicklung ist allgemein definiert als „(…)eine abstrakte Darstellung(…)“¹⁰, von „(…) Tätigkeiten, die zur Produktion eines Softwareproduktes führen.“¹¹ und kann nach verschiedenen Gesichtspunkten klassifiziert werden. Eine Möglichkeit ist die Differenzierung nach traditionell und agil.

Traditionelle Vorgehensmodelle basieren auf ingenieursmäßigem Vorgehen und sind dadurch charakterisiert, dass sie sehr genaue Vorgaben machen, auf welche Art und Weise ein definiertes Artefakt innerhalb einer vorgegebenen Phase zu erzeugen ist. Sie implizieren, dass Anforderungen an das zu erstellende Software-Produkt vor dessen

Realisierung umfassend spezifiziert sind und sich im Produkterstellungsverlauf nicht mehr ändern, da die Änderungskosten mit jeder weiteren Phase nahezu exponentiell steigen.¹² Die Phasen werden in der Regel sequentiell durchlaufen und erst vollständig abgeschlossen, bevor eine nächste Phase startet. Weit verbreitete Modelle, mit denen große Software-Entwicklungsprojekte durchgeführt werden und daher bei Großunter- nehmen häufig Anwendung finden, sind das Wasserfallmodell, der IBM Rational Uni- fied Process und das V-Modell XT.

2.2 Agile Vorgehensmodelle zur Software-Entwicklung

Agile Vorgehensmodelle basieren auf den Prinzipien des agilen Manifests und unter- scheiden sich von traditionellen Modellen im Wesentlichen dadurch, dass nur ein Mini- mum an Regelwerk und Rollen existiert, so dass die Art und Weise der Ausführung den Individuen obliegt.¹³ Ein weiteres Wesensmerkmal ist die inkrementelle Vorgehenswei- se, die beinhaltet, dass die Phasen Analyse, Spezifikation, Realisierung und Test nicht einmalig durchgeführt, sondern ständig für jede Iteration wiederholt werden. Dadurch wird ermöglicht, dass nicht alle Systemanforderungen bereits vor einer ersten Realisie- rung vorliegen müssen, sondern nur so viele, wie sich innerhalb eines definierten Zeit- fensters auch in lauffähige Software umsetzen lassen. Während die inkrementelle Vor- gehensweise auch in klassischen Vorgehensmodellen angewandt werden kann und eine Strategie bei der Systemintegration beschreibt, ein vordefiniertes Ziel in Teiletappen zu erreichen, beinhalten Agile Vorgehensmodelle auch noch die iterative Vorgehensweise, bei der sich das entstehende Softwareprodukt, durch sukzessive Verfeinerung und stän- dige Änderung, den Zielen und Wünschen des Auftraggebers annähern soll.

2.3 Agiles Management-Framework Scrum

Scrum wurde im Jahre 2001 von Jeff Sutherland, Ken Schwaber und Mike Beedle ent- wickelt und lässt sich als agiles Management-Framework beschreiben, um Software in- krementell und iterativ entwickeln zu können.¹⁴ Abgeleitet von den Prinzipien des „agi- len Manifests“¹⁵ und inspiriert von einem Artikel in der Harvard Business Review: „The

New New Product Development Game“¹⁶ haben die Autoren eine Anleitung zur Software-Entwicklung verfasst, die im Gegensatz zu schwergewichtigen Prozessen zwar eine Grundstruktur mit Rollen, Artefakten und Meetings beinhaltet, jedoch keine detaillierte Beschreibung zur Art und Weise der Entwicklung vorgibt. Diese wird vom Entwicklungsteam selbst auf empirischer Basis erarbeitet.

Folgende Rollen finden in jedem Scrum-Projekt Anwendung:

- Product Owner

Er repräsentiert den Kunden bzw. den Auftraggeber der zu erstellenden Soft- ware und erfasst dessen Bedürfnisse. Er ist verantwortlich für den Produkterfolg und erstellt und priorisiert kontinuierlich ein Prodcuct Backlog, welches ein aus User Stories bestehender Anforderungskatalog umfasst. Eine User Story ist eine Anforderung, die aus Kundenperspektive formuliert und mit Akzeptanzkriterien versehen wird, anhand dessen der Fertigstellungsgrad der zu entwickelnden Software erkannt werden kann.

- Entwicklungsteam

Das Entwicklungsteam besteht aus allen Personen, die aktiv an der Gestaltung der Software beteiligt sind. Dazu zählen aber mindestens Entwickler und Tester, es können aber auch weitere Personen wie z.B. Systemarchitekten oder Designer einbezogen werden. Aufgabe des Teams ist die Umsetzung der im Product Backlog abgebildeten User Stories zu einem vereinbarten Zeitpunkt. Eine Be- sonderheit des Teams ist, dass es selbstgesteuert arbeitet und innerhalb des Pro- jektrahmens keinem Projektleiter oder sonstigen Führungskräften fachlich un- terstellt ist.

- Scrum Master

Der Scrum Master ist verantwortlich für die Einhaltung des leichtgewichtigen Scrum-Regelwerks, moderiert alle Meetings und hilft dem Team beim Lernprozess und der Selbstorganisation. Er hat keine direkte Weisungsbefugnis und sollte möglichst keine weitere Rolle innerhalb des Teams einnehmen.

Ein Scrum-Projekt startet mit der Envisioning-Phase, in welcher der Product Owner eine Produktvision erstellt. Damit ist ein Dokument gemeint, welches Aufschluss über die strategische Ausrichtung des Produktes gibt. Außerdem werden darin die Zielgrup- pe(n), der Wettbewerbsstand und der potentiell zu erwartende Umsatz beschrieben. Ab- geleitet aus der Produktvision entsteht das initiale Product Backlog, dem mindestens so viele User Stories hinzufügt werden, dass das Produkt nach dessen Umsetzung einen Mehrwert für den Kunden bereitstellen würde und somit vermarktbar wäre. Anschlie- ßend beginnt die erste Iteration, die Sprint genannt wird und deren Länge je nachdem meist zwischen 2-4 Wochen beträgt. Jeder Sprint besteht aus vier sequenziell, nach glei- chem Muster ablaufenden Phasen.¹⁷

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Envisioning und Sprintphasen in Scrum

Quelle: Eigene Abbildung

In der Phase Sprint Planning entscheidet das Entwicklungsteam, welche User Stories es umsetzen möchte. Die Realisierung geschieht im sogenannten Sprint Run. Während die- ser Zeit sind die Anforderungen stabil und dürfen nicht verändert werden. Nach Ab- schluss der Realisierung erfolgt das Sprint Review, in dem die umgesetzten User Stories dem Product Owner als fertige Software demonstriert werden und dieser gleichzeitig die Möglichkeit bekommt, die fertige Software zu akzeptieren oder Teile abzulehnen. Die Sprintphase wird durch das Meeting Sprint Retrospective abgeschlossen. Hierbei be- trachtet das Team zusammen mit dem Scrum Master die letzten drei Phasen rückwir- kend und diskutiert gemeinsam, inwieweit dieser Prozess zu Zufriedenheit von Statten ging und/oder ob der Ablauf bzw. die einzelnen Arbeitsschritten als verbesserungswür- dig erscheinen. Anschließend beginnt die nächste Sprintiteration. Die vier Phasen wer- den in den folgenden Kapiteln noch genauer zu betrachten sein.

2.3.1 Sprint Planning

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Detailausschnitt der Phase: Sprint Planning

Quelle: Eigene Abbildung

Nachdem der Product Owner das Product Backlog mit ausreichend User Stories gefüllt und in ihrer Signifikanz absteigend priorisiert hat, ruft der Scrum Master ein Sprint Planning Meeting ein, welches auch von ihm moderiert wird. In der ersten Hälfte des Meetings präsentiert der Product Owner dem Entwicklungsteam seine am höchsten priorisierten User Stories und beantwortet die Fragen des Entwicklungsteams. Das Entwicklungsteam schätzt den jeweiligen Aufwand der einzelnen User Stories und legt fest, welche User Stories es bis zum Ende der nächsten Phase, dem Sprint Run, umset- zen möchte. Die umzusetzenden User Stories werden dann vom Entwicklungsteam in einem Sprint Backlog festgehalten. In der zweiten Hälfte des Meetings verlässt der Pro- duct Owner den Raum, während das Entwicklungsteam aus den User Stories konkrete Aufgaben ableitet und auf seine Mitglieder verteilt.

2.3.2 Sprint Run

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Detailausschnitt der Phase: Sprint Run

Quelle: Eigene Abbildung

In der Phase Sprint Run werden die User Stories aus dem Sprint Backlog vom Entwick- lungsteam in lauffähige und potentiell auslieferungsreife Software transformiert. Wäh- rend dieses fixen Zeitraums von wenigen Wochen, designt, kodiert, testet und doku- mentiert das Entwicklungsteam das Produkt mit einer Qualität, die es erlauben würde, es nach Sprint-Ende ohne weitere Anpassung an den Kunden auszuliefern zu können. Im Gegensatz zu traditionellen Vorgehensweisen des Software-Engineering, in denen häufig erst eine Phase wie beispielsweise Anforderungsspezifikation oder Realisierung vollständig durchlaufen wird, bevor die nächste daran anknüpft, finden in Scrum die Phasen Design, Kodierung, Test und Dokumentation in jedem Sprint Run erneut statt. Um den Entwicklungsfortschritt transparent zu machen und den Austausch wichtiger Informationen im Team sicherzustellen, findet täglich ein Daily Scrum-Meeting statt, in dem der Scrum Master jedem Teammitglied drei Fragen stellt:

1. „Was wurde seit dem letzten Daily Scrum erledigt?“¹⁸
2. „Sind während der Entwicklung Probleme aufgetreten - und wenn ja, welche waren das?“¹⁹
3. „Was ist das Ziel bis zum nächsten Daily Scrum?“²⁰

Falls während des letzen Daily Scrum Hindernisse aufgetreten sind, die die Produktivität des Teams negativ beeinflusst haben, ist es Aufgabe des Scrum Masters diese zu identi- fizieren und zu beheben.²¹ Dies können z.B. Beziehungskonflikte innerhalb des Teams sein, oder aber auch organisatorische Hindernisse, wie ein zu Scrum nicht kompatibles, jedoch obligatorisch zu nutzendes, unternehmensweites Vorgehensmodell zur Software- entwicklung.

2.3.3 Sprint Review

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Detailausschnitt der Phase: Sprint Review

Quelle: Eigene Abbildung

Das Sprint Review dient dazu, dem Product Owner und Stakeholdern das fertige Pro- duktinkrement vorzustellen und die entstandenen Arbeitsergebnisse zu begutachten. Während der Demonstration validiert der Product Owner jede umgesetzte User Story und hat das Recht sie zu akzeptieren oder abzulehnen. Falls eine User Story abgelehnt wird, dokumentiert er direkt im Dokument seine gewünschten Änderungen und gibt sie zurück in das Product Backlog.

2.3.4 Sprint Retrospektive

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Detailausschnitt Sprint Retrospective

Quelle: Eigene Abbildung

Direkt nach dem Sprint Review findet die Sprint Retrospektive statt, die zum Ziel hat„…die Zusammenarbeit innerhalb des Teams und die Anwendung des Prozesses zu verbessern“²². Der gesamte Sprint wird vom Entwicklungsteam ex post reflektiert und positive wie auch negative Erfahrungen auf Karteikarten festgehalten. Anschließend werden die wichtigsten Themen die die Produktivität des Teams stören einer Ursachen- analyse unterzogen, um Verbesserungsmaßnahmen abzuleiten. Der Product Owner ist fakultativ zu der Besprechung eingeladen. Bei Bedarf werden weitere Interessenvertreter eingeladen, die gegebenenfalls zur Behebung von Produktivitätsproblemen beitragen können. Nach dem Ende der Sprint Retrospektive beginnt der nächste Sprint erneut mit der Phase Sprint Planning.²³

2.4 Organisationsstrukturen in Unternehmen

Die Organisationsstruktur eines Unternehmens kann als ein System von „(…) unbefris- teten generellen Regelungen für die Verteilung von Aufgaben auf organisatorische Ein- heiten und die Gestaltung der Handlungsbeziehungen zwischen den Einheiten verstan- den (...)“²⁴ werden. Demzufolge kann zwischen zwei Dimensionen unterschieden wer- den: der Aufbau- und der Ablauforganisation. Die Aufbauorganisation beschreibt die dauerhafte hierarchische Struktur einer Organisation und legt somit allgemeine Rah- menbedingungen fest. Die Ablauforganisation hingegen bildet die Arbeits- und Infor- mationsprozesse hinsichtlich Raum, Zeit und Arbeitsmittel ab und legt diese fest. Die allgemeine Organisationsstruktur eines Unternehmens wird aus dauerhaften Organisa- tionseinheiten wie z.B. Stellen und Abteilungen gebildet, die in einem Über- und Unter- ordnungsverhältnis zueinander stehen und miteinander verflochten sind. Eine solche hierarchische Grundstruktur ist in sämtlichen Unternehmen - und das unabhängig von ihrer Größe - wiederzufinden und wird als Primärorganisationsstruktur bezeichnet. Da- mit stellt sie die Abwicklung des Kerngeschäfts sicher und dient hauptsächlich der Erle- digung von Routineaufgaben. Anhand des Spezialisierungsmerkmals auf der zweiten Hierarchieebene kann die Form der Primärorganisation unterschieden werden.²⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Formen der Primärorganisation

Quelle: In Anlehnung an Vahs, Dietmar, Organisation, 7. Auflage 2009, Schäffer Pöschel, S. 148

Die funktionale Organisation wird nach dem Verrichtungsprinzip gebildet und beruht auf dem Einliniensystem, so dass Mitarbeiter von genau einer direkt übergeordneten Stelle Weisungen und Arbeitsaufgaben erhalten. Die Bildung der einzelnen Funktions- bereiche erfolgt häufig in Anlehnung an primäre Prozessaktivitäten, welche sich aus dem Wertkettenmodell von Porter ableiten lassen.²⁶ Diese lassen sich mit den Attributen „Eingangslogistik, Operationen, Marketing & Vertrieb [und] Ausgangslogistik“²⁷ identi- fizieren. Eine etwaige Form der Organisation eignet sich besonders für kleine bis mit- telständige Unternehmen, deren Funktionsbereiche untereinander geringe Interdepen- denzen aufweisen.²⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Beispiel einer einfachen funktionalen Organisationsstruktur

Quelle: Eigene Abbildung

Die divisionale Organisationsstruktur gliedert sich in ihrer zweiten Hierarchieebene nach Geschäftsbereichen wie z.B. Länder, Kunden oder Produkte und folgt dabei eben- falls dem Einliniensystem. Es bilden sich sozusagen „Unternehmen in Unternehmen“, die vom Top-Management häufig eigene Umsatzverantwortung und hohe Entschei- dungskompetenzen für ihren Geschäftsbereich übertragen bekommen. Dieses Konzept setzte sich bereits Mitte des zwanzigsten Jahrhunderts durch und ist heute bei Großun- ternehmen weit verbreitet.²⁹

[...]

---

¹ vgl. Standish Group, CHAOS Summary Report 2009, Zugriff: 06.12.2010

² vgl. Beck, Kent et al., Manifesto for agile Software Development, Zugriff: 10.12.2010

³ vgl. Cohn, Mike, Agile Softwareentwicklung, 1. Auflage 2010, Addison-Wesley, S. 31

⁴ vgl. Doppler, Klaus et al., Change Management, 11. Auflage 2005, Campus Verlag, S. 324

⁵ vgl. Schwaber, Ken, Scrum im Unternehmen, 1. Auflage 2008, Microsoft Press Deutschland, S. 9-19 6

⁶ vgl. Vahs, Dietmar, Organisation, 7. Auflage 2009, Schäffer Pöschel, S. 394

⁷ Wright, Patrick M., The Chief HR Officer: Defining the New Role of Human Resource Leaders, 1. Auflage 2011, John Wiley & Sons, S. 215

⁸ vgl. Schwaber, Ken, The Enterprise and Scrum, 1. Auflage 2007, Microsoft Press, S. 13-15

⁹ vgl. Object Management Group, Business Process Modeling Notation V 1.1, Zugriff: 27.04.2011 8

¹⁰ Sommervielle, Ian, Software Engineering, 8. Auflage 2007, Pearson Studium, S. 95

¹¹ Sommervielle, Ian, Software Engineering, 8. Auflage 2007, Pearson Studium, S. 94

¹² vgl. Helmke, Hartmut et al., Einführung in die Software-Entwicklung: Vom Programmieren zur erfolgreichen Software-Projektarbeit, 1. Auflage 2007, Hanser Fachbuchverlag, S. 175

¹³ vgl. Schneider, Uwe et al., Taschenbuch der Informatik, 6. Auflage 2007, Hanser Fachbuch, S. 231

¹⁴ vgl. Pichler, Roman, Scrum, 1. Auflage 2008, dpunkt.Verlag, S.1

¹⁵ vgl. Beck, Kent et al., Manifesto for agile Software Development, Zugriff: 10.12.2010

¹⁶ vgl. Takeuchi, Hirotaka et al., The New New Product Development Game, 1. Auflage 1986, Harvard Business Review

¹⁷ vgl. Pichler, Roman, Scrum, 1. Auflage 2008, dpunkt.Verlag, S.57-62

¹⁸ Schatten, Alexander et al., Best Practice Software-Engineering: Eine praxiserprobte Zusammenstellung von komponentenorientierten Konzepten, Methoden und Werkzeugen, 1. Auflage 2010, Spektrum Akademischer Verlag, S.64

¹⁹ ebd., S. 64

²⁰ ebd., S. 64

²¹ vgl. Gloger, Boris, Scrum: Produkte zuverlässig und schnell entwickeln, 2. Auflage 2009, Hanser Fachbuch, S. 87

²² Pichler, Roman, Scrum, 1. Auflage 2008, dpunkt.Verlag, S. 111

²³ Vgl. ebd., S. 111-115

²⁴ Krallmann, Hermann et al., Systemanalyse im Unternehmen - Prozessorientierte Methoden der Wirtschaftsinformatik, 5. Auflage 2007, Oldenbourg Wissenschaftsverlag GmbH, S. 25

²⁵ vgl. Vahs, Dietmar, Organisation, 7. Auflage 2009, Schäffer Pöschel, S. 147-148

²⁶ vgl. Porter, Michael E., Wettbewerbsvorteile: Spitzenleistungen erreichen und behaupten, 6. Auflage 2000, Campus Verlag, S. 66

²⁷ Henze, Joachim et al., Allgemeine Betriebswirtschaftslehre: Aus Sicht des Managements, 1. Auflage 2001, UTB, S. 238

²⁸ vgl. Vahs, Dietmar, Organisation, 7. Auflage 2009, Schäffer Pöschel, S. 155

²⁹ vgl. ebd., S. 159