Scrum in der Rückversicherung Eine Erfolgsgeschichte

Wolfgang Pleus (www.pleus.net)

Scrum Day – SAP St. Leon Rot , 05.07.2012

Agenda

Ausgangslage und Motivation

Phase 1 - Initialisierung

• Vom UseCase zur UserStory

• Wasserfall trifft Scrum

Phase 2 – Durchführung

• Spezifizieren mit Scrum?

• Umgang mit dynamischen Teams

• Qualitätssicherung und Test

• Projektmanagement im veränderlichen Umfeld

Phase 3 - Perspektiven

• Übertragbarkeit auf andere Projekte

• Organisatorische Verankerung

Ausgangslage

Hannover Re - Einer der weltgrößten Rückversicherer

Technische und methodische Erneuerung des zentralen Business Partner

Management Systems

Geschäftskritisches Projekt, weltweites Rollout, 11.2009 – 01.2012

Bereitschaft neue Wege zu gehen

Wolfgang Pleus - PLEUS Consulting

• IT- und Methodenberatung seit 1993

• Scrum Master und Coach, Solution Architect

• Begleitet das Projekt von der Analyse bis zur Produktion

Phase 1 - Initialisierung

Vom UseCase zur UserStory

Strukturierte Anforderungs-

analyse

• Ergebnisse: Usecases, Requirements und Grobkonzept

• 3 Personen: Erschliessen des Kontextes

• Dauer: 3 Monate

Product Backlog

Workshop

• Ergebnis: Initiales Product Backlog

• Gesamtes Team (20): Verteilung des Kontextwissens

• Dauer: 3 Tage

Umsetzung

• Ergebnisse: Konzeption und Produkt

• Dynamisches Team: Iterative Umsetzung

• Dauer: 23 Monate

Product Owner und Solution Architect transportieren Kontextwissen

Vom UseCase zur UserStory

Strukturierte Anforderungs-

analyse

• Ergebnisse: Usecases, Requirements und Grobkonzept

• 3 Personen: Erschliessen des Kontextes

• Dauer: 3 Monate

Product Backlog

Workshop

• Ergebnis: Initiales Product Backlog

• Gesamtes Team (20): Verteilung des Kontextwissens

• Dauer: 3 Tage

Umsetzung

• Ergebnisse: Konzeption und Produkt

• Dynamisches Team: Iterative Umsetzung

• Dauer: 23 Monate

Lessons learned:

1. Grobanalyse hilft den Kontext zu verstehen.

2. Product Owner und Solution Architect müssen das Projekt

fortwährend begleiten (Kontextwissen).

3. Trennung von Analyse- und Entwicklungsteam nicht hilfreich

Product Backlog Workshop

Storypoints

Business value

Team

Product

Owner

Scrum

Master

Product Backlog Workshop

Storypoints

Business value

Team

Product

Owner

Scrum

Master

Lessons learned:

1. Unterscheidung von Konzeption und Umsetzung ist hilfreich.

2. Mapping der Anforderung stellt 100% Abdeckung sicher.

3. Workshop ermöglicht gemeinsames Verständnis im Team

(Fach/IT).

Wasserfall trifft Scrum

Initialisierung Planung Definition Entwurf Implementierung Einführung Wartung

Analyse Design Entwicklung Betrieb

Grobkonzept

REVIEW MEETING

RETROSPECTIVE

MEETING

Agile Spezifikation

Agile Entwicklung

Agiler Test

Agiles Projektmanagement

Pflichten:

Abgenommene Konzepte

Testfälle

Monatliche Statusberichte

Wasserfall trifft Scrum

Initialisierung Planung Definition Entwurf Implementierung Einführung Wartung

Analyse Design Entwicklung Betrieb

Grobkonzept

REVIEW MEETING

RETROSPECTIVE

MEETING

Agile Spezifikation

Agile Entwicklung

Agiler Test

Agiles Projektmanagement

Pflichten:

Abgenommene Konzepte

Testfälle

Monatliche Statusberichte

Lessons learned:

1. Klassische und agile Methoden sind kombinierbar, solange die

Artefakte geliefert werden.

2. Klassischer Mehraufwand bringt wenig Mehrwert.

3. Prinzipiell jederzeit zu Scrum gewechselt werden.

Phase 2 – Durchführung

Spezifizieren mit Scrum?

Silverlight SketchFlow

Enterprise Architect

XML

Annotationen

und Screens Entwerfen / Spezifizieren

Generieren

Veröffentlichen

Interne Freigabe

(DoD)

Offizielle Abnahme

Pflicht:

Abgenommene Konzepte

Word Wiki

Spezifizieren mit Scrum?

Silverlight SketchFlow

Enterprise Architect

XML

Annotationen

und Screens Entwerfen / Spezifizieren

Generieren

Veröffentlichen

Interne Freigabe

Offizielle Abnahme

Pflicht:

Abgenommene Konzepte

Word

Lessons learned:

1. Erst konzipieren, dann implementieren.

2. Konzeption steigert Verbindlichkeit und Klarheit.

3. Spezifizieren nur soviel wie nötig.

4. Zeitliche Nähe von Spezifikation und Umsetzung erhält den

Wissenskontext (1 Sprint Vorlauf ideal).

5. Bug or Change Problem (Vertrauen ist essentiell).

Umgang mit dynamischen Teams

Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Entwicklung

snb (dev) 26 25 10 15 18 17 13 8 20 17 16 19 18 22 21 16 17 21 8 15 10 9

pw2 (dev) 26 25 23 20 22 23 9 22 20 19 14 23 17 19 19 20 14 19 19 21 20 10

ren (db, bi, dev) 10 10 8 6 10 10 13 7 15 19 18 20 22 22 18 19 17 12 22 21 19 15

mf2 (dev) 21 19 22 20 21 20 20 20 14 20 23 20 15

hto(db) 10 10 10 10 10 10 5 18 10 8 12

sb3 (migration) 14 20 15 14 25 25 4

Spezifikation

svd (po) 5 13 13 12 11 12 10 8 5 10 7 7 10 9 9 5 9 8 8 10 10 5

jds (spec) 5 20 20 12 15 16 16 12 8 8 7 5 4 5 8 9 9 9 5 9 9 5

htn (spec, test) 8 13 10 10 12 8 7 9 7 7 7 12 11 13 11 10 21 17 19 10 8

sta (spec) 8 8 6 5 5 2 3 3 1 1 2 2 2 4 4 4 4 3 3 5 3

eth (spec) 3 4 8 9 10 6 3 10 6 5 2 5 3 2 2 4 6

ghc/dki (spec) 8 4 5 9 6 6 4 4 2 6

tj (spec) 1 1 1 1 3 1 5 2

knt (spec) 3 3 4 6 10 10 10 3 3 3 5 2 3

Test

krc (test) 7 10 10 13 9 10 9 12 15 15 18 19 20 25 14 25 23 23

dai (training) 6 8 8 8 5

fnn (test) 20 20 9 5 5

Weitere

mrk (bi) 10 10 8 6 3 5 6 5 10 4 2 1

lad (db) 3 4 5

dai (training) 6 8 8 8 5

le2 (trainings) 6 2

Umgang mit dynamischen Teams

Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Entwicklung

snb (dev) 26 25 10 15 18 17 13 8 20 17 16 19 18 22 21 16 17 21 8 15 10 9

pw2 (dev) 26 25 23 20 22 23 9 22 20 19 14 23 17 19 19 20 14 19 19 21 20 10

ren (db, bi, dev) 10 10 8 6 10 10 13 7 15 19 18 20 22 22 18 19 17 12 22 21 19 15

mf2 (dev) 21 19 22 20 21 20 20 20 14 20 23 20 15

hto(db) 10 10 10 10 10 10 5 18 10 8 12

sb3 (migration) 14 20 15 14 25 25 4

Spezifikation

svd (po) 5 13 13 12 11 12 10 8 5 10 7 7 10 9 9 5 9 8 8 10 10 5

jds (spec) 5 20 20 12 15 16 16 12 8 8 7 5 4 5 8 9 9 9 5 9 9 5

htn (spec, test) 8 13 10 10 12 8 7 9 7 7 7 12 11 13 11 10 21 17 19 10 8

sta (spec) 8 8 6 5 5 2 3 3 1 1 2 2 2 4 4 4 4 3 3 5 3

eth (spec) 3 4 8 9 10 6 3 10 6 5 2 5 3 2 2 4 6

ghc/dki (spec) 8 4 5 9 6 6 4 4 2 6

tj (spec) 1 1 1 1 3 1 5 2

knt (spec) 3 3 4 6 10 10 10 3 3 3 5 2 3

Test

krc (test) 7 10 10 13 9 10 9 12 15 15 18 19 20 25 14 25 23 23

dai (training) 6 8 8 8 5

fnn (test) 20 20 9 5 5

Weitere

mrk (bi) 10 10 8 6 3 5 6 5 10 4 2 1

lad (db) 3 4 5

dai (training) 6 8 8 8 5

le2 (trainings) 6 2

Lessons learned:

1. Je kleiner die Entfernung vom Projektbüro umso größer das Committment.

2. Das Kernteam muss stabil bleiben.

3. Projektbüro und Vor-Ort-Präsenz sind essentiell.

4. Kurze Wege zwischen Spezifikation, Entwicklung und Test steigern die

Produktivität.

5. Teamgröße teilweise am Limit (erschwerte Kommunikation), Split erschien

als Nachteil.

Qualitätssicherung und Test

Strukturierte Qualitätssicherung im Team

• Unit, Integration, Akzeptanz, Last&Performance

Qualität in der DoD

• Anzahl neue Testfälle = SP im Sprint *Testfälle pro SP-Faktor (z.B. 2)

• Durchführen aller Neuen + 25% Retest

Bug Backlog als messbarer Qualitätsindikator (bei >50 Eintrag ins Changelog)

Testfälle für die QM-Endabnahme wiederverwendbar. uc Load profile

Sperren setzen (pid:

277511)

Standard user (95,5%)

Power user (4,5%)

Datamanager

(1,1%)

Stammdaten ändern /

anlegen (Bids)

Run off manager

(2,8%)

Simple user

(Protection Re)

(1,1%)

Standard user (z.B.

Underwriter)

(66,1%)

Security Consumer

(4,4%)

Security Analyst

(0,6%)

Maximalnutzung: Maximal 900 User können

RoBP potentiell gleichzeitig verwenden und

verschiedene Geschäftsvorgänge ausführen.

Fav oriten erzeugen -

Limit 3s

Suchergebnis exportieren -

Limit 6s

Änderung/Neuanlage

beantragen (bid:13553)

Verfahren durchführen

(Pids, pid:370661)

Stammdaten ansehen (Bids)

Dokument anhängen

(pid:370661)

RoBP starten - Limit 12s

Portal ansehen

Current Accountant

(3,3%)

Technical

Accountant (20,6%)

Keine RoBP

Benutzung

Suchen (QueryStrings) - Limit

0,5s

Report anzeigen (pid:

370661)

Approv e durchführen

(pid:370661)

Kontext anzeigen

Validieren

50%

20%

100%

10%

50%30%

35%

20%

50%

10%

20%

25%

80%

50%

25%

N:98%, H:

95%

N:2% ,H:5%

N:15%, H:

40%

N:70%, H:

5%

N:15%, H:

55%

2%20%

Pflicht:

Testfälle

Pflicht:

Testfälle

Qualitätssicherung und Test

Strukturierte Qualitätssicherung im Team

• Unit, Integration, Akzeptanz, Last&Performance

Qualität in der DoD

• Anzahl neue Testfälle = SP im Sprint *Testfälle pro SP-Faktor (z.B. 2)

• Durchführen aller Neuen + 25% Retest

Bug Backlog als messbarer Qualitätsindikator (bei >50 Eintrag ins Changelog)

Testfälle für die QM-Endabnahme wiederverwendbar. uc Load profile

Sperren setzen (pid:

277511)

Standard user (95,5%)

Power user (4,5%)

Datamanager

(1,1%)

Stammdaten ändern /

anlegen (Bids)

Run off manager

(2,8%)

Simple user

(Protection Re)

(1,1%)

Standard user (z.B.

Underwriter)

(66,1%)

Security Consumer

(4,4%)

Security Analyst

(0,6%)

Maximalnutzung: Maximal 900 User können

RoBP potentiell gleichzeitig verwenden und

verschiedene Geschäftsvorgänge ausführen.

Fav oriten erzeugen -

Limit 3s

Suchergebnis exportieren -

Limit 6s

Änderung/Neuanlage

beantragen (bid:13553)

Verfahren durchführen

(Pids, pid:370661)

Stammdaten ansehen (Bids)

Dokument anhängen

(pid:370661)

RoBP starten - Limit 12s

Portal ansehen

Current Accountant

(3,3%)

Technical

Accountant (20,6%)

Keine RoBP

Benutzung

Suchen (QueryStrings) - Limit

0,5s

Report anzeigen (pid:

370661)

Approv e durchführen

(pid:370661)

Kontext anzeigen

Validieren

50%

20%

100%

10%

50%30%

35%

20%

50%

10%

20%

25%

80%

50%

25%

N:98%, H:

95%

N:2% ,H:5%

N:15%, H:

40%

N:70%, H:

5%

N:15%, H:

55%

2%20%

Lessons learned:

1. Test beginnen, sobald etwas Testbares da ist.

2. Akzeptanztest: Kosten/Nutzen-Verhältnis zugunsten manueller Tests.

3. Messbare Qualitätsindikatoren etablieren (Wann ist etwas gut?).

4. Tester müssen im Team sein - kurze Wege.

5. Nähe von Spezifikation und Test sicherstellen (Wissenskontext).

6. Entspannte Produktivsetzung als neue Erfahrung.

Projektmanagement im veränderlichen Umfeld

Velocity = Storypoints / Personentage

• Vorher / Nachher Betrachtung (Commitment und Realität)

Releaseprognosen unter Einbeziehung regelmäßiger SP Zuwächse

Grooming Workshops als zentraler Steuerungsmechanismus

31.12.2010 Ursprüngliche

Annahme

10.03.2010 Initiales Backlog

18.06.2013 - Grooming +

Reestimation

20.12.2011 Grooming

17.06.2012 06.01.2012 Grooming

16.01.2012 Release

06.07.200914.10.200922.01.201002.05.201010.08.201018.11.201026.02.201106.06.201114.09.201123.12.201101.04.201210.07.201218.10.201226.01.201306.05.201314.08.201322.11.2013

0100200300400500600700800900

10001100120013001400150016001700180019002000

13

.11

.200

9

13

.12

.200

9

13

.01

.201

0

13

.02

.201

0

13

.03

.201

0

13

.04

.201

0

13

.05

.201

0

13

.06

.201

0

13

.07

.201

0

13

.08

.201

0

13

.09

.201

0

13

.10

.201

0

13

.11

.201

0

13

.12

.201

0

13

.01

.201

1

13

.02

.201

1

13

.03

.201

1

13

.04

.201

1

13

.05

.201

1

13

.06

.201

1

13

.07

.201

1

13

.08

.201

1

13

.09

.201

1

13

.10

.201

1

13

.11

.201

1

13

.12

.201

1

13

.01

.201

2

Pro

gn

ose E

nd

ete

rmin

Pro

du

ct

Backlo

g

Erfassungsdatum

Product Backlog und Releaseprognose Product Backlog

Prognose Endetermin

Pflicht:

Statusberichte

Projektmanagement im veränderlichen Umfeld

Velocity = Storypoints / Personentage

• Vorher / Nachher Betrachtung (Commitment und Realität)

Releaseprognosen unter Einbeziehung regelmäßiger SP Zuwächse

Grooming Workshops als zentraler Steuerungsmechanismus

31.12.2010 Ursprüngliche

Annahme

10.03.2010 Initiales Backlog

18.06.2013 - Grooming +

Reestimation

20.12.2011 Grooming

17.06.2012 06.01.2012 Grooming

16.01.2012 Release

06.07.200914.10.200922.01.201002.05.201010.08.201018.11.201026.02.201106.06.201114.09.201123.12.201101.04.201210.07.201218.10.201226.01.201306.05.201314.08.201322.11.2013

0100200300400500600700800900

10001100120013001400150016001700180019002000

13

.11

.200

9

13

.12

.200

9

13

.01

.201

0

13

.02

.201

0

13

.03

.201

0

13

.04

.201

0

13

.05

.201

0

13

.06

.201

0

13

.07

.201

0

13

.08

.201

0

13

.09

.201

0

13

.10

.201

0

13

.11

.201

0

13

.12

.201

0

13

.01

.201

1

13

.02

.201

1

13

.03

.201

1

13

.04

.201

1

13

.05

.201

1

13

.06

.201

1

13

.07

.201

1

13

.08

.201

1

13

.09

.201

1

13

.10

.201

1

13

.11

.201

1

13

.12

.201

1

13

.01

.201

2

Pro

gn

ose E

nd

ete

rmin

Pro

du

ct

Backlo

g

Erfassungsdatum

Product Backlog und Releaseprognose Product Backlog

Prognose Endetermin

Lessons learned:

1. Initiale Terminschätzung (vor Scrum) war unrealistisch.

2. Releaseprognose besser verständlich als das Product Backlog.

3. Frühzeitiger Erkenntnissgewinn ist ungewohnt.

4. Flexbilität bei Anforderungen (was und wie) und …

5. … Flexibilität bei der Realisierung (wie) als Schlüssel zum Termin.

6. Product Owner mit Kompetenz für schnelle Entscheidungen.

Pflicht:

Statusberichte

Phase 3 - Perspektiven

Übertragbarkeit auf andere Projekte

Übertragbarkeit ist schwierig

• Integration der Fachbereiche ist ungewohnt und teilweise nicht gewollt

• Scrum Master Schulung macht keinen Scrum Master

• Nicht jeder Product Owner hat die notwendigen Entscheidungskompetenzen

Falsche Schlussfolgerung: Scrum für kleine Projekte, klassisches Vorgehen für

große Projekte

Richtig wäre: Scrum für ALLE Projekte, bei denen die Voraussetzungen

stimmen

Naive Anwendung

• schadet mehr als sie nutzt

• Scrum ist kein Dogma, aber …

• … nenne es nicht Scrum wenn es kein Scrum ist

Organisatorische Verankerung

Projekt-Retrospektive/Review erzeugen Impulse in die Organisation

Beteiligte IT und Fachbereich sehen Scrum als hilfreich an

Zentrales QM und PM sehen sich subjektiv in Frage gestellt

Weitgehende Unkenntniss im Management

Fürstentümer und hierarchische Kultur stehen im Weg

„Was du mir sagst, das vergesse ich. Was du mir zeigst, daran erinnere ich mich.

Was du mich tun lässt, das verstehe ich.“ – Konfuzius, chinesischer Philosoph

= schwieriges Klima für nachhaltige Veränderung

Organisatorische Verankerung

IT und Fachbereich sehen Scrum als hilfreich an

Zentrales QM und PM sehen sich subjektiv in Frage gestellt

Weitgehende Unkenntniss im Management

Fürstentümer und hierarchische Kultur

„Was du mir sagst, das vergesse ich. Was du mir zeigst, daran erinnere ich mich.

Was du mich tun lässt, das verstehe ich.“ – Konfuzius, chinesischer Philosoph

= schwieriges Klima für nachhaltige Veränderung

Lessons learned:

1. Scrum von unten stößt schnell an Grenzen

2. Überzeugen durch Erfolg ist der Weg

3. Projektmarketing und Informieren sind wichtig

4. Nachhaltige Agilität ist ein langwieriger Prozess

5. Ohne das Management ist sie nicht zu erreichen

Fazit

Scrum hat sich sehr bewährt

Scrum gibt dem Team Struktur und Beweglichkeit

Die Beteiligten empfinden es als Modell für die Zukunft

Scrum allein ist ok, aber …

… individuelle Antworten für Test, Spezifikation, Projektmanagement, etc. sind

erforderlich

Teambesetzung (Persönlichkeit und Expertise) ist der Schlüssel zum Erfolg

Scrum erscheint einfach aber kulturelle Implikationen sind weitreichend

Vielen Dank