1.
Hier Testorganisatiosno llS dteart eT iotef lt rheein A rt
www.qs-tag.de
Workshop: Agile Planung
Stefan Roock
it-agile GmbH
stefan.roock@it-agile.de
Twitter: @StefanRoock
Veranstalter: imbus AG www.qs-tag.de

2.
Angebot
Beyond
autonomes
Team
empirisches
Management und
Lernen
Mechanik der
Releaseplanung
Release-
Controlling
Varianz-quellen
Schätzungen
Little’s
Law

3.
Scrum-Team
Klassische sequenzielle
Entwicklung
Überlappende Phasen
Scrum
Nonaka, Takeuchi: „The New New Product Development Game“

4.
Das Scrum-Team
inspect&adapt
cross-funktional
autonom

5.
Agilität
inspect&adapt
cross-funktional
business-orientierte
autonom
autonome
Teams, die ihren
Prozess in Besitz und
Verantwortung
nehmen

6.
Lieferbar

7.
braucht QS-/
Test-Skills
Produkt ist
lieferbar, wenn vor
Auslieferung nichts mehr
getan werden muss (auch
kein Testen).

8.
Geht nicht?
Wer Scrum anpasst, sollte
die Konsequenzen kennen!

9.
Empirisches Management
Transparenz
Inspektion
Adaption

10.
Empirisches Management im Review
Transparenz
Inspektion
Adaption
Demo
Produktinkrement
Feedback,
Wert?, ROI?
Product
Backlog
anpassen

11.
Warum ist Little’s Law relevant?
Kleinere Batches, !
kürzere Queues
Kürzere !
Time-to-Market
Früheres
Feedback
Höhere Qualität
Weniger !
Overhead
Größere !
Effizienz
erwartet
unerwar tet
vollkommen
unerwartet
nach D. Reinertsen

12.
Vom Wasserfall zu Scrum 1/2
Activity 1 Activity 2 ... Activity n
Sprint 1 ... Sprint n
Activity 1
Activity n
Wasserfall
Eingebettete Iterationen
Work-in-Progress
ist beiden Fällen
gleich hoch

13.
Vom Wasserfall zu Scrum 2/2
Sprint 1 Sprint 2
Sprint 3
Sprint 1 Sprint 2 Sprint 3
vielfach so hoch
wie in Scrum
Activities
1 - n
Sprint 1
Sprint 2 Sprint 3
Sprint 1 ... Sprint n
Pipeling
Work-in-
Progress
Scrum
Work-in-
Progress
minimal

14.
Pipelining-Konsequenzen 1/2
Sprint 1 Sprint 2
Sprint 3
Sprint 1 Sprint 2 Sprint 3
Sprint 1
Sprint 2 Sprint 3
Feedback Cycle Length

15.
Pipelining-Konsequenzen 1/2
Sprint 1 Sprint 2
Sprint 3
?
Sprint 1 Sprint 2 Sprint 3
Sprint 1
Sprint 2 Sprint 3
?
?
Rückläufer
(Failure Demand)
zerstören das
Konzept

16.
PDCA-Zyklus nach Sheward/Deming

17.
Scrum-Produktzyklus Sprint
Planning
Sprint
Sprint
Review

18.
Diskutiert:
War u m b r a u c ht
man
Release plan ung?
Wer braucht
wann welche
Infor mationen?
Aufgabe
5 Minuten

19.
Releaseplanung - wozu?
Rendezvous
-Planung
€
Imvestitions-
Planung
Kann man mit den
Rendezvouspartnern
neue Arten der
Zusammenarbeit
etablieren?
(inkrementelle
Releaseplanung)
Wie genau muss der
Scope bekannt sein?
Reicht nicht ein Ziel?

20.
Ökonomie des Front Loading 1/3
Bsp.:
Einfaches Lotto: 4 Ziffern von 0-9 zu tippen.
Gewinn bei 4 Richtigen: 1 Mio. EUR
Wieviel darf der Lotto-Schein kosten, damit es ökonomisch
sinnvoll ist, Lotto zu spielen?
angelehnt an Don Reinertsen: „Flow“

21.
Ökonomie des Front Loading 2/3
Bsp.:
Einfaches Lotto: 4 Ziffern von 0-9 zu tippen.
Gewinn bei 4 Richtigen: 1 Mio. EUR
Wieviel darf der Lotto-Schein kosten, damit es ökonomisch
sinnvoll ist, Lotto zu spielen?
Antwort: weniger als 100 EUR (1 Mio. / 10.000)
Jemand bietet mir an, dass ich für 50 EUR meine erste Ziffer
testen kann. Ist es ökonomisch sinnvoll, dieses Angebot zu nutzen?
angelehnt an Don Reinertsen: „Flow“

22.
Ökonomie des Front Loading 3/3
Bsp.:
Einfaches Lotto: 4 Ziffern von 0-9 zu tippen.
Gewinn bei 4 Richtigen: 1 Mio. EUR
Wieviel darf der Lotto-Schein kosten, damit es ökonomisch sinnvoll ist, Lotto zu
spielen?
Antwort: weniger als 100 EUR (1 Mio / 10.000)
!
Jemand bietet mir an, dass ich für 50 EUR meine erste Ziffer testen kann. Ist es
ökonomisch sinnvoll, dieses Angebot zu nutzen?
Antwort: Definitiv. Ich kann für durchschnittlich 250 EUR herausfinden, wie die
erste Ziffer lautet. Danach habe ich nur noch 1.000 Möglichkeiten, kann also
durch Investition von 100.000 EUR (100 EUR * 1.000 Möglichkeiten) garantieren,
dass ich den Gewinn von 1 Mio. EUR bekommen.
!
Erkenntnis: Informationsgewinn hat einen ökonomischen Wert! Projektstart mit
festem Featureset ist ökonomisch unsinnig. Wie kann ich günstig wertvolle
Informationen beschaffen (Prototypen, MVPs, etc.)?
angelehnt an Don Reinertsen: „Flow“

23.
Steuerungsgrößen
Scope
Ressourcen Zeit

24.
Releaseplanung
Scope
Scopebasierte
Planung
Ressourcen Zeit
zeitbasierte
Planung

25.
Releaseplanung
Product
Backlog
Velocity
1 2 3
10
Summe:
400 Story Points
Story
Points
10 Story Points
scopebasierte
Planung
gegebene Deadline: in 30 Sprints
30 Sprints * 10 Story Points je Sprint
= 300 Story Points
400 Story Points
10 Story Points per Sprint
= 40 Sprints
zeitbasierte
Planung
100 Story Points aus
Backlog entfernen

26.
Feste Containergrößen
Scope
Ressourcen Zeit
3 Monate 3 Monate 3 Monate 3 Monate 3 Monate
•begrenzt Investitionsrisiken
•erleichtert Planung
•erleichtert Team-Änderungen
•erzeugt Fokus

27.
Roadmap Planung
Name/version Name/version Name/version Name/version
DATE
The launch date or timeframe
GOAL
The reaon for creating the
new version
FEATURES
7KHWKUHHWRȴYHIHDWXUHV
necessary to meet the goal
METRICS
The metrics/ KPIs to determine
if the goal has been met
Goal
This work is licensed under a Creative Commons
Attribution-ShareAlike 3.0 Unported License
THE GO PRODUCT ROADMAP
Date or timeframe
Features
Metrics
Date or timeframe
Goal
Features
Metrics
Date or timeframe
Goal
Features
Metrics
Date or timeframe
Goal
Features
Metrics
NAME
The name of the new product
version or major release
www.romanpichler.com
Template version 12/13

28.
Release Burnup Chart
Sprint
Verbleibender Aufwand
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Scope
Rescoping
Feature
Creep
Release Burndown
Nach Sprint
Bar Chart
Restaufwand
1 2 3 4 5

29.
Cumulative Flow Diagram (CFD)
geplant
konzipiert
programmiert
modul-getestet
integrations-getestet
(lieferbar)

30.
Parking Lot Diagram

31.
Sam m elt
Va r i a n z q u e l l e n ,
die bei Euch
Schätzungen
und Planungen
fal s c h b z w.
ins tabil
machen.
Aufgabe
5 Minuten

32.
Varianzquellen
unerwünscht
unvermeidbar vermeidbar erwünscht
Impediments
Teamdynamik
Sprint-Review
Sprint-
Retrospektive
…
Störungen durch
Vorgesetzte
Bugs
…
Gesetzgebung
…
Kündigung
Krankheit
Feueralarm
Erdbeben
neue
Technologien
Missverständnisse
Langsame PCs
fehlende
Testumgebung

33.
Varianzquellen
unerwünscht
unvermeidbar vermeidbar erwünscht
Großer Hebel zur
Verbesserung der Release-Planung:
guter Scrum-Master, der
Impediments beseitigt.
Impediments
Teamdynamik
Sprint-Review
Sprint-
Retrospektive
…
Störungen durch
Vorgesetzte
Bugs
…
Gesetzgebung
…
Kündigung
Krankheit
Feueralarm
Erdbeben
neue
Technologien
Missverständnisse
Langsame PCs
fehlende
Testumgebung

34.
Varianzquellen
unerwünscht
unvermeidbar vermeidbar erwünscht
Impediments
Teamdynamik
Sprint-Review
Sprint-
Retrospektive
…
Störungen durch
Vorgesetzte
Bugs
…
Gesetzgebung
…
Kündigung
Krankheit
Feueralarm
Erdbeben
neue
Technologien
Missverständnisse
Langsame PCs
fehlende
Testumgebung
Die richtigen
Varianzen sind
ökonomische
Optionen!

35.
Stabilität
Effizienz optimieren
Instabilität
Lernen
maximieren
Geschäfts-system
Innovations-system

36.
Schätzmaße
high low
Impact of
sources of variability
high
Appropriate
precision of
estimation
low
Hours
Days
Function
Points
Story
Points
T-Shirt
sizes
Counting

37.
Schätzgenauigkeit
low high
effort for estimation
high
precision of
estimation
low

38.
Story Points
3 8
1 2
13
3 5
•meist guter Kompromiss aus Schätzaufwand
und Genauigkeit
•weniger abhängig vom Individuum als
Personentage
•schnellere Einigkeit bei Team-Schätzung
•insgesamt schneller (weil weniger
Commitment mitschwingt)

39.
•Varianzquellen verstehen
(Workshop)
•klassisches Risikomanagement
•fähigen Scrum-Master
integrieren
•positive Varianzen nutzen
Tipps zu
Varianzquellen

40.
Trends
Messen statt schätzen (Beyond
Estimating), z.B. mit Lean Forecasting
Inkrementelle Relaseplanung
keine Releaseplanung (für bestimmte
Kontexte)

41.
Zusammenfassung
Agile Planung ist ehrlicher und verlässlicher
als klassische Planung.
Realitätsferne Planungen werden früh
sichtbar.
Genaue Vorhersagbarkeit für Zeit und
Scope widerspricht dem Wunsch nach
Flexibilität und Innovation.
Planung muss kontinuierlich angepasst
werden.

42.
Vielen Dank für die Aufmerksamkeit
Agil auf allen Ebenen
Stefan Roock
stefan.roock@it-agile.de
Twitter: @StefanRoock