SCRUM KANBAN MANAGEMENT 30 amp CO

DAS WHITEPAPER FUumlR ENTSCHEIDER

MODERNES (PROJEKT-)MANAGEMENT

S 2Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

INHALTSVERZEICHNIS

1 VORWORT 6

2 EINLEITUNG 7

3 bdquoPLAN DRIVEN DEVELOPMENTldquo VS bdquoVISION DRIVEN DEVELOPMENTldquo 8

4 AGILES VORGEHEN IST ITERATIV UND INKREMENTELL WAS HEISST DAS 9

41 Inkrement vs Iteration verbildlicht Die Mona Lisa 9

42 Was ist das kleinste shippable increment der Mona Lisa 10

43 Was ist die einfachste Iteration des Inkrements die shippable ist 10

44 Woher weiszlig man was Business Value hat 11

5 AGILE ANFORDERUNGSANALYSE MIT IMPACT MAPPING 12

51 Was ist Impact Mapping und wofuumlr wird es genutzt 12

52 So funktioniert Impact Mapping 13

6 AGILES PROJEKTMANAGEMENT MIT SCRUM 15

61 Die Scrum-Rollen 17

611 Product Owner 17

612 Scrum Master 17

62 Scrum Meetings 18

621 Sprint Planning 1 18

622 Sprint Planning 2 18

623 Daily Scrum 18

624 Sprint Review 19

625 Retrospektive 19

63 Sprint 20

64 Die Scrum-Artefakte 21

641 Sprint Backlog 21

642 Product Backlog 21

643 Impediment Backlog 22

644 Burndown-Diagramm 23

65 Welche Vorteile bietet Scrum 23

66 Die Kostenkalkulation in Scrum 24

67 Die groumlszligten Fehler im Scrum-Prozess 26

68 Uumlbersicht der Vor- und Nachteile von Scrum 29

69 Zusammenfassung Scrum 30

S 2Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

INHALTSVERZEICHNIS

1 VORWORT 6

2 EINLEITUNG 7

3 bdquoPLAN DRIVEN DEVELOPMENTldquo VS bdquoVISION DRIVEN DEVELOPMENTldquo 8

4 AGILES VORGEHEN IST ITERATIV UND INKREMENTELL WAS HEISST DAS 9

41 Inkrement vs Iteration verbildlicht Die Mona Lisa 9

42 Was ist das kleinste shippable increment der Mona Lisa 10

43 Was ist die einfachste Iteration des Inkrements die shippable ist 10

44 Woher weiszlig man was Business Value hat 11

5 AGILE ANFORDERUNGSANALYSE MIT IMPACT MAPPING 12

51 Was ist Impact Mapping und wofuumlr wird es genutzt 12

52 So funktioniert Impact Mapping 13

6 AGILES PROJEKTMANAGEMENT MIT SCRUM 15

61 Die Scrum-Rollen 17

611 Product Owner 17

612 Scrum Master 17

62 Scrum Meetings 18

621 Sprint Planning 1 18

622 Sprint Planning 2 18

623 Daily Scrum 18

624 Sprint Review 19

625 Retrospektive 19

63 Sprint 20

64 Die Scrum-Artefakte 21

641 Sprint Backlog 21

642 Product Backlog 21

643 Impediment Backlog 22

644 Burndown-Diagramm 23

65 Welche Vorteile bietet Scrum 23

66 Die Kostenkalkulation in Scrum 24

67 Die groumlszligten Fehler im Scrum-Prozess 26

68 Uumlbersicht der Vor- und Nachteile von Scrum 29

69 Zusammenfassung Scrum 30

S 3Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

INHALTSVERZEICHNIS

7 AGILES PROJEKTMANAGEMENT MIT KANBAN 31

71 Zur Geschichte von Kanban 31

72 Kanban in der Softwareentwicklung 31

73 Kanban in Projekten 32

74 So funktioniert Kanban 32

75 Vorteile im Uumlberblick 34

76 Konsens ndash Die Basis des Kanban-Change 34

77 Sieben Schritte fuumlr erfolgreiches Kanban 35

8 KANBAN VS SCRUM 37

81 Vorgaben bei Kanban 38

82 Vorgaben bei Scrum 38

83 Scrum und Kanban im direkten Vergleich 39

84 Wann eignet sich Kanban und wann Scrum besonders 40

85 Von Wasserfall uumlber Scrum zu Kanban 41

9 VERTRAGSGESTALTUNG BEI WEBPROJEKTEN 42

91 Klassisches oder agiles Projektmanagement 42

92 Probleme des klassischen bdquoWasserfallsldquo 42

93 Agile Projektmethode als Heilsbringer 43

94 Was beudeutet Agilitaumlt rechtlich 44

95 Gretchenfrage Werk- oder Dienstvertrag 44

96 Entscheidend ist der Vertragsinhalt 45

98 Zusammenfassung 46

10 TECHDIVISION BUBBLE BUDGETING 47

101 Bubble Budgeting 48

102 Wozu brauche ich Agile 50

103 Wozu brauche ich Lean 50

104 Alter Wein in neuen Schlaumluchen 50

11 WARUM EIN TRADITIONELLER AUSSCHREIBUNGSPROZESS VERALTET IST 51

12 AGILE METHODEN SIND ERFOLGREICH(ER) UND AUF DEM VORMARSCH 53

13 DER AGILE EVALUIERUNGSPROZESS 56

131 Klassisches Vorgehen vs agiles Vorgehen 57

132 Die vier Phasen der agilen Software-Evaulierung 58

1321 Discovery Phase 59

1322 Translation-Phase (User-Stories Epics) 63

1323 Auswahl- und Praumlsentationsphase 65

1324 Implementierungsphase 68

133 Kosten fuumlr das Testprojekt 70

S 4Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

INHALTSVERZEICHNIS

14 FAZIT 71

15 AGILE ARBEITSWEISEN EIGNEN SICH NICHT NUR FUumlR ENTWICKLUNG 72

151 Problem der Usability Engineers 73

152 Problem des Entwicklungsteams 73

153 Loumlsungsansatz 74

154 3 Praxistipps fuumlr eine erfolgreiche interdisziplinaumlre Zusammenarbeit 75

155 Loumlsungsansatz 76

156 Ausblick 77

16 DAS DIGITALISIERUNGSMANAGEMENT-DILEMMA 78

161 Wir machen jetzt Scrum und sind damit modern und agil 79

162 Agilisierung in der Praxis ndash unser Ansatz und einige Erfahrungen 80

163 Ein kurzer historischer Abriss 81

17 THEORIE X UND THEORIE Y ALS AUSGANGSPUNKT 82

171 McGregorlsquos kritische Entscheidung 83

18 FLOW 84

19 AGILE MANAGEMENT INNOVATIONS (AMIS) - HILFSMITTEL ZUR AGILISIERUNG 86

191 Die 26 AMIS im Uumlberblick 86

20 DER TECHDIVISION AGILISIERUNGSPROZESS UND EINIGE LEARNINGS DARAUS 88

21 DIE ERGEBNISSE UNSERES AGILISIERUNGSWORKSHOPS 89

22 DIE RECHNUNG OHNE DEN WIRT 92

23 FAZIT 93

24 AUTOREN 94

25 TECHDIVISION GMBH 95

26 WAS WIR FUumlR SIE TUN KOumlNNEN 96

27 DAS SAGEN KUNDEN UumlBER UNS 97

28 DIE ERGEBNISSE UNSERES AGILISIERUNGSWORKSHOPS 98

29 DAMIT NEHMEN SIE FAHRT AUF 99

30 LESETIPPS 100

31 IMPRESSUM 101

S 5Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

S 5

VOLLER LESESTOFFhellipBei vorliegendem Dokument handelt es sich um einen Auszug unseres

kostenlosen Whitepapers bdquoModernes (Projekt-)Management ndash Scrum

Kanban Management 30 amp Co

Auf rund 100 Seiten erlaumlutern wir Ihnen ausfuumlhrlich und praxisnah

Wissenswertes zu modernem (agilem) Projektmanagement das nicht

nur fuumlr IT-Abteilungen relevant ist Dabei gewaumlhren wir auch einen

Blick in unsere Agilisierungs- und Managementansaumltze und die damit

einhergehenden Praxiserfahrungen

Das Dokument kann unter nachfolgendem Link kostenlos

heruntergeladen werden

wwwtechdivisioncomprojektmanagement-whitepaper

Hier gehtlsquos zur Vollversion

S 6Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

VORWORT Das vorliegende Whitepaper moumlchte ich allen leidgeplagten (IT-)

Projektverantwortlichen widmen die sich mit den Tuumlcken staumlndig

aumlndernder Anforderungen bei (IT-)Projekten herumschlagen Aufgrund

von vorab ndash meist zu einem zu fruumlhen Zeitpunkt ndash fest definierten

Vorgaben werden Projekte meist unnoumltig in ein starres bdquoKorsettldquo

gezwaumlngt das keinerlei Aktion sondern nur noch Reaktion zulaumlsst In

Zeiten sich extrem dynamisch aumlndernder Umgebungen kann so kaum

mehr der noumltige Freiraum fuumlr einen erfolgreichen Projektabschluss

bestehen

Daruumlber hinaus moumlchten wir mit dem vorliegenden Whitepaper alle

Entscheidungstraumlger uumlberzeugen und sie ermutigen einen neuen Weg

einzuschlagen Pflichtenhefte und bis ins letzte Detail durchgeplante

Konzepte sowie klassisches bdquoCommand amp Controlldquo waren gestern

Lassen Sie Ihren Projekten und Mitarbeitern die Freiheit sich

dynamisch gemeinsam mit ihrem Umfeld zu entwickeln und erleben

Sie die Vorteile des agilen Projektmanagementansatzes der zu einer

erfolgreichen Bewaumlltigung von IT-Projekten beitraumlgt

In diesem Sinne wuumlnsche ich Ihnen die noumltige Geduld einen

gewissen Weitblick und ein ganzes Stuumlck Vertrauen in Ihre

Projektverantwortlichen Ich bin mir sicher dass diese das in

sie gesetzte Vertrauen und die damit moumlgliche Flexibilitaumlt nicht

missbrauchen werden und stattdessen noch praxisorientiertere und

auch bessere Endergebnisse abliefern werden

Sollten Sie noch kein entsprechendes Basiswissen in modernem

(Projekt-)Management besitzen oder Ihre bereits vorhandenen

Kenntnisse nochmals auffrischen wollen bieten wir Ihnen individuelle

Workshops und Trainings mit entsprechendem Praxisbezug an

Sprechen Sie einfach mit uns Gerne beraten wir Sie kostenlos und

unverbindlich

Ihr Josef Willkommer

S 7Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

EINLEITUNG

Wer kennt im IT-Umfeld nicht das altbekannte und auch

oftmals bdquoverdammteldquo Projektmanagement anhand des

sog Wasserfall-Modells Hierbei wird in einer mitunter

recht umfangreichen Konzeptphase im Vorfeld zuerst

ein Lastenheft erstellt das die fachlichen Anforderungen

an ein Projekt beschreibt Die technische Uumlbersetzung

dieser Anforderungen erfolgt dann im sog Pflichtenheft

das bei Bedarf noch um technische Feinkonzepte ergaumlnzt

wird Jedoch vergehen nicht selten viele Wochen ja

sogar Monate bis mit der eigentlichen Entwicklung

anhand der so erstellten Dokumente begonnen werden

kann Dabei beinhaltet diese Vorgehensweise einen ganz

entscheidenden Nachteil der in der Vergangenheit aber

dennoch immer wieder aufs Neue uumlbersehen wurde

Ein nicht unwesentlicher Teil der Anforderungen ist zu

Projektbeginn entweder noch nicht bekannt oder laumlsst

sich im Vorfeld nur grob skizzieren und definieren da

aufgrund von zunehmender Komplexitaumlt im Webumfeld

haumlufig erst im Projektverlauf alle technischen

Anforderungen bekannt und evaluiert werden koumlnnen

Zudem gibt es meist aufgrund sich aumlndernder externer

Faktoren oder Marktgegebenheiten nahezu immer

notwendige Anpassungen die in den meisten Faumlllen zur

Konsequenz haben dass das Endergebnis haumlufig ganz

anders aussieht bzw aussehen soll als dies zu Beginn

der Konzeption geplant war

Bereits vor etlichen Jahren wurde dieser

Umstand zum Anlass genommen um uumlber neue

Projektmanagementansaumltze nachzudenken die mehr

Flexibilitaumlt und am Ende auch mehr Sicherheit fuumlr alle

Beteiligten bieten sollen Das agile Projektmanagement

war geboren und mit zunehmender Dynamik

insbesondere im Webumfeld haben auch die Nachfrage

und die Bedeutung dieser agilen PM-Ansaumltze in den

letzten Jahren zu Recht signifikant zugenommen

Quelle httpwwwscrumallianceorg

Dabei haben sich insbesondere Scrum und Kanban

in juumlngerer Zeit etabliert Mit vorliegendem Dokument

moumlchten wir diese beiden Ansaumltze kurz vorstellen auf

deren Besonderheiten Vor- und Nachteile eingehen und

einige Tipps und Tricks zum Einstieg in die Welt des

agilen Projektmanagements vermitteln

An dieser Stelle empfehlen wir sich mit diesen Ansaumltzen

intensiv auseinander zu setzen da wir davon uumlberzeugt

sind dass insbesondere Webprojekte aufgrund der

weiter zunehmenden Dynamik und Komplexitaumlt zukuumlnftig

nur noch agil erfolgreich bewerkstelligt werden koumlnnen

S 8

Beim klassischen Projektmanagement-Ansatz wird der

Umfang der gesamten zu entwickelnden Loumlsung vorab

festgelegt und genau definiert Bei einer derartigen

Planungs- und Spezifikationsphase ndash dem bdquoBig Design

Up-Frontldquo ndash stellt der Projektleiter bei Umsetzung

eines Projekts oftmals fest dass Zeit und Budget

falsch kalkuliert sind oder dass das Projektteam die

Beduumlrfnisse und Anforderungen des Kunden nicht

zielfuumlhrend bearbeiten konnte Durch das bdquoPlan-

Driven-Developmentldquo entstehen daher meist Stress

Unzufriedenheit und auch mangelnde Wirtschaftlichkeit

Nachfolgende Abbildung verdeutlicht den Unterschied

zwischen dem klassischen Projektmanagement und

agilen Methoden

Quelle httpt3ndemagazinpraxisbericht-scrum-

kanban-scrumbuts-agiles-232822

bdquoPLAN DRIVEN DEVELOPMENTldquo VS bdquoVISION DRIVEN DEVELOPMENTldquo

Der agile Ansatz zeichnet

sich vor allem dadurch

aus dass zu Beginn eines Projekts

Zeit und Budget als Konstanten definiert

werden Zusammen mit dem Kunden werden

dann Anforderungen ausgearbeitet die sich innerhalb

dieses Rahmens realisieren lassen Die Rede ist dann

vom sogenannten bdquoVision Driven Developmentldquo Der

Vorteil dieser Vorgehensweise liegt vor allem darin

dass der Kunde fortwaumlhrend den Verlauf des Projekts

mitbestimmen kann und die einzelnen To-Dorsquos

von Iteration zu Iteration bestimmen kann (Scope

Management) Das transparente Vorgehen hilft nicht nur

den Entwicklern zielfuumlhrend zu arbeiten Auch der Kunde

bekommt dadurch ein besseres Gefuumlhl fuumlr das laufende

Projekt Durch die Value-Driven-Arbeitsweise kann das

Team aus vorangegangenen Iterationen lernen und das

Gelernte fuumlr die naumlchsten Schritte nutzen

Quelle httpt3ndemagazinpraxisbericht-scrum-

kanban-scrumbuts-agiles-232822

S 9Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

AGILES VORGEHEN IST ITERATIV UND INKREMENTELL WAS HEISST DAS

Ein Inkrement ist ein fertiges Teilstuumlck Ergebnis einer

Iteration ist dagegen eine neue (moumlglichst verbesserte)

Version eines bestehenden Teilstuumlcks oder auch des

Ganzen

Das fertige Stahlgeruumlst einer Bruumlcke von Ufer zu Ufer

das man noch auskleiden muss damit man die Bruumlcke

befahren kann ist Ergebnis einer Iteration bdquoBruumlcke

bauenldquo

Die ganze Bruumlcke ist da aber eben erst einmal nur

als Geruumlst Schwindelfreie koumlnnen den Fluss so schon

uumlberqueren Hinuumlberfahren kann man aber noch nicht

Die ersten 100 Meter fertige Bruumlcke bis zum Pfeiler 2

mit allem Pipapo fertig befahrbar sind ein Inkrement der

Bruumlcke Das Inkrement ist fertig aber es ist noch keine

Bruumlcke nur ein Teilstuumlck Niemand kommt uumlber den

Fluss auch kein Fuszliggaumlnger

Bildlich zeigt die Mona Lisa was gemeint ist Das

Beispiel ist von Jeff Patton dem Erfinder der Story

Maps fuumlr User Storys Oben sehen wir inkrementelles

Vorgehen Stuumlck fuumlr Stuumlck wird das Bild in den

Endzustand versetzt Unten sehen wir iteratives

Vorgehen das gesamte Bild wird vom Start weg erstellt

erst einmal grob dann wird es immer weiter verfeinert

bzw ausgemalt bis das Gesamte fertig ist

Der Kern des agilen Vorgehens ist nun Was ist das

kleinste Inkrement mit dem wir etwas Wertvolles

liefern Und was ist die einfachste Iteration die wir dafuumlr

verwenden koumlnnen

Quelle httpwwwagileproductdesigncomblogdont_know_what_i_wanthtml

41 INKREMENT VS ITERATION VERBILDLICHT DIE MONA LISA

S 10Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

Vielleicht ihr Gesicht Ja die Kunstliebhaber wuumlrden

etwas zahlen um ein kleines Portrait (gemalt von da

Vinci) von Mona Lisa zu bekommen sagt der Gemaumllde-

PO Also nicht das gesamte Bild der Mona Lisa sitzend

vor einer Landschaft sondern nur das Gesicht Besser

als nichts Wuumlrden die Leute auch zahlen um die linke

obere Ecke des finalen Bilds zu besitzen Weniger

wahrscheinlich sagt der Gemaumllde-PO Fangen wir also

mit dem Gesicht an das scheint als erstes Inkrement

den houmlchsten Business Value zu haben

Unser Ziel ist dabei nicht das groszlige Ganze einfach nur in

Teilstuumlcke (Inkremente) zu zerbrechen die wir dann nach

und nach liefern Denn dann hat erst das Ganze das sich

am Schluss zusammensetzt einen Wert

Ein Gesicht schoumln zu malen kostet Zeit und Geld sagt

da Vinci Fangen wir deshalb mit einer ersten Iteration

an Eine Strichzeichnung des Gesichts Ist diese

Strichzeichnung ein potentially shippable product

Ja denn die Leute zahlen auch fuumlr eine Skizze von

da Vinci meint der PO Waumlre eine niedergeschriebene

Absichtserklaumlrung von da Vinci bdquoIch werde ein schoumlnes

Gesicht malen es wird eine Frau zeigen die laumlchelt als

habe sie sich einen kleinen Witz erzaumlhlt ich sagrsquos euch

das wird superldquo waumlre das ein potentially shippable

product Der Gemaumllde-PO geht davon aus dass die

Leute nicht viel fuumlr so etwas zahlen wuumlrden Also nein

(Working software over comprehensive documentation)

Das ist zu spaumlt Vielmehr wollen wir Inkremente

waumlhlen die vermutlich () einen hohen Wert haben

Vielleicht kommt der Gemaumllde-PO und erzaumlhlt uns nach

Praumlsentation des Inkrements uumlberrascht bdquoPortraits sind

out Kein Mensch will nur Gesichter Haumlnde Das ist es

Wir brauchen die Haumlnde dazuldquo Wir passen uns an den

Markt an und sagen da Vinci bdquoMach als naumlchstes die

Haumlndeldquo We increment to adapt

Noch besser als ein fertiges Inkrement abzuliefern um

zu sehen ob es den Beduumlrfnissen der Nutzer entspricht

ist es aber sich iterativ dem perfekten fertigen

Inkrement zu naumlhern So merken wir noch schneller ob

Gesichter uumlberhaupt gefragt sind

42 WAS IST DAS KLEINSTE SHIPPABLE INCREMENT DER MONA LISA

43 WAS IST DIE EINFACHSTE ITERATION DES INKREMENTS DIE SHIPPABLE IST

Bei Scrum fallen die beiden bdquoRhythmenldquo von

Inkrementen und Iterationen uumlbrigens zusammen (im

Sprint) Das muss nicht so sein und ist in anderen agilen

Methoden anders z B im XP oder DSDM oder den

Crystal Methods

Noch mal zur Iteration Ist eine Strichzeichnung

die einen Kreis zwei Punkte (= Augen) und einen

Halbkreis (= Laumlcheln) zeigt ein akzeptables Ergebnis

einer ersten Iteration Der Gemaumllde-PO sagt nein

die Implementierungstiefe bdquoStrichmaumlnnchenldquo des

InkrementsbdquoGesichtldquo der Mona Lisa wuumlrden die

Kunstliebhaber mit houmlchster Wahrscheinlichkeit nicht

akzeptieren Ein bisschen mehr muss es schon sein

S 11

bdquoIst das immer soldquo fragen wir den Gemaumllde-PO

Nein sagt er Es ist houmlchstwahrscheinlich bei Keith

Haring anders als bei da Vinci Keith Haring ging in der

Implementierungstiefe uumlber Strichmaumlnnchen selten

hinaus Ein Strichmaumlnnchen von Keith Haring kaufen die

Leute wie warme Semmeln auf die Art verdienen wir

Geld

Der Business Value ist kontextspezifisch

domaumlnenspezifisch usw Der Kunde muss uns sagen

was fuumlr ihn Wert hat wir koumlnnen es (meistens) nicht

ohne ihn wissen Oft weiszlig er es selber nicht dann

muumlssen wir ihm helfen herauszufinden was fuumlr ihn

welchen Business Value hat und wie man das testen

kann Impact Mapping ist eine der vielen Moumlglichkeiten

die dem Kunden dabei helfen koumlnnen

44 WOHER WEISS MAN WAS BUSINESS VALUE HAT

S 11

S 12Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

AGILE ANFORDERUNGSANALYSE MIT IMPACT MAPPING

Impact Mapping ist eine strategische Planungstechnik

und Anforderungsanalyse Es hilft Unternehmen dabei

das Ziel waumlhrend einer Projektarbeit nicht aus den Augen

zu verlieren und foumlrdert ein zielgerichtetes Arbeiten

Konzepte wie Lean Startup oder Continuous Delivery

gewinnen dabei immer mehr an Bedeutung waumlhrend

der herkoumlmmliche auf Vollstaumlndigkeit und Korrektheit

abzielende Begriff der bdquoAnforderungldquo immer mehr in den

Hintergrund geraumlt (vgl httpbtdaysde2014sesessions

continuous-learning-agile-anforderungsanalyse-mit-

impact-mapping) In diesem Zusammenhang wurde von

Gojko Adzic das sogenannte Impact Mapping entwickelt

welches sich des Problems annimmt und den Spagat

zwischen Plan und Experiment schafft (vgl http

deslidesharenetspringifysoftware-that-matters-agile-

anforderungsanalyse-mit-impact-mapping)

Projekte haben eine voneinander abhaumlngige dynamische

Beziehung zu Menschen anderen Projekten sowie

Organisationen und Gemeinschaften um sie herum

Impact Mapping versteht sich dabei als kooperatives

und kreatives Verfahren das einen besseren Uumlberblick in

einem laufenden Projekt verschaffen soll

(vgl httpdeslidesharenetspringifysoftware- that-

matters-agile-anforderungsanalyse-mit-impact-

mapping)

bdquoImpact mapping helps to reduce waste by preventing

scope creep and over-engineered solutions It provides

focus for delivery by putting deliverables in the context

of impacts they are supposed to achieve It enhances

collaboration by creating a big-picture view that

business sponsors and delivery teams can use for better

priorisation and as a reference for more meaningful

progress monitoring and reporting Finally it helps to

ensure that the right business outcomes are achieved or

that unrealistic projects are stopped before they cost too

much by clearly communicating underlying assumptions

and allowing teams to test themldquo

Quelle httpimpactmappingorgaboutphp

51 WAS IST IMPACT MAPPING UND WOFUumlR WIRD ES GENUTZT

S 12Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

AGILE ANFORDERUNGSANALYSE MIT IMPACT MAPPING

Impact Mapping ist eine strategische Planungstechnik

und Anforderungsanalyse Es hilft Unternehmen dabei

das Ziel waumlhrend einer Projektarbeit nicht aus den Augen

zu verlieren und foumlrdert ein zielgerichtetes Arbeiten

Konzepte wie Lean Startup oder Continuous Delivery

gewinnen dabei immer mehr an Bedeutung waumlhrend

der herkoumlmmliche auf Vollstaumlndigkeit und Korrektheit

abzielende Begriff der bdquoAnforderungldquo immer mehr in den

Hintergrund geraumlt (vgl httpbtdaysde2014sesessions

continuous-learning-agile-anforderungsanalyse-mit-

impact-mapping) In diesem Zusammenhang wurde von

Gojko Adzic das sogenannte Impact Mapping entwickelt

welches sich des Problems annimmt und den Spagat

zwischen Plan und Experiment schafft (vgl http

deslidesharenetspringifysoftware-that-matters-agile-

anforderungsanalyse-mit-impact-mapping)

Projekte haben eine voneinander abhaumlngige dynamische

Beziehung zu Menschen anderen Projekten sowie

Organisationen und Gemeinschaften um sie herum

Impact Mapping versteht sich dabei als kooperatives

und kreatives Verfahren das einen besseren Uumlberblick in

einem laufenden Projekt verschaffen soll

(vgl httpdeslidesharenetspringifysoftware- that-

matters-agile-anforderungsanalyse-mit-impact-

mapping)

bdquoImpact mapping helps to reduce waste by preventing

scope creep and over-engineered solutions It provides

focus for delivery by putting deliverables in the context

of impacts they are supposed to achieve It enhances

collaboration by creating a big-picture view that

business sponsors and delivery teams can use for better

priorisation and as a reference for more meaningful

progress monitoring and reporting Finally it helps to

ensure that the right business outcomes are achieved or

that unrealistic projects are stopped before they cost too

much by clearly communicating underlying assumptions

and allowing teams to test themldquo

Quelle httpimpactmappingorgaboutphp

51 WAS IST IMPACT MAPPING UND WOFUumlR WIRD ES GENUTZT

S 13

Impact Mapping verbindet verschiedene Methoden

miteinander und stellt Prozesse visuell dar Die Methode

dient somit zum Loumlsen komplexer Probleme und

eignet sich vor allem auch fuumlr heterogene Gruppen

Vorkenntnisse werden kaum benoumltigt Der Start beim

Impact Mapping ist immer mit einem geschaumlftlichen

Ziel verbunden So kann der eigentliche Nutzen eines

Projekts staumlrker fokussiert werden

52 SO FUNKTIONIERT IMPACT MAPPING

Impact Mapping bedeutet so viel wie bdquoAuswirkungs-

Zuordnungldquo und besteht aus den Phasen

bdquoVorbereitungldquo (Preparation) und Zuordnung (Mapping)

In der ersten Phase geht es vor allem darum Ziele genau

zu definieren passende Messmethoden zu finden und

den ersten Meilenstein festzulegen In Phase zwei wird

das Ganze dann in Form einer Mindmap-artigen Karte

aufgearbeitet und visualisiert (vgl httpwwwwolterbiz

tagimpact-mapping)

Beim Impact Mapping wird vor allem ein iteratives

sowie agiles Arbeiten unterstuumltzt welches in vielen

Unternehmen bereits zum Alltag gehoumlrt Die graphische

Herangehensweise foumlrdert dabei die Entwicklung neuer

Ideen (vgl httpwwwwolterbiztagimpact-mapping)

VISION

CONSUMER

IMPACT

PRODUCT MILESTONE

WHO

HOW

S 14Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

Quelle wwwimpactmappingorg

PLAY

ERS

INTE

RNAL

ADVE

RTIS

ERS

1M PLAYERS

BULK

INUI

TATI

ONS

PUBL

ISHI

NG O

UR B

ANNE

RS

ENGA

GING

OUR

NET

WOR

K

INVI

TES

ORGA

NISE

PRE

VENT

INVI

TING

FRI

ENDS

VIRA

L CO

NTEN

T

INCE

NTIV

ESRe

cogn

ition

for i

nviti

ng lo

ts o

f frie

nds

My

tour

nam

ents

My

tabl

e

My

even

ts

Web

site

opt

imiz

ed fo

r new

use

rs

Rebr

andi

ng G

ames

MOR

E CO

MPE

LLIN

G PR

ODUC

TS

PERS

ONAL

ISAT

ION

SEM

I AUT

OMAT

IC IN

VITE

S

BOOK

MAR

KING

REC

OMM

ENDI

NG

LEVE

LS

ARCH

IEVE

MEN

TS

WEE

KLY

COM

PETI

TION

S

TOUR

NAM

ENT

ENDI

NG

CONT

ENT

TO P

OST

ABOU

T PO

STIN

G

S 15Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

AGILES PROJEKTMANAGEMENTMIT SCRUM

Dabei charakterisiert sich Scrum ndash insbesondere im direkten Vergleich mit klassischen Entwicklungsmethoden ndash

durch die nachfolgenden drei Prinzipien

S 15

bull TRANSPARENZ Der F ortschriftt und die Hindernisse eines Projektes w erden taglich fuumlr alle sichtbar festgehalten

bull UumlBERPRUumlFEN In regelmassigen Abstanden w erden Produktfunktionalitaten geliefert und beurteilt

bull ANPASSUNG Die Anforderungen an das Produkt w erden nicht ein fuumlr alle Mal im Vorfeld festgelegt sondern nach jeder L ieferung eines Teilprojektes neu bew ertet und bei Bedarf angepasst

Im vorliegenden Kapitel moumlchten wir die agile

Projektentwicklung mit Scrum etwas naumlher beleuchten

wichtige Rollen und Tools sowie das Vorgehen in der

Praxis kurz erlaumlutern und auch auf das Thema Pricing

und Kalkulation eingehen Vorab moumlchten wir aber gleich

noch mit einem Trugschluss aufraumlumen Obwohl es bei

Scrum keine ausufernde Konzeptphase gibt bedeutet

dies mitnichten dass man planlos agiert Genau das

Gegenteil ist der Fall

Aber lesen Sie einfach selbst

Waumlhrend man beim klassischen Entwicklungsansatz

nach dem sog Wasserfall-Modell im Vorfeld bereits

detaillierte Anforderungen mit entsprechend genauen

Arbeitsanweisungen fuumlr das gesamte Projekt zu leisten

versucht erhalten Scrum Teams ihre entsprechenden

Zielvorgaben erst kurz vor der Implementierung und

auch nur fuumlr das jeweilige Teilstuumlck (Inkrement) der

gesamt zu entwickelnden Software Das hochqualifizierte

und insgesamt interdisziplinaumlre Scrum Team bringt

sich zudem in die Planung und konzeptionelle

Weiterentwicklung der Software aktiv mit ein

Insofern kann auch der erste moumlgliche Trugschluss

Scrum sei bdquoplanlosldquo widerlegt werden Bei Scrum

wird lediglich die genaue Art der Umsetzung nicht

vorgegeben sondern im Team erarbeitet wobei hier

zum einen der gruppendynamische Prozess im Team

vorteilhaft zum Tragen kommt und zum anderen

natuumlrlich auch laufende Erkenntnisse permanent in die

Arbeit einflieszligen

Der Scrum-Ansatz Zerteilung komplexer und

umfangreicher Entwicklung in kleine Teilprojekte

(Inkremente) die nacheinander in sog Sprints

(Iterationen) die in der Regel zwei bis vier Wochen

dauern umgesetzt werden und bei denen das Ziel

die Auslieferung von funktionsfaumlhigem und qualitativ

hochwertigem Code darstellt

Scrum akzeptiert dabei dass der gesamte

Entwicklungsprozess nicht vorherzusehen ist Das

oberste Ziel in einem Scrum-Projekt besteht darin die

bestmoumlgliche Software unter Beruumlcksichtigung der

Kosten der Funktionalitaumlt der Zeit und der Qualitaumlt

abzuliefern

S 16Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

Im Jahre 2001 wurde von einigen IT-Vordenkern

das mittlerweile beruumlhmte bdquoAgile Manifestldquo erstellt

das auf den nachfolgenden zwoumllf Prinzipien

basiert und die Grundlage fuumlr verschiedene agile

Projektmanagementansaumltze bildet

rsaquo Unsere houmlchste Prioritaumlt ist es den Kunden durch

fruumlhe und kontinuierliche Auslieferung wertvoller

Software zufrieden zu stellen

rsaquo Heiszlige Anforderungsaumlnderungen selbst spaumlt in der

Entwicklung sind willkommen Agile Prozesse nutzen

Veraumlnderungen zum Wettbewerbsvorteil des Kunden

rsaquo Liefere funktionierende Software regelmaumlszligig

innerhalb weniger Wochen oder Monate und

bevorzuge dabei die kuumlrzere Zeitspanne

rsaquo Fachexperten und Entwickler muumlssen waumlhrend des

Projektes taumlglich zusammenarbeiten

rsaquo Errichte Projekte rund um motivierte Individuen Gib

ihnen das Umfeld und die Unterstuumltzung die sie

benoumltigen und vertraue darauf dass sie die Aufgabe

erledigen

rsaquo Die effizienteste und effektivste Methode

Informationen an und innerhalb eines

Entwicklungsteams zu uumlbermitteln ist im Gespraumlch

von Angesicht zu Angesicht

rsaquo Funktionierende Software ist das wichtigste

Fortschrittsmaszlig

rsaquo Agile Prozesse foumlrdern nachhaltige Entwicklung Die

Auftraggeber Entwickler und Benutzer sollten ein

gleichmaumlszligiges Tempo auf unbegrenzte Zeit halten

koumlnnen

rsaquo Staumlndiges Augenmerk auf technische Exzellenz und

gutes Design foumlrdert Agilitaumlt

rsaquo Einfachheit ndash die Kunst die Menge nicht getaner

Arbeit zu maximieren ndash ist essenziell

rsaquo Die besten Architekturen Anforderungen und

Entwuumlrfe entstehen durch selbstorganisierte Teams

rsaquo In regelmaumlszligigen Abstaumlnden reflektiert das Team wie

es effektiver werden kann und passt sein Verhalten

entsprechend an

Quelle httpagilemanifestoorgisodeprincipleshtml

S 17Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

Das bdquoAgile Manifestldquo fuumlhrt auszligerdem die u s Werte

auf von denen die jeweils links stehenden in der agilen

Softwareentwicklung eine besonders wichtige d h

groumlszligere Rolle spielen als die rechts davon stehenden

Quelle httpagilemanifestoorg

Waumlhrend in der klassischen Entwicklung haumlufig isoliert

entwickelt wird und jeder Entwickler sein bdquoeigenes

Suumlppchenldquo kocht steht bei Scrum der Team-Gedanke im

Vordergrund So unterscheidet man innerhalb von Scrum

drei klassische Rollen sowie drei dazugehoumlrige Gruppen

die man jedoch auch aus anderen Entwicklungsansaumltzen

kennt

61 DIE SCRUM-ROLLEN

611 PRODUCT OWNER

612 SCRUM MASTER

Diese Rolle kann als verlaumlngerter Arm des Kunden

gesehen werden Der Product Owner gibt die

Anforderungen und die strategische Marschrichtung

inkl Priorisierung von Anforderungen bzw Tasks vor

Diese werden als sog User Stories in Abstimmung mit

dem Entwicklungsteam im Product Backlog erfasst

Damit werden die gewuumlnschten bzw benoumltigten

Funktionalitaumlten aus der Sicht des Users beschrieben

Waumlhrend der Product Owner fuumlr den Erfolg des Projekts

zustaumlndig ist garantiert der Scrum Master fuumlr den

Erfolg des Scrum-Prozesses Dabei moderiert er die

anfallenden Meetings und kuumlmmert sich darum dass

etwaige Hemmnisse im Scrum-Prozess beseitigt werden

Der Product Owner uumlberpruumlft am Ende eines Sprints

ob die gelieferte Software die User Akzeptanz Kritierien

erfuumlllt und verwendet werden kann Entscheidungen

des Product Owners sind verbindlich denn er ist fuumlr

das Endergebnis und die wirtschaftlichen Aspekte

verantwortlich Haumlufig wird der Product Owner vom

Auftragnehmer gestellt und stellt die Bruumlcke zwischen

Kunde und dem restlichen Scrum Team dar

Dazu zaumlhlen u a mangelnde Kommunikation oder

Stoumlrungen von auszligen Der Scrum Master arbeitet eng mit

dem Entwicklungsteam zusammen und uumlbernimmt dabei

ausschlieszliglich administrative Aufgaben ohne konkrete

Arbeitsanweisungen geben zu duumlrfen Dabei agiert der

Scrum Master als bdquoCoachldquo innerhalb des Teams

INDIVIDUALS amp INTERACTIONS

WORKING SOFTWARE

CUSTOMER COLLABORATION

RESPONDING TO CHANGE

Over processes and tools

Over comprehensive documentation

Over contract negotiation

Over follow ing a plan

S 18Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

62 SCRUM MEETINGS

621 SPRINT PLANNING 1

622 SPRINT PLANNING 2

623 DAILY SCRUM

Im sog Sprint Planning 1 werden die Anforderungen

dem Entwicklungsteam vom Product Owner vorgestellt

Einfach ausgedruumlckt erklaumlrt der Product Owner dem

Entwicklungsteam was zu tun ist Waumlhrend dieses

Meetings kann auch ein User d h tatsaumlchlicher

Anwender der Software dabei sein der dem Team ndash

zusammen mit dem Product Owner ndash erklaumlren kann

wie er sich die entsprechenden Funktionalitaumlten

vorstellt Das Entwicklungsteam hat hier Zeit sich

mit den Anforderungen vertraut zu machen etwaige

Fragen zu klaumlren und die Anforderungen auch wirklich

Im anschlieszligenden Sprint Planning 2 klaumlrt das

Entwicklerteam dann eigenverantwortlich wie die zuvor

vorgestellten Anforderungen umgesetzt werden Dabei

werden die Anforderungen in sog Tasks zerlegt die

normalerweise nicht laumlnger als einen Tag dauern sollen

Die Tasks werden dann am sog Taskboard angebracht

rsaquo Waumlhrend des Sprints trifft sich das Entwicklungsteam

taumlglich zum sog Daily Scrum Darunter versteht man ein

zwingend auf maximal 15 Minuten definiertes Meeting

bei dem das Team den aktuellen Stand der Entwicklung

sowie die aktuellen und die zuletzt bearbeiteten Tasks

sowie die fuumlr heute anstehenden Tasks bespricht

Konkret werden dabei die folgenden Fragestellungen im

Team besprochen

zu verstehen Im Sprint Planning 1 werden auch die

Abnahmekriterien User Akzeptanz Kriterien fuumlr die

einzelnen Stories definiert die am Ende im sog Sprint

Review gepruumlft werden Das Ziel eines jeden Sprints

besteht in der Auslieferung gebrauchsfaumlhiger und

getesteter Software Als zeitlicher Umfang fuumlr dieses

Meeting koumlnnen pro Sprint-Woche (in der Regel besteht

ein Sprint aus 2-4 Wochen) 60 Minuten angesetzt

werden Die im Sprint Planning Meeting besprochenen

Anforderungen werden im sog Sprint-Backlog erfasst

und dort uumlberwacht

wodurch ein sehr schneller Uumlberblick uumlber den aktuellen

Sprint die dafuumlr anstehenden Aufgaben und den

jeweiligen Status moumlglich wird

Auch fuumlr dieses Meeting sollten pro Sprint-Woche ca 60

Minuten angesetzt werden

rsaquo Sollte sich herausstellen dass einzelne Tasks z B

nicht innerhalb eines Tages erledigt werden koumlnnen

koumlnnen diese auch in kleinere Aufgaben herunter

gebrochen werden Sollten sich Fragen oder Probleme

ergeben die innerhalb der 15 Minuten nicht geklaumlrt

werden koumlnnen ist es die Aufgabe des Scrum Masters

sich um diese Punkte zu kuumlmmern Diese Punkte werden

vom Scrum Master dann im sog Impediment Backlog

erfasst und weiter bearbeitet rsaquo

S 19Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

624 SPRINT REVIEW

625 RETROSPEKTIVE

Am Ende eines Sprints erfolgt das sog Sprint Review

bei dem das Entwicklungsteam dem Product Owner

und vor allem auch dem User die aus den im Sprint

Planning Meeting 1 definierten Anforderungen realisierte

Softwareloumlsung vorstellt Der Product Owner entscheidet

dann anhand der vorab definierten Kriterien ob das

Ergebnis abgenommen werden kann oder nicht Dabei

Mit Abschluss des Sprint Reviews erfolgt ein ganz

entscheidender Abschnitt im Rahmen eines Scrum-

Projektes Das Scrum-Team (Product Owner Scrum

Master Entwicklungsteam) trifft sich geschlossen zur

sog Retrospektive bei der etwaige Probleme Learnings

und Verbesserungsmoumlglichkeiten fuumlr den nachfolgenden

Sprint diskutiert werden Im Prinzip wird hier der

vorangegangene Sprint nochmals kritisch hinterfragt und

besteht das Ziel in einem 100-igen Erreichen des

Zieles Sollten bestimmte Anforderungen nicht ganz

erfuumlllt sein werden diese vom Product Owner als neue

bzw nochmalige User Story in das kommende Sprint

Planning Meeting uumlbernommen

Gleiches gilt fuumlr neue Ideen oder Anforderungen die sich

waumlhrend des Sprint Reviews ergeben

positive sowie negative Erkenntnisse werden notiert mit

dem Ziel Verbesserungspotentiale fuumlr den neuen Sprint

abzuleiten Sofern es sich um Verbesserungen handelt

die das Team alleine betreffen werden diese auch

vom Team selbst geloumlst Etwaige andere Hemmnisse

werden vom Scrum Master im sog Impediment Backlog

aufgenommen und vom ihm dann an den Product Owner

zur Bewertung fuumlr den folgenden Sprint weitergegeben

S 19

S 20

63 SPRINT

PRODUKT

BACKLOG

SPRINT

BACKLOG

LAUFFAumlHIGE

INKREMENTELL VERBESSERTE

SOFTWARE

SPRINTS

30

TAGE

1

TAG

DAILY

SCRUM

Im Rahmen eines Sprints der eine Iteration von max

4 Wochen darstellt werden die im Sprint Planning

besprochenen und am houmlchsten priorisierten Tasks (User

Stories) erledigt Waumlhrend eines Sprints konzentriert sich

das Entwicklungsteam also ausschlieszliglich auf die in User

Stories formulierten Anforderungen auf die es sich im

Sprint Planning committet hat

Die Aufgabe des Scrum Masters besteht darin etwaige

Stoumlrfeuer oder Hemmnisse zu beseitigen so dass sich

das Team ausschlieszliglich auf die Fertigstellung und

Auslieferung funktionsfaumlhiger Software konzentrieren

kann Der Scrum Master darf dabei keine Anweisungen

an das Team erteilen sondern unterstuumltzt das Team

lediglich dabei das definierte Ziel zu erreichen

Das zentrale Ziel eines Sprints ist es ein Stuumlck potentiell

auslieferbarer Software zu liefern Selbst wenn aus

Zeitgruumlnden oder aus Gruumlnden unerwarteter Komplexitaumlt

bestimmte Aspekte in einem Sprint nicht (wie

vorgesehen) realisiert werden koumlnnen endet der Sprint

dennoch gemaumlszlig Zeitplan ndash und muss dabei zwingend ein

in sich abgeschlossenes funktionierendes Stuumlck Arbeit

produzieren So kann der Kunde nach jedem Sprint

entscheiden ob er das Teilstuumlck des Gesamtprojekts

evtl schon produktiv einsetzen oder aber mehrere

Teilstuumlcke in ein Release buumlndeln und zu einem spaumlteren

Zeitpunkt online stellen moumlchte ndash der Geschaumlftswert fuumlr

den Kunden steht bei Scrum also stets im Vordergrund

S 21Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

64 DIE SCRUM-ARTEFAKTE

641 SPRINT BACKLOG

642 PRODUCT BACKLOG

Das Sprint Backlog ist eine Liste von Aufgaben die

vom Scrum Team definiert und waumlhrend eines Sprints

abgearbeitet wird Die Aufgaben werden dabei taumlglich

uumlberarbeitet und aktualisiert Durch das Sprint Backlog

wird ein Projekt transparenter und es wird ein Uumlberblick

geschaffen welches Team-Mitglied an welcher Aufgabe

arbeitet und welche Tasks noch umgesetzt werden

muumlssen In diesem Zusammenhang wird ein Taskboard

eingesetzt Quelle httpsborisglogercomscrum

Wikipedia erklaumlrt den Sprint Backlog wie folgt

bdquoDas Sprint Backlog dient zur Uumlbersicht der fuumlr einen

Sprint zu erledigenden Aufgaben Zu diesem Zweck

kann ein Taskboard eingesetzt werden Es besteht

aus vier Spalten In der ersten Spalte (bdquoStoriesldquo)

Wie bereits erwaumlhnt werden die Anforderungen vom

Product Owner im Product Backlog festgehalten Unter

dem Product Backlog versteht man eine priorisierte

und rein nutzerorientierte Liste mit Anforderungen die

das zu entwickelnde Produkt beruumlcksichtigen muss

Idealerweise erfolgt ein Eintrag in Form einer User Story

als Antwort auf die Frage

bdquoWer moumlchte was warumldquo nach folgendem Muster

werden die User Stories aufgehaumlngt fuumlr die sich das

Entwicklungsteam zu diesem Sprint verpflichtet hat

(in der vom Product Owner priorisierten Reihenfolge)

Die drei weiteren Spalten enthalten die Aufgaben oder

Tasks die sich aus den einzelnen User Stories ergeben

(und die im Sprint Planning 2 festgelegt worden sind) Je

nach Bearbeitungsstand sind die Tasks entweder offen

(bdquoTasks to Doldquo) in Bearbeitung (bdquoWork in Progressldquo)

oder erledigt (bdquoDoneldquo) Im Daily Scrum erklaumlrt jedes

Mitglied des Entwicklungsteams anhand des Taskboards

an welcher Aufgabe es am Vortag gearbeitet hat und

ob diese erledigt wurde Tasks die an einem Tag nicht

beendet werden konnten werden mit einem roten Punkt

markiert So koumlnnen Hindernisse schnell identifiziert

werdenldquo

bdquoAls User x moumlchte ich Funktionalitaumlt y damit ich Nutzen

z habeldquo

Quelle httpsborisglogercomscrum

S 21Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

64 DIE SCRUM-ARTEFAKTE

641 SPRINT BACKLOG

642 PRODUCT BACKLOG

Das Sprint Backlog ist eine Liste von Aufgaben die

vom Scrum Team definiert und waumlhrend eines Sprints

abgearbeitet wird Die Aufgaben werden dabei taumlglich

uumlberarbeitet und aktualisiert Durch das Sprint Backlog

wird ein Projekt transparenter und es wird ein Uumlberblick

geschaffen welches Team-Mitglied an welcher Aufgabe

arbeitet und welche Tasks noch umgesetzt werden

muumlssen In diesem Zusammenhang wird ein Taskboard

eingesetzt Quelle httpsborisglogercomscrum

Wikipedia erklaumlrt den Sprint Backlog wie folgt

bdquoDas Sprint Backlog dient zur Uumlbersicht der fuumlr einen

Sprint zu erledigenden Aufgaben Zu diesem Zweck

kann ein Taskboard eingesetzt werden Es besteht

aus vier Spalten In der ersten Spalte (bdquoStoriesldquo)

Wie bereits erwaumlhnt werden die Anforderungen vom

Product Owner im Product Backlog festgehalten Unter

dem Product Backlog versteht man eine priorisierte

und rein nutzerorientierte Liste mit Anforderungen die

das zu entwickelnde Produkt beruumlcksichtigen muss

Idealerweise erfolgt ein Eintrag in Form einer User Story

als Antwort auf die Frage

bdquoWer moumlchte was warumldquo nach folgendem Muster

werden die User Stories aufgehaumlngt fuumlr die sich das

Entwicklungsteam zu diesem Sprint verpflichtet hat

(in der vom Product Owner priorisierten Reihenfolge)

Die drei weiteren Spalten enthalten die Aufgaben oder

Tasks die sich aus den einzelnen User Stories ergeben

(und die im Sprint Planning 2 festgelegt worden sind) Je

nach Bearbeitungsstand sind die Tasks entweder offen

(bdquoTasks to Doldquo) in Bearbeitung (bdquoWork in Progressldquo)

oder erledigt (bdquoDoneldquo) Im Daily Scrum erklaumlrt jedes

Mitglied des Entwicklungsteams anhand des Taskboards

an welcher Aufgabe es am Vortag gearbeitet hat und

ob diese erledigt wurde Tasks die an einem Tag nicht

beendet werden konnten werden mit einem roten Punkt

markiert So koumlnnen Hindernisse schnell identifiziert

werdenldquo

bdquoAls User x moumlchte ich Funktionalitaumlt y damit ich Nutzen

z habeldquo

Quelle httpsborisglogercomscrum

S 22Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

643 IMPEDIMENT BACKLOG

10 TIPPS ZUM RICHTIGEN IMPEDIMENT BACKLOG

Beim Impediment Backlog handelt es sich um eine Liste aller Blockaden die einer effektiven produktiven Arbeit des

Teams im Weg stehen Dieses Backlog wird bei den Scrum- Artefakten meist uumlbersehen Boris Gloger gibt in seinem

Blog bdquo10 Tipps zum richtigen Impediment Backlogldquo die von einem Scrum Master beachtet werden sollten

Quelle httpsborisglogercomscrum

1 Haumlnge es oumlffentlich auf Am besten im

Gang so dass es alle sehen koumlnnen

3 Beim Formulieren der Saumltze nicht

beleidigen aber auch nichts verschweigen

5 Denke daran alle Bereiche der

Verbesserung tatsaumlchlich zu bearbeiten

7 Das Impediment Backlog muss sich

veraumlndern Zeige durch Durchstreichen und

Hinzufuumlgen dass auch DU als Scrum Master

etwas tust

9 Sprich das Backlog einmal in der Woche

mit den anderen Scrum Mastern in deiner

Organisation durch Aktualisiere es mit den

neuen Informationen

2 Schreibe aktive Saumltze z B ldquoWir benoumltigen

eine bessere Kaffeemaschinerdquo

4 Das Impediment Backlog sollte immer

mindestens 10 Eintraumlge vorweisen

6 Mach es ordentlich Es ist ein Ausdruck

Eures Qualitaumltsbewusstseins ob das

Impediment Backlog ordentlich und gepflegt

aussieht oder schlampig ist Wir alle schlieszligen

von der Form auf den Inhalt Unordentliche

Charts = Schlampig programmierte Software

8 Sage nicht Der oder Die muss etwas tun

sondern DU als Scrum Master musst etwas tun

10 Sprich das Backlog einmal in der Woche

mit den anderen Scrum Mastern in deiner

Organisation durch Aktualisiere es mit den

neuen Informationen

S 23Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

644 BURNDOWN-DIAGRAMM

65 WELCHE VORTEILE BIETET SCRUM

Der aktuelle Entwicklungsstand wird idealerweise

in einem sog Burndown-Diagramm dargestellt auf

dem auf der x-Achse der Zeitverlauf und auf der

y-Achse die Tasks oder Storypoints eingetragen

werden Eine Diagonale von links oben nach rechts

unten stellt dabei den optimalen Projektverlauf dar

Je nach Abweichung der aktuellen Burndown-Linie

von der Diagonale kann sehr schnell beurteilt werden

ob das Entwicklungsteam in Time ist oder aktuell

Die Vorteile der agilen Softwareentwicklung mit

Scrum sind vielfaumlltig Zum einen ist es so dass bei

Scrum-Projekten die Flexibilitaumlt deutlich zunimmt da

man ein Groszligprojekt in kleinere Teilprojekte (Sprints)

herunterbricht und diese einzeln und nacheinander

realisiert Nach jedem Teilprojekt erfolgt ein Review Die

Erkenntnisse flieszligen dann wieder in die nachfolgenden

Teilprojekte ein Damit koumlnnen auch Aumlnderungen am

Markt oder neue Erkenntnisse und Ideen zum Produkt

jederzeit aufgegriffen und in einem der kommenden

Sprints beruumlcksichtigt werden

Quelle Exemplarischer Burndown-Chart mit dem Projektmanagement-Tool JIRA TechDivision

Verzoumlgerungen bestehen die bis zum Ende aufgeholt

werden muumlssen Da alle Projektbeteiligten also auch

der Kunde () Zugriff auf dieses Burndown-Diagramm

haben wird houmlchstmoumlgliche Transparenz waumlhrend der

Implementierung gewaumlhrleistet Dadurch laumlsst sich bei

etwaigen bdquoAusreiszligernldquo auch fruumlhzeitig gegensteuern

bzw es werden geeignete Gegenmaszlignahmen ergriffen

um das Projekt wieder auf bdquoSchieneldquo zu bringen

Ein ganz entscheidender Vorteil bei Scrum liegt auch

im ausgepraumlgten Team-Gedanken Anforderungen und

Probleme werden im Team diskutiert und geloumlst Durch

das cross functional Team und den gruppendynamischen

Prozess ergeben sich vielfach bessere Endergebnisse

Daruumlber hinaus arbeiten selbstorganisierte Teams

effektiver

Einer der groumlszligten Vorteile von Scrum liegt in der

houmlchstmoumlglichen Transparenz Alle Projektbeteiligten

haben durch Zugriff auf Backlogs auf Burndown-

Diagramme mit dem Projektfortschritt den angefallenen

Guideline

Remaining Values

Non - working Days

Oct 10 0

10

20

30

STOR

Y PO

INTS

TIME

40

50

60

BURNDOWN CHART

Oct 11 Oct 12 Oct 13 Oct 14 Oct 15 Oct 16 Oct 17 Oct 18 Oct 19 Oct 20 Oct 21 Oct 22

S 24Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

Projektzeiten sowie etwaige Hemmnisse zu jedem

Zeitpunkt vollstaumlndige Transparenz auf den aktuellen

Entwicklungsstand Hier kann jeweils sehr zeitnah

gegengesteuert werden wodurch boumlse Uumlberraschungen

ausbleiben

Durch die permanente Diskussion in der Gruppe sowie

die Reflexion am Ende eines jeden Sprints wird ein

kontinuierlicher Verbesserungsprozess gewaumlhrleistet

der sich sehr positiv auf die fachlichen Ergebnisse und

auch auf die wirtschaftlichen Belange auswirkt Aufgrund

der bdquohaumlppchenweisenldquo Realisierung arbeiten Entwickler

konzentrierter und auch fokussierter Durch das Arbeiten

im Team und den dadurch gegebenen gegenseitigen

Ansporn steigt die Motivation und die Arbeitsergebnisse

werden besser

66 DIE KOSTENKALKULATION IN SCRUM

Haumlufig wird vom Auftraggeber ein Fixpreis-Angebot

gefordert was in der Praxis ganz offensichtliche Maumlngel

und Nachteile mit sich bringt Zum einen lassen sich

bestimmte Anforderungen und Features im Vorfeld haumlufig

kaum vernuumlnftig schaumltzen da hier Erfahrungswerte und

detaillierte Informationen fehlen Zum anderen ist es bei

dem uumlberwiegenden Teil von IT-Projekten so dass sich

waumlhrend der Implementierung mitunter weitreichende

Aumlnderungen ergeben Entweder weil sich Anforderungen

ndash z B aufgrund von geaumlnderten Marktbedingungen ndash

aumlndern oder weil sich herausstellt dass die im Vorfeld

geplanten Loumlsungsansaumltze ndash aus welchem Grund auch

immer ndash sich in der Praxis so nicht umsetzen lassen

Das zieht zwei Probleme nach sich die mitunter recht

schwergewichtig sind und die die scheinbare Sicherheit

eines Fixpreisangebotes fuumlr den Auftraggeber in einem

anderen Licht erscheinen lassen

Ein vernuumlnftig agierender Dienstleister kalkuliert ndash und

dies muss er aus wirtschaftlichen Gesichtspunkten auch

ndash Unsicherheiten bzw Unwaumlgbarkeiten aufgrund von

fehlenden Detailinformationen und Erfahrungswerten in

sein Angebot mit ein was fuumlr den Auftraggeber bedeuten

kann dass er fuumlr die gewuumlnschte Leistung deutlich zu

viel bezahlt

Gerade Agenturleistungen sind dabei sehr preisgetrieben

Der Auftraggeber entscheidet sich daher moumlglicherweise

fuumlr den vermeintlich guumlnstigsten Anbieter Machen wir

uns hier aber nichts vor Heutzutage hat niemand etwas

zu verschenken Genauso wenig wie Sie Ihre Produkte

oder Dienstleistungen fuumlr wenig Geld abgeben wird

dies eine Agentur tun Insofern erlebt man es auch recht

haumlufig dass der vermeintlich guumlnstigste Anbieter den

Zuschlag bekommt dieser in der Umsetzung dann aber

eben aus Budgetgruumlnden entweder nicht sauber arbeitet

ein halbfertiges Produkt abliefert undoder am Ende eine

Nachkalkulation fordert um seine Kalkulation bdquosauberldquo

halten zu koumlnnen Dadurch kann das vermeintliche

Schnaumlppchen schnell in einem Desaster enden Im

schlimmsten Fall geht es dann jedoch nicht mehr bdquonurldquo

ums Geld sondern moumlglicherweise auch ums Image und

etwaige Schaumlden

Aus unserer Sicht und aufgrund unserer 15-jaumlhrigen

Erfahrung im Bereich Webentwicklung koumlnnen wir mit

nahezu 100-iger Sicherheit feststellen dass man

bei Softwareprojekten serioumlser- und richtigerweise im

Vorfeld eigentlich nur Schaumltzungen abgeben kann da

hier einfach zu viele Unwaumlgbarkeiten mitspielen die

nicht kalkulierbar sind Insofern bietet ein Fixpreis-

Angebot nur auf den allerersten Blick die vermeintliche

Sicherheit fuumlr den Auftraggeber Wie bereits ausgefuumlhrt

wird er die tatsaumlchlichen Kosten ndash und diese werden

sehr haumlufig houmlher ausfallen als das erste Angebot ndash

anderweitig bezahlen entweder unmittelbar in Form

von Change Requests oder uumlber Umwege also etwa

uumlber Nachbesserungsmaszlignahmen durch einen anderen

Dienstleister aufgrund mangelnder Qualitaumlt bzw nicht

fertiggestellter Software Daruumlber sollte man sich

S 25Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

als Auftraggeber im Klaren sein Die Rechnung wird

kommen ndash so oder so

Fairerweise muss man hier auch ganz klar erwaumlhnen

dass es unter wirtschaftlichen Gesichtspunkten kaum

moumlglich sein wird bei einem komplexeren IT-Projekt ein

Lasten- und Pflichtenheft in der Qualitaumlt zu erstellen

sodass es als richtige Basis fuumlr ein Fixpreisangebot

verwendet werden kann Der Aufwand hierfuumlr wird am

Markt kaum bezahlt werden wodurch sich dann einmal

mehr die Frage stellt ob ein guumlnstigeres bdquoAlibi-Lasten-

und Pflichtenheftldquo dann uumlberhaupt Sinn macht

Scrum ist insofern der fuumlr alle Beteiligten ehrlichste

Ansatz Ein Groszligprojekt wird in kleinere Teilprojekte

zerlegt und dann einzeln geschaumltzt Es wird auch

nur das abgerechnet was tatsaumlchlich an Aufwand

entstanden ist Durch die vollstaumlndige Transparenz und

Involvierung des Kunden in den Enwicklungsprozess

hat dieser houmlchstmoumlgliche Sicherheit und kann auch

jederzeit reagieren d h er kann bei sich abzeichnenden

Budgetuumlberschreitungen jederzeit ndash auch in Abstimmung

mit dem Scrum-Team ndash gegensteuern und im Notfall

natuumlrlich auch abbrechen Hier hat er auch immer den

Vorteil dass bis dahin entwickelte Software oder Teile

davon weiterverwendet werden koumlnnen da das Ziel

von Scrum in der Bereitstellung von funktionsfaumlhiger

Software bzw Softwareteilen besteht Das bedeutet

Transparenz und Bezahlung nur fuumlr die tatsaumlchlich

erbrachte Leistung Aus unserer Sicht ist dies der

deutlich bessere und auf lange Sicht gesehen auch fuumlr

alle Beteiligten der wirtschaftlichste Ansatz

In der Praxis hat sich bewaumlhrt dass das initiale

Backlog mit auf hohem Abstraktionsniveau formulierten

Anforderungen zusammen mit dem Kunden erstellt wird

Auf Basis der so erfassten Anforderungen kann eine

erste Abschaumltzung der Aufwaumlnde erfolgen Wir gehen

dabei aufgrund der im Backlog erfassten Anforderungen

von x Sprints aacute 2-4 Wochen mit x Personen aus Durch

diese Kalkulation kann der Projektumfang in einem sehr

fruumlhen Stadium bereits umrissen werden Hier besteht

fuumlr den Auftraggeber dann auch die Moumlglichkeit die

so ermittelten Werte zu deckeln oder einen niedrigeren

Wert als Houmlchstgrenze fuumlr die Implementierung

anzusetzen Bei der Umsetzung wird dies dann

entsprechend beruumlcksichtigt Grundsaumltzlich werden in

der Folge nur die tatsaumlchlich angefallenen Aufwaumlnde

abgerechnet wobei durch den jederzeitigen Zugriff auf

die Projektmanagementtools diese Aufwaumlnde taumlglich

eingesehen und uumlberwacht werden koumlnnen Dadurch

werden boumlse Uumlberraschungen vermieden

Insofern laumlsst sich mit Scrum ndash auch wenn dies nicht der

eigentlichen Idee von Scrum entspricht ndash ein IT-Projekt

auch mit einem vorab fixierten Budget realisieren In

diesem Fall wird sofern das Budget fuumlr die gewuumlnschten

Features nicht ausreichen sollte in Abstimmung mit dem

Kunden die eine oder andere Funktionalitaumlt gestrichen

oder angepasst wodurch das definierte Projektbudget

wieder gehalten werden kann und das ohne ndash und dies

ist sicherlich ganz entscheidend ndash Kompromisse bei der

Qualitaumlt eingehen zu muumlssen

S 26

Innerhalb eines Scrum-Projekts zeigen Retrospektiven

schnell auf wie die Effizienz und damit Performance des

Teams weiter gesteigert werden kann Dabei besteht

allerdings auch die Gefahr dass eigene Modifikationen ndash

sogenannte ScrumButs ndash an Scrum vorgenommen und

wichtige Elemente ausgeblendet werden Meist wurde

dann die Quintessenz von Scrum nur bedingt verstanden

67 DIE GROumlSSTEN FEHLER IM SCRUM-PROZESS

BEISPIELE FUumlR SCRUMBUTS SIND

Wir nutzen Scrum aber wir hellip

Quelle httpt3ndemagazinpraxisbericht-scrum-

kanban-scrumbuts-agiles-232822

hellip benoumltigen aufgrund unseres kleinen

Teams keinen Scrum Master

hellip brauchen die Aufwandschaumltzung einzelner

Aufgaben nicht

hellip verlaumlngern einen Sprint bis wir unser Ziel

erreicht haben

hellip verzichten auf Retrospektiven

SCUMBUTS = an Scrum vor- genommene eigene Modifikationen

S 27Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

KEINE UMFASSENDE PLANUNG VORBEREITUNGBei Scrum sind exzessive Vorbereitungsphasen nicht

notwendig Stattdessen sollte versucht werden

moumlglichst schnell mit der Implementierung zu starten

und ein permanentes Feedback in den Sprint Reviews

zur Weiterentwicklung und Verbesserung zu nutzen

Sogar das Product Backlog kann bei Bedarf nach Beginn

des ersten Sprints erst noch erstellt werden

KEINE VERSTEIFUNG AUF TOOLS DIE DEN SCRUM PROZESS VEREINFACHEN Haumlufig wird versucht im Vorfeld (bevor man Scrum

wirklich verinnerlicht hat) entsprechende Softwaretools

zu finden die den Scrum-Prozess abbilden und

vereinfachen Zu Beginn reichen hier jedoch Stifte und

Papier da der Start damit genauso moumlglich und haumlufig

gerade zu Beginn einfacher und schneller abbildbar ist

DAILY SCRUM ndash KURZ UND KNACKIGDas taumlgliche Scrum Meeting darf nicht dazu dienen

groumlszligere Probleme oder Schwierigkeiten zu diskutieren

und hier Loumlsungsansaumltze zu erarbeiten Stattdessen

sollte das Meeting moumlglichst kurz und bdquoknackigldquo

gehalten werden

Problemdiskussionen sollten dann im Anschluss mit den

relevanten Personen separat gefuumlhrt werden Der Scrum

Master uumlberwacht dabei die Diskussion und sorgt dafuumlr

dass das Ganze moumlglichst zielgerichtet ablaumluft

SELBSTSTAumlNDIGES ARBEITENScrum Teams arbeiten selbst organisierend und

bdquobesorgenldquo sich die Aufgaben eigenstaumlndig Eine

Zuweisung von Tasks ist nicht erforderlich und meist

auch kontraproduktiv

TIPPS amp TRICKS ndash SO VERMEIDEN SIE SCRUM-FEHLER

SCRUM MASTER ALS MITWIRKENDERDer Scrum Master kann als Coach im Scrum Team

bezeichnet werden der dafuumlr sorgt dass der Scrum-

Prozess moumlglichst reibungslos funktioniert und das Team

sich vollstaumlndig auf die Implementierung konzentrieren

kann Eine aktive Mitarbeit im Projekt ist hier nicht

foumlrderlich und sollte in jedem Fall vermieden werden

Gleiches gilt fuumlr technische Vorgaben die der Scrum

Master unbedingt unterlassen sollte

PRODUCT OWNER ALS KOMPETENTER ANSPRECHPARTNERAls verlaumlngerter Arm des Kunden muss der Product

Owner in den Entwicklungsprozess und den aktuellen

Stand der Entwicklung immer eingebunden und fuumlr

das Team bei Fragen oder Unklarheiten auch jederzeit

greifbar sein Zudem sorgt er fuumlr die permanente

Kommunikation mit dem Kunden

KEINE VORGABEN bdquoVON AUSSENldquoAusschlieszliglich das Team entscheidet wie viele Tasks

in einem Sprint abgearbeitet werden Vorgaben bdquovon

auszligenldquo sollten hier unbedingt vermieden werden um

bestmoumlgliche Qualitaumlt gewaumlhrleisten zu koumlnnen

KEINE ALLEINGAumlNGE INNERHALB DES TEAMSScrum lebt vom Teamgedanken und der gemeinsamen

Arbeit an einem Projekt Die Teammitglieder sollten

daher auf Alleingaumlnge jeglicher Art verzichten und

stattdessen ein moumlglichst umfassendes Wir-Gefuumlhl

entwickeln Das Team gewinnt und verliert gemeinsam

KLARE VERANTWORTLICHKEITENDer Product Owner ist fuumlr die Spezifikation der

Anforderungen zustaumlndig Er beschreibt und bdquouumlbersetztldquo

was am Ende erstellt werden muss Die technische

Umsetzung und die technologischen Ansaumltze obliegen

jedoch einzig und allein dem Team

S 28Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

KEINE UNTERBRECHUNGEN INNERHALB EINES SPRINTSSofern waumlhrend des Sprints besonders dringende

Themen auftauchen sollte nach Moumlglichkeit versucht

werden diese nach dem Sprint anzugehen und den

Sprint moumlglichst unveraumlndert zu Ende zu fuumlhren In

besonders dringenden Faumlllen sollte statt einer Aumlnderung

innerhalb des Sprints der komplette Sprint abgebrochen

werden

TEAMMITGLIEDER ENTSCHEIDEN NICHT SELBST UumlBER ANFORDERUNGENDer Product Owner ist als Produktverantwortlicher

fuumlr die Ausgestaltung des Produktes und das

Endergebnis verantwortlich Er entscheidet auch

alleine uumlber Anforderungen und Besonderheiten

Teammitglieder muumlssen sich bei Fragen im Vorfeld mit

dem PO abstimmen und duumlrfen hier nicht eigenstaumlndig

Entscheidungen treffen die uumlber technische Ansaumltze

hinausgehen

ZIELORIENTIERTES VORGEHENZu Beginn eines Sprints werden entsprechende

Sprintziele definiert die zwingend eingehalten und

waumlhrend des gesamten Sprints uumlberwacht werden

muumlssen Anhand von sog Burndown-Charts kann der

Projektverlauf taumlglich mitverfolgt werden Am Ende

eines Sprints muss eine funktionsfaumlhige und getestete

Software ausgeliefert werden bei der im Zweifelsfall

lieber ein Feature weggelassen wird Die fertig gestellten

Funktionen muumlssen jedoch moumlglichst fehlerfrei

funktionieren so dass damit ein bdquoGo Liveldquo jederzeit

moumlglich waumlre

KOMPRIMIERTE TEAMSDa bei Scrum das Team im Vordergrund steht und

hier der Teamgedanke uumlber allem schwebt sollte

das Team auch moumlglichst in einem Raum sitzen um

die Kommunikation und das Wir-Gefuumlhl optimal zu

unterstuumltzen Verteilte Scrum-Teams funktionieren

zwar grundsaumltzlich auch am meisten kann jedoch von

komprimierten Teams profitiert werden

AumlNDERUNGEN DES SCRUM TEAMS VERMEIDENWie bereits mehrfach erwaumlhnt entfaltet Scrum seine

Staumlrken im Team und mit laufender Zusammenarbeit der

Team-Mitglieder Insofern sollte waumlhrend eines Scrum-

Projektes eine Aumlnderung am Scrum Team unbedingt

vermieden werden Insbesondere durch Kontinuitaumlt kann

sich ein Scrum Team laufend verbessern und die Arbeit

im Team permanent optimieren

AUGENMERK AUF QUALITAumlTEigenverantwortlichkeit sowie das Thema bdquoAuslieferbare

Softwareldquo steht bei Scrum im Vordergrund Dies

bedeutet nichts anderes als dass die gelieferten

Ergebnisse waumlhrend des Sprints entsprechend getestet

und optimiert werden um ein bestmoumlgliches und finales

Ergebnis abzuliefern Dies muss vom Team im Rahmen

des Sprint-Plannings beruumlcksichtigt werden damit

die implementierten Features auch noch ausreichend

getestet werden koumlnnen Separate Test-Teams sind bei

Scrum nicht vorgesehen da die Ergebnisse dies nicht

erforderlich machen

S 29Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

Was aus unserer Sicht noch besonders herauszustellen

ist Auch mit Scrum ist man vor Sackgassen in einem IT-

Projekt nicht geschuumltzt man erkennt diese in der Regel

jedoch deutlich schneller und kann dementsprechend

fruumlhzeitig reagieren Insofern eignet sich Scrum

immer dann ganz besonders gut wenn bereits zu

Beginn des Projektes bei einer Vielzahl von Punkten

noch Klaumlrungsbedarf besteht gewisse Unsicherheiten

vorhanden sind bzw bereits im Vorfeld zu erkennen

ist dass es hier noch zu diversen Aumlnderungen und

Anpassungen im Projektverlauf kommen kann bzw wird

Die Grundlagen von Scrum und Kanban sind zwar

einfach zu verstehen eine disziplinierte Umsetzung ist

jedoch meist nicht so einfach zu erzielen In diesem

Zusammenhang lohnt es sich meist auf Scrum-Experten

ndash bei TechDivision arbeiten u a vier Certified Scrum

Professionals ndash zuruumlckzugreifen die Team und Kunden

schulen und so eine reibungslose Projektabwicklung

garantieren Scrum ist dabei weitaus mehr als bdquonurldquo

ein Framework fuumlr Software- bzw Produktentwicklung

Scrum ist vielmehr ein Paradigmenwechsel der

sowohl vom Kunden als auch vom Team ein Umdenken

voraussetzt

68 UumlBERSICHT DER VOR- UND NACHTEILE VON SCRUM +

-VORTEILE rsaquo Houmlchstmoumlgliche Flexibilitaumlt durch

jederzeitige Aumlnderung und Priorisierung

von Anforderungen

rsaquo Fruumlhzeitige Ergebnisse amp funktionsfaumlhige

Teilprojekte

rsaquo Verbesserung in der Time to Market

rsaquo Erhoumlhung der Kommunikation im Team

und dadurch Verbesserungspotentiale

rsaquo Groumlszligtmoumlgliche Transparenz fuumlr alle

Projektbeteiligten

rsaquo Realistische und genaue

Aufwandsschaumltzungen im Team

rsaquo Fruumlhzeitiges Erkennen von Problemen mit

entsprechenden Handlungsmoumlglichkeiten

rsaquo Verbesserung der Qualitaumlt durch

konseqentes Teamwork

rsaquo Fixe Termine

NACHTEILE rsaquo Erhoumlhter Kommunikations- und

Abstimmungsaufwand

rsaquo Ggf Unklarheiten bei Zustaumlndigkeiten

von interdisziplinaumlren Themen

rsaquo Moumlglichkeiten zur Verzettelung im

Detail bei unerfahrenen Teams

rsaquo Verschlechterung der Effizienz durch

fehlende Beseitigung bekannter

Probleme aus den Reviews

rsaquo Ggf muumlssen Unternehmensstrukturen

geaumlndert werden damit das Team

sebstorganisiert arbeiten kann und die

notwendige Unterstuumltzung erhaumllt

S 30Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

bdquoWAS IST SCRUMldquo VON BORIS GLOGER536

gt borisgloger consulting GmbH

bdquoTo say how much something will cost you need to

know in great detail exactly what needs to be built so

that your estimates for the work can be accurate But

you canacutet define everything you want in detail and up

front and get it exactly right so there will be no changes

in the future And no estimate is ever accurate (it

wouldnacutet be an estimate if it was) [hellip] Donacutet base the

contract with your vendor on conformance to a detailed

requirements specification

If you do youacutere saying all your good ideas happen at the

start of a project and youacutere effectively betting all your

money on a hole-in-oneldquo

Quelle httpswwwenergizedworkcom

weblog200705fixed-price-contracts-dont-work

Das nachfolgende Video zeigt in knapp 5 Minuten

nochmals die wesentlichen Elemente sowie die

Vorgehensweise bei Scrum

Aus unserer Sicht bleibt fuumlr Auftraggeber nur die

Empfehlung sich beim naumlchsten Projekt einmal auf das

Thema Scrum einzulassen Auch ein Festpreisangebot

schuumltzt den Auftraggeber nicht vor etwaigen Risiken

und damit verbundenen Mehraufwaumlnden die dann

vielleicht zwar nicht sofort zu Buche schlagen zu einem

spaumlteren Zeitpunkt aber in nahezu allen Faumlllen zum

Tragen kommen Bei Scrum steht nicht ein fixer Preis fuumlr

vorab genauestens definierte Features im Vordergrund

sondern die termingerechte Auslieferung bestmoumlglicher

und funktionierender Software die die definierten

Anforderungen erfuumlllen muss Bei der Umsetzung

bestehen hier mehr Freiheiten ndash was jedoch keinesfalls

mit mangelnder Qualitaumlt gleichzusetzen ist

Simon Baker hat vor laumlngerer Zeit zum Thema

Festpreisprojekte folgendes geschrieben

69 ZUSAMMENFASSUNG SCRUM

Watch the Video

S 31Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

AGILES PROJEKTMANAGEMENT MIT KANBANbdquoKanban ist eine Methode der Produktionsprozesssteuerung

Das Vorgehen orientiert sich ausschlieszliglich am tatsaumlchlichen Verbrauch von

Materialien am Bereitstellungs- und Verbrauchsort Kanban ermoumlglicht ein

Reduzieren der lokalen Bestaumlnde von Vorprodukten in und nahe der Produktion die

dort in Produkten der naumlchsten Integrationsstufe verbaut werdenldquo

Quelle httpdewikipediaorgwikiKanban

Das Wort Kanban stammt aus dem Japanischen und

bedeutet so viel wie bdquoKarteldquo bdquoTafelldquo oder bdquoBelegldquo Das

Prinzip ist auch unter Hol- Zurufprinzip oder Pull-Prinzip

bekannt Das urspruumlngliche Kanban wurde bereits 1947

von Taichi Ohno entwickelt der mit dem System auf die

mangelnde Produktivitaumlt bei Toyota Motor Corporation

im Vergleich zur amerikanischen Konkurrenz reagierte

Seine Idee war es dabei die Produktion nach dem

Supermarkt-Prinzip zu gestalten und zu organisieren

Sobald ein Verbraucher etwas aus dem Regal nimmt

wird dieses sofort wieder aufgefuumlllt

David J Andersson uumlberarbeitete die Grundidee von

Kanban und passte diese vor allem hinsichtlich der

Beduumlrfnisse in der Softwareentwicklung an Ergebnis

ist ein evolutionaumlres Vorgehen bei dem kontinuierlich

Arbeitsweisen verbessert und optimiert werden In

diesem Zusammenhang wird dabei immer von der

gegenwaumlrtigen Situation ausgegangen Einen Kanban-

Sollzustand gibt es dabei nicht Kanban-Teams halten

sich vielmehr an folgende grundlegende Prinzipien

Das Kanban-Prinzip ist auch als eine Reaktion auf

die Beduumlrfnisse der Kunden zu sehen die neue

Anforderungen an die Produktionsgeschwindigkeit

Lieferbereitschaft und Zuliefererbeziehungen haben

Das Kanban-Verfahren ersetzte dabei bisherige

Produktionsverfahren und wurde von zahlreichen

japanischen Unternehmen darunter auch Toyota

eingefuumlhrt In den 70er Jahren wurde das System auch

in Deutschland und in den USA adaptiert

vgl httpdewikipediaorgwikiKanbanHistorische_

Entwicklung

Quelle wwwheisededeveloperartikelSoftware-

Kanban-im-Einsatz-1235465html

rsaquo Visualisierung des Arbeitsflusses und der Arbeit

rsaquo Limitierung des WIP (WIP = Work In Progress in

Ausfuumlhrung befindliche Arbeit)

rsaquo Steuerung und Messung des Arbeitsflusses

rsaquo Prozessregeln explizit machen

rsaquo Verbesserung durch bewaumlhrte Modelle und

wissenschaftliche Methoden

71 ZUR GESCHICHTE VON KANBAN

72 KANBAN IN DER SOFTWAREENTWICKLUNG

S 32Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

Quelle httpsmanagement30comabout

ZIEL IST ES DURCH KANBAN MECHANISMEN IM SYSTEM ZU IMPLEMENTIEREN

DIE LAUFENDE VERBESSERUNGEN UND VERAumlNDERUNGEN ERLAUBEN IM LAUFE

DES PROZESSES KOumlNNEN SICH SO DIE TEAMMITGLIEDER EINBRINGEN UND

OPTIMIERUNGEN DES WORKFLOWS VORNEHMEN DIESBEZUumlGLICH MUSS ERST

EINMAL DER KAIZEN-GEDANKE IN DIE KOumlPFE DER MENSCHEN GEBRACHT WERDEN

DABEI MUumlSSEN VERAumlNDERUNGEN NICHT AM MENSCHEN SONDERN DURCH DEN

MENSCHEN PASSIEREN

Kanban und Scrum finden ihren Einsatz in

unterschiedlichen Projekten Bei Kanban handelt es

sich im Gegensatz zu Scrum um eine Vorgehensweise

die einen kontinuierlichen Arbeitsfluss garantieren soll

In diesem Zusammenhang werden alle anstehenden

Aufgaben und Ablaumlufe mit Hilfe eines Boards das

in Zeilen und Spalten aufgeteilt ist visualisiert Auf

dem Board finden sich die Aufgaben in Form von

Tickets wider Jede Spalte repraumlsentiert dabei einen

Arbeitsschritt und das Projektteam kann jederzeit

den Status einer Aufgabe einsehen In diesem

Zusammenhang gibt es ein Limit an parallel laufenden

Aufgaben Ziel dabei ist es das Team nicht mit

unterschiedlichen Aufgaben zu uumlberhaumlufen sondern ein

konzentriertes Arbeiten an einem Task zu ermoumlglichen

Eine wichtige Aufgabe von Kanban ist es vorhandene

Probleme und Arbeiten darzustellen und zu

visualisieren In diesem Zusammenhang spielt das

sogenannte Kanban-Board eine wichtige Rolle welches

beispielsweise aus einem Whiteboard Karteikarten oder

Haftnotizen bestehen kann Jede Aufgabe wird dabei

durch eine Karte etc praumlsentiert Der Vorteil dieser

Vorgehensweise ist eine erhoumlhte Transparenz bei der

Bearbeitung von Projekten

(bdquoLimit work in progressldquo) So ist ein gleichmaumlszligiges

Bearbeiten von Tickets ohne lange Wartezeiten oder

Blockaden gewaumlhrleistet Ein zentraler Aspekt ist dabei

der Flow-Gedanke Kanban visualisiert somit den

aktuellen Prozess aumlndert diesen aber zunaumlchst nicht

Kanban gilt als eine agile Methode um Change

Management evolutionaumlr durchfuumlhren zu koumlnnen Dabei

werden bestehende Prozesse schrittweise optimiert und

verbessert Durch die Aumlnderung kleinerer Aspekte wird

das Risiko fuumlr jede einzelne Maszlignahme verringert Ein

Vorteil von Kanban ist auch der geringere Widerstand

bei den Beteiligten (vgl httpwwwit- agiledewissen

methodenkanban)

Quelle httpswwwit-agiledewisseneinstieg-und-

ueberblickkanban

Kanban orientiert sich dabei an Lean- Prinzipien und

basiert auf dem Pull-Prinzip (Hol-Prinzip) bei dem die

anfallende Arbeit nicht von einem Vorgesetzten verteilt

wird sondern die Arbeiter bzw Teammitglieder sich

selbststaumlndig ihre Arbeit holen Diese wird auf sog

Kanban-Karten am Kanban-Board hinterlegt

73 KANBAN IN PROJEKTEN

74 SO FUNKTIONIERT KANBAN

S 33

Die Praxis hat gezeigt dass eine komplexe Welt in der

wir uns heute bewegen nur noch uumlber agile Methoden

erfolgreich gemanaged werden kann Diverse Studien

belegen diese These auch recht eindrucksvoll

Ob dies nun uumlber Scrum Kanban oder bdquoexotischereldquo

bzw eigens adaptierte Modelle erfolgt haumlngt von

unterschiedlichsten Faktoren ab und muss jedes

Unternehmen anhand der jeweiligen Gegebenheiten fuumlr

sich selbst herausfinden

Was beim Thema Agilisierung jedoch niemals vergessen

werden darf sind die Mitarbeiter die moumlglichst

fruumlhzeitig in den Prozess involviert und an die Hand

genommen werden muumlssen Eine Agilisierung und die

damit verbundenen Vorteile im Bezug auf Flexibilitaumlt

und Zeit funktionieren nur wenn Entscheidungen auch

dort kurzfristig getroffen werden koumlnnen wo sie gerade

anstehen Fuumlhrungskraumlfte muumlssen daher lernen los

zu lassen Verantwortung zu uumlbertragen und etwaige

Konsequenzen auch mitzugehen Kaum ein Mitarbeiter

wird bewusst falsche Entscheidungen treffen und die

Praxis hat ja auch mehr als haumlufig gezeigt dass selbst

die erfahrensten und bdquobestenldquo Manager nicht vor

Fehlentscheidungen gefeit sindhellip

Die Ideen hinter Management 30 dienen dazu ein fuumlr

agile Arbeits- und Managementmethoden passenderes

Umfeld sowie eine zeitgemaumlszligere Unternehmenskultur zu

etablieren uumlber die Unternehmen auch ihre Attraktivitaumlt

als Arbeitgeber (wieder) steigern koumlnnen

Wir freuen uns in jedem Fall jederzeit uumlber Feedback

Fragen und Anregungen aber auch uumlber Erfahrungen

und Learnings anderer Unternehmen

FAZIT

S 33

S 34Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

AUTORENJOSEF WILLKOMMER GESCHAumlFTSFUumlHRER TECHDIVISIONAls Geschaumlftsfuumlhrer von TechDivision beschaumlftigt sich

Josef Willkommer seit vielen Jahren sehr intensiv

mit Themen aus den Bereichen E-Commerce Online

Marketing und den dazu notwendigen modernen

Projektmanagement-Ansaumltzen Daruumlber ist er als

Chef-Redakteur des eStrategy-Magazins ndash einem

quartalsweise erscheinenden kostenlosen Online-

Magazin mit Fokus auf E-Commerce und Online

Marketing ndash auch journalistisch taumltig und versucht sein

Wissen in Form von Fachbeitraumlgen weiterzugeben Auch

auf diversen Fachkonferenzen trifft man ihn als Referent

zu Themen rund um den elektronischen Handel

SACHA STORZ STANDORTLEITUNG MUumlNCHEN BUSINESS DEVELOPMENTSacha Storz ist ausgebildeter Psychologe und als Agile

Evangelist bei TechDivision fuumlr die Einfuumlhrung und

Optimierung moderne Managementmethoden in der

taumlglichen Praxis verantwortlich Er verfuumlgt hierzu uumlber

folgende Ausbildungen und Zertifizierungen

- Certified Scrum Product Owner (CSPO)

- Certified Scrum Professional (CSP)

- Professional Scrum Master Level I

- Kanban Management Professional

- Certified Agile Requirements Specialist (cars)

- Licensed Management 30 Facilitator

Sacha Storz ist als Speaker auf unterschiedlichsten

auch internationalen Veranstaltungen rund um

Projektmanagement und New Work anzutreffen

Daruumlberhinaus gibt es Schulungen und Trainings zu

diesen Themen

DOMINIK HALLER ONLINE MARKETING MANAGER PROJEKTMANAGERDer studierte Kommunikationswissenschaftler arbeitet

als Online Marketing Manager bei der TechDivision

GmbH und ist fuumlr das Content Management

Partnermanagement fuumlr die Eventorganisation sowie

saumlmtliche Marketingaktivitaumlten online offline zustaumlndig

Daruumlber hinaus ist er als leitender Redakteur und Autor

des eStrategy Magazins fuumlr Hintergrundrecherchen rund

um das Thema E-Commerce Online Marketing E-Recht

etc zustaumlndig Neben seiner beruflichen Taumltigkeit bei

der TechDivision GmbH engagiert er sich auch als

Lehrbeauftragter an der Universitaumlt Salzburg

EXTERNE AUTORENDR MATTHIAS ORTHWEIN LLM (BOSTON) SKW SCHWARZ RECHTSANWAumlLTEDr Matthias Orthwein LLM beraumlt nationale

und internationale Mandanten im IT-Recht

vor allem im Softwarerecht bspw bei

Lizenzrechtsauseinandersetzungen beim Entwurf

und der Verhandlung von Softwareerstellungs- und

-kaufvertraumlgen

Als erfahrener Experte im IT Outsourcingrecht und im IT

Projektrecht verhilft er Providern und Kunden zu einem

erfolgreichen Projektabschluss und ist sowohl bei der

Ausschreibung und Verhandlung von Vertraumlgen als

auch bei der Vertragsdurchfuumlhrung und bei der Loumlsung

eventueller Konflikte zwischen den Parteien taumltig

Der Schwerpunkt seiner Taumltigkeit wird zudem durch

die Beratung im nationalen und internationalen

Datenschutzrecht sowie im e-Commerce abgerundet

Dr Orthwein ist Lehrbeauftragter fuumlr IT und Daten-

schutzrecht an der Hochschule Rosenheim

Der Branchendienst bdquoLegal 500 Germanyldquo zeichnet ihn

auch 2017 wieder als bdquoHaumlufig empfohlenen Anwalt fuumlr IT

und Outsourcingldquo aus

S 34Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

AUTORENJOSEF WILLKOMMER GESCHAumlFTSFUumlHRER TECHDIVISIONAls Geschaumlftsfuumlhrer von TechDivision beschaumlftigt sich

Josef Willkommer seit vielen Jahren sehr intensiv

mit Themen aus den Bereichen E-Commerce Online

Marketing und den dazu notwendigen modernen

Projektmanagement-Ansaumltzen Daruumlber ist er als

Chef-Redakteur des eStrategy-Magazins ndash einem

quartalsweise erscheinenden kostenlosen Online-

Magazin mit Fokus auf E-Commerce und Online

Marketing ndash auch journalistisch taumltig und versucht sein

Wissen in Form von Fachbeitraumlgen weiterzugeben Auch

auf diversen Fachkonferenzen trifft man ihn als Referent

zu Themen rund um den elektronischen Handel

SACHA STORZ STANDORTLEITUNG MUumlNCHEN BUSINESS DEVELOPMENTSacha Storz ist ausgebildeter Psychologe und als Agile

Evangelist bei TechDivision fuumlr die Einfuumlhrung und

Optimierung moderne Managementmethoden in der

taumlglichen Praxis verantwortlich Er verfuumlgt hierzu uumlber

folgende Ausbildungen und Zertifizierungen

- Certified Scrum Product Owner (CSPO)

- Certified Scrum Professional (CSP)

- Professional Scrum Master Level I

- Kanban Management Professional

- Certified Agile Requirements Specialist (cars)

- Licensed Management 30 Facilitator

Sacha Storz ist als Speaker auf unterschiedlichsten

auch internationalen Veranstaltungen rund um

Projektmanagement und New Work anzutreffen

Daruumlberhinaus gibt es Schulungen und Trainings zu

diesen Themen

DOMINIK HALLER ONLINE MARKETING MANAGER PROJEKTMANAGERDer studierte Kommunikationswissenschaftler arbeitet

als Online Marketing Manager bei der TechDivision

GmbH und ist fuumlr das Content Management

Partnermanagement fuumlr die Eventorganisation sowie

saumlmtliche Marketingaktivitaumlten online offline zustaumlndig

Daruumlber hinaus ist er als leitender Redakteur und Autor

des eStrategy Magazins fuumlr Hintergrundrecherchen rund

um das Thema E-Commerce Online Marketing E-Recht

etc zustaumlndig Neben seiner beruflichen Taumltigkeit bei

der TechDivision GmbH engagiert er sich auch als

Lehrbeauftragter an der Universitaumlt Salzburg

EXTERNE AUTORENDR MATTHIAS ORTHWEIN LLM (BOSTON) SKW SCHWARZ RECHTSANWAumlLTEDr Matthias Orthwein LLM beraumlt nationale

und internationale Mandanten im IT-Recht

vor allem im Softwarerecht bspw bei

Lizenzrechtsauseinandersetzungen beim Entwurf

und der Verhandlung von Softwareerstellungs- und

-kaufvertraumlgen

Als erfahrener Experte im IT Outsourcingrecht und im IT

Projektrecht verhilft er Providern und Kunden zu einem

erfolgreichen Projektabschluss und ist sowohl bei der

Ausschreibung und Verhandlung von Vertraumlgen als

auch bei der Vertragsdurchfuumlhrung und bei der Loumlsung

eventueller Konflikte zwischen den Parteien taumltig

Der Schwerpunkt seiner Taumltigkeit wird zudem durch

die Beratung im nationalen und internationalen

Datenschutzrecht sowie im e-Commerce abgerundet

Dr Orthwein ist Lehrbeauftragter fuumlr IT und Daten-

schutzrecht an der Hochschule Rosenheim

Der Branchendienst bdquoLegal 500 Germanyldquo zeichnet ihn

auch 2017 wieder als bdquoHaumlufig empfohlenen Anwalt fuumlr IT

und Outsourcingldquo aus

S 35Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

Der Webtechnologiedienstleister TechDivision gehoumlrt im deutschsprachigen Raum zu den fuumlhrenden Adressen

fuumlr anspruchsvolle eCommerce-Loumlsungen und Digitalisierung von Geschaumlftsprozessen auf Basis von Open

Source Technologien Das Leistungsspektrum von TechDivision reicht von Consultingleistungen uumlber Konzept-

und Designentwicklung sowie Implementierung und Betreuung bis hin zu Online-Marketing Neben diversen

mittelstaumlndischen Kunden vertrauen auch international agierende Unternehmen wie Allianz Ritter-Sport ZORO Tools

Salewa FERRERO oder Cherry auf das Know-how und die Erfahrung von TechDivision Aktuell verfuumlgt TechDivision

uumlber zwei Standorte in RosenheimKolbermoor und Muumlnchen und beschaumlftigt insgesamt mehr als 75 Mitarbeiter

Mit dem eStrategy-Magazin veroumlffentlich TechDivision zudem einmal im Quartal das fuumlhrende Online-Magazin

zum Thema eCommerce und Online-Marketing in der DACH-Region Das Magazin kann kostenlos unter

wwwestrategy-magazinde herunter geladen werden

Mehr Informationen uumlber TechDivision lesen Sie unter wwwtechdivisioncom

TECHDIVISION GMBHTURNING ONLINE PROJECTS INTO SUCCESS

EIN BLICK HINTER DIE KULISSEN0216

gt TechDivision

Watch the Video

S 36Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

WAS WIR FUumlR SIE TUN KOumlNNENhellipSie brauchen Unterstuumltzung bei Ihrer Digitalen Transformation

TechDivision verfuumlgt sowohl im Bereich Technologie als auch

PersonalHR uumlber fundierte und langjaumlhrige Expertise

LEISTUNGSSPEKTRUM

TECHNOLOGIE

Entwicklung von individuellen Webapplikationen auf

Basis modernster Open Source Technologie Dadurch

koumlnnen wir groumlszligtmoumlgliche Flexibilitaumlt Wirtschaftlichkeit

und Zukunftsfaumlhigkeit gewaumlhrleisten

bull eCommerce Plattformen (b2c amp b2b) einschlieszliglich

Omnichannel-Loumlsungen

bull Individuelle Webapplikationen inkl Single Page Apps

bull Corporate Web Intranet Extranet

bull Technologie-Audits und Evaluierungen

PERSONAL UND PROZESSE

bull Workshops und Trainings zu agilen

Managementmethoden (Scrum Kanban

Management 30)

bull Vortraumlge zum Thema Digitale- amp Agile

Transformation

bull Consulting und Begleitung bei entsprechenden

Change-Prozessen

S 37Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

bdquoDer Workshop mit Stefan Willkommer (Geschaumlftsfuumlhrer) und Sacha Storz (Management 30 Trainer Agile

Evangelist) der TechDivision war interessant und inspirierend Unser Austausch uumlber agiles Management und

agile Transformation hat uns zum einen einen spannenden Einblick in die dynamische Organisation einer der

70-Personen-Agentur gegeben Die Feedbacks Anregungen und kritischen Fragen der beiden wiederum

haben dazu gefuumlhrt Aspekte unserer Change-Initiative Organisationsstruktur und Unternehmenskultur neu zu

betrachten Ein sehr lohnenswerter Termin der mit Sicherheit Folgetermine nach sich ziehen wirdldquo

Margerete Voll Projektleiterin Allianz in Fuumlhrung

bdquoWir sind sehr froh bei unserem digitalen Transformationsprozess einen erfahrenen Partner wie TechDivision an

unserer Seite zu haben der im Vorfeld bei der Auswahl entsprechender Technologien und Prozesse beratend

zur Seite stand und uns in der Folge auch bei der Umsetzung und Weiterentwicklung unterstuumltzt An dieser

Stelle schon mal vielen Dank fuumlr die bisher geleistete sehr gute Arbeitldquo

Michael Schmid Leitung Marketing amp PR Cherry GmbH

bdquoWie viele mittelstaumlndische Unternehmen beschaumlftigen uns auch wir inzwischen intensiver mit der

fortschreitenden Digitalisierung Bei der Unmenge an Moumlglichkeiten und Optionen war bzw ist es fuumlr uns jedoch

nicht einfach die richtigen Ansaumltze zu finden Hierbei begleitet uns TechDivision bereits seit geraumer Zeit sehr

erfolgreich An dieser Stelle vielen Dank fuumlr ihre bisherige Arbeit und ihr Engagement Wir sind gespannt wie

sich unsere Ansaumltze weiterhin entwickelnldquo

Holger Wagner Leitung Marketing Erich Jaeger GmbH + Co KG

DAS SAGEN KUNDEN UumlBER UNS

S 38Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

EIN AUSZUG UNSERER REFERENZEN

Alle auf dieser Webseite abgebildeten Logos und genannten Warenzeichen sowie Markennamen sind Eigentum der entsprechenden Unternehmen

S 39Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

DAMIT NEHMEN SIE FAHRT AUF

bdquoDRIVEldquo VON DANIEL PINKSind wir nicht alle davon uumlberzeugt dass wir am besten

mit aumluszligeren Anreizen wie Geld und Prestige oder durch

bdquoZuckerbrot und Peitscheldquo zu motivieren sind bdquoAlles

falschldquo sagt Daniel H Pink in seinem provokanten

und zukunftsweisenden Buch Das Geheimnis unseres

persoumlnlichen Erfolges ist das zutiefst menschliche

Beduumlrfnis unser Leben selbst zu bestimmen zu lernen

Neues zu erschaffen und damit unsere Lebensqualitaumlt

und unsere Welt zu verbessern Daniel H Pink enthuumlllt

die Widerspruumlche zwischen dem was die Wissenschaft

weiszlig und dem was die Wirtschaft tut ndash und wie

genau dies jeden Aspekt unseres Lebens beeinflusst

Er demonstriert dass das Prinzip von Bestrafung und

Belohnung exakt der falsche Weg ist um Menschen

fuumlr die Herausforderungen von Heute zu motivieren

egal ob in Beruf oder Privatleben In bdquoDriveldquo untersucht

er die drei Elemente der wirklichen Motivation ndash

Selbstbestimmung Perfektionierung und Sinnerfuumlllung

ndash und bietet kluge sowie uumlberraschende Techniken an

um diese in die Tat umzusetzen Daniel H Pink stellt uns

Menschen vor die diese neuen Ansaumltze zur Motivation

bereits erfolgreich in ihr Leben integriert haben und uns

damit entschlossen einen auszligergewoumlhnlichen Weg in die

Zukunft zeigen

Jetzt bei Amazon bestellen

THE SURPRISING TRUTH ABOUT WHAT MOTIVATES US1047

gt Daniel Pink

Watch the Video

S 40Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

LESETIPPS

bull Semler Ricardo bdquoMAVERICK THE SUCCESS STORY BEHIND THE WORLDlsquoS MOST UNUSUAL WORKPLACEldquo Jetzt bei Amazon bestellen

bull Pink Daniel H bdquoDRIVE THE SURPRISING TRUTH ABOUT WHAT MOTIVATES USldquo Jetzt bei Amazon bestellen

bull Appelo Jurgen bdquoMANAGEMENT 30 - LEADING AGILE DEVELOPERS DEVELOPING AGILE LEADERSldquo Jetzt bei Amazon bestellen

bull Hsieh Tony bdquoDELIVERING HAPPINESS A PATH TO PROFITS PASSION AND PURPOSEldquo Jetzt bei Amazon bestellen

bull Ries Eric bdquoTHE LEAN STARTUP HOW CONSTANT INNOVATION CREATES RADICALLY SUCCESSFUL BUSINESSESldquo Jetzt bei Amazon bestellen

bull Hanisch Roland bdquoDAS ENDE DES PROJEKTMANAGEMENTSldquo Jetzt bei Amazon bestellen

bull Soll Donald Eisenhard Kathleen M bdquoSIMPLE RULES - EINFACHE REGELN FUumlR KOMPLEXE SITUATIONENldquo Jetzt bei Amazon bestellen

bull IT-Agile

bdquoAGILE MANAGEMENT INNOVATIONS ndash A PRIMERldquo Jetzt PDF downloaden

bull Valve 2012

bdquoHANDBOOK FOR NEW EMPLOYEESldquo (PDF) Jetzt PDF downloaden

bull Wagepoint

bdquoTHE EPIC GUIDE TO EMPLOYEE MANAGEMENTldquo Jetzt zu wagepointcom gehen

S 41Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

IMPRESSUMTechDivision GmbH

Spinnereiinsel 3a

83059 Kolbermoor

Tel +49 8031 221055-0

Fax +49 8031 221055-22

infotechdivisioncom

HERAUSGEBERTechDivision GmbH

QUELLENVERZEICHNIS

bull httpwwwscrumallianceorg

bull httpt3ndemagazinpraxisbericht-scrumkanban-scrumbuts-agiles-232822

bull httpwwwagileproductdesigncomblogdont_know_what_i_wanthtml

bull httpbtdaysde2014sesessionscontinuous-learning-agile-anforderungsanalyse-mitimpact-mapping

bull httpdeslidesharenetspringifysoftware-that-matters-agileanforderungsanalyse-mit-impact-mapping

bull httpdeslidesharenetspringifysoftware- thatmatters-agile-anforderungsanalyse-mit-impactmapping

bull httpimpactmappingorg

bull httpwwwwolterbiztagimpact-mapping

bull httpagilemanifestoorgisodeprincipleshtml

bull httpagilemanifestoorg

bull httpborisglogercomscrumscrumflowdie-scrum-artefakte

bull httpborisglogercom20110620scrumessentials-die-sieben-fragen-der-user- story

bull httpborisglogercom20101004das-impediment-backlog-10-tipps

bull httpswwwenergizedworkcomweblog200705fixed-price-contracts-dont-work

bull httpdewikipediaorgwikiKanban

bull httpdewikipediaorgwikiKanbanHistorische_Entwicklung

bull wwwheisededeveloperartikelSoftware-Kanban-im-Einsatz-1235465html

bull httpwwwit- agiledewissenmethodenkanban

bull wwwheisededeveloperartikelKanban-richtigeinfuehren-1344554htmlartikelseite=2

bull wwwheisededeveloperartikelKanban-richtig-einfuehren- 1344554htmlartikelseite=3

bull wwwt3ndemagazinpraxisbericht-scrum-kanban-scrumbuts-agiles-2328222

bull wwwinfoqcomresourcenews201001kanban-scrum- minibookenresourcesKanbanAndScrum-Germanpdf

bull httpsjaxenterdeagile-im-konzern-kann-das-funktionieren-41026

bull httpswwwgpm-ipmadefileadminuser_uploadKnow-HowstudienStudie_Agiles-PM_webpdf

bull httpsmanagement30com

bull Douglas McGregor bdquoThe Human Side of Enterpriseldquo 1960

bull httpagiletrailcom20121108agile-management-innovations-a-primer

S 42Gekuumlrzte Version ndash die Vollversion finden Sie unter httpswwwtechdivisioncomprojektmanagement-whitepaper

bdquoTURNING ONLINE PROJECTS INTO SUCCESSldquo

Spinnereiinsel 3a

83059 Kolbermoor

Balanstr 73 Haus 8 3 OG

81541 Muumlnchen

Tel +49 8031 2210 55-0

Fax +49 8031 2210 55-22

infotechdivisioncom

wwwtechdivisioncom

TechDivision GmbH

Sie haben Fragen Wir stehen Ihnen telefonisch und per Mail gerne zur Verfuumlgung und freuen uns auf eine

gemeinsame und erfolgreiche Zusammenarbeit