BACHELOR-T - PRINCE2 · PRINCE2 und Scrum: Eine Analyse der Planung und Umsetzung beider...

Fakultät für Wirtschaftswissenschaften

BACHELOR-THESIS

PRINCE2 und Scrum: Eine Analyse der Planung und Umsetzung beider Projektmanagementmethoden als Kombination

(im DVZ M-V GmbH)

Abschlussarbeit zur Erlangung des Grades eines

BACHELOR OF SCIENCE (B. SC.)

in Wirtschaftsinformatik

der Hochschule Wismar

eingereicht von: Sebastian Bliesath

geboren am 24. Oktober 1983 in Schwerin

Matrikelnummer: 141615

Erstgutachter: Herr Prof. Dr. Reinhard J. Weck (Hochschule Wismar)

Zweitgutachter: Herr Arne Hennes, Dipl.-Inf. (DVZ M-V GmbH)

Schwerin, 26. Juni 2017

„Das Problem zu erkennen ist wichtiger als die Lösung zu erkennen,

denn die genaue Darstellung des Problems führt zur Lösung.“

Albert Einstein, Physiker

Bachelor-Thesis: PRINCE2 und Scrum – Eine Analyse der Planung und Umsetzung beider Projektmanagementmethoden als Kombination (im DVZ M-V GmbH)

Sebastian Bliesath | Wirtschaftsinformatik | Hochschule Wismar Seite 5

I. Vorwort

Während meines beruflichen Werdeganges hatte ich schon viele Berührungspunkte mit dem Managen

von Projekten. In der Fernmeldetruppe der Bundeswehr habe ich Schulungen, Ausbildungen und

abteilungsübergreifende Projekte sowohl für den militärischen als auch für den fachlichen Bereich

geplant, vorbereitet, durchgeführt, dokumentiert, nachbereitet und ausgewertet. Mit einem Projekt

wird in ähnlicher Weise verfahren. Es muss bereits vor, aber auch während der Durchführung

möglichst genau mit dem Fokus auf Wirtschaftlichkeit und unter der Berücksichtigung von Vorgaben

bezüglich Kosten, Zeit und Qualität geplant und kalkuliert bzw. überwacht werden. Weiterhin muss es

nach erfolgreichem, aber auch nach nicht erfolgreichem Abschluss nachbereitet und ausgewertet

werden. Die Dokumentation ist ebenso ein wichtiger Bestandteil des Projektmanagements, bei dem

die gesammelten Erfahrungen vollständig erfasst und der „Nachwelt“ zur Verfügung gestellt werden.

Projekte sind jedoch nicht nur Vorhaben in der Geschäftswelt oder Bestandteil vieler Studiengänge an

Hochschulen und Universitäten – sie begegnen uns schon im alltäglichen Leben. So ist die Planung

eines Tagesablaufes in gewisser Hinsicht ebenfalls schon ein kleines Projekt. Steht beispielsweise ein

wichtiger Termin an, so muss der Ablauf nach ihm ausgerichtet werden. Ein solcher Termin wird in der

Projektsprache als Meilenstein bezeichnet. Welche Aufgaben sind bis zu diesem Termin und/oder

danach zu erledigen? Wieviel Zeit und evtl. Geld steht dafür zur Verfügung? Gibt es Puffer oder

Alternativen? Welche Risiken können die Einhaltung des Termins in Gefahr bringen? Es ist uns vielleicht

nicht immer bewusst, aber prinzipiell planen und kontrollieren wir, um diese und auch weitere Fragen

bestmöglich beantworten zu können und den anstehenden Termin nicht zu überschreiten. Das

Projektmanagement befasst sich intensiv mit solchen Fragen und kann sich vieler Methoden und

Werkzeuge bedienen, um Initiierung, Planung, Steuerung und den Abschluss eines Projektes

bestmöglich zu verwirklichen. Doch welche Methoden und Werkzeuge sind wirklich hilfreich und

geeignet? Hängt das vom Projekttyp ab? Oder gibt es auch universelle Anwendungsmöglichkeiten?

Können Methoden und Werkzeuge darüber hinaus miteinander kombiniert werden? Die Suche nach

Antworten auf diese Fragen gab erste intrinsische Impulse für die Bearbeitung der Thesis.

Externe Motivatoren wurden ferner durch meine fachlichen Qualifikationen bestimmt. Die

Weiterbildung zum geprüften IT-Berater, bei der ich ein größeres Migrationsprojekt begleitet habe,

das Studium der Wirtschaftsinformatik, einige Lehrgänge bzw. Schulungen im Bereich

Projektmanagement und zuletzt ein Praktikum und die Werkstudententätigkeit als

Projektunterstützung im Datenverarbeitungszentrum Mecklenburg-Vorpommern GmbH1 (Abteilung

1 nachfolgend DVZ genannt


Seite 6 Sebastian Bliesath | Wirtschaftsinformatik | Hochschule Wismar

Managementberatung / Sachgebiet Projektmanagement) prägten und intensivierten nicht nur mein

Interesse in diesem Bereich, sondern führten des Weiteren zu Gesprächen mit den Betreuern dieser

Thesis, Herrn Prof. Dr. Reinhard J. Weck von der Hochschule Wismar und Herrn Arne Hennes, Dipl.-Ing.

vom DVZ (Abteilung Unternehmenssteuerung, Sachgebiet Controlling / Projekt- und

Servicekoordinierung), und schließlich zur Ausformulierung des Themas.

Die Herangehensweise für die vorliegende Thesis kann in gewisser Hinsicht mit dem Thema der

selbigen verglichen werden. Auf der einen Seite gibt es bestimmte Richtlinien2, die eingehalten werden

müssen (z.B. Bearbeitungszeit, Wort- und Seitenzahl, Zitierregeln usw.). Zudem muss die Arbeit

strukturiert werden (z.B. Gliederung, Inhalts-, Literatur- und Abbildungsverzeichnisse), um eine

bessere Übersicht zu gewähren und den roten Faden nicht zu verlieren. Das Einhalten von

Rahmenbedingungen und die strukturierte Vorgehensweise können mit den Grundprinzipien von

PRINCE2 verglichen werden, bei denen vorausschauend gehandelt wird.

Auf der anderen Seite lässt sich eine wissenschaftliche Arbeit inhaltlich nur schwer von A bis Z nach

einem geplanten Schema ausarbeiten. Nicht selten wird bei der Bearbeitung zwischen den Kapiteln

und Unterabschnitten hin und her gewechselt, z.B. wenn sich neue Erkenntnisse und/oder

Informationen ergeben. Ganze Textpassagen werden manchmal verschoben oder gelöscht und neu

erstellt. Zudem kann sich herausstellen, dass die anfangs geplante Herangehensweise zwischendurch

überdacht und ggfs. geändert werden muss. Da zu Beginn meistens noch nicht feststeht, was sich am

Ende manifestiert hat, ist hier eine Parallele zur Scrum-Philosophie sichtbar. Der Fokus liegt darauf,

durch ständige Anpassung und Optimierung der Zwischenergebnisse (bei Scrum in Rücksprache mit

dem Kunden; bei einer Thesis in Rücksprache mit den Betreuern) am Ende ein Produkt, in diesem Falle

eine abgeschlossene Bachelor-Arbeit, in bestmöglicher Qualität zu erstellen. Eine Kombination beider

Philosophien und Prinzipien ist somit auch für das wissenschaftliche Arbeiten sinnvoll und nötig, um

erfolgreich Resultate erzielen zu können.

Um eine bessere Lesbarkeit der vorliegenden Arbeit zu gewährleisten, wird auf eine

Genderkonformität der Wörter verzichtet. Die gewählte Form bezieht an den entsprechenden Stellen

im Text das andere Geschlecht vollumfänglich ein.

Alle in den Text aufgenommenen Zitate bekannter Persönlichkeiten entstammen der gleichen Quelle.3

2 siehe: https://www.fww.hs-wismar.de/fileadmin/hs- wismar/Fakultaet_fuer_Wirtschaftswissenschaften/allgemeine_infos/Richtlinie_zur_Anfertigung_wissenscha ftlicher_Arbeiten.pdf, letzter Zugriff am 11.06.2017 3 siehe: https://projekte-leicht-gemacht.de/blog/lesestoff/die-75-besten-projektmanagement-zitate/, letzter Zugriff am 15.05.2017



II. Inhaltsverzeichnis

I. Vorwort ................................................................................................................................ 5

II. Inhaltsverzeichnis ................................................................................................................. 7

III. Abbildungsverzeichnis ........................................................................................................... 9

IV. Tabellenverzeichnis ............................................................................................................. 10

V. Abkürzungsverzeichnis ........................................................................................................ 11

1. Einleitung............................................................................................................................ 13

1.1. Ausgangssituation ................................................................................................................. 13

1.2. Problemstellung .................................................................................................................... 13

1.3. Zielsetzung ............................................................................................................................. 15

1.4. Methodik der Arbeit .............................................................................................................. 16

1.5. Abgrenzung der Arbeit .......................................................................................................... 16

2. Methoden im Überblick ....................................................................................................... 17

2.1. PRINCE2 ................................................................................................................................. 17

2.1.1. Geschichtliches .............................................................................................................. 17

2.1.2. Grundzüge ..................................................................................................................... 17

2.1.3. Grundprinzipien ............................................................................................................. 18

2.1.4. Rollen und Aufgaben ..................................................................................................... 18

2.1.5. Die PRINCE2-Prozesse ................................................................................................... 19

2.1.6. Best Practice Award ....................................................................................................... 20

2.2. Scrum ..................................................................................................................................... 20

2.2.1. Geschichtliches .............................................................................................................. 21

2.2.2. Grundzüge (Agiles Manifest) ......................................................................................... 21

2.2.3. Grundprinzipien ............................................................................................................ 21

2.2.4. Rollen und Aufgaben ..................................................................................................... 22

2.2.5. Der Scrum-Prozess ......................................................................................................... 22

3. Gegenüberstellung der Methoden ....................................................................................... 25

3.1. Allgemeiner Vergleich ........................................................................................................... 25

3.2. Vergleich von Muster und Verhalten .................................................................................... 26

3.3. Vorteile PRINCE2 und Nachteile Scrum ................................................................................. 27

3.4. Vorteile Scrum und Nachteile PRINCE2 ................................................................................. 28



3.5. Vereinbarkeit der Basiskomponenten ................................................................................... 29

3.5.1. Prinzipien und Grundsätze ............................................................................................ 29

3.5.2. Themen / Aufgabenbereiche ......................................................................................... 30

3.5.3. Prozesse ......................................................................................................................... 30

3.6. Ergebnis der Gegenüberstellung ........................................................................................... 32

4. Der Weg zu agilem Projektmanagement .............................................................................. 35

4.1. Warum sollte ein Unternehmen „agiler“ werden? ............................................................... 35

4.2. Wann sollte Agilität eingesetzt werden? .............................................................................. 37

4.3. Anforderungen an agiles Projektmanagement ..................................................................... 38

4.4. Herausforderungen für den Einsatz agiler Methoden .......................................................... 41

4.5. Bezug zur Praxis ..................................................................................................................... 49

4.5.1. Andere Unternehmen ................................................................................................... 49

4.5.2. DVZ ................................................................................................................................ 51

4.6. Ergebnis der Analyse ............................................................................................................. 52

5. Umsetzung von hybridem Projektmanagement .................................................................... 53

5.1. Vorteile einer Kombination von PRINCE2 und Scrum ........................................................... 53

5.2. Notwendige Schritte vor einer Kombination ........................................................................ 55

5.3. Grundprinzip hybrider Vorgehensmodelle............................................................................ 56

5.3.1. Steuerungsmodell ......................................................................................................... 57

5.3.2. Durchführungsmodell .................................................................................................... 57

5.4. Vorschlag zur Umsetzung ...................................................................................................... 58

5.4.1. Steuerungsmodell PRINCE2 ........................................................................................... 58

5.4.2. Durchführungsmodell Scrum......................................................................................... 58

5.4.3. Kopplung innerhalb Phasen ........................................................................................... 59

5.4.4. Kopplung der Prozesse .................................................................................................. 60

5.4.5. Kopplung der Rollen ...................................................................................................... 60

6. Fazit .................................................................................................................................... 65

VI. Literaturverzeichnis ............................................................................................................. 69

VII. Ehrenwörtliche Erklärung .................................................................................................... 73

VIII. Anlagenverzeichnis ............................................................................................................. 75



III. Abbildungsverzeichnis

Abbildung 1 – Projektorganisation in PRINCE2 ..................................................................................... 18

Abbildung 2 – Rollen und Aufgaben in PRINCE2 ................................................................................... 19

Abbildung 3 – PRINCE2-Prozess ............................................................................................................ 20

Abbildung 4 – Rollen und Aufgaben in Scrum ....................................................................................... 22

Abbildung 5 – Scrum-Prozess ................................................................................................................ 23

Abbildung 6 – Umstellungsprozess auf agile Methoden ....................................................................... 49

Abbildung 7 – Promotoren für die Umstellung auf agile Methoden .................................................... 50

Abbildung 8 – Ergebnis- und Effizienzverbesserung durch agile Methoden......................................... 51

Abbildung 9 – Grundprinzip eines hybriden Vorgehensmodells ........................................................... 56

Abbildung 10 – Kopplungspunkte von PRINCE2 und Scrum ................................................................. 59

Abbildung 11 – Varianten des Product Owners in einer PRINCE2-Organisation .................................. 62

Abbildung 12 – PRINCE2-Prozess .......................................................................................................... 77

Abbildung 13 – PRINCE2-Prozess in einem Hybridmodell .................................................................... 77

Abbildung 14 – PRINCE2-Projektorganisation ....................................................................................... 78

Abbildung 15 – PRINCE2-Projektorganisation in einem Hybridmodell ................................................. 78



IV. Tabellenverzeichnis

Tabelle 1 – Vergleich PRINCE2 und Scrum – Allgemeines ..................................................................... 25

Tabelle 2 – Vergleich PRINCE2 und Scrum – Muster/Verhalten ........................................................... 26

Tabelle 3 – Vergleich PRINCE2 und Scrum – Vorteile PRINCE2 ............................................................. 27

Tabelle 4 – Vergleich PRINCE2 und Scrum – Vorteile Scrum................................................................. 28

Tabelle 5 – Abgleich der Prinzipien und Grundsätze von PRINCE2 und Scrum ..................................... 29

Tabelle 6 – Abgleich der Themen aus PRINCE2 mit Scrum ................................................................... 30

Tabelle 7 – Abgleich der PRINCE2-Prozesse mit Scrum......................................................................... 31

Tabelle 8 – Herausforderungen für den Einsatz agiler Methoden ........................................................ 45



V. Abkürzungsverzeichnis

Interne Firmenabkürzungen

DVZ Datenverarbeitungszentrum

FA Fachapplikation

FAO Fachapplikation / Ordnungswesen

FAT Fachapplikation / Technologie- und Applikationsmanagement

GE E-Government

GEI E-Government / Anwendungen und Integration

MB Managementberatung

MBP Managementberatung / Projektmanagement

USC Unternehmenssteuerung / Controlling, Projekt- und Servicekoordinierung

Weitere Abkürzungen

BCS Business Coordination Software

GPM Deutsche Gesellschaft für Projektmanagement e.V.

IT Informationstechnik

OGC Office of Government Commerce

OOPSLA Object-Oriented Programming, Systems, Languages & Applications

PMO Project Management Office

PRINCE Projects in Controlled Environments



1. Einleitung

1.1. Ausgangssituation

Projekte werden – nicht nur im IT-Bereich – immer komplexer, die Kundenwelt heterogener und

anspruchsvoller und der Markt konkurrenzfähiger. Das sind Gründe dafür, dass nicht jedes Projekt im

Sinne der Einhaltung von Kosten und Zeit gelingt. Ungefähr 60 Prozent aller Projekte scheitern, weil

die gesetzten Rahmen überschritten werden. 4 Das ist sowohl ein Fakt aus der Gegenwart als auch aus

der Vergangenheit. In zahlreichen Online-Artikeln ist nachzulesen, dass daran nicht nur einzelne

Personen, sondern das gesamte Projektumfeld und falsche bzw. unrealistisch geschaffene

Rahmenbedingungen Schuld sind. 5 6 7 Das fängt bei unzulänglicher Planung und unklar definierten

Projektzielen an, geht über sabotier-freudige Stakeholder und mangelnde Rückendeckung von Seiten

Geschäftsleitung hinaus und führt hin bis zu überflüssig geschaffener Komplexität. 8 Allem voran steht

die teilweise misslungene Kommunikation – sowohl innerhalb der eigenen Organisation, als auch

extern mit dem Kunden.

„Wenn über das Grundsätzliche keine Einigkeit besteht, ist es sinnlos,

miteinander Pläne zu machen.“

Konfuzius, chinesischer Philosoph

Es gilt entsprechend, zu analysieren, wie Kunde und Lieferant ihre gemeinsamen Ziele in einem Projekt

noch besser erreichen können. Dazu bedarf es der Bereitwilligkeit beider Seiten, Kompromisse

einzugehen und gewohnte Abläufe zu überdenken und ggfs. zu optimieren. Ein Aspekt dabei ist das

Nutzen von gegebenen Werkzeugen und Methoden des Projektmanagements, ein weiterer, deren

Vorzüge auf seine Ziele gerichtet anzupassen und sinnvoll dem Zweck entsprechend zu kombinieren.

Letzteres wird Gegenstand dieser Arbeit sein.

1.2. Problemstellung

In der Projektmanagementwelt treffen häufig klassische und agile Philosophien aufeinander. Klassisch

steht hier im Sinne von stabil, bewährt und traditionell, aber meist auch hierarchisch, konservativ und

4 siehe: http://www.silicon.de/41591125/60-prozent-aller-it-projekte-nicht-im-plan/, letzter Zugriff am 14.05.2017 5 siehe: https://www.gpm-ipma.de/fileadmin/user_upload/Know-How/Ergebnisse_Erfolg_und_Scheitern- Studie_2008.pdf, letzter Zugriff am 14.05.2017 6 siehe: http://d-nb.info/99200375X/34, letzter Zugriff am 14.05.2017 7 siehe: http://www.effectiveui.com/landingages/downloads/publications/EffectiveUI_Study_Integrated_ Thinking.pdf, letzter Zugriff am 14.05.2017 8 siehe: https://www.computerwoche.de/a/gescheiterte-it-projekte,2546218, letzter Zugriff am 14.05.2017



statisch. Agil hingegen steht für individuell, schlank und flexibel, aber auch unvorhersehbar,

unbestimmt und kurzsichtig. Standardisierte Projektmanagement-Methoden in Unternehmen können

aufgrund der steigenden Diversität von Projekten schnell an ihre Grenzen stoßen. Die Ursachen dafür

sind verschieden: Nicht jede Methode eignet sich für ein konkretes Projekt, die Anzahl von ihnen ist

meist begrenzt und/oder sie lassen sich nicht optimal adaptieren. Ein Scheitern des Projektes ist dann

schon halbwegs vorprogrammiert, da trotzdem zwangsläufig mit den Gegebenheiten gearbeitet

werden muss. Hinzu kommt, dass sich während des Projektes Änderungen ergeben können, die den

weiteren Ablauf beeinflussen und das bis dahin verwendete Vorgehensmodell eventuell in Frage

stellen. Daher ist es umso wichtiger, von Anfang an eine anpassungsfähige Methode zu wählen, die

unabhängig vom Projektumfeld für klassische und agile Projekte anwendbar ist.

Das DVZ ist IT-Dienstleister des Landes Mecklenburg-Vorpommern – und damit aller Ministerien und

nachgeordneten Behörden – und hat die Methode PRINCE2 im Jahr 2006 eingeführt. Vor dem

Hintergrund, dass es für alle Arten von Projekten einsetzbar ist, wurde es als Standard für das

Projektmanagement im eigenen Haus definiert. Seitdem wird es regelmäßig für alle Arten von

Projekten (IT-Infrastruktur-, Software-Entwicklungs-, Konzept- und Organisationsprojekte)

angewendet. PRINCE2 repräsentiert ein klassisches, aber modernes Vorgehen in Projekten, bei dem

jede Phase individuell und detailliert für sich geplant wird. Dabei muss jedoch immer das Gesamtziel –

der Nutzen, den das Projekt schaffen soll – unter Berücksichtigung der Rahmenbedingungen (Kosten,

Zeit und Qualität) im Auge behalten werden.

In Gesprächen mit A. Hennes (Sachgebiet USC) hat sich herausgestellt, dass einige Software-

Entwicklungsbereiche im DVZ agile Methoden, wie z.B. Scrum oder Kanban, nutzen, um schnell

brauchbare Zwischenergebnisse erzielen zu können. Gemeinsam mit dem Kunden werden die

Anforderungen regelmäßig und iterativ angepasst, damit das Endprodukt bestmöglich den

Kundenvorstellungen entspricht. Trotz der vielen Vorteile von agilen Methoden aus Entwicklersicht

sind diese nicht als Standard im Haus definiert, nicht zuletzt deshalb, weil die wenigsten Projekte im

DVZ die Entwicklung von Software beinhalten. Bei agilen Methoden rückt die Dokumentation in den

Hintergrund und sie lassen zudem kaum Vorhersagen in Hinblick auf Zeit- und Kostenplanung zu. Dies

widerspricht zum einen der PRINCE2-Philosophie und dem damit gesetzten Standard im Haus; zum

anderen entspricht es teilweise nicht den Erwartungshaltungen der Kunden, die hauptsächlich aus den

Bereichen Wirtschaft, Politik und Verwaltung kommen. Das Kundenumfeld des DVZ ist in der Regel

vom jeweiligen Haushalt getrieben und lässt daher wenig Spielraum hinsichtlich einer flexiblen

Budgetvereinbarung zu. Es kommt erschwerend hinzu, dass das Anwenden agiler Methoden eine



besondere Herausforderung in personeller und fachlicher Hinsicht darstellt, sowohl für das DVZ als

auch für den Kunden.

Seit 2016 werden interne und externe Projekte im DVZ weitestgehend zentral vom Sachgebiet MBP

(Abteilung Managementberatung / Sachgebiet Projektmanagement) aus geleitet. Ein weiteres

Problem besteht demnach darin, dass es den Projektleitern, die nach PRINCE2 zertifiziert und

ausgebildet sind, teilweise schwerfällt, Software-Entwicklungsprojekte zu managen, in denen sich die

jeweiligen Entwickler-Teams schon selbst mit Scrum oder Kanban eingearbeitet haben. Dadurch

können schnell Interessenkonflikte innerhalb der Projektorganisation zwischen dem Projektmanager

und seinem Team entstehen. Um solche Konflikte zu vermeiden, haben sich einige Projektleiter im

Sachgebiet MBP selbst agile Praktiken angeeignet und sind so in der Lage, mit den Entwickler-Teams

besser zusammenzuarbeiten.

Umgekehrt betrachtet besteht ebenso ein Konflikt, wenn ein Projektleiter ein Entwicklungsprojekt mit

Scrum oder Kanban durchführen möchte und das ihm zur Verfügung gestellte Team keine Erfahrungen

mit Agilität hat. Er müsste sein Team zunächst dahingehend schulen, was mit zusätzlichem Aufwand

verbunden wäre. Für Scrum wird zum Beispiel sehr ausgereiftes fachliches Know-How – also

Spezialistenwissen – vorausgesetzt. Die Ressourcen müssen zudem uneingeschränkt einem konkreten

Projekt zur Verfügung stehen können.

Somit ergeben sich nicht nur Probleme auf Management-Ebene, sondern ebenso auf der Arbeits- bzw.

Liefer-Ebene, welche es im weiteren Verlauf der Arbeit zu analysieren und bewerten gilt, um

Lösungsansätze zu schaffen.

1.3. Zielsetzung

„Ein klar formuliertes Problem ist schon halb gelöst.“

Charles Kettering, US-amerikanischer Wissenschaftler

Ziel der Arbeit ist es zum einen, die Notwendigkeit einer Optimierung der im DVZ vorherrschenden

Praktiken und Methoden im Projektmanagement zu verdeutlichen; zum anderen sollen diese

Methoden auf Kombinationsmöglichkeiten hin untersucht werden, um die dafür nötigen Folgeschritte

ermitteln zu können. Das Ergebnis der Analyse einer Kombination der beiden Methoden PRINCE2 und

Scrum soll darüber hinaus konkrete Lösungsansätze liefern, die das Projektmanagement im DVZ

nachhaltig verbessern.



1.4. Methodik der Arbeit

Bei der Herangehensweise werden die nötigen Informationen zum einen aus Gesprächen mit

Mitarbeitern aus dem DVZ und zum anderen aus Büchern und E-Books (z.B. das PRINCE2-Handbuch

der Firma Axelos oder der Scrum Guide von K. Schwaber und J. Sutherland), empfohlenen Online-

Magazinen und -Artikeln (z.B. ProjektMagazin, Computerwoche, GPM9), Online-Dokumenten und

selbst recherchierten Quellen (z.B. Informatik Aktuell) gewonnen, anschließend zusammengetragen

und aufbereitet. Zudem werden gesammelte Projektmanagement-Erfahrungen des Verfassers dieser

Arbeit mit einfließen.

Zunächst werden die beiden Methoden PRINCE2 und Scrum näher dar- und anschließend

gegenübergestellt. Das Ergebnis der Gegenüberstellung wird erste Hinweise auf mögliche

Kombinationsmöglichkeiten geben und die Sinnhaftigkeit einer geplanten Kombination verdeutlichen.

Ferner werden die Herausforderungen und Voraussetzungen für den Einsatz agiler Methoden als

Ergänzung zum bisherigen Projektmanagement untersucht, um zu prüfen, ob diese im DVZ erfüllt

werden können und welche Faktoren für eine Umsetzung eventuell geändert bzw. angepasst werden

müssen. Dazu werden in ausgewählten Bereichen im DVZ Interviews und Brainstormings (vgl. Anlage 1

– Beispiel Brainstorming) mit den Mitarbeitern durchgeführt. Aus den Gesprächen, die zudem weitere

Erkenntnisse in Hinblick auf bereits gesammelte Erfahrungen in agilen Projekten liefern sollen, wird

dann zusammen mit recherchierten Lösungsansätzen letztendlich ein mögliches Modell zur

Umsetzung einer Kombination von PRINCE2 und Scrum im DVZ vorgeschlagen.

1.5. Abgrenzung der Arbeit

In dieser Thesis wird ausschließlich die Kombination von PRINCE2 und Scrum behandelt. Andere agile

Methoden werden an einigen Stellen im Text erwähnt, aber nicht in die Betrachtung mit einbezogen.

Weiterhin wird keine neuartige Projektmanagement-Methode geschaffen, sondern vielmehr

untersucht, wie das DVZ von einer Kombination bereits existenter Methoden profitieren kann. Ansätze

für hybrides Projektmanagement gibt es schon und werden bereits in der Praxis umgesetzt (z.B.

PRINCE2 Agile10). Solche Ansätze gilt es auf die bestehenden Unternehmensstrukturen zu übertragen

und anzupassen.

9 GPM = Deutsche Gesellschaft für Projektmanagement e.V. 10 siehe: https://www.axelos.com/best-practice-solutions/PRINCE2/PRINCE2-agile, letzter Zugriff am 20.05.2017



2. Methoden im Überblick

In diesem Kapitel werden die Methoden PRINCE2 und Scrum näher dargestellt. Sinn und Zweck ist es,

ein Grundverständnis in Hinblick auf die Gegenüberstellung beider Methoden im darauffolgenden

Kapitel zu schaffen.

2.1. PRINCE2

PRINCE ist eine Abkürzung und steht für Projects in Controlled Environments – zu Deutsch: Projekte in

kontrollierten Umgebungen. Es ist eine strukturierte Projektmanagement-Methode, die jedem

Mitglied der Projektorganisation für jede Phase konkrete Handlungsempfehlungen an die Hand gibt

und den „Best Practice“-Gedanken11 verfolgt – die Methode soll auf Basis der Erfahrungen von

Benutzern und Anmerkungen zur Anwendung regelmäßig aktualisiert und verbessert werden (Prinzip:

Lessons learned).12

2.1.1. Geschichtliches

PRINCE wurde im Jahr 1989 in Großbritannien ursprünglich als Regierungsstandard für IT-Projekte

entwickelt. Nachdem festgestellt wurde, dass die Methode auch für andere Arten von Projekten

einsetzbar ist, wurde sie 1996 unter der Bezeichnung „PRINCE2“ als allgemeine Projektmanagement-

Methode veröffentlicht. Seitdem ist sie regelmäßig überarbeitet worden und läuft aktuell unter dem

„Release“ PRINCE2:2009. Mittlerweile ist sie die weltweit führende Methode zum Managen von

Projekten jeglicher Art. PRINCE2 definiert ein Projekt folgendermaßen: „Ein Projekt ist eine für einen

befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wurde, ein oder

mehrere Produkte in Übereinstimmung mit einem vereinbarten Business Case13 zu liefern.“ 12 14

2.1.2. Grundzüge 15

▪ Starke Ergebnis- und Qualitätsorientierung

▪ Lässt Soft-Skills und den Faktor Mensch außen vor

▪ Skalierbar und für jede Projektgröße geeignet

11 Best Practice = bestmögliche [bereits erprobte] Methode, Maßnahme o. ä. zur Durchführung, Umsetzung von etwas (http://www.duden.de/rechtschreibung/Best_Practice, letzter Zugriff am 13.05.2017) 12 siehe: https://de.wikipedia.org/wiki/PRINCE2, letzter Zugriff am 19.06.2017 13 Business Case = Szenario zur betriebswirtschaftlichen Beurteilung einer Investition (https://www.projektmagazin.de/glossarterm/business-case, letzter Zugriff am 13.05.2017) 14 Office of Government Commerce (OGC): Erfolgreiche Projekte managen mit PRINCE2. (Official PRINCE2 publication) The Stationery Office Books, Norwich, erste Auflage 2009 der deutschen Übersetzung der fünften englischen Ausgabe 2009, Seite 3. 15 siehe: http://dieprojektmanager.com/PRINCE2-grundprinzipien/, letzter Zugriff am 22.05.2017



2.1.3. Grundprinzipien16

▪ Fortlaufende geschäftliche Rechtfertigung (durch den Business Case)

▪ Lernen aus Erfahrungen (Prinzip: Lessons learned, Dokumentation der Erkenntnisse und

Erlebnisse)

▪ Definierte Rollen und Verantwortlichkeiten (vgl. Kapitel 2.1.4)

▪ Steuern über Managementphasen (vgl. PRINCE2-Prozess, Kapitel 2.1.5, Abb. 3)

▪ Steuern nach dem Ausnahmeprinzip (vgl. Eskalationsebenen, Kapitel 2.1.4, Abb. 2)

▪ Produktorientierung (Produkt geht vor Aktivitäten)

▪ Anpassen an die Projektumgebung (gut an Rahmenbedingungen anpassbar)

2.1.4. Rollen und Aufgaben

Abbildung 1 – Projektorganisation in PRINCE217

Im Gegensatz zu anderen Projektmanagement-Methoden trägt der Projektleiter bei PRINCE2 nur für

einen klar begrenzten Bereich die Verantwortung. Es sollen zusätzliche Verantwortliche aus dem

16 siehe: http://dieprojektmanager.com/PRINCE2-grundprinzipien/, letzter Zugriff am 22.05.2017 17 entnommen aus: Office of Government Commerce (OGC): Erfolgreiche Projekte managen mit PRINCE2. 2009



Unternehmensmanagement ins Projekt eingebunden werden. So wird die Gesamtverantwortung für

das Projekt durch den Auftraggeber und die Verantwortung für den Nutzen des Projektendproduktes

durch den Benutzervertreter getragen. Zusammen mit dem Lieferantenvertreter, der zuständig für die

Lieferung bzw. Erstellung der Produkte (u.a. durch die Bereitstellung der Ressourcen) ist, bilden diese

den Lenkungsausschuss (vgl. Abb. 1 vorherige Seite).

Allgemein betrachtet ergeben sich für die Rollen in einem Projektmanagement-Team nach PRINCE2

folgende Aufgaben:

Abbildung 2 – Rollen und Aufgaben in PRINCE218

2.1.5. Die PRINCE2-Prozesse

Der Fokus von PRINCE2 liegt auf dem Nutzen, den das initiierte Projekt dem Unternehmen stiften soll.

Ein erfolgreiches Projekt ist in diesem Sinne also erst dann gegeben, wenn neben den eingehaltenen

Zeit-, Kosten- und Qualitätstoleranzen auch der erwartete Nutzen - üblicherweise nach Projektende -

erreicht wurde. Die strukturierten Prozesse in PRINCE2 gliedern sich in die drei Management-Ebenen

Lenken, Managen und Liefern, die Bestandteil jeder Projektphase sind und auch in jeder Phase

durchlaufen werden. Die benötigten Rollen und ihre Aufgaben werden den verschiedenen Ebenen

zugeordnet (vgl. Abb. 3 nächste Seite).

18 entnommen von: https://www.tiba.de/sendf.php?i=002277-0.html, letzter Zugriff am 21.05.2017



Abbildung 3 – PRINCE2-Prozess19

2.1.6. Best Practice Award

Im Jahr 2016 wurde das DVZ von der Best Practice User Group Deutschland mit dem „Best Practice

Award“ – auch als „Oskar der Projektmanagementwelt“ bezeichnet – für den Einsatz von PRINCE2 in

einem größeren internen Projekt ausgezeichnet.20

2.2. Scrum

Scrum kommt aus dem Englischen und bedeutet so viel wie „[das] Gedränge“. Es ist weniger eine

Methode zum Managen von Projekten, als vielmehr ein Vorgehensmodell innerhalb eines Projektes

und wurde ursprünglich für die agile Software-Entwicklung entwickelt. Auch wenn Scrum in diesem

Bereich die häufigste Anwendung findet, ist es unabhängig davon und kann – wie PRINCE2 auch –

ebenso in anderen Bereichen eingesetzt werden. Scrum verfolgt den „Lean Management“-Gedanken21

– schlanke Denkprozesse sollen schnell und effektiv zum Erfolg führen. 22

19 entnommen aus: Office of Government Commerce (OGC): Erfolgreiche Projekte managen mit PRINCE2. 2009 20 siehe: http://www.bpug-deutschland.de/bpug-kongress-2016-pressetext, letzter Zugriff am 13.05.2017 21 Lean Management = Unternehmensführung nach einem Konzept, das auf die zielgerichtete Gestaltung der wirtschaftlichen Aktivitäten und den Abbau unnötiger Kosten ausgerichtet ist (http://www.duden.de/rechtschreibung/Lean_Management, letzter Zugriff am 13.05.2017) 22 siehe: https://de.wikipedia.org/wiki/Scrum, letzter Zugriff am 19.06.2017

Lenkungs-ausschuss

Projektleiter

Team-Manager + Team



2.2.1. Geschichtliches

Scrum lässt sich bis zum Anfang der 90er Jahre zurückverfolgen. Jeff Sutherland definierte die Rolle

des Projektleiters neu: Dieser sollte weniger managen und mehr moderieren. K. Schwaber

veröffentlichte im Jahr 1995 auf der OOPSLA23 den ersten Konferenzbeitrag zu Scrum. Darin erwähnt

er unter anderem: „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“. 24 Der Begriff „Scrum“ stammt letztendlich jedoch von I. Nonaka und H. Takeuchi,

die die Parallelen des „Gedränges“ zu der Sportart Rugby sehen: „Teams arbeiten als kleine, selbst-

organisierte Einheiten und bekommen von außen nur eine Richtung vorgegeben, bestimmen aber

selbst die Taktik, wie sie ihr gemeinsames Ziel erreichen.“ 22 25

2.2.2. Grundzüge (Agiles Manifest) 26

▪ „Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

▪ Funktionierende Software ist wichtiger als umfassende Dokumentation.

▪ Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten

Leistungsbeschreibungen.

▪ Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.“

2.2.3. Grundprinzipien 27

▪ „Transparenz: Fortschritt und Hindernisse eines Projektes werden regelmäßig und für alle

sichtbar festgehalten.

▪ Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und

sowohl das Produkt als auch das Vorgehen beurteilt.

▪ Anpassung: Anforderungen an das Produkt, Pläne und Vorgehen werden nicht ein für alle Mal

festgelegt, sondern kontinuierlich detailliert und angepasst. Scrum reduziert die Komplexität

der Aufgabe nicht, strukturiert sie aber in kleinere und weniger komplexe Bestandteile, die

Inkremente.“

23 OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) = jährliche Forschungskonferenz der ACM (Association for Computing Machinery) https://en.wikipedia.org/wiki/OOPSLA, letzter Zugriff am 13.05.2017) 24 B. Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, Seite 19. 25 übersetzt von http://www.scrumguides.org/history.html, letzter Zugriff am 13.05.2017 26 siehe: Agiles Manifest, von Schwaber und Sutherland unter https://www.scrumalliance.org/code-of-ethics, letzter Zugriff am 21.05.2017 27 siehe: http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-German.pdf, Seite 4, letzter Zugriff am 21.05.2017



2.2.4. Rollen und Aufgaben

Abbildung 4 – Rollen und Aufgaben in Scrum28

B. Radon, Agile Coach und Expert Scrum Master bei Netpioneer, beschreibt in einem Artikel von CIO29

die drei Rollen in Scrum folgendermaßen: „Der Product Owner achtet darauf, dass das Scrum Team

das Richtige entwickelt und entscheidet, welche Features als nächstes umgesetzt werden. Dadurch

sorgt er dafür, dass das bestmögliche Produkt entsteht.“ Aufgabe der Entwickler sei es laut Radon,

„das Produkt richtig zu entwickeln. Sie müssen in der Lage sein, das Produkt in der richtigen Qualität

zu liefern.“ Dieses entscheiden sie konkret in Abstimmung mit dem Product Owner. „Der Scrum Master

achtet unter anderem darauf, dass das Produkt in der angemessenen Zeit entsteht“ fügt Radon hinzu.

2.2.5. Der Scrum-Prozess

M. Foegen (Geschäftsführer der Consulting-Firma wibas), definiert den Scrum-Prozess wie folgt30: „Der

Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele

Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können.“

Laut Foegen ist ein „wesentlicher Teil der Anforderungen und der Lösungsansätze“ zu Beginn unklar.

Diese Unklarheit lassen sich seiner Auffassung nach aber beseitigen, „indem Zwischenergebnisse

geschaffen werden“, anhand derer sich die „fehlenden Anforderungen und Lösungstechniken

effizienter finden“ lassen als durch eine „abstrakte Klärungsphase“. Foegen ergänzt, dass in Scrum

28 entnommen aus: https://www.cio.de/a/projekt-entwicklung-mit-scrum,2974798, letzter Zugriff am 21.05.2017 29 siehe: https://www.cio.de/a/projekt-entwicklung-mit-scrum,2974798, letzter Zugriff am 21.05.2017 30 M. Foegen: Der Ultimative Scrum Guide. wibas, Darmstadt 2014, Seiten 112–113.



neben dem Produkt „auch die Planung iterativ und inkrementell entwickelt“ wird. „Der langfristige

Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint

Backlog) wird nur für den jeweils nächsten Zyklus (den Sprint) erstellt.“ schreibt Foegen und betont,

dass die Projektplanung damit „auf das Wesentliche fokussiert“ wird (vgl. Abb. 5, Anm. d. Verf.).

Abbildung 5 – Scrum-Prozess31

B. Gloger (Geschäftsführer Boris Gloger Consulting) ergänzt dazu in einem seiner Bücher32: „Ziel ist die

schnelle und kostengünstige Entwicklung hochwertiger Produkte entsprechend einer formulierten

Vision. Die Umsetzung der Vision in das fertige Produkt erfolgt nicht durch die Aufstellung möglichst

detaillierter Lasten- und Pflichtenhefte. In Scrum werden die Anforderungen in Form von

Eigenschaften aus der Anwendersicht formuliert.“ Gloger sagt, dass am Ende eines Sprints bei Scrum

„die Lieferung eines fertigen Teilprodukts (das Product Increment)“ steht, weist aber darauf hin, dass

sich dieses in einem Zustand befinden sollte, der auch an den Kunden auslieferbar ist.

Der Fokus bei Scrum liegt demnach darauf, den Kunden bzw. Auftraggeber so oft wie möglich in die

Entwicklung einzubinden, um die Anforderungen zu optimieren, zügig Zwischenergebnisse zu liefern

und zu verfeinern mit dem Ziel, ein einwandfreies Endprodukt zu übergeben – und das möglichst

kostenschonend.

31 entnommen aus K. Schwaber: Agiles Projektmanagement mit Scrum. Microsoft Press Deutschland, Unterschleißheim 2007. 32 B. Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, Seite 12.



3. Gegenüberstellung der Methoden

Die nachfolgende Gegenüberstellung wird nicht nur Gemeinsamkeiten und Unterschiede aufzeigen,

sondern auch jeweils Vor- und Nachteile beleuchten. Des Weiteren wird aus den gewonnenen

Erkenntnissen geschlussfolgert, inwieweit eine Kombination beider Methoden sinnvoll ist.

3.1. Allgemeiner Vergleich

Da beide Methoden in der Regel auf verschiedenen Ebenen zum Einsatz kommen (PRINCE2 auf

Management-Ebene, Scrum auf Entwickler- bzw. Produkt-Ebene), ist ein direkter Vergleich nur schwer

möglich. Es sollen durch den nachfolgenden Vergleich jedoch die allgemeinen Prinzipien beider

Methoden gegenübergestellt werden.

Tabelle 1 – Vergleich PRINCE2 und Scrum – Allgemeines:33

PRINCE2 Scrum

PRINCE2 liefert Management-Prozesse für jegliche Arten und Größen von Projekten.

Scrum ist ideal für Produktentwicklung (bewährt in Software-Entwicklung), für große Projekte aber weniger geeignet.

Das Projekt ist aufgeteilt in verschiedene Phasen. Die Phasenlänge richtet sich nach Anzahl und Komplexität der Produkte. Projekt und Phasen werden iterativ angepasst und ggfs. nachgeplant.

Das Produkt entwickelt sich „inkrementell“ und „iterativ“ durch Sprints. Diese haben einen festen Turnus (1 – 4 Wochen) und richten sich nach Reifegrad der Projektbeteiligten.

Grobplanung für das Gesamtprojekt, Detailplanung von Phase zu Phase

Wenig Grobplanung, Detailplanung in Iterationen / Sprints

Der Projektmanager definiert in Absprache mit den Spezialisten im Team die zu erledigende Arbeit.

Der „Product Owner“ definiert aus Kundensicht das „Was“, das Entwickler-Team das „Wie“ und den „Scope“ (Umfang) pro Iteration.

Wenn Planungen nicht eingehalten werden, wird der Projektverlauf durch Änderungsanträge angepasst.

Gesetzte Zeiten bleiben „fix“, der Scope wird ggfs. verringert.

Flexibilität wird durch Change-Management und Phasenübergänge gewährleistet.

Nach jeder Iteration (Sprint) ist eine Re-Planung möglich.

Prinzip „Lessons learned“, „Post mortem“: gesammelte Erfahrungen sollen durch intensive Dokumentation der Erkenntnisse / Ergebnisse der „Nachwelt“ zur Verfügung gestellt werden.

Nach jedem Sprint gibt es ein Review- und Retrospektiven-Meeting . Diese werden aber weniger dokumentiert.

33 siehe: https://scrumtrainings.files.wordpress.com/2014/01/scrumklassischesprojektmanagement.pdf, letzter Zugriff am 22.05.2017



PRINCE2 Scrum

Das Projekt ist nicht zu Ende, solange nicht alle vereinbarten Ziele und Anforderungen erfüllt bzw. erreicht wurden. Es wird jedoch Produkt-basiert gearbeitet, damit bereits erstellte Produkte jederzeit an den Kunden übergeben werden können.

Das Produkt entwickelt sich in Iterationen und kann jederzeit ausgeliefert werden, evtl. aber noch nicht in ausgereifter Qualität.

„Fertig“ wird durch Akzeptanzkriterien definiert. Daher ist eine rechtzeitige Abgrenzung ist im Planungsprozess nötig.

„Fertig“ „Done“ ist im Framework verankert und ein Muss.

3.2. Vergleich von Muster und Verhalten

Tabelle 2 – Vergleich PRINCE2 und Scrum – Muster/Verhalten: 34

PRINCE2 Scrum

Projektleiter: „Ich bin verantwortlich, dass Ressourcen optimal eingesetzt werden, um den Budget- und Zeitrahmen nicht zu überschreiten und in der gewünschten Qualität liefern zu können.“

Scrum Master: „Ich gebe Freiräume in einem Umfeld, das Transparenz und Feedback erzeugt. Dies stellt sicher, dass Wert erzeugt wird.“

Es wird nicht ohne Plan, Controlling und Dokumentation gearbeitet. Durch das vorgeschriebene Statusberichtswesen wird dieses vorangetrieben.

Intrinsische Motivation wird erreicht durch Vertrauen und Selbstorganisation. Controlling wird durch Reviews und Retrospektiven betrieben.

Durch intensives Risiko- und Change-Management und rechtzeitige Eskalation an die entsprechenden Ebenen werden eventuelle Schäden durch Fehler minimiert. Entsprechend den Erfahrungsberichten sollen Fehler in Folgeprojekten vermieden werden.

Von Fehlern soll schnell und nachhaltig gelernt werden. Durch intensive und offene Kommunikation im Team und mit dem Kunden können Fehler schnell identifiziert und gemeinsam behoben werden.

Der Fokus liegt auf dem Nutzen, den das Projekt schaffen soll und somit eher auf der Zeit nach dem Projekt. Dazu wird im während des Projektes ein intensives Anforderungsmanagement mit dem Kunden betrieben. Die Qualitätssicherung garantiert, dass das Produkt am Ende den Erwartungen des Kunden entspricht.

Der Fokus liegt darauf, ein Produkt liefern zu können, welches den Erwartungen des Kunden bestmöglich entspricht. Dazu werden die Anforderungen in enger Zusammenarbeit mit dem Kunden regelmäßig erarbeitet und iterativ erneuert / optimiert. Dies ist wichtig, da in Entwicklungsprojekten meistens am Anfang noch nicht alle Anforderungen konkret festgelegt werden können bzw. der Kunde noch nicht weiß, wie das Produkt am Ende aussehen soll.

34 siehe: https://scrumtrainings.files.wordpress.com/2014/01/scrumklassischesprojektmanagement.pdf, letzter Zugriff am 22.05.2017



3.3. Vorteile PRINCE2 und Nachteile Scrum

Tabelle 3 – Vergleich PRINCE2 und Scrum – Vorteile PRINCE2: 35 36

Vorteil PRINCE2 Nachteil Scrum

Der detaillierte Planungshorizont liegt bei 2 – 3 Monaten bzw. bei der nächsten Phase; das gesamte Projekt und das damit verbundene Ziel werden aber nie aus den Augen verloren. Projektplan und Business Case werden in jeder Phase aktualisiert, um zu gewährleisten, dass die Anforderungen des Kunden im vorgegebenen Rahmen erfüllt werden können.

„Die Zergliederung des Projektablaufs in Sprints mit eigenen Teilzielen“ birgt die Gefahr, „dass das Augenmerk immer nur auf den kleinschrittigen Fortschritt gelegt wird. Es besteht die Gefahr, das eigentliche Projektziel aus den Augen zu verlieren und mit Tunnelblick nur kurzfristige Lösungen zu schaffen.“

Durch ein intensives Anforderungsmanagement in Zusammenarbeit mit dem Kunden im Rahmen der Vorbereitungs- und Initiierungsphasen des Projektes wird gewährleistet, dass Projektdauer, Budget und Ressourcen so eingeplant werden, dass Abweichungen theoretisch nicht eintreten können.

„Da sich als Konsequenz der bei den Sprints erreichten Teilergebnisse oft genug Anforderungen verändern, sind Kosten-, Budget- und Terminplanung ebenfalls nur kleinschrittig möglich. Die Gesamtkosten des Projektes können im schlimmsten Fall aus dem Ruder laufen.“

Die Projektorganisation in PRINCE2 ist hierarchisch aufgebaut. Durch den Einsatz von Team-Managern können größere Projekte organisatorisch in Teilprojekte zerlegt werden. Dieses ermöglicht dem Projektmanager, Verantwortung abzugeben, um den Gesamtüberblick behalten zu können.

„Bei einem Großprojekt gibt es kaum Koordinierungsmöglichkeiten zwischen mehreren Teams, da das agile Projektmanagement den Prozess nur innerhalb eines Teams plant, nicht aber die Koordination zwischen verschiedenen Projektteams.“

Das intensive Statusberichtswesen, das sich über alle Ebenen in einer PRINCE2-Projektorganisation erstreckt, ermöglicht die ständige Kontrolle der Ergebnisse in Hinblick auf die Einhaltung von Kosten, Zeit und Qualität.

Scrum „reduziert die Kontrolle und basiert auf mehr Vertrauen. Daher hängen die Ergebnisse stark“ von den „sich selbst organisierenden Teams ab.“

Die umfangreiche Dokumentation von Ergebnissen und Erfahrungen kann Folgeprojekten zur Verfügung gestellt werden und es somit nachfolgenden Projektleitern ermöglichen, gemachte Fehler zu vermeiden.

Bei Scrum wird größtenteils auf eine formale Dokumentation verzichtet, um Zeit zu sparen. Das hat teilweise zur Folge, dass eventuell wichtige Erkenntnisse verloren gehen können.

35 siehe: http://blog.strategie-und-planung.de/agiles-projektmanagement, letzter Zugriff am 27.05.2017 36 siehe: https://www.computerwoche.de/i/detail/artikel/3064183/1/2501394/EL_mediaN1015D/, letzter Zugriff am 27.05.2017



3.4. Vorteile Scrum und Nachteile PRINCE2

Tabelle 4 – Vergleich PRINCE2 und Scrum – Vorteile Scrum: 37 38

Vorteil Scrum Nachteil PRINCE2

„Falls sich bei der Erreichung der Zwischenziele oder definierter Meilensteine“, z.B. nach der Erstellung eines Prototyps, „Änderungen am Gesamtziel ergeben, können diese schnell in die Planung des weiteren Projektverlaufs einfließen.“

Da die Anforderungen an das Endprodukt schon vor dem Beginn des Projektes klar definiert werden, sind Änderungen während des Projektverlaufes, u.a. durch Change-Management, zwar möglich, aber teilweise aufwändig und nur ungern zugelassen. Unter Umständen müssen bereits geschlossene Verträge geändert bzw. ergänzt und der Projektplan überarbeitet werden.

Durch einen „kontinuierlichen Informationsaustausch, insbesondere bei der Auswertung der Sprint-Ergebnisse und der Festlegung der unmittelbar nächsten Teilziele, entsteht höchstmögliche Transparenz: Alle Projektbeteiligten haben zu jedem Zeitpunkt vollständige Transparenz im Hinblick auf den aktuellen Entwicklungsstand. Durch die permanente Diskussion in der Gruppe schreitet das Erreichen des Projektziels etappenweise voran.“ Risiken, Fehler und Hindernisse werden dadurch rechtzeitig erkannt und können dementsprechend schnell behoben werden.

In einer PRINCE2-Organisation ist der Projektleiter alleiniger Dreh- und Angelpunkt, der alle relevanten Informationen sammelt, diese aufbereitet und sie an über- und untergeordnete Ebenen weitergibt. Da nicht alle Informationen für alle Projektbeteiligten relevant sind, herrscht keine vollständige Transparenz unter allen Mitgliedern der Organisation. Dadurch kann es durchaus vorkommen, dass sich nicht jeder Projektbeteiligte als Teil des Ganzen sieht, weil sein Erfolg nur begrenzt wahrgenommen wird. Zudem kann es passieren, dass Fehler nicht rechtzeitig erkannt werden.

Scrum lässt eine regelmäßige Lieferung von funktionsfähigen und qualitätsgesicherten Zwischenprodukten in kurzen (zwei bis vier Wochen) Intervallen zu. Dazu wird der Kunde intensiv in das Projekt eingebunden, da er am Entscheidungsprozess für das weitere Vorgehen und die Aktualisierung der Anforderungen stets beteiligt wird. Somit herrscht von Anfang an für Kunde und Lieferant eine vollständige und regelmäßige Transparenz über den Verlauf der Produktherstellung. Zudem bekommt der Kunde ein Gefühl der Mitverantwortung für die Qualität des zu erstellenden Produktes.

Bei PRINCE2 werden dem Kunden am Ende jeder Phase ein oder mehrere Produkte übergeben. Die Intervalle für Auslieferungen hängen von Anzahl und Komplexität der Produkte ab. Regelmäßige Auslieferungen sind aber möglich. Durch die typische Kunden-/Lieferantenbeziehung wird die Verantwortung für die Herstellung der Produkte allerdings an den Lieferanten (intern oder extern) delegiert. Das Vorgehensmodell zur Herstellung der Produkte wählt der „Lieferant“ selbst. Da PRINCE2 kein konkretes Vorgehen auf Liefer-Ebene vorschreibt, kann es unter Umständen passieren, dass am Bedarf des Kunden „vorbei gearbeitet“ wird bzw. der Kunde aus seiner Sicht nicht intensiv genug eingebunden wird.

37 siehe: http://blog.strategie-und-planung.de/agiles-projektmanagement, letzter Zugriff am 27.05.2017 38 siehe: https://www.computerwoche.de/i/detail/artikel/3064183/1/2501394/EL_mediaN1015D/, letzter Zugriff am 27.05.2017



3.5. Vereinbarkeit der Basiskomponenten

Für eine Kombination von PRINCE2 und Scrum ist es wichtig, dass sich nicht nur die Grundsätze und

Prinzipien, sondern auch die Aufgaben und Prozesse vereinen lassen.

3.5.1. Prinzipien und Grundsätze

Sowohl PRINCE2 als auch Scrum besitzen vordefinierte Philosophien, die konkret die jeweiligen

Ansätze beschreiben. Tabelle 5 zeigt, dass die Prinzipien von PRINCE2 und die Grundsätze von Scrum

miteinander harmonieren und sich sogar teilweise unterstützen.

Tabelle 5 – Abgleich der Prinzipien und Grundsätze von PRINCE2 und Scrum: 39

39 entnommen aus: https://www.projektmagazin.de/artikel/hybrides-projektmanagement-mit-prince2-und- scrum-teil-1_1105769, letzter Zugriff am 19.06.2017



3.5.2. Themen / Aufgabenbereiche

Im Folgenden werden die sieben Themen bzw. Aufgabenbereiche von PRINCE2 betrachtet und

untersucht, wie diese sich mit Scrum in einem möglichen hybriden Modell vereinen lassen. Die

folgende Tabelle macht deutlich, wie sich die Methoden sinnvoll ergänzen.

Tabelle 6 – Abgleich der Themen aus PRINCE2 mit Scrum: 40

3.5.3. Prozesse

Da PRINCE2 im Gegensatz zu vielen anderen Projektmanagement-Systemen ein auf seinen Prinzipien

basierendes und direkt ausführbares Projektvorgehen bietet und eine strukturierte Abfolge von

40 entnommen aus: https://www.projektmagazin.de/artikel/hybrides-projektmanagement-mit-prince2-und- scrum-teil-1_1105769, letzter Zugriff am 19.06.2017



Aktivitäten beinhaltet, wird es im folgenden Abgleich (vgl. Tabelle 7) als Vorgehensmodel für den

hybriden Ansatz betrachtet. Die vordefinierten Prozesse im Vorgehensmodell PRINCE2 werden auf

Vereinbarkeit mit Scrum geprüft und ggfs. angepasst.

Tabelle 7 – Abgleich der PRINCE2-Prozesse mit Scrum: 41

Die Prüfung auf Vereinbarkeit beider Methoden zeigt deutlich, dass PRINCE2 und Scrum sehr gut

miteinander harmonieren und sich nahezu ideal ergänzen, nicht zuletzt auch deshalb, weil PRINCE2

den Freiraum für den Einsatz agiler Methoden auf Liefer-Ebene zulässt. Die Harmonie zweier

Methoden ist eine Grundvoraussetzung dafür, in einem hybriden Modell aus klassischem und agilen

Projektmanagement sowohl die Anforderungen des Managements – und in Hinblick auf das DVZ auch

der Kunden – nach einer übergeordneten Projektsteuerung als auch die Anforderungen der

Entwicklerteams nach weitgehend selbstorganisierter Software-Entwicklung zu erfüllen.

41 entnommen von: https://www.projektmagazin.de/artikel/hybrides-projektmanagement-mit-prince2-und- scrum-teil-1_1105769, letzter Zugriff am 19.06.2017



3.6. Ergebnis der Gegenüberstellung42

Die Entwicklungstendenzen im modernen IT-Projektmanagement „scheinen erkennbar auf die

Anwendung agiler Methoden in der Kombination“ mit klassischen hinzudeuten. Letztlich zeigt die

Gegenüberstellung von PRINCE2 und Scrum, dass es nicht um die Entscheidung geht, ob klassische

durch agile Methoden ersetzt werden können oder umgekehrt. Vielmehr haben beide

Vorgehensmodelle „ihre Daseinsberechtigung innerhalb des Projektmanagements, bei dem diese ein

vorab definiertes Ziel mit den zur Verfügung stehenden Ressourcen bis zu einem festgelegten

Zeitpunkt realisieren sollen.“ Die Prüfung einer Vereinbarkeit hat zudem ergeben, dass sich beide

Methoden sehr gut ergänzen.

Die Wahl der Methode innerhalb des Projektmanagements hängt unter anderem von der Größe und

den Anforderungen eines Projektes ab. Formal gesehen eignet sich zum Beispiel ein Vorgehen mit

Scrum für kleinere Projekte mit bis zu neun Team-Mitgliedern, die sich selbst organisieren. Bei

größeren und komplexeren Projekten ist dann PRINCE2 zu favorisieren, da mit dieser Methode eine

bessere Koordination möglich ist. An dieser Stelle wird deutlich, dass eine Kombination – gerade in

Hinblick auf die Projektorganisation in größeren Projekten – sinnvoll ist, da das DVZ zum Großteil

Projekte mit mehr als zehn Team-Mitgliedern durchführt.

Nach Auswertung der Gegenüberstellung und der Prüfung einer Vereinbarkeit beider Methoden bietet

sich hinsichtlich der stets zunehmenden Komplexität von Projekten folgende Möglichkeit einer

Kombination an: PRINCE2 legt den Rahmen fest und behält das Gesamtprojekt unter Kontrolle, also

beispielsweise Budget, laufende Kosten, Meilensteine und Termine. Kleinere, geeignete Teilprojekte

bzw. Phasen oder die Lieferung bestimmter Produkte werden auf Management-Ebene weiterhin mit

PRINCE2 gesteuert, im Detail jedoch bei Bedarf auf Arbeitspaket-Ebene agil mit Scrum umgesetzt. Die

Dokumentation und das Berichtswesen, welches PRINCE2 mitbringt, gewährleisten jederzeit einen

Überblick über die Gesamtsituation; die intensivere Zusammenarbeit mit dem Kunden, das

Fokussieren auf das Wesentliche und die Verschlankung einiger Formalien durch Scrum garantieren

die zügige Lieferung von Zwischenergebnissen. Dies hängt unter anderem jedoch davon ab, wieviel

Agilität das Projekt bzw. der Kunde zulässt. Bei Software-Entwicklungsprojekten ist z.B. ein höherer

Anteil an Scrum-Elementen effizienter, bei Infrastruktur-Projekten sollten mehr PRINCE2-Bestandteile

vorhanden sein. Es ist also wichtig, bereits vor dem Projektbeginn das Vorgehen mit seinem Team und

dem Kunden abzustimmen.

42 siehe: http://blog.strategie-und-planung.de/agiles-projektmanagement, letzter Zugriff am 28.05.2017



Bei einer hybriden Vorgehensweise können also beide Modelle ihre Vorteile ausspielen, das

Gesamtprojekt kann schneller zu marktnahen Ergebnissen führen und durch die intensive

Zusammenarbeit im Team – auch mit dem Kunden – alle Beteiligten zufriedener stellen, da auch der

Anteil am Gesamterfolg wichtiger und sichtbarer wird. Die Frage, ob eine Kombination beider

Methoden allgemein sinnvoll ist, kann aus Sicht des Verfassers an dieser Stelle positiv beantwortet

werden.



4. Der Weg zu agilem Projektmanagement

Dieses Kapitel betrachtet hauptsächlich die Voraussetzungen und Anforderungen, die ein

Unternehmen für den Einsatz von agilen Methoden erfüllen muss. Die geplante Kombination von

klassischen und agilen Methoden setzt voraus, dass beide Philosophien nicht nur beherrscht werden,

sondern auch praktizierbar sind. Im Falle des DVZ ist, wie in der Einleitung schon erwähnt, bisher nur

PRINCE2 als Standard etabliert. Dazu finden neben der regelmäßigen Anwendung in der Praxis jährlich

Weiterbildungen innerhalb des Unternehmens durch externe Coaches und Trainer statt. Einige

Entwicklungsbereiche haben sich agile Methoden nach Scrum und Kanban selbst angeeignet und

bereits in Projekten, zumindest auf der Liefer- bzw. Produkt-Ebene, erprobt. Teilweise fanden auch

dafür Zertifizierungen statt und die Methoden wurden durch die ausgebildeten Mitarbeiter in die

Entwickler-Teams hineingetragen. Trotzdem sind die derzeitigen Rahmenbedingungen noch nicht

optimal für den Einsatz von Scrum und es fehlen noch die nötige Erfahrung und die gängige Praxis, um

es als Teil eines hybriden Projektmanagement-Modells, das für alle Arten von Projekten geeignet sein

soll, bestmöglich einsetzen zu können. Somit zielt die geplante Kombination hauptsächlich darauf ab,

agile Methoden bzw. deren nützlichste Elemente mit in das Standard-Projektmanagement-Portfolio

als Ergänzung zu PRINCE2 aufzunehmen und zu integrieren.

4.1. Warum sollte ein Unternehmen „agiler“ werden?

In der Auswertung einer Studie43 der GPM in den Jahren 2014 und 2015 zur Nutzung von agilen

Methoden, an der 600 Teilnehmer aus über 30 Länder teilnahmen, gaben die Befragten an, dass agile

Methoden „in allen untersuchten Kriterien (Ergebnisqualität, Mitarbeitermotivation, Teamwork,

Termintreue, Effizienz, Kundenorientierung und Transparenz)“ besser abschnitten als klassische. Sogar

80 % der Teilnehmer sahen laut den Autoren „Ergebnis- und Effizienzverbesserungen durch die

Anwendung agiler Methoden. Agile Methoden haben eine höhere Erfolgsquote als klassisches

Projektmanagement. Dies gilt für durchgängige, hybride und selektive Nutzer agiler Methoden.“

In einem Artikel auf der Webseite von Informatik Aktuell44 gibt Autorin und Führungskräfte-Beraterin

S. Hofert an, dass agil arbeitende Teams „visions- und aufgabenorientierter“, aber auch

„innovationsbereiter“ sind. Sie stellt die Frage: „Warum verbessern die von uns zugrunde gelegten

agilen Elemente wie Visualisierung, Teamentscheidung, Retrospektiven, iterative Planung und Stand-

Up-Meetings die Zusammenarbeit?“ und beantwortet sie damit, dass die „im agilen Arbeiten

43 siehe: https://www.gpm-ipma.de/fileadmin/user_upload/GPM/Know-how/Studie_Agiles-PM_web.pdf, letzter Zugriff am 12.06.2017 44 siehe: https://www.informatik-aktuell.de/management-und-recht/projektmanagement/agile-fuehrung-6- gruende-die-finger-davon-zu-lassen.html, letzter Zugriff am 01.06.2017



verankerten strukturellen Elemente Interaktion, Wissensaustausch und Verantwortung fördern sowie

dem Wir-Gedanken zuspielen und damit Gegenspieler der Ego-Statusorientierung sind“. Nach ihrer

Auffassung ist es weiterhin naheliegend, dass „die in den agilen Konzepten integrierte häufige

Reflexion und intensive Kommunikation die persönliche Entwicklung und Reife der Einzelpersonen

fördert. Teamführung im agilen Kontext zielt darauf, die Selbstorganisation zu unterstützen und sich

selbst überflüssig zu machen.“ Hofer sagt, die Teamführung ist damit „per Definition Teamentwicklung

und Coaching“ und „darauf an- und ausgelegt, eine fruchtbare Zusammenarbeit zu initiieren und

sicherzustellen.“ Diese Form der Führung ist laut Hofert „gerade bei hoch entwickelten Teams

wirksam“, bei denen es gilt, „Innovationspotenziale freizusetzen.“

Unternehmensberater K. Tumuscheit führt in einem seiner Artikel45 im ProjektMagazin noch weitere

Gründe auf: „Weil man unzufrieden ist mit dem aktuellen Projektmanagement. Weil Projekte nicht

rechtzeitig abgeliefert, Budgets überschritten und Ziele verfehlt werden. Weil die Zusammenarbeit in

den Teams wenig effizient und stark konfliktbelastet ist und weil wenig Transparenz besteht.“

Bestätigt werden kann Letzteres durch im DVZ geführte Gespräche mit Mitarbeitern aus den

Entwicklungsbereichen GEI (Abteilung E-Government / Sachgebiet Anwendungen und Integration),

FAO (Abteilung Fachapplikation / Sachgebiet Ordnungswesen) und FAT (Abteilung Fachapplikation /

Sachgebiet Technologie und Applikationsmanagement), die auf agile Methoden umschwenkten, da

Software-Entwicklungsprojekte hinsichtlich der aufgeführten Gründe nicht zufriedenstellend verliefen.

Zudem gab es Probleme bei Abrechnungen mit dem Kunden. Durch den Einsatz agiler Methoden wie

Scrum und die damit verbundene zügige Lieferung von Zwischenergebnissen können diese in Form von

Leistungsscheinen regelmäßig in Rechnung gestellt werden.

Es ist aber nicht nur eine Frage des „Warum?“, sondern auch des „Wie?“. In großen Unternehmen wie

dem DVZ kann es vorkommen, dass sich die Mitarbeiter bei zu geringer Transparenz in ihren

Möglichkeiten eingeschränkt und nicht als Teil des Ganzen sehen. Es müssen also Möglichkeiten und

Rahmenbedingungen geschaffen werden, beginnend beim Management, damit sich Mitarbeiter freier

entfalten können. Scrum kann aufgrund seiner Philosophien, die den Menschen in den Mittelpunkt

rücken, die Beteiligten in einem Projekt langfristig zufriedener stellen. Zudem kommt es Kunden

entgegen, denen die fachliche Expertise fehlt, konkrete Anforderungen an ein Produkt zu stellen, das

es zu entwickeln gilt. Der Kunde muss sich dabei bewusst sein, dass der Projekterfolg zu einem großen

Teil von ihm selbst abhängt. Ein Gespräch mit Christian Dähn aus dem DVZ (Sachgebietsleiter FAO)

45 siehe: https://www.projektmagazin.de/meilenstein/projektmanagement-blog/alles-agil-oder-was_1120082, letzter Zugriff am 31.05.2017



lieferte die Erkenntnis, dass der durch Scrum erzeugte höhere Personalaufwand und die

Notwendigkeit einer gemeinsamen Anforderungsdokumentation für den Kunden fachlich,

organisatorisch und personell eine besondere Herausforderung darstellt.

4.2. Wann sollte Agilität eingesetzt werden?

Grundsätzlich sollten agile Methoden dort ansetzen, wo klassisches Projektmanagement an seine

Grenzen stößt. Tumuscheit schreibt in seinem Artikel46 dazu: „Agiles Projektmanagement wird häufig

angewandt, wenn man nicht genau weiß, wie das Ergebnis aussehen soll. Dann macht es Sinn und

liefert tadellose Ergebnisse.“. Er erwähnt jedoch, dass man bei „harten“ Lieferterminen oft nicht am

klassischen Wasserfall-Modell vorbeikommt. Für Tumuscheit ist das agile Projektmanagement

prädestiniert für Entwicklungsprojekte, „bei denen das Ergebnis nicht per Auftrag bestimmt werden

kann“ Weiterhin schreibt er: „Verantwortliche, die ihre Projekte agiler machen wollen, geben ihren

Teams mehr Freiraum.“ Sie sagen zum Beispiel: "In acht Wochen muss zwar dies und das vorliegen –

aber wie ihr dahin kommt und das organisiert, das definieren wir nicht per Wasserfall von oben. Das

macht ihr so, wie es für euch passt. "“

In der Auswertung der Studie der GPM47 schreiben die Autoren dazu: „Der Einsatz agiler Methoden ist

nicht für jeden Entwicklungsprozess gleich stark geeignet. Meist verhindern die Rahmenbedingungen

agile Methoden so einzusetzen, dass signifikante Verbesserungen erzielt werden können.“ Die

Teilnehmer der Studie wurden „um eine Einschätzung gebeten, bei welchen Charakteristika sie agile

Methoden für besonders geeignet halten.“

Agile Methoden sind nach Meinung der Befragten besonders vorteilhaft bei:

• einer vorrangig internen Ausrichtung

• einem Budget unter einer Mio. Euro

• einer Teamgröße von fünf bis neun Personen

• „häufig bis ständig wiederkehrenden Aktivitäten“

• „grob definierten Budgetvorgaben und unscharf formulierten Ergebnisvorgaben“

• einer Projektdauer von drei bis neun Monaten

Die Ergebnisse zeigen, dass die von den Teilnehmern herausgehobenen Anwendungsfälle den Regeln

agiler Methoden (zum Beispiel kleine Teamgröße, keine starren Zielvorgaben, keine genau definierten

46 siehe https://www.projektmagazin.de/meilenstein/projektmanagement-blog/alles-agil-oder-was_1120082, letzter Zugriff am 31.05.2017 47 siehe: https://www.gpm-ipma.de/fileadmin/user_upload/GPM/Know-How/Studie_Agiles-PM_web.pdf, letzter Zugriff am 12.06.2017



Budgetvorgaben, Einsatz in sich wiederholenden und weiterentwickelbaren Aktivitäten) nahezu

gleichen.

4.3. Anforderungen an agiles Projektmanagement

In ihrem Artikel48 führt Hofert mehrere Gründe an, warum agile Führung scheitern könnte. Daraus

leiten sich entsprechende Anforderungen an das Management ab:

Kommunikation auf Augenhöhe

Ein agiles Team soll laut Hofert „effektiver kommunizieren – und das fordert viel Augenhöhe.“ Agile

Führung hat nach ihrer Auffassung eine Menge mit Kommunikation zu tun. „Der agile Coach (bzw. der

Team-Manager oder Scrum Master, Anm. d. Verf.) in einem Scrum-Team übernimmt oft Aufgaben im

Bereich Coaching und Teamentwicklung. Die in den agilen Konzepten integrierte häufige Reflexion und

intensive Kommunikation fördert – richtig angewendet – persönliche Entwicklung und Reife des

Teams.“ Hofert betont dabei, dass ein offener Umgang mit Fehlern ebenfalls zur Teamreife gehört.

„Ein kluger Mann macht nicht alle Fehler selbst. Er gibt auch anderen eine Chance.“

Winston Churchill, britischer Staatsmann

Fehler sollten nicht, dürfen aber gemacht werden. Es ist folgenschwerer, Fehler zu verschweigen oder

zu verbergen, als diese offen zuzugeben und daraus zu lernen. Der Projektmanager muss sein Team

dahingehend ermutigen. Gemeinsam können dann schneller Lösungen erarbeitet werden.

Geschäftsführer der it-agile GmbH und Agile Coach H. Wolf weist in seinem Artikel auf Informatik

Aktuell49 darauf hin, das Lernen (aus Fehlern, Anm. d. Verf.) erlaubt und erwünscht sein muss. Agile

Teams lernen laut Wolf „schnell über ihre eigene Leistungsfähigkeit und die Bedürfnisse der Kunden“.

Das Lernen gelingt nach Wolfs Auffassung nur, wenn „Fehler im System nicht zu Bestrafung führen“.

Ziel soll es sein, aus Fehlern zu lernen, um diese nicht erneut zu machen.

Offene und direkte Kommunikation

Hofert schreibt dazu, dass reflektierte Teams und Mitarbeiter eher mitdenken. Da sie weniger

angepasst sind, äußern sie offen ihre Meinung. Weiterhin sehen diese sich als mitspracheberechtigt.

Laut Hofert sind sie „bevollmächtigt“. Ein Unternehmen muss dieses nach Meinung der Autorin

48 siehe: https://www.informatik-aktuell.de/management-und-recht/projektmanagement/agile-fuehrung-6- gruende-die-finger-davon-zu-lassen.html, letzter Zugriff am 01.06.2017 49 siehe: https://www.informatik-aktuell.de/management-und-recht/projektmanagement/back-to-the- future-eine-zeitreise-in-die-zukunft-der-agilen-softwareentwicklung.html, letzter Zugriff am 20.06.2017



verkraften können und auch wirklich wollen. „Dafür muss es etwas bieten, das auch dann noch Bestand

hat, wenn Mitarbeiter sich nicht mehr anpassen: ein gutes Produkt, eine klare Vision, attraktive Ziele.“

Offene und direkte Kommunikation erfordert viel Vertrauen untereinander. Jedes Team-Mitglied muss

sich in seiner Rolle wohlfühlen und jederzeit Probleme und Sorgen ansprechen können. Der Manager

eines agilen Teams sollte die nötigen Soft Skills dafür mitbringen.

Mitarbeiter-Motivatoren erkennen und fördern

Des Weiteren merkt Hofert an, dass motivierte Mitarbeiter „anstrengend“ sein können, da sie nicht

nur Spaß an der Arbeit haben, sondern auch bestimmte Dinge fordern. Sie möchten, laut Hofert,

„entlang ihrer eigenen Motive und Stärken eingesetzt werden“, denn „in einem demotivierenden

Umfeld hat Agilität keinen Platz.“ Sie schlägt vor, dass Führungskräfte hinterfragen oder zumindest

herausfinden sollen, warum Mitarbeiter gerne unter ihnen arbeiten, bevor überhaupt an agile

Maßnahmen gedacht werden kann.

„Die meisten Führungskräfte zögern, ihre Leute mit dem Ball laufen zu lassen,

aber es ist erstaunlich, wie schnell ein informierter und motivierter Mensch laufen kann.“

Lee Iacocca, US-amerikanischer Manager

Offenheit und Werte-Verständnis

Weiterhin erwähnt Hofert, dass Mitarbeiter öfter Widersprüche durchschauen und daher auch

unangenehme Fragen stellen. Sie empfiehlt dahingehend einen „schonungslosen Artefakte-Check.

Artefakte sind manifestierte Werte. Sie zeugen, wie etwas gelebt wird. Welche Werte soll ein Team

oder Unternehmen haben […]?“ Als Beispiel führt sie an: „Wenn […] der Schreibtisch des Chefs zum

Fenster ausgerichtet und von Pflanzen und Büchern abgeriegelt ist, aber Offenheit gefordert ist, gibt

es einen Widerspruch.“ Ebenso weist Hofert auf Leitbilder von Firmen hin, die oft im Schrank oder

Intranet „abgelegt“ sind. Sie vermutet, dass diese nur erstellt wurden, damit es sie gibt und das

Unternehmen reinen Gewissens diesbezüglich ist. Hofert empfiehlt, vor der Ausarbeitung von neuen

zunächst die bisher gelebten Werte zu betrachten, die „in Form von Artefakten bereits manifestiert

sind.“ Sie ergänzt: „Ein Blick auf den Firmenparkplatz ist da auch sehr interessant.“

Prozesse, Ziele und Risiken verstehen

Nach Hofert müssen Manager „vom bisherigen Zielorientierungsdenken abweichen – und sich auf

einen Prozess einlassen.“ Auf eine mögliche Frage von Managern, ob es dafür messbare Kennzahlen

gibt, entgegnet sie, dass dem nicht so ist. Zumindest gibt es ihrer Meinung nach keine Kennzahlen, die

eine Wirksamkeit tatsächlich solide erfassen würden. „Wenn ein Unternehmen agiler werden will, so



ist das ein laufender Prozess, mit Zielen und iterativen Schleifen“ fügt sie hinzu. Agil bedeutet im

Kontext ebenso, sich immer wieder die Fragen zu stellen: „Wo stehen wir?“, „Was war gut?“ und „Was

geht besser?“ Das Prinzip ist laut Hofert „Inspect & adopt“ (untersuchen und anpassen, Anm. d. Verf.),

welches sich auch auf Führungsebene anwenden lässt. Sie fügt hinzu, dass Prozesse und Ziele

gleichwertig und miteinander verzahnt sind. Ihrer Erfahrung nach „ist das intellektuell gut

nachvollziehbar, aber die grundlegende Orientierung ist meist entweder auf das Eine oder das Andere

gerichtet.“ Manager sollten „wirklich loslassen und bereit sein, sich auf ein Experiment einzustellen.“

Solche Experimente Geduld erfordern und können auch scheitern. Trotzdem sollten sie als Chance und

weniger als ein Risiko gesehen werden.

„Wer jedes Risiko ausschalten will, der zerstört auch alle Chancen.“

Hans-Olaf Henkel, deutscher Manager

Veränderungen akzeptieren

Hofert schreibt, dass nach einer Veränderung im Unternehmen „erstmal alles schlechter“ werden kann

und sich die Gruppe der Mitarbeiter ändert, „sobald etwas Neues“ aufkommt. Sie fügt hinzu, dass es

üblich und normal sei, wenn es sich zunächst negativ auf das Betriebsklima auswirkt: „Mehr Vielfalt

führt immer auch zu mehr Reibung.“ Die Autorin unterlegt dies mit einem Beispiel zu einem radikal

durchgeführten Experiment der Amazon-Tochter Zappos, bei der eine Holokratie50 eingeführt wurde,

die zu einer regelrechten Kündigungswelle geführt hat. Veränderungen, auch die zum Guten, sind

immer ein Einschnitt in die gewohnten Arbeitsabläufe. Diese Veränderungen ziehen laut Hofert

zunächst wohl immer Widerstand auf sich und bringen vorübergehend eine Verschlechterung des

Klimas mit sich. Sie empfiehlt daher, Neuerungen vorerst nur in Teilbereichen auszuprobieren.

„Wenn du etwas so machst, wie du es seit zehn Jahren gemacht hast,

dann sind die Chancen groß, dass du es falsch machst.“

Charles Kettering, US-amerikanischer Wissenschaftler

An sich selbst arbeiten

Die Autorin rät, dass muss man zunächst seine Haltung, „sein Mindset“ (Denkweise, Anm. d. Verf.)

ändern muss, um agiler werden zu können. Das bedeutet auch immer wieder, sich selbst in Frage zu

stellen. Ihrer Auffassung nach denken die Menschen immer, sie lägen mit ihrer Einstellung richtig.

50 Holokratie = eine vom Unternehmer B. Robertson entwickelte Systemik, die Entscheidungsfindungen „mit durch alle Ebenen hindurch gewünschter Transparenz und partizipativen Beteiligungsmöglichkeiten“ in großen Netzwerken und vielschichtigen Unternehmen eine günstige Struktur gibt (https://de.wikipedia.org/wiki/Holokratie, letzter Zugriff am 18.06.2017)



Diese Selbstbestätigungstendenz führt häufig dazu, die eigenen Annahmen als wahr zu betrachten.

Widersprechende Wahrheiten werden ausgeblendet. Hofert meint, Führungskräfte sollen ihre eigene

Denk- und Handlungslogik weiterentwickeln, indem sie deren „Richtigkeit“ grundlegend in Frage

stellen. Hierbei gibt es kein „richtig“ oder „falsch“, sondern nur „passend“ und „im Moment sinnvoll.“

Wolf bestätigt diese Feststellung in seinem Artikel51, indem er anmerkt, dass zu einer Veränderung im

Unternehmen im Wesentlichen ein „geändertes Mindset“ gehört, „das nicht nur Mitarbeiter betrifft,

sondern auch Management und Fachseite umfasst“.

4.4. Herausforderungen für den Einsatz agiler Methoden

Kapazitäten schaffen

Tumuscheit gibt in seinem Artikel52 im ProjektMagazin dazu an, dass „in agilen Projektteams die Team-

Mitglieder fast ausschließlich fürs agile Projekt freigestellt“ sind. Dagegen hat im „normalen“

Projektmanagement ein Team-Mitglied gerade mal „einen Tag pro Woche, realistisch eher einen

halben Tag Zeit fürs Projekt; viele können gerade mal zwei, drei Stunden freimachen.“ Unter der

Voraussetzung, dass ein Mitarbeiter für ein Projekt komplett von der Linienarbeit freigestellt ist, fällt

es nach Tumuscheit diesem leichter, „agil zu sein“. Doch dafür ist „nicht das agile Projektmanagement

ursächlich, sondern die Freistellung.“

Als möglichen Lösungsansatz dazu formuliert er, dass eine Freistellung der Arbeitszeit in Höhe von 20%

bis 40% für Projekte – „konsequent von oben angeordnet und konsequent in der Einhaltung verfolgt“

– in „etlichen“ Unternehmen in wenigen Wochen möglich sei, nachdem diese u.a. im „Multi-

Projektmanagement aufgeräumt“ und „nutzlose Ressourcenverbraucher“ beseitigt haben.

B. Gloger, Scrum-Trainer und Autor, hat die Problemstellung in einem Artikel auf Informatik Aktuell53

folgendermaßen dargestellt: „Obwohl heute alle vor den gleichen Problemen stehen […], gehen viele

Unternehmen nach wie vor den […] traditionellen und damit ungeeigneten Weg: Projekte werden aus

der Taufe gehoben und erst dann wird überlegt, wer die Aufgaben am besten erledigen kann.“ Nach

Gloger werden oft Ressourcenmanager eingestellt, die Projektmanager immer mit den richtigen

Ressourcen versorgen sollen. Er fügt hinzu, dass die Realität anders aussieht: „In Projekten werden

immer wieder die gleichen Personen benötigt, die genau deswegen bereits in vielen Projekten

gleichzeitig arbeiten.“ Als hinlänglich „bekannte“ Gründe führt er an, dass zu viele Projekte zur selben

51 siehe: https://www.informatik-aktuell.de/management-und-recht/projektmanagement/back-to-the- future-eine-zeitreise-in-die-zukunft-der-agilen-softwareentwicklung.html, letzter Zugriff am 20.06.2017 52 siehe: https://www.projektmagazin.de/meilenstein/projektmanagement-blog/alles-agil-oder-was_1120082, letzter Zugriff am 31.05.2017 53 siehe: https://www.informatik-aktuell.de/management-und-recht/projektmanagement/die- umfeldbedingungen-des-skalierens.html, letzter Zugriff am 01.06.2017



Zeit durchgeführt werden und die sogenannten „Key Player“ im Unternehmen die entscheidenden

Wissensträger sind, bei bzw. „in“ denen sich das Wissen konzentriert, weshalb sie daher in mehr als

einem Projekt gebraucht werden.

Die meisten Organisationen leiden heute laut Wolf unter extremem „Verzetteln“. Auch er stellt fest,

dass zu viele Projekte gleichzeitig durchgeführt werden und neue Projekte starten, bevor laufende

fertig sind. „Selbst die Anzahl strategischer Ziele und Maßnahmen liegt gern im zweistelligen Bereich“

ergänzt Wolf und fügt hinzu, dass für erfolgreiches agiles Arbeiten „eine große Disziplin und

Fokussierung notwendig“ ist, „auch wenn das für viele kontra-intuitiv klingen mag“. Agilität braucht

Fokussierung, die nach Wolfs Auffassung auch nicht-agilen Umfeldern guttun würde.

In vielen Unternehmen treffen Linien- und Projekt-Hierarchie aufeinander. Die Matrix-Organisation ist

in der Theorie ein sinnvolles Konstrukt, das in der Realität jedoch oft Konflikte verursacht. Ein

Mitarbeiter in einem Projekt hat dementsprechend zwei Vorgesetzte (Sachgebietsleiter und

Projektleiter), die sich im schlimmsten Fall um eine Ressource streiten. Zum einen muss das Projekt

vorangetrieben und zum anderen das Tagesgeschäft in der Linie bzw. im Sachgebiet aufrechterhalten

werden. Dies erfordert eine intensive Koordination in Hinblick auf die Ressourcenplanung. Gerade in

agilen Projekten benötigen die Team-Mitglieder jedoch den nötigen Freiraum, möglichst frei vom

Tagesgeschäft, um sich komplett auf das Projekt konzentrieren zu können.

In der Regel besetzt ein Abteilungsleiter im DVZ die Rolle des internen Auftraggebers für ein Projekt in

seinem Bereich. Das hat den Vorteil, dass, abgesehen von der Geschäftsführung, der

Hauptverantwortliche in einem Projekt (Auftraggeber) gleichzeitig Zugriff auf die Ressourcen als

Linienmanager (Abteilungsleiter) hat. Der eingesetzte Projektleiter aus MBP (Abteilung

Managementberatung / Sachgebiet Projektmanagement) muss sich dementsprechend mit seinem

Auftraggeber über die zur Verfügung stehenden Know-How-Träger abstimmen. Da beide ein Interesse

am Projekterfolg haben, sollte es in Hinblick auf die Freigabe von Ressourcen keine Probleme geben.

In der Abteilung SD (Service Delivery), die hauptsächlich für Infrastruktur-Projekte zuständig ist, gibt es

zum Beispiel regelmäßige Projektkoordinations-Meetings, um die zur Verfügung stehenden

Ressourcen den Anforderungen entsprechend neben dem Tagesgeschäft auf die Projekte aufzuteilen.

Da die Anzahl der erfahrenen Wissensträger begrenzt ist, können Ausfälle eventuell unerwünschte

Projektverzögerungen zur Folge haben. Gespräche mit Verantwortlichen in den Sachgebieten GEI, FAO

und FAT haben im Gegensatz dazu ergeben, dass die Stabilität von Scrum-Teams nur schwer zu

gewährleisten ist. Das liegt zum einen daran, dass in Entwickler-Teams teilweise externe Entwickler

eingebunden sind, die nur primär für ein Projekt oder Teilprojekt anwesend sind und zum anderen das



Tagesgeschäft aufrechterhalten werden muss. Es wird nach Auskunft der Beteiligten in den

Entwicklungsbereichen noch zu sehr am operativen Geschäft festgehalten. Dadurch kann die

vorgeschriebene Scrum-Teamgröße von sieben Entwicklern, einem Product Owner und einen Scrum

Master in der Regel nicht eingehalten werden. Das Management muss an diesem Punkt ansetzen und

die Ressourcen-Koordination ändern bzw. anpassen, wenn agiler gearbeitet werden soll.

Kommunikationswege verkürzen

Zum Thema Teamarbeit und Kommunikation schreibt Tumuscheit, dass beim klassischen

Projektmanagement die Team-Mitglieder häufig „über das ganze Werksareal“ oder sogar über

Standorte verstreut sind, oft auch über Länder und Zeitzonen. „Agile Teams sitzen dagegen meist in

einem Projektraum: Die Wege sind kurz, die Kommunikation ist direkt, die Koordination schnell.“ Er

erklärt, dass agile Teams im permanenten Kundenkontakt stehen. Das durchschnittliche Team-

Mitglied in einem klassischen Projektteam kennt laut Tumuscheit den Endkunden eher nur vom

„Hörensagen“. Wenn man dieses änderte, wäre man bereits „ein wenig agiler“.

Dementsprechend müssen auch Räumlichkeiten zur Verfügung gestellt werden, in denen die

Projektteams zusammenarbeiten können. Wie oft mit dem Kunden kommuniziert wird, hängt in der

Regel von diesem selbst ab. Es gibt Kunden, die regelmäßig im Projekt eingebunden werden wollen

und wiederum andere, die nur bei wichtigen Entscheidungen hinzugezogen werden möchten. Daraus

lässt sich u.a. ableiten, wie agil das Projekt sein kann bzw. darf. Wenn der Kunde von einer intensiveren

Kommunikation überzeugt wird, kann auch agiler gearbeitet werden.

„Sag mir, wie ein Projekt beginnt und ich sage Dir, wie es endet.“

Projektweisheit

Der Autor legt dar, dass Teams auch agiler werden, wenn diese „von sich aus Kontakt mit dem Kunden

halten“ und deshalb nicht mehr am Bedarf des Nutzers vorbei arbeiten. „Normale“ Projekte werden

laut Tumuscheit allein schon „schneller, besser und agiler“, wenn es einen ständig erreichbaren und

entscheidungsfreudigen Verantwortlichen gibt, wie es beim agilen Projektmanagement üblich ist. Ein

„nur vierteljährlich tagender Lenkungsausschuss“ ist nicht ausreichend.

Die Kommunikation muss jedoch weiterhin koordiniert werden, damit wichtige Informationen nicht

verloren gehen. Im DVZ ist der interne Auftraggeber erster Ansprechpartner des Kunden. Dieser ist

gleichzeitig extern als Lieferantenvertreter eingesetzt und lenkt die Kommunikation nach innen zum

Projektteam. Wie oft und in welcher Form Informationen an die über- und untergeordneten Ebenen



weitergegeben werden, legt der Lenkungsausschuss in einer Kommunikationsmatrix fest, die mit dem

Kunden vereinbart und anschließend abgenommen wird. Es ist dem Lenkungsausschuss jedoch

freigestellt, gewisse Kompetenzen an die Projektteams abzugeben, so dass diese zum Beispiel in agilen

Projekten selbstständig untereinander und mit dem Kunden kommunizieren können. Er muss den

Kommunikationsplan jedoch im Überblick behalten.

Regelmäßige Retrospektiven und Reports

Dazu stellt Tumuscheit fest, dass agile Teams sich wöchentlich fragen: „Was lief diese Woche gut? Wo

könnten wir besser werden?“ In klassischen Teams hingegen soll dieses, laut Handbuch, mindestens

am Projektende gemacht werden. In der Praxis erlebt Tumuscheit letzteres jedoch eher selten. Er

machte die Erfahrung, dass, wenn klassische Teams dann doch die Vorschriften befolgen, „Lessons

Learned“ (bzw. Erfahrungsberichte, Anm. d. Verf.) gemacht werden, „die dann in der Schublade

verschwinden“, wodurch sich dieselben Fehler im nächsten Projekt wiederholen“.

Scrum verschlankt den formalen Prozess und konzentriert sich auf das Wesentliche. Durch das

hochfrequentierte (meist mündliche) Berichtswesen sind alle Team-Mitglieder und der Kunde stets auf

aktuellem Stand und lernen so viel schneller voneinander. Trotzdem darf die Dokumentation nicht zu

sehr in den Hintergrund rücken.

Tumuscheit machte die Erfahrung, dass es in vielen Projekten überhaupt keine Team-Meetings gibt,

„weil man den von oben verordneten Projektplan abarbeiten muss“ und „bitte keine Fragen stellen“

soll. Ein kleiner Schritt in Richtung Agilität wäre laut Tumuscheit schon getan, wenn Projektteams es

schaffen, sich wöchentlich zusammenzusetzen.

„Gute Informationen sind schwer zu bekommen. Noch schwerer ist es, mit ihnen etwas anzufangen.“

Sir Arthur Conan Doyle, britischer Schriftsteller

Bezogen auf eine PRINCE2-Organisation ist es auf Liefer-Ebene sinnvoll, die Status-Meetings öfter als

auf Lenkungs- bzw. Management-Ebene anzusetzen. Es gibt vielleicht nicht immer viele neue

Informationen, über die berichtet werden kann, aber selbst eine halbe Stunde pro Woche reicht, um

alle Beteiligten im Projekt auf den aktuellen Stand zu bringen. In agilen Teams gibt es die sogenannten

„Daily Scrum Meetings“, bei denen sich die Mitarbeiter sogar täglich, dafür aber nur eine Viertelstunde

zusammenstellen und gegenseitig über Ergebnisse und Herausforderungen informieren. Diese

Meetings werden vom Scrum Master organisiert und sind verpflichtend. Da sie kurz sind, müssen sie

oft stattfinden, sodass in einer Woche aufsummiert mindestens eine Stunde dafür verbraucht wird. In



Entwicklungsprojekten ist dieses aber weitaus effektiver, als wenn sich nur einmal die Woche für eine

Stunde getroffen wird.

Im Folgenden sind die Herausforderungen für den Einsatz agiler Methoden noch einmal tabellarisch

aufgelistet und zusammengefasst. Zusätzlich sind Ergänzungen aufgeführt, inwieweit die

Herausforderungen durch das DVZ bewältigt werden bzw. welche Anpassungen dafür vorgenommen

werden müssen.

Tabelle 8 – Herausforderungen für den Einsatz agiler Methoden:

Herausforderung Beschreibung Bewältigung durch das DVZ

Kapazitäten schaffen

(1) Mehr Freistellungen vom Tagesgeschäft für die Bearbeitung der Projekte

(2) Weniger Projekthierarchie vs. Linienhierarchie

(3) Weniger parallele Projekte mit gleichen Beteiligten

Zu (1) Da das DVZ mit Kundenprojekten Umsatz generiert, sind die eingebundenen Mitarbeiter nur bedingt durch das Tagesgeschäft eingeschränkt und bekommen feste Arbeitszeiten den Projekten zugewiesen. Wie hoch der Anteil an der täglichen Arbeitszeit ist, variiert allerdings. Bei der Abstimmung mit dem Kunden über die anstehende Projektdauer werden Aspekte, wie z.B. die Verfügbarkeit der Ressourcen, mit eingeplant. Durch regelmäßige Koordinations-Meetings wird die Aufteilung der Ressourcen überwacht und kontrolliert. Da eine Stabilität der Scrum-Teams in der Regel nicht gewährleistet werden kann, müssen pragmatische Ansätze erörtert werden. Eventuell sollte das Personal in Entwicklungsabteilungen aufgeteilt werden in „reine Entwickler“, die zu 100 Prozent in Projekten mitwirken und „operative Entwickler“, die das Tagesgeschäft am Laufen halten.

Zu (2) Interner Auftraggeber des Projektes ist zumeist Linienvorgesetzter der erforderlichen Ressourcen. Das vermeidet Konflikte zwischen Linien- und Projektvorgesetzten.

Zu (3) Da die Anzahl der Know-How-Träger begrenzt ist, wird es sich nicht vermeiden lassen, dass diese in mehreren Projekten parallel arbeiten. In Infrastruktur-Projekten, in denen es auch mal Leerlaufzeiten gibt, wie z.B. bei einer Hardware-Bestellung oder baulichen Maßnahme, ist es sinnvoll, Aktivitäten parallel in anderen Projekten von den entsprechenden Ressourcen durchführen zu lassen. In Entwicklungsprojekten hingegen gibt es kaum Leerlaufzeiten. Da schnelle Ergebnisse erzielt werden sollen, müssen die Entwickler nahezu in vollem Umfang




dem Projekt zur Verfügung stehen. Es muss ein Weg gefunden werden, dass Entwickler die nötigen Freiräume zur Wahrnehmung ihres Entwicklungsauftrags bekommen, um dem Kunden in der vorgeschriebenen Zeit Ergebnisse liefern zu können. Ein möglicher Ansatz wäre, dass bei Ressourcenbündelung und genügend Freistellung ein Projekt schneller durchgeführt werden kann, als dass es als Parallelprojekt längere Zeit beansprucht. So könnte man die Projekte sequentiell anstatt parallel abarbeiten.

Kommunikations-wege verkürzen

(1) Mehr Räume für das gemeinsame Arbeiten zur Verfügung stellen

(2) Intensivere Kommunikation (auch mit dem Kunden)

Zu (1) Das Raumplan-Management-System im DVZ sieht vor, dass Projekt- bzw. Konferenzräume prinzipiell von jedem Mitarbeiter genutzt werden können, diese aber im Vorfeld gebucht werden müssen, da mehrere Bereiche darauf Zugriff haben. Das funktioniert insofern gut, dass es fast immer einen Raum im DVZ gibt, der zu einer konkreten Zeit genutzt werden kann. Die Nachteile sind, dass die Team-Meetings nur so lange dauern dürfen, wie der gebuchte Raum zur Verfügung steht und es auch nicht zwangsläufig immer der gleiche Raum ist, der genutzt werden kann. Für das agile Arbeiten ist es aber notwendig, Räume zur Verfügung zu stellen, die für ein konkretes Projekt immer zur Verfügung stehen (z.B. für die Planung von Sprints und das Durchführen von Retrospektiven) – auch spontan, ohne diese buchen zu müssen.

Zu (2) Die Koordination der internen und externen Kommunikation in einem Projekt obliegt in PRINCE2 dem Projektleiter. Dieser stimmt im Vorfeld mit dem Kunden ab, auf welchem Weg und wie oft kommuniziert werden soll und benennt die Ansprechpartner. In agilen Projekten kann das genauso funktionieren. Sobald der Projektleiter Kompetenzen an die Team-Manager oder Scrum Master und deren Teams abgibt, können diese eigenständige Kommunikationspläne aufstellen. Es muss allerdings darauf geachtet werden, dass die Informationen gebündelt und transparent für das gesamte Projekt gemacht werden.

Regelmäßige Retrospektiven

(1) Aus Erfahrungen lernen

(2) Sich öfter zusammensetzen

Zu (1) Regelmäßige Meetings sollen nicht nur dem Status-Abgleich, sondern auch dem Erfahrungsaustausch dienen, damit sofort




voneinander gelernt werden kann, anstatt erst am Phasen- oder Projektende.

Zu (2) Auch an dieser Stelle legt der Projektleiter bzw. der Scrum Master fest, wie oft sich das Team trifft. Für agile Projekte, in denen Meetings sehr oft stattfinden, diese dafür aber kurz und auf das Wichtigste reduziert sind, benötigen die Mitarbeiter die nötige Freistellung, sowohl vom Tagesgeschäft, als auch von anderen Projekten.

Weitere Erkenntnisgewinne bei der Einführung agiler Methoden in verschiedenen Unternehmen

liefert ein Interview von Informatik Aktuell54 mit M. Friedrich (Geschäftsführer der Cegeka Deutschland

GmbH) und V. Schmidt (Agile Coach bei der Cegeka Deutschland GmbH und ausgebildeter Scrum

Master), deren Aufgabe es ist, Unternehmen von der fachlichen Seite aus auf dem Weg zu mehr Agilität

zu begleiten.

Geduld und Kontinuität

Friedrich merkt an: „Wie bei allen großen Veränderungen war es zu Beginn am wichtigsten, die

Mitarbeiter mit ins Boot zu holen. Hierzu mussten wir einiges an Aufklärungs- und Überzeugungsarbeit

leisten, um Skepsis und Ängste auszuräumen.“ Dieses betraf laut Friedrich nicht nur die Mitarbeiter,

sondern auch „Projektleiter und Manager, die lernen mussten, Kontrolle abzugeben und ihre Rollen

neu zu definieren.“ Friedrich betont, dass es die größte Anstrengung war, „konsequent am Ball zu

bleiben und die gelernten agilen Werte und Methoden zu verinnerlichen.“

Eine Zertifizierung allein reicht nicht aus, um die agilen Methoden zu beherrschen. Dazu bedarf es

genügend Anwendungsmöglichkeiten in der Praxis. Da es dem DVZ an Projekten, für die sich agile

Methoden als vorteilhaft erweisen, nicht mangelt, können diese stets angewendet, geübt und

verbessert werden. Durch Reviews und Retrospektiven muss im Rahmen des Qualitätsmanagements

kontrolliert und ausgewertet, ob sie nachhaltig und zielführend eingesetzt werden bzw. wurden.

Hierarchien durchbrechen

Schmidt triff die Aussage, dass eine agile Transformation nicht nur „die Einführung einer neuen

Arbeitsweise und eines neuen Prozesses“ umfasst, sondern „die Veränderung der Organisation und

der Unternehmenskultur selbst.“ Dafür sind laut Schmidt „die Mitarbeiter gefordert, mehr

54 siehe: https://www.informatik-aktuell.de/management-und-recht/projektmanagement/wer-hat-angst-vor- agil-so-gelingt-die-agile-transformation.html, letzter Zugriff am 31.05.2017



Verantwortung zu übernehmen. Gleichzeitig muss ihnen aber auch die entsprechende

Handlungskompetenz und Entscheidungsfreiheit eingeräumt werden.“ Schmidt ergänzt, dass es in

vielen Unternehmen „langjährig gewachsene, starre Hierarchiestrukturen und Entscheidungswege“

gibt, die „erst mal durchbrochen werden“ müssen. Für das Management liegt laut Schmidt „die große

Herausforderung insbesondere darin, zu lernen, den gefühlten Kontrollverlust zu ertragen und

Vertrauen in das Team zu entwickeln.“

Wolf ergänzt hierzu in seinem Artikel55, dass auf Management-Ebene zuweilen die „Angst“ existiert,

„überflüssig zu werden“. Diese Angst sei laut Wolf unbegründet. „Vielmehr können sich Manager im

agilen Kontext mehr auf ihre Kernaufgaben konzentrieren: Richtung vorgeben, Personal entwickeln,

Umgebung optimieren.“

Einführung planen

Schmidt empfiehlt, bei einer Einführung von agilen Methoden „die Ziele zu definieren, die […] erreicht

werden sollen und einen Plan für das weitere Vorgehen zu entwickeln.“ Der Fortschritt des Plans muss

dem Autor nach regelmäßig kontrolliert und ggfs. angepasst werden. Noch wichtiger aber sei es, eine

„gemeinsame Informationsbasis und ein gemeinsames Verständnis aller Beteiligten zu schaffen.“

Folgende Fragen sollten dabei regelmäßig gestellt werden „Warum machen wir das Ganze?“, „Was

wollen wir erreichen?“ und „Was bedeutet die Veränderung für das Unternehmen und für den

Einzelnen?“ Schmidt ergänzt, dass die agile Transformation ein Organisationsprojekt ist, bei dem

„Strukturen, Einstellungen, Verhalten und Kultur“ innerhalb des Unternehmens (aber auch außerhalb

in Abstimmung mit dem Kunden, Anm. d. Verf.) verändert werden. Das passiert Schmidts Auffassung

nach nicht „über Nacht“, sondern „Schritt für Schritt.“

Unterstützung von außen

Weiterhin empfiehlt der Autor, bei Bedarf eine Unterstützung bei größeren Projekten oder einer

Transformation der Methoden in einer Organisation durch erfahrene Experten und Agile Coaches.

Da die Methoden im DVZ nicht transformiert, sondern lediglich angepasst und ergänzt werden, ist es

aus derzeitiger Sicht nicht vorgesehen, externe Unterstützung anzufordern. Das Management muss

sich nur auf Veränderungen einlassen und die erforderlichen Rahmenbedingungen schaffen.

55 siehe: https://www.informatik-aktuell.de/management-und-recht/projektmanagement/back-to-the- future-eine-zeitreise-in-die-zukunft-der-agilen-softwareentwicklung.html, letzter Zugriff am 20.06.2017



4.5. Bezug zur Praxis

Die beiden folgenden Abschnitte zeigen, wie der Umstieg auf agile Methoden im DVZ und in anderen

Unternehmen verlief und welche Erfahrungen dadurch gemacht wurden.

4.5.1. Andere Unternehmen

Umstieg auf agile Methoden

In der Studie der GPM56 erwähnen die Autoren, dass viele Entwicklungsprozesse in Unternehmen, in

denen heute agile Methoden eingesetzt werden, zuvor mit Hilfe von klassischen Projektmanagement-

Methoden bearbeitet wurden. Bei der Auswertung der Umfrageergebnisse zeigte sich, dass der

Umstieg von drei Viertel der Unternehmen nicht als Projekt, sondern auch als Entwicklungsprozess

verstanden wurde. „Bei knapp zwei Dritteln der Befragten erfolgte die Umstellung zunächst nur bei

ausgewählten Projekten. 11% gaben an, agile Methoden zunächst als Testprojekt einzusetzen (vgl.

Abb. 6, Anm. d. Verf.). Durch diese agile Art der Umstellung können Lerneffekte schnell auf andere

Projekte übertragen werden.“

Abbildung 6 – Umstellungsprozess auf agile Methoden56

56 siehe: https://www.gpm-ipma.de/fileadmin/user_upload/GPM/Know-How/Studie_Agiles-PM_web.pdf, letzter Zugriff am 12.06.2017



Initiatoren für die Einführung

Die Teilnehmer wurden weitergehend dazu befragt, wer Initiator für die Einführung von agilen

Methoden war (vgl. Abb. 7). Die Ergebnisse zeigten, dass der Umstieg bei mehr als zwei Drittel der

Befragten von den eigenen Mitarbeitern im Unternehmen initiiert wurde. „Dies deckt sich auch mit

der Erkenntnis, dass die persönliche Nutzung agiler Methoden bei den meisten Befragten noch vor der

Nutzung agiler Methoden im Unternehmen lag.“ Die Hälfte der Teilnehmer gab an, durch externe

Beratung den Umstieg auf agile Methoden zu vollziehen. Gegenüber den Studienergebnissen von 2012

war hier ein Zuwachs von 14% zu verzeichnen.“

Abbildung 7 – Promotoren für die Umstellung auf agile Methoden57

Ergebnisse nach der Einführung

In der Studie wurde zudem ermittelt, ob durch die Transformation zu agilen Methoden Erfolge bei den

Teilnehmern zu verzeichnen waren. Die Autoren merken an, dass sich „durch die Umstellung einzelner

Entwicklungsprozesse vom klassischen Projektmanagement auf agile Methoden eine Veränderung im

gesamten Bearbeitungsprozess“ zeigt. In der Studie wird der Erfolg bzw. Misserfolg dieses

Veränderungsprozesses näher untersucht. Die Teilnehmer wurden „gebeten, eine Einschätzung zur

Verbesserung der Entwicklungsprozesse durch den Umstieg auf agile Methoden zu geben. Hierbei

gaben 80 % der Befragten an, bessere und effizientere Ergebnisse zu erzielen (vgl. Abb. 8 nächste Seite,

Anm. d. Verf.).“

57 entnommen: https://www.gpm-ipma.de/fileadmin/user_upload/GPM/Know-How/Studie_Agiles-M_web.pdf, letzter Zugriff am 12.06.2017



Abbildung 8 – Ergebnis- und Effizienzverbesserung durch agile Methoden58

4.5.2. DVZ

Umstieg auf agile Methoden

Nach Auskunft von Falk Friese (Sachgebiet FAT) gibt es im DVZ ca. 200 Entwickler, die in etwa 30 Teams

aufgeteilt sind. Bisher gab es aber nur drei Projekte, in denen agiles Projektmanagement in

Kombination mit Scrum eingesetzt und erprobt wurde. Die Abteilung GE nutzt agile Methoden seit ca.

vier Jahren, die Abteilung FA hingegen seit einem Jahr.

Initiatoren für die Einführung

Die Motivatoren waren, wie der Großteil der Teilnehmer der GPM-Studie, einzelne Mitarbeiter aus

den Abteilungen selbst. Diese besuchten im Vorfeld Schulungen für PRINCE2, Scrum und PRINCE2 Agile

und coachen in Eigenregie ihre Kollegen bzw. Team-Mitglieder.

Ergebnisse nach der Einführung

Das Nutzen und Erproben agiler Methoden stieß nach einem Gespräch mit C. Dähn (Sachgebietsleiter

FAO) unter den Mitarbeitern auf keinen spürbaren Widerstand. Dieser war eher auf der Kundenseite

vorzufinden, u.a. auch deshalb, weil es bei den Vereinbarungen über die Rahmenbedingungen wenig

Spielraum hinsichtlich Zeit- und Kostenrahmen gibt. Wie in der Einleitung schon erwähnt, stammen

die Kunden hauptsächlich (zu 90 Prozent) aus den Bereichen Politik, Wirtschaft und Verwaltung. Die

Budgets für Projekte werden in den jeweiligen Haushalten festgelegt. Dementsprechend musste der

Kunde in einem konkreten Projekt für eine agilere Zusammenarbeit und die damit verbundenen

Vorteile zunächst einmal gewonnen werden. Teilweise erforderte dies nicht unerhebliche

58 entnommen: https://www.gpm-ipma.de/fileadmin/user_upload/GPM/Know-How/Studie_Agiles-M_web.pdf, letzter Zugriff am 12.06.2017



Überzeugungsarbeit, da der Kunde seine gewohnte Arbeitsweise und Mitwirkungsleistung umstellen

musste. Insgesamt gelang dieses jedoch, da mit Scrum die zuvor völlig unüberschaubar geltende

Ausgangssituation schneller und schrittweise beherrschbar wurde.

„Ein Anwender wird dir alles sagen, wenn du ihn danach fragst – aber nicht mehr.“

Management-Weisheit

Den größten Vorteil in Scrum sah Dähn in der hohen Einbeziehung des Kunden und die damit

einhergehende Transparenz, die geholfen hat, in Diskussionen nicht mehr die klassische „Auftraggeber

vs. Auftragnehmer“-Situation zu haben, sondern einen Teamgedanken und starken Fokus auf die

Zusammenarbeit über das DVZ hinaus zu etablieren. Das hat alle Mitarbeiter motiviert und die

Arbeitsatmosphäre erheblich verbessert. Nach Aussage von Dähn gab es jedoch Schwierigkeiten,

Zwischenergebnisse zu jedem Sprint zu liefern – dies überforderte nicht nur teilweise den Kunden, da

dieser mit dem Testen und den Anforderungsdefinitionen nicht mehr nachkam, sondern auch das

Scrum-Team, da die Sprint-Vorplanung bei schwierigen Themen sehr viel Aufwand erzeugte. Durch

einen pragmatischen Ansatz, die Sprint-Abstände auf drei Wochen festzulegen und

Zwischenergebnisse erst auszuliefern, wenn die Funktionen und Workflows weitestgehend vollständig

implementiert sind, gelang das Projekt schließlich.

4.6. Ergebnis der Analyse

Das DVZ befindet sich in einer guten Ausgangsposition, agile Methoden als Ergänzung zu PRINCE2

einzusetzen. Die Anforderungen und Voraussetzungen dafür können durch Abgabe von Kompetenzen,

Schaffung von Freiräumen und Anpassung gewohnter Abläufe erfüllt werden. Das Management muss

die nötigen Rahmenbedingungen dafür schaffen. Gleichzeitig muss der Kunde in agileren Projekten auf

veränderte Arbeitsweisen vorbereitet werden. Nur so ist es möglich, die Vorteile von Scrum ausnutzen

zu können. Ferner muss erwähnt werden, dass die Einführung von agilen Methoden ein Unternehmen

nicht automatisch agiler macht. Es muss von einer anderen Seite aus betrachtet werden: Ein

Unternehmen muss zunächst seine Kultur und Denkweise in den zuvor erwähnten Bereichen ändern

bzw. anpassen, um anschließend das Potenzial agiler Methoden ausnutzen zu können.



5. Umsetzung von hybridem Projektmanagement

In diesem Kapitel wird – ausgehend von den Vorteilen und den zu erfüllenden Voraussetzungen für

eine Kombination zweier Methoden – ein Modell als Vorschlag für das DVZ erarbeitet. Dieses orientiert

sich hauptsächlich an einem von T. Albers (Manager des PMO59 von Europcar Autovermietung GmbH)

und S. Hilmer (Principal Consultant60 bei Acando GmbH) geschaffenen Ansatz. Die Autoren haben in

einer zweiteiligen Serie im ProjektMagazin61 das hybride Projektmanagement mit PRINCE2 und Scrum

untersucht.

Die recherchierten und theoretischen Ansätze werden um bereits gewonnene Erkenntnisse aus

Gesprächen mit Mitarbeitern aus den Entwicklungsbereichen ergänzt.

5.1. Vorteile einer Kombination von PRINCE2 und Scrum

Gewohnte Organisation und Arbeitsweisen können bestehen bleiben 62

PRINCE2 schafft einen strukturierten und organisierten Rahmen, den die meisten Unternehmen für

den Einsatz agiler Methoden wie Scrum benötigen. Der Lenkungsausschuss kann bei einer Kombination

mit Scrum weiterhin die Verantwortung für die Projektdurchführung an den Projektleiter und den bzw.

die Product Owner delegieren. Er muss also nur bei Änderungsanträgen und Ausnahmefällen ins

Projekt eingreifen. Da PRINCE2 der gesetzte Standard im DVZ ist, muss sich in der gewohnten

Projektorganisation, zumindest auf der Lenkungs- und Management-Ebene, nicht allzu viel verändern.

Begeisterung im Team trotz Hierarchie 62

Da das Projektteam die Möglichkeit bekommt, sich nach Scrum zu organisieren, kann das Projekt von

der agilen Begeisterung, die den Menschen in den Mittelpunkt rückt, und der effektiven

Zusammenarbeit profitieren. Die hierarchische und zielgerichtete Führung innerhalb einer PRINCE2-

Organisation kann dabei bestehen bleiben. In Unternehmen wie dem DVZ ist dieses ein willkommener

Aspekt, da die vorgegebenen Strukturen meist nicht viel Handlungsspielraum in Hinblick auf Hierarchie

und Koordination zulassen, sich die Mitarbeiter aber dennoch individuell und eigenverantwortlich in

das Projekt einbringen können und dadurch einen spürbaren Anteil am Gesamterfolg bekommen.

59 PMO = Project Management Office, siehe: https://www.projektmagazin.de/glossarterm/project- management-office, letzter Zugriff am 05.06.2017 60 Principal Consultant = Hauptverantwortlicher Berater, übersetzt mit: http://www.linguee.de/deutsch- englisch/search?source=auto&query=principal+consultant, letzter Zugriff am 05.06.2017 61 siehe: https://www.projektmagazin.de/artikel/hybrides-projektmanagement-mit-prince2-und-scrum-teil- 1_1105769, letzter Zugriff am 05.06.2017 62 siehe: https://www.computerwoche.de/a/prince2-oeffnet-die-tuer-fuer-scrum,2489890,6, letzter Zugriff am 29.05.2017



Einheitliches Berichtswesen 63

Der Rahmen von PRINCE2 macht ein standardisiertes Berichtswesen in einem hybriden Modell für alle

Projekttypen möglich. Unabhängig von der gewählten Vorgehensweise innerhalb des Projektes

erhalten die übergeordneten Ebenen, wie Lenkungsausschuss und Unternehmens- bzw. Programm-

Management, einheitliche Berichte. Somit bleibt das bisherige Verständnis für den Stand eines

konkreten Vorhabens in einem PRINCE2-Projekt bestehen und ermöglicht so, im Bedarfsfall steuernd

einzugreifen. Des Weiteren entsteht für die übergeordneten Ebenen eine vergleichende Übersicht der

verschiedenen Projekte, so dass ein strategisches Eingreifen möglich ist, wie z.B. eine Neupriorisierung

der Projekte.

Bessere Anpassung an Kundenanforderungen und Rechnungslegung

Ein weiterer Vorteil ist, dass sich die Kombination von PRINCE2 und Scrum optimal an die

Anforderungen des Kunden anpassen kann und damit ermöglicht, unabhängig vom Projekttyp und von

der Komplexität des Projektes, dieses bestmöglich umzusetzen. Dazu muss das agile Potenzial des

Projektes im Vorfeld erörtert werden. Als „Lieferprojekte“ lassen sich kleinere Scrum-Projekte in ein

größeres PRINCE2-Projekt einbetten. Dadurch können Scrum-Projekte miteinander oder auch mit

Festpreis-Projekten und klassischen Arbeitspaketen kombiniert werden. Das erleichtert zudem die

Rechnungslegung dem Kunden gegenüber. Das Kundenumfeld des DVZ ist darauf angewiesen, seinem

Haushalt entsprechend zu handeln. Dazu bedarf es der Festlegung eines genauen Kosten- und

Zeitrahmens, der vertraglich vereinbart und eingehalten werden muss. In einem Hybridmodell mit

PRINCE2 als Grundgerüst können zu festgelegten Meilensteinen auf Management-Ebene Zahlungen

vereinbart und die Einhaltung des Budgets kontrolliert werden, während die Teams auf Liefer-Ebene

innerhalb des Kostenrahmens agil und selbstorganisiert arbeiten können.

Verbessertes Image

Die Standards von PRINCE2 wurden seit der Veröffentlichung 1996 regelmäßig überarbeitet und

zuletzt im Jahr 2009 vom Office of Government Commerce (OGC) veröffentlicht64, nicht zuletzt deshalb,

um vom Ruf einer starren und überbürokratischen Projektmanagement-Methode Abstand zu

gewinnen. Durch die Kombination mit Scrum kann das Image von PRINCE2, eine zuverlässige und

zugleich sehr flexible Methode zu sein, stärker betont werden. Dem agilen Vorgehen bei Scrum

hingegen wird unterstellt, zu viele Freiräume zuzulassen und in organisatorischer Hinsicht schnell den

Überblick zu verlieren. Eingebettet in einem PRINCE2-Gerüst kann auch diesen Zweifeln

63 siehe: https://www.projektmagazin.de/artikel/hybrides-projektmanagement-mit-prince2-und-scrum-teil- 2_1105830, letzter Zugriff am 20.06.2017 64 siehe: http://de.wikipedia.org/wiki/PRINCE2, letzter Zugriff am 04.06.2017



entgegengewirkt werden. Das DVZ kann zudem seinen Standpunkt am Markt durch die

Weiterentwicklung eingesetzter und etablierter Methoden weiter festigen.

Zusammengefasst bringt die Kombination von klassischen und agilen Methoden eine Menge Vorteile.

Als Nachteile können hingegen die nötigen Schulungen, Umstellungen bzw. Anpassungen der

Arbeitsweisen und die damit entstehenden Investitionen von Zeit und/oder Geld aufgeführt werden,

welche aber hinnehmbar sein müssen, da Neuerungen, die ein Unternehmen vorantreiben sollen, stets

mit Aufwänden in Zusammenhang stehen.

5.2. Notwendige Schritte vor einer Kombination

Dabei geben sie folgende allgemeine Hinweise, die vor einer Kombination zweier Methoden beachtet

werden müssen:

• Maß bestimmen: Die bestehenden Methoden sollen nicht komplett verändert werden, um ein

neues Modell zu erzeugen, sondern weitestgehend bestehen bleiben und ggfs. nur geringfügig

angepasst werden.

• Vereinbarkeit der Methoden überprüfen lassen (siehe Kapitel 3.5, Anm. d. Verf.):

Verantwortliche müssen „neben den prozessualen und organisatorischen Gegebenheiten

auch die Philosophien der gewählten Ansätze vergleichen“. Dabei muss beachtet werden, dass

o sich die Grundprinzipien nicht widersprechen

o die behandelten Themen (z.B. Risiken, Qualität usw.) von beiden Methoden

unterstützt werden

o sich die Aufgaben der definierten Rollen auf ein gemeinsames Rollenmodell

übertragen lassen

o die „Verschmelzung beider Vorgehensmodelle“ in einem „Phasenmodell“ möglich ist

• Steuerungsmodell festlegen: Ein Modell bildet den übergeordneten Rahmen zur

Projektsteuerung.

• Durchführungsmodell bestimmen. Das andere Modell kann projektspezifisch ausgewählt oder

erstellt werden.

Eine weitere Voraussetzung ist, dass bei Verwendung einer Softwarelösung, die das

Projektmanagement im Unternehmen unterstützt, diese dann – in Hinblick auf die Anforderungen für

ein hybrides Modell – sowohl klassische, als auch agile Anteile abbilden können muss. Dazu hat das

DVZ bereits einen Grundstein mit der pipe+ gelegt, die am 01.05.2017 das Vorgängermodell abgelöst

hat. Die pipe+ basiert auf der Softwarelösung BCS65 von der Firma Projektron. Die Software unterstützt

65 BCS = Business Coordination Software, siehe: https://www.projektron.de/bcs, letzter Zugriff am 19.06.2017



bei der Projektvorbereitung und detaillierten Projektplanung sowie bei der Überwachung der

Projektabwicklung und garantiert ein effektives Projektcontrolling. Sie unterstützt Methoden, wie

PRINCE2 und Scrum, und bringt die nötigen Schnittstellen zur Hard- und Software für eine Integration

in die bestehende IT-Infrastruktur des Unternehmens mit.

Ausgehend von den Vorteilen einer Kombination von klassischen und agilen Methoden, den

notwendigen Vorbereitungen und allgemeinen Voraussetzungen dafür, bietet es sich für das DVZ an,

die bestehende Methode PRINCE2 als Grundgerüst für die Lenkungs- und Management-Ebene zu

belassen, um der Komplexität von Projekten entgegenwirken zu können, und die Vorteile von Scrum

auf Liefer-Ebene einzubinden bzw. zu integrieren, um die Effizienz in Entwicklungsprojekten zu

steigern. Zudem wird es den Projektleitern im DVZ erleichtert, sowohl Infrastruktur- als auch

Entwicklungsprojekte zu leiten.

5.3. Grundprinzip hybrider Vorgehensmodelle

Zunächst werden die allgemeinen Grundprinzipien und Begrifflichkeiten eines kombinierten

Projektmanagement-Modells erklärt. Dieses schafft für den weiteren Verlauf der Arbeit ein besseres

Grundverständnis.

Abbildung 9 – Grundprinzip eines hybriden Vorgehensmodells66




Albers und Hilmer schreiben dazu, dass ein hybrides Vorgehensmodell im Kern auf Basis der

Kombination zweier verschiedener Modelle liegt (vgl. Abb. 9 vorherige Seite, Anm. d. Verf.). „Dabei

bildet ein Modell, das sog. "Steuerungsmodell", den übergeordneten Rahmen zur Projektsteuerung.

Innerhalb des Steuerungsmodells bieten Kopplungspunkte die Möglichkeit zur Kombination mit dem

sogenannten "Durchführungsmodell", das projektspezifisch ausgewählt oder erstellt werden kann.“

5.3.1. Steuerungsmodell

Als Steuerungsmodelle kommen nach Albers und Hilmer in der Regel sequentielle Vorgehensmodelle

zum Einsatz, wie z.B. PRINCE2. Diese werden „einmalig, z.B. unternehmensweit, festgelegt“ und bilden

„den Rahmen für das Durchführungsmodell“. Des Weiteren kommt ein potenzielles Steuerungsmodell

in der Regel in jedem Projekt zum Einsatz. Um das ausgewählte Durchführungsmodell anbinden zu

können, wird laut Albers und Hilmer im Steuerungsmodell eine „einheitlich vorgegebene Kopplung“

definiert, die sogenannte „feste Kopplung“. Diese sieht vor, „dass der erste und der letzte Meilenstein

des Durchführungsmodells zwei definierte Meilensteine des Steuerungsmodells ersetzen“ (vgl. Abb. 9

vorherige Seite, Meilenstein zur Kopplung, Anm. d. Verf.).

Ferner betonen die Autoren, dass die notwendigen Anpassungen für die Kombination von Scrum und

PRINCE2 „aufgrund der hohen Gemeinsamkeiten des Sprintansatzes aus Scrum und des PRINCE2-

Prinzips Steuern nach Managementphasen“ gering ausfallen.

5.3.2. Durchführungsmodell

Innerhalb des Steuerungsmodells kommt laut Albers und Hilber das sogenannte

„Durchführungsmodell“ zum Tragen. Welches Modell konkret dafür genutzt wird, entscheidet

üblicherweise die Projektleitung in Abstimmung mit den jeweiligen Lenkungsgremien. „Die Kopplung

des Durchführungsmodells an das Steuerungsmodell erfolgt flexibel“ heißt es weiterhin im Artikel.

Albers und Hilber erklären, dass diese sogenannte „flexible Kopplung“ zu einem bestimmten Zeitpunkt,

der im Steuerungsmodell vorgegeben ist (vgl. Abb. 9 vorherige Seite, Meilenstein zur Festlegung, Anm.

d. Verf.), definiert wird. Der Projektmanager legt dabei in Abstimmung mit dem Projektteam das

„einzusetzende Durchführungsmodell, seine erforderlichen Spezifika, seine "Meilensteine zur

Steuerung", seine geplante Einsatzdauer sowie Art und Umfang des zu erreichenden Ergebnisses fest.“

Die Vielfalt für mögliche Durchführungsmodelle reicht „von einfachen sequentiellen Modellen bis hin

zu agilen Vorgehensweisen.“

So können außer Scrum auch weitere Methoden wie Kanban und Xtreme Programming mit PRINCE2

gekoppelt werden.



5.4. Vorschlag zur Umsetzung

5.4.1. Steuerungsmodell PRINCE2

Als vorteilhaften Grund, PRINCE2 als Steuerungsmodell einzusetzen, führen Albers und Hilber an, dass

die Methode „das Management von Projekten und nicht die eigentliche Wertschöpfung beschreibt“

und dadurch den notwendigen Freiraum lässt, „auf der liefernden Ebene vom traditionellen,

sequentiellen Vorgehen abzuweichen und eine agile Vorgehensweise zu implementieren.“ PRINCE2

benennt laut den Autoren im Prozess Managen der Produktlieferung „selbst explizit diesen Freiraum,

da es dem Anwender freistellt, für diesen Prozess ein anderes Vorgehensmodell einzusetzen“ (vgl.

OGC, 2009). Diese Eigenschaft sei „ausschlaggebend für die Verwendung von PRINCE2 als

Steuerungsmodell in einem hybriden Ansatz.“

In Hinblick auf die Anpassung der Rollen sorgt nach Albers und Hilber das PRINCE2-Grundprinzip

Definierte Rollen und Verantwortlichkeiten für „klar definierte […] Abläufe, auch innerhalb des

Durchführungsmodells.“ Die freie Wahl eines geeigneten und individuellen Durchführungsmodells in

der Initiierungsphase des Projektes schafft nach Auffassung der Autoren die notwendige Flexibilität für

das Projektteam. Der Vorteil dabei ist, dass sich „die Erfahrungen und Stärken der Team-Mitglieder

situationsbedingt einsetzen und Besonderheiten des Vorhabens bei der Wahl berücksichtigen“ lassen.

Da die Kundenprojekte im DVZ immer komplexer und größer werden, wächst dementsprechend auch

die Projektorganisation. Nicht selten sind bis zu 30 Mitarbeiter in einem Projekt eingebunden. Dies

verlangt eine strukturierte Koordination der Beteiligten. PRINCE2 gewährleistet dieses und ist deshalb

besonders als Steuerungsmodell für das DVZ geeignet.

5.4.2. Durchführungsmodell Scrum

Da Scrum prinzipiell keine Meilensteine vorsieht, empfehlen Albers und Hilber, diese „künstlich“

hinzuzufügen. Hierfür können zum Beispiel der Startpunkt des ersten und der Endpunkt des letzten

Sprints gewählt werden. Diese hinzugefügten Meilensteine erlauben es, die „Kopplungspunkte“ in

einem PRINCE2-Gerüst zum einen vor die erste Managementphase, in der die Produkte erstellt

werden, und zum anderen vor die letzte Managementphase, in der hauptsächlich das Projekt

abgeschlossen wird, zu legen. So ist es nach Auffassung der Autoren möglich, die künstlichen

Meilensteine „zur Einbindung unterschiedlicher Durchführungsmodelle innerhalb eines Projekts zu

verwenden“, wenn Teams zum Beispiel nach „unterschiedlichen Vorgehensweisen arbeiten oder wenn

eine unterschiedliche Risikobehaftung der Tätigkeiten ein differenziertes Vorgehen erforderlich

macht.“



Die Scrum-Rollen lassen sich laut Albers und Hilber den Aufgaben entsprechend den Ebenen des

PRINCE2-Prozesses folgendermaßen zuordnen:

• Product Owner = fachlicher Ansprechpartner, verantwortet den wirtschaftlichen Erfolg des

Produktes Lenkungs-Ebene

• Scrum Master = beratende Führungskraft, regelt Verbreitung und Einhaltung der Scrum-

Grundprinzipien Management-Ebene

• Entwicklungsteam = Experten, setzen Anforderungen selbstorganisiert um Liefer-Ebene

5.4.3. Kopplung innerhalb Phasen

In einem hybriden Modell wird die Einteilung der Projektphasen laut Albers und Hilmer generell vom

Steuerungsmodell vorgegeben: „Der Vorteil von PRINCE2 bei der Kombination mit einem agilen Ansatz

ist, dass sich die Managementphasen mit jeweils einem Sprint gleichsetzen lassen, da sie hinsichtlich

Zahl und Dauer frei definierbar und inhaltlich nicht festgelegt sind.“

Abbildung 10 – Kopplungspunkte von PRINCE2 und Scrum67

Wie in Abschnitt 5.3.2 beschrieben, muss das Durchführungsmodell für einzelne Phasen oder das

gesamte Projekt bereits in der Planungsphase (hier: Initiierungsphase, vgl. Abb. 10, roter Meilenstein)

durch den Projektmanager in Absprache mit seinem Teammanager festgelegt werden. Da für die




folgende Kopplung Scrum als Durchführungsmodell gewählt wird, muss zunächst das Product Backlog

erstellt werden, „welches alle bis dahin bekannten Anforderungen an das gewünschte Produkt

enthält“. Die „Meilensteine zur Kopplung“ (vgl. Abb. 10 vorherige Seite, orange Meilensteine und

Abschnitt 5.3.1 „Steuerungsmodell“) bestehen aus dem ersten und letzten Meilenstein des

Durchführungsmodells, die zwei festgelegte Meilensteine im Steuerungsmodell ersetzen. Die erste

Kopplung findet im Folgenden mit Abschluss der Initiierungsphase statt. Ab der ersten

Durchführungsphase (vgl. Abb. 10 vorherige Seite, Managementphase (2)) wird das Product Backlog

sprintweise auf Basis von Sprint Backlogs abgearbeitet. Wenn die Produkte fertiggestellt bzw. alle

Anforderungen aus dem Product Backlog erfüllt wurden, wird mit Abschluss der vorletzten

Managementphase (vgl. Abb. 10 vorherige Seite, Managementphase (N-1)) das Durchführungsmodell

(also Scrum) wieder verlassen.

5.4.4. Kopplung der Prozesse

Bei einer Kombination mit Scrum sind nach Albers und Hilber die folgenden drei PRINCE2-Prozesse

anzupassen (vgl. hierzu Anlage 2 – Anpassung der Prozesse von PRINCE2): Initiieren eines Projekts,

Steuern einer Phase und Managen der Produktlieferung.

Die ersten beiden Prozesse, die sich auf der Management-Ebene befinden, werden nur teilweise

angepasst. Der Prozess Initiieren eines Projekts wird auf die Liefer-Ebene erweitert, „um zu

verdeutlichen, dass bereits an dieser Stelle Einschätzungen von Spezialisten und Generalisten aus dem

Entwicklungsteam einfließen.“ Der zweite Prozess Steuern einer Phase wird „durch die Einbindung des

Product Backlogs als Steuerungs- und Kontrollmittel“ auf den Einsatz von Scrum angepasst.

Der auf Liefer-Ebene befindliche Prozess Managen der Produktlieferung wird hingegen „vollständig an

den Scrum-Prozess angepasst.“ Es wird eine Schnittstelle der zum PRINCE2-Prozess gehörenden

Schritte Arbeitspaket annehmen, Arbeitspaket ausführen und Arbeitspaket abliefern zum Prozess

Steuern einer Phase gebildet.

5.4.5. Kopplung der Rollen

Um die angepassten Prozesse anwenden zu können, ist es nötig, auch Änderungen bzw. Anpassungen

an Mitgliedern der Projektorganisation vorzunehmen. Albers und Hilber erklären, dass dadurch

sichergestellt wird, „dass alle notwendigen Aktivitäten aus dem Steuerungs- und Durchführungsmodell

auch einer entsprechenden Rolle zugewiesen sind.“ Hierfür sind laut den Autoren geringe Änderungen

an den folgenden drei PRINCE2-Rollen „mit ihren Aufgaben, Kommunikationswegen und

Rollenbeschreibungen“ erforderlich (vgl. hierzu Anlage 3 – Kopplung der Rollen von PRINCE2 und

Scrum): Projektsicherung, Projektunterstützung und Projektteam.



Projektsicherung

Nach Auffassung von Albers und Hilber gibt es viele Gemeinsamkeiten bei einem Vergleich der

Aufgabenfelder der PRINCE2-Rolle Projektsicherung und der Scrum-Rolle Product Owner. Die Autoren

empfehlen daher, die Aufgaben der Projektsicherung auf den Product Owner zu übertragen: „Beide

Rollen haben die Aufgabe, die Interessen der Stakeholder zu wahren, sind aber (in der Praxis auch der

Product Owner) bei verbindlichen Entscheidungen auf den Lenkungsausschuss angewiesen.“

Erfahrungsgemäß wird die Rolle des Benutzervertreters laut Albers und Hilber „häufig von einem

direkten Vorgesetzten des Product Owners besetzt“. Aus diesem Grund kann diese Rolle weiterhin

bestehen bleiben. Durch die direkte Unterstützung des Product Owners auf der Management-Ebene

kann sich der Benutzervertreter weiterhin auf seine Lenkungsaufgaben konzentrieren. Die Autoren

ergänzen: „Im Zuge der Verpflichtung des Product Owners, die Interessen und Anforderungen aller

Stakeholder verstehen und abzuwägen, nimmt er auch die Projektsicherung im Namen des

Auftraggebers und Lieferantenvertreters wahr.“ Sollte das Projekt sehr umfangreich sein, empfehlen

Albers und Hilmer, die Projektsicherung mit „einer weiteren Person“ zu besetzen, „die den Product

Owner bei seinen Aufgaben unterstützt“.

Projektunterstützung

Die Projektsicherung kann zudem „verbleibende Aufgaben“ der Projektunterstützung „übernehmen,

die durch den Scrum Master ersetzt wird.“ Hierbei handelt es sich nach Auffassung der Autoren

„zumeist um Aufgaben des Qualitätsmanagements bezüglich der Projektdurchführung“. Als Beispiel

führen sie die Dokumentation von Ergebnissen bzw. Entscheidungen an.

Projektteam

In Hinblick auf das Projektteam merken Albers und Hilmer an, dass dieses „durch den Scrum-Ansatz

über die ursprüngliche Beschreibung von PRINCE2 hinausgehende Aufgaben“ erhält. Die größte

Änderung ist „die Integration des Scrum Masters, der die Aufgaben der Rolle "Projektunterstützung"

übernimmt, Hilfestellung zu den Scrum-Regeln gibt und auch deren Einhaltung überprüft.“ Das Product

Backlog und der dafür verantwortliche Product Owner ersetzen die Änderungssteuerung von PRINCE2.

Alternative Möglichkeiten

Einen anderen Ansatz schlägt A. Ockl in einem Artikel68 der Computerwoche vor. Dieser beinhaltet zwei

Varianten für die Integration der Rolle des Product Owners in eine PRINCE2-Organisation. Hierbei

werden die Aufgabenfelder des Product Owners um die des Projekt- bzw. Teammanagers ergänzt, um

68 siehe: https://www.computerwoche.de/a/prince2-oeffnet-die-tuer-fuer-scrum,2489890,4, letzter Zugriff am 20.06.2017



bei agilen Anteilen in einem PRINCE2-Projekt ein Vorgehen nach Scrum abbilden zu können (vgl.

Abb. 11). Der Scrum Master agiert im Modell von Ockl als Projektsicherung zwischen den Ebenen. Seine

Aufgabe ist es, die Arbeitsabläufe innerhalb der Teams zu überwachen und zu coachen.

Dieser Ansatz kann zum Beispiel dann gewählt werden, wenn die vorhandene Projektorganisation in

einem Unternehmen weitestgehend bestehen bleiben soll.

Abbildung 11 – Varianten des Product Owners in einer PRINCE2-Organisation69

Die erste Variante (vgl. Abb. 11, V1) bietet sich bei kleineren Projekten an. Der Product Owner ist als

Projektmanager für das Projektergebnis verantwortlich und kann nach eigenem Ermessen sein Team

führen bzw. organisieren. Innerhalb der Toleranzen seines Auftrags kann er zudem zulassen, dass sich

dieses auch selbst organisiert. Des Weiteren ist der Product Owner als Projektleiter Bindeglied

zwischen Lenkungsausschuss und der agilen Liefer-Ebene. Er muss die Arbeitspakete und das

Tagesgeschäft fachlich führen. In den Arbeitspaketen geht es dabei um die technische Umsetzung der

fachlichen Anforderungen. Somit steht der Nutzen des Fachbereiches immer im Vordergrund des

Projektes. Die täglichen Scrum-Meetings reduzieren laut Ockl den permanenten E-Mail-Verkehr und

69 entnommen aus: https://www.computerwoche.de/a/prince2-oeffnet-die-tuer-fuer-scrum,2489890,6, letzter Zugriff am 23.06.2017



weitere Besprechungen auf Arbeitspaket-Ebene. Er fügt jedoch hinzu, dass die Kommunikation nur

effektiv bleibt, „so lange das Team klein ist“.

Die zweite Variante (vgl. Abb. 11 vorherige Seite, V2) kommt bei größeren Projekten zum Einsatz, in

denen oft viele Arbeitspakete parallel abzuarbeiten sind. An dieser Stelle wird der Product Owner als

Team-Manager eingesetzt, der dann für die Ergebnisse der Sprints bzw. Arbeitspakete verantwortlich

ist. Vorgaben erhält er dann „von einem dedizierten Projektmanager.“ Der Product Owner agiert bei

dieser Variante als ein „fachlicher Projekt-Manager“, wie es ein Team-Manager nach PRINCE2 für

seinen Bereich auch tut. Laut Ockl können dadurch auch mehrere Scrum-Produkte gleichzeitig

gesteuert werden, indem mehrere Product Owner eingesetzt werden. Bei vielen Abhängigkeiten

zwischen den Arbeitspaketen empfiehlt Ockl, die Product Backlogs bzw. die Anforderungen

entsprechend aneinanderzukoppeln.

Pragmatischer Ansatz im DVZ

In einem Gespräch mit Falk Friese (FAT) hat sich herausgestellt, dass die Rolle des Product Owners in

einer PRINCE2-Struktur im DVZ auf Lenkungs-Ebene und selbst auf Management-Ebene nicht sehr

sinnvoll ist. Aufgrund der steigenden Komplexität der Projekte und der vorherrschenden Projekt-

Parallelität müssen Lenkungsausschuss und Projektleiter in der Lage sein, nicht nur große, sondern

auch mehrere Projekte gleichzeitig zu managen. Dementsprechend können diese nicht für jedes

Projekt das tiefgehende technische Verständnis aufbauen, sondern müssen vielmehr die Projekte im

Überblick behalten. Ein Product Owner hingegen braucht nicht nur das Verständnis für die

Anforderungen des Kunden, sondern ebenso eine tiefgehende Fachlichkeit. In kleineren Projekten mit

relativ geringer Besetzung kann dieser durchaus auch Leitungsfunktionen übernehmen. Da es aber

kaum kleine Projekte mit kleinen Organisationen im DVZ gibt, ist es sinnvoller, den Ansatz von Albers

und Hilmer zu wählen, beim dem der Product Owner zwischen den Ebenen als Projektsicherung agiert

und den Benutzervertreter unterstützt. Das gewährt zum einen die erforderliche Fachlichkeit für die

Erstellung der Produkte; zum anderen haben Projektleitung und Lenkungsausschuss den nötigen

Freiraum, Projekte managen bzw. lenken zu können.

Der Scrum Master stellt die organisatorische Komponente dar und kann in seiner Rolle als

Projektunterstützung für ein oder mehrere Teams im Projekt auf die Einhaltung der agilen

Vorgehensweisen achten und.

Abschließend betrachtet ergibt sich somit ein Vorschlag für ein Hybridmodell, der – als möglicher

Ausblick auf ein weiteres Vorgehen – für eine Umsetzung mit den entsprechenden

Entscheidungsträgern erörtert werden sollte.



6. Fazit

Zusammenfassung und Ergebnisse der Arbeit

Das DVZ nutzt seit etwa elf Jahren PRINCE2 zum Managen von Projekten und hat diese Methode als

Standard definiert. Auf der regelmäßigen Suche nach Innovationen und Optimierungen von eigenen

Arbeitsweisen haben insbesondere die Entwicklungsbereiche im DVZ vor ca. vier Jahren selbstständig

damit begonnen, schrittweise agile Methoden, wie z.B. Scrum oder Kanban, speziell für Software-

Projekte einzuführen und zu erproben, um diese erfolgreicher durchführen zu können. Das größte

Hindernis bei diesem immer noch anhaltenden Prozess sind die vorhandenen Rahmenbedingungen für

die interne und externe Zusammenarbeit. Ausgehend von dieser Problemstellung war das Ziel der

vorliegenden Arbeit, die Vorteile von PRINCE2 und Scrum herauszufiltern, an die Rahmenbedingungen

anzupassen und eine Kombination beider Methoden in Form eines Hybridmodells zu erarbeiten.

Dazu wurden die beiden Vorgehensmodelle zunächst erläutert und anschließend gegenübergestellt.

Das Ergebnis lieferte die Erkenntnis, dass die beiden Methoden nicht nur miteinander harmonieren,

sondern sich in Teilen sogar ergänzen. Darüber hinaus hat sich für das weitere Vorgehen abgezeichnet,

dass PRINCE2 als „Grundgerüst“ im DVZ bestehen bleibt und die agile Vorgehensweise mit Scrum bei

Bedarf auf der „Arbeitsebene“ integriert wird. Das hat zum Vorteil, dass sich an den Arbeitsweisen im

Unternehmen, zumindest oberhalb der Liefer-Ebene in Projekten, nicht allzu viel ändern muss.

Um die Vorteile von Scrum ordnungsgemäß in die vorhandene Projektstruktur einbinden zu können,

wurde in einem weiteren Schritt geprüft, welche Rahmenbedingungen an agile Arbeitsweisen geknüpft

sind und welche Änderungen bzw. Anpassungen allgemein und im DVZ vorgenommen werden müssen,

um diesen gerecht zu werden. Das Resultat der Analyse ergab, dass die nötigen Voraussetzungen für

den Einsatz agiler Methoden im DVZ erfüllbar sind. Abhängig ist dieses hauptsächlich von den

Führungsebenen, die den nötigen Freiraum für Veränderungen schaffen müssen.

Aufbauend auf den gewonnenen Erkenntnissen und recherchierten Möglichkeiten wurde

abschließend ein mögliches Hybridmodell für das DVZ als Vorschlag erarbeitet, dessen Umsetzung in

einem möglichen weiteren Verlauf mit Entscheidungsträgern in Betracht gezogen werden sollte.

Gesammelte Erkenntnisse und Erfahrungen aus der Arbeit

Die Recherche und das Zusammentragen der vorliegenden Informationen haben ergeben, dass viele

„Alltagsprobleme“ in der Projektmanagement-Welt, wie z.B. das Überschreiten von Zeit- und

Kostenrahmen zugunsten der geforderten Qualität, seit vielen Jahren existieren und scheinbar

unlösbar sind. Der Vergleich verschiedener Quellen führte zu der Schlussfolgerung, dass nicht das

gewählte Vorgehen innerhalb des Projektes dafür ausschlaggebend ist, sondern unklar definierte

Zielvorgaben und dementsprechend falsch geschaffene bzw. vereinbarte Rahmenbedingungen



hinsichtlich Kosten und Zeit. Die am besten geeignete Projektmanagement-Methode liefert nicht

automatisch ein gutes Projektergebnis. Vielmehr muss von vornherein realistisch geplant werden. Bei

der Einführung neuer Methoden gehen einige Unternehmen nach Ansicht des Verfassers teilweise zu

optimistisch vor, ohne sich vorher intensiv mit den dafür notwendigen Voraussetzungen befasst zu

haben. Liefert die Methode nicht die gewünschten Ergebnisse oder Erfolge innerhalb kürzester Zeit,

stellen die jeweiligen Unternehmen dann enttäuschend fest, dass das gewählte Modell schlecht bzw.

ungeeignet ist oder vermutlich nicht funktioniert. Der bessere Ansatz wäre, so der Verfasser, neue

Methoden vorerst nur in Teilbereichen und zudem langfristig zu erproben.

Die im DVZ geführten Interviews lieferten ähnliche Erkenntnisse wie die Analyse der GPM-Studie: Die

Motivation für eine Einführung agiler Methoden wurde hauptsächlich von den unternehmenseigenen

Mitarbeitern herbeigeführt, da diese unzufrieden mit der bisherigen Projektarbeit waren. Darüber

hinaus wurden die agilen Vorgehensweisen auf beiden Seiten zunächst nur in einzelnen ausgewählten

Projekten erprobt und brachten zudem eine Effizienzsteigerung.

Allgemein betrachtet hat ein Vergleich zwischen dem DVZ und anderen Unternehmen hinsichtlich

möglicher Hürden für den Einsatz agiler Methoden ergeben, dass vorrangig das Projektumfeld dafür

geschaffen sein bzw. werden muss. Dabei geht es hauptsächlich um die beteiligten Menschen und

gelebten Werte. Transparenz, Kommunikation auf Augenhöhe, Fokus und Teamgeist sind die

wichtigsten Voraussetzungen für agiles Arbeiten und erfordern ein Umdenken auf allen Ebenen. Die

wesentliche Erkenntnis hierbei ist, dass agile Methoden ein Unternehmen oder ein Projekt nicht

automatisch agiler machen. Vielmehr müssen die eigenen Werte hinterfragt werden und der Mut

vorhanden sein, Veränderungen zuzulassen.

Reflexion der Arbeit

Wesentlicher Bestandteil der Arbeit war es, die Notwendigkeit einer Optimierung bzw. Anpassung der

im DVZ vorhandenen Projektmanagement-Methoden aufzuzeigen, um der wachsenden Heterogenität

und Komplexität in der Projektwelt entgegenwirken zu können. Der Verfasser vertritt die Auffassung,

dass die Ergebnisse der durchgeführten Analysen in der Arbeit ein hybrides Modell im DVZ nicht nur

rechtfertigen, sondern auch in Hinblick auf die steigenden Kundenanforderungen notwendig machen.

Während der Arbeit wurde deutlich, dass die Erarbeitung eines Vorschlags zur Umsetzung einer

Kombination nur einen Bruchteil eines gesamten Konzeptes ausmacht. Ausgehend von der

ursprünglichen Zielsetzung, konkrete Lösungsansätze zu liefern, um das Projektmanagement

nachhaltig zu verbessern, ist es nach Meinung des Verfassers gelungen, diese theoretisch zu erörtern.

Es muss an dieser Stelle jedoch erwähnt werden, dass diese lediglich als Fundament betrachtet werden

können. Ein vollumfängliches Konzept, welches maßgeschneidert auf das DVZ übertragbar ist, muss

durch entsprechende Fachexpertisen ausgearbeitet und betreut werden.



Ausblick auf das weitere Vorgehen

Aus den gewonnenen Erkenntnissen der Recherche und Interviews lässt sich ableiten, dass die

Kombination von PRINCE2 und Scrum nicht nur in der Theorie, sondern auch in der Praxis sinnvoll und

einsetzbar ist. Dieser Gedanke sollte aus Sicht des Verfassers im DVZ weitergeführt werden. Dazu

empfiehlt es sich, weiterhin Ideen für eine Umsetzung zu sammeln und diese schrittweise zu erproben.

Es sollte ein Team, bestehend aus erfahrenen Projektmitarbeitern und -managern der Abteilungen GE,

FA und MB, gebildet werden, welches durch regelmäßige Meetings die Weiterentwicklung des

hausinternen Projektmanagements und den damit verbundenen Best Practices vorantreibt. Diese

Meetings sollten u.a. Erfahrungswerte und recherchierte Erkenntnisse widerspiegeln. Nach der

Definition klarer Zielvorgaben müssen messbare Erfolgsfaktoren festgelegt werden, anhand derer

geprüft werden kann, ob die gesetzten Ziele erreicht wurden. Um für ein derartiges Vorhaben über die

nötigen Ressourcen wie Zeit und Geld verfügen zu können, schlägt der Verfasser vor, dieses nicht als

laufenden Prozess zu betrachten, sondern als internes Projekt durchzuführen.

In Bezug auf das weitere Vorgehen eignet sich nach Ansicht des Verfassers folgendes Zitat als Abschluss

der vorliegenden Arbeit:

„Diejenigen, die immer nur das Mögliche fordern, erreichen gar nichts.

Diejenigen, die aber das Unmögliche fordern, erreichen wenigstens das Mögliche.“

Michail Bakunin, russischer Revolutionär



VI. Literaturverzeichnis

agile tour. (2012). Klassisches Projektmanagement und Scrum.

Abgerufen am 22. Mai 2017 von https://scrumtrainings.files.wordpress.com/2014/01/

scrumklassischesprojektmanagement.pdf

Albers, T., & Hilmer, S. (27. Januar 2016). ProjektMagazin. Hybrides Projektmanagement mit

PRINCE2 und Scrum Teil 1

Abgerufen am 05. Juni 2017 von: https://www.projektmagazin.de/artikel/hybrides-

projektmanagement-mit-prince2-und-scrum-teil-1_1105769

Albers, T., & Hilmer, S. (10. Februar 2016). ProjektMagazin. Hybrides Projektmanagement mit

PRINCE2 und Scrum Teil 2

Abgerufen am 23. Juni 2017 von: https://www.projektmagazin.de/artikel/hybrides-

projektmanagement-mit-prince2-und-scrum-teil-2_1105830

AXELOS. Agile Project Management - PRINCE2 Agile.

Abgerufen am 20. Mai 2017 von https://www.axelos.com/best-practice-

solutions/prince2/prince2-agile

Becker, C., & Huber, E. (2008). Die Bilanz des (Miss)-Erfolges in IT-Projekten.

Abgerufen am 14. Mai 2017 von http://d-nb.info/99200375X/34

BPUG Deutschland. BPUG Kongress 2016: Pressetext.

Abgerufen am 13. Mai 2017 von http://www.bpug-deutschland.de/bpug-kongress-2016-

pressetext

dieprojektmanager. PRINCE2 Grundprinzipien.

Abgerufen am 22. Mai 2017 von http://dieprojektmanager.com/prince2-grundprinzipien/

Ellenberger, A. (Januar 2014). Tiba Magazin. PRINCE2® - schlanker Projektmanagement-Standard für

jede Anforderung

Abgerufen am 21. Mai 2017 von: https://www.tiba.de/sendf.php?i=002277-0.html

Engel, K., Tamdjidi, A., & Quadejacob, N. (Dezember 2008). Ergebnisse der Projektmanagement

Studie 2008. Erfolg und Scheitern im Projektmanagement

Abgerufen am 14. Mai 2017 von: https://www.gpm-ipma.de/fileadmin/user_upload/Know-

How/Ergebnisse_Erfolg_und_ Scheitern-Studie_2008.pdf

Foegen, M. (2014). Der Ultimative Scrum Guide. Darmstadt: wibas.

Forrester Research, Inc. (2013). Integrated Thinking: The Answer To Enterprise IT’s Perpetual.

Abgerufen am 14. Mai 2017 von http://www.effectiveui.com/landing-

pages/downloads/publications/EffectiveUI_Study_Integrated_Thinking.pdf

Gloger, B. (2011). Scrum. Produkte zuverlässig und schnell entwickeln. München: Hanser Verlag.



Gloger, B. (21. Februar 2017). Informatik Aktuell.Die Umfeldbedingungen des Skalierens

Abgerufen am 01. Juni 2017 von: https://www.informatik-aktuell.de/management-und-

recht/projektmanagement/die-umfeldbedingungen-des-skalierens.html

Hahne, A., & Lämmel, U. Fakultät für Wirtschaftswissenschaften der Hochschule Wismar.

Abgerufen am 11. Juni 2017 von https://www.fww.hs-wismar.de/fileadmin/hs-

wismar/Fakultaet_fuer_Wirtschaftswissenschaften/allgemeine_infos/Richtlinie_zur_Anfertig

ung_wissenschaftlicher_Arbeiten.pdf

Hofert, S. (18. April 2017). Informatik Aktuell. Agile Führung: Warum jetzt alle auf den Zug springen –

und 6 Gründe, die Finger davon zu lassen


recht/projektmanagement/agile-fuehrung-6-gruende-die-finger-davon-zu-lassen.html

Informatik Aktuell. (06. Dezember 2016). Wer hat Angst vor Agil? Worauf Sie bei der agilen

Transformation achten sollten ...

Abgerufen am 31. Mai 2017 von: https://www.informatik-aktuell.de/management-und-

recht/projektmanagement/wer-hat-angst-vor-agil-so-gelingt-die-agile-transformation.html

Kempfle, W. (30. Juni 2014). Strategieplanung – Instrumente des Strategischen Marketings. Agil statt

klassisch – Entwicklungstendenzen im modernen Projektmanagement

Abgerufen am 27. Mai 2017 von: http://blog.strategie-und-planung.de/agiles-

projektmanagement

Komus, A., & Kuberg, M. (Oktober 2015). GPM. Status Quo Agile - Studie zu Verbreitung und Nutzen

agiler Methoden

Abgerufen am 12. Juni 2017 von: https://www.gpm-

ipma.de/fileadmin/user_upload/GPM/Know-How/Studie_Agiles-PM_web.pdf

Lixenfeld, C. (26. Januar 2014). Gescheiterte IT-Projekte. (Computerwoche). Zu komplex und schlecht

geplant

Abgerufen am 14. Mai 2017 von: https://www.computerwoche.de/a/gescheiterte-it-

projekte,2546218

Ockl, A. (30. Oktober 2012). Computerwoche. Agiles Projekt-Management: Prince2 öffnet die Tür für

Scrum

Abgerufen am 29. 05 2017 von: https://www.computerwoche.de/a/prince2-oeffnet-die-tuer-

fuer-scrum,2489890

Office of Government Commerce (OGC). (2009). Erfolgreiche Projekte managen mit PRINCE2.

Norwich: The Stationery Office Books.

ProjektMagazin. Business Case.

Abgerufen am 13. Mai 2017 von https://www.projektmagazin.de/glossarterm/business-case



ProjektMagazin. Project Management Office.

Abgerufen am 05. Juni 2017 von https://www.projektmagazin.de/glossarterm/project-

management-office

Radon, B. (28. Mai 2015). CIO. Projekt-Entwicklung mit Scrum

Abgerufen am 21. Mai 2017 von: https://www.cio.de/a/projekt-entwicklung-mit-

scrum,2974798

Schindler, M. (28. Oktober 2013). silicon. 60 Prozent aller IT-Projekte nicht im Plan

Abgerufen am 14. Mai 2017 von: http://www.silicon.de/41591125/60-prozent-aller-it-

projekte-nicht-im-plan/

Schwaber, K. (2007). Agiles Projektmanagement mit Scrum. Unterschleißheim: Microsoft Press

Deutschland.

Schwaber, K., & Sutherland, J. (Juli 2016). SCRUM GUIDES. Der gültige Leitfaden für Scrum (Deutsch)

Abgerufen am 21. Mai 2017 von:

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-German.pdf

Scrum Alliance. Scrum Alliance Code of Ethics.

Abgerufen am 21. Mai 2017 von https://www.scrumalliance.org/code-of-ethics

SCRUM GUIDES. The History of Scrum.

Abgerufen am 13. Mai 2017 von http://www.scrumguides.org/history.html

Thun, H. (09. Oktober 2014). Computerwoche. Unternehmenskultur: Projektmanagement-Methode

muss zur Firma passen

Abgerufen am 27. Mai 2017 von: https://www.computerwoche.de/a/projektmanagement-

methode-muss-zur-firma-passen,3064183

Tumuscheit, K. D. (12. Mai 2017). Projektmagazin. Alles agil – oder was?

Abgerufen am 31. Mai 2017 von: https://www.projektmagazin.de/meilenstein/projekt-

management-blog/alles-agil-oder-was_1120082

Windolph, A. (02. Juli 2015). Online-Blog. Die 75 besten Projektmanagement-Zitate

Abgerufen am 15. Mai 2017 von: https://projekte-leicht-gemacht.de/blog/lesestoff/die-75-

besten-projektmanagement-zitate/

Wolf, H. (01. November 2016). Informatik Aktuell. Back to the future – eine Zeitreise in die Zukunft

der agilen Softwareentwicklung


recht/projektmanagement/back-to-the-future-eine-zeitreise-in-die-zukunft-der-agilen-

softwareentwicklung.html



VII. Ehrenwörtliche Erklärung

Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt habe. Die

aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.

Dies gilt auch für Zeichnungen, Skizzen und bildliche Darstellungen. Es wurden keine anderen als die

angegebenen Stellen und Hinweise verwandt.

Alle Quellen, die dem World Wide Web entnommen oder in einer sonstigen digitalen Form verwendet

wurden, ohne allgemein zugänglich zu sein, sind der Arbeit als elektronische Kopie beigefügt. Der

Durchführung einer elektronischen Plagiatsprüfung stimme ich hiermit zu. Die eingereichte schriftliche

Fassung entspricht der auf dem Medium gespeicherten Fassung.

Ich erkläre ferner, dass die vorliegende Arbeit bisher keiner anderen Prüfungsbehörde vorgelegt und

auch noch nicht veröffentlicht wurde.

Schwerin, 26.06.2017 _______________

Ort, Datum Unterschrift



VIII. Anlagenverzeichnis

Anlage 1 – Beispiel Brainstorming ......................................................................................................... 76

Anlage 2 – Anpassung der Prozesse von PRINCE2 ................................................................................ 77

Anlage 3 – Kopplung der Rollen von PRINCE2 und Scrum .................................................................... 78



Anlage 1 – Beispiel Brainstorming



Anlage 2 – Anpassung der Prozesse von PRINCE2

Abbildung 12 – PRINCE2-Prozess70

Abbildung 13 – PRINCE2-Prozess in einem Hybridmodell71

70 entnommen aus: Office of Government Commerce (OGC): Erfolgreiche Projekte managen mit PRINCE2. 2009 71 entnommen aus: https://www.projektmagazin.de/artikel/hybrides-projektmanagement-mit-prince2-und- scrum-teil-2_1105830, letzter Zugriff am 23.06.2017



Anlage 3 – Kopplung der Rollen von PRINCE2 und Scrum

Abbildung 14 – PRINCE2-Projektorganisation72

Abbildung 15 – PRINCE2-Projektorganisation in einem Hybridmodell73

72 entnommen aus: Office of Government Commerce (OGC): Erfolgreiche Projekte managen mit PRINCE2. 2009 73 entnommen aus: https://www.projektmagazin.de/artikel/hybrides-projektmanagement-mit-prince2-und- scrum-teil-2_1105830, letzter Zugriff am 24.06.2017

BACHELOR-T - PRINCE2 · PRINCE2 und Scrum: Eine Analyse der Planung und Umsetzung beider...

Documents

Transcript of BACHELOR-T - PRINCE2 · PRINCE2 und Scrum: Eine Analyse der Planung und Umsetzung beider...