SlideShare ist ein Scribd-Unternehmen logo
1 von 43
Downloaden Sie, um offline zu lesen
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
Angebot 
Beyond 
autonomes 
Team 
empirisches 
Management und 
Lernen 
Mechanik der 
Releaseplanung 
Release- 
Controlling 
Varianz-quellen 
Schätzungen 
Little’s 
Law
Scrum-Team 
Klassische sequenzielle 
Entwicklung 
Überlappende Phasen 
Scrum 
Nonaka, Takeuchi: „The New New Product Development Game“
Das Scrum-Team 
inspect&adapt 
cross-funktional 
autonom
Agilität 
inspect&adapt 
cross-funktional 
business-orientierte 
autonom 
autonome 
Teams, die ihren 
Prozess in Besitz und 
Verantwortung 
nehmen
Lieferbar
braucht QS-/ 
Test-Skills 
Produkt ist 
lieferbar, wenn vor 
Auslieferung nichts mehr 
getan werden muss (auch 
kein Testen).
Geht nicht? 
Wer Scrum anpasst, sollte 
die Konsequenzen kennen!
Empirisches Management 
Transparenz 
Inspektion 
Adaption
Empirisches Management im Review 
Transparenz 
Inspektion 
Adaption 
Demo 
Produktinkrement 
Feedback, 
Wert?, ROI? 
Product 
Backlog 
anpassen
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)
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
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
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
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
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
PDCA-Zyklus nach Sheward/Deming
Scrum-Produktzyklus Sprint 
Planning 
Sprint 
Sprint 
Review
Diskutiert: 
War u m b r a u c ht 
man 
Release plan ung? 
Wer braucht 
wann welche 
Infor mationen? 
Aufgabe 
5 Minuten
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?
Ö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“
Ö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“
Ö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“
Steuerungsgrößen 
Scope 
Ressourcen Zeit
Releaseplanung 
Scope 
Scopebasierte 
Planung 
Ressourcen Zeit 
zeitbasierte 
Planung
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
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
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
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
Cumulative Flow Diagram (CFD) 
geplant 
konzipiert 
programmiert 
modul-getestet 
integrations-getestet 
(lieferbar)
Parking Lot Diagram
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
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
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
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!
Stabilität 
Effizienz optimieren 
Instabilität 
Lernen 
maximieren 
Geschäfts-system 
Innovations-system
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
Schätzgenauigkeit 
low high 
effort for estimation 
high 
precision of 
estimation 
low
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)
•Varianzquellen verstehen 
(Workshop) 
•klassisches Risikomanagement 
•fähigen Scrum-Master 
integrieren 
•positive Varianzen nutzen 
Tipps zu 
Varianzquellen
Trends 
Messen statt schätzen (Beyond 
Estimating), z.B. mit Lean Forecasting 
Inkrementelle Relaseplanung 
keine Releaseplanung (für bestimmte 
Kontexte)
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.
Vielen Dank für die Aufmerksamkeit 
Agil auf allen Ebenen 
Stefan Roock 
stefan.roock@it-agile.de 
Twitter: @StefanRoock

Weitere ähnliche Inhalte

Ähnlich wie Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)

Projekte mittels Scrum und agiler Software Entwicklung meistern
Projekte mittels Scrum und agiler Software Entwicklung meisternProjekte mittels Scrum und agiler Software Entwicklung meistern
Projekte mittels Scrum und agiler Software Entwicklung meisternINM AG
 
ASQF Nürnberg - Bitter Scrum
ASQF Nürnberg - Bitter ScrumASQF Nürnberg - Bitter Scrum
ASQF Nürnberg - Bitter ScrumThomas Moedl
 
Roadmaps und Agile Reporting abseits von Velocity und Story Points
Roadmaps und Agile Reporting abseits von Velocity und Story PointsRoadmaps und Agile Reporting abseits von Velocity und Story Points
Roadmaps und Agile Reporting abseits von Velocity und Story PointsStefan ROOCK
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshopmrdoubleb
 
NRWConf 2013 - Effort Estimation in Agile Projects
NRWConf 2013 - Effort Estimation in Agile ProjectsNRWConf 2013 - Effort Estimation in Agile Projects
NRWConf 2013 - Effort Estimation in Agile ProjectsRainer Stropek
 
Das TIB AV-Portal setzt auf das agile Management-Framework Scrum
Das TIB AV-Portal setzt auf das agile Management-Framework ScrumDas TIB AV-Portal setzt auf das agile Management-Framework Scrum
Das TIB AV-Portal setzt auf das agile Management-Framework ScrumSvenDrStrobel
 
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der PraxisResponsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der PraxisRoberto Rizzi
 
Alles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenAlles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenTechDivision GmbH
 
Den PEP (Produktentwicklungsprozess) neu denken!
Den PEP (Produktentwicklungsprozess) neu denken!Den PEP (Produktentwicklungsprozess) neu denken!
Den PEP (Produktentwicklungsprozess) neu denken!Christoph Schmiedinger
 
Metrics we can gain from our (Kanban) system and what we can learn from ..
Metrics we can gain from our (Kanban) system and what we can learn from .. Metrics we can gain from our (Kanban) system and what we can learn from ..
Metrics we can gain from our (Kanban) system and what we can learn from .. Martin Putz
 
UX & AGILE vom SCRUM Stammtisch Graz
UX & AGILE vom SCRUM Stammtisch GrazUX & AGILE vom SCRUM Stammtisch Graz
UX & AGILE vom SCRUM Stammtisch GrazHAnnes Robier
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...QAware GmbH
 
Digital Labs & Hubs - ein Erfolgsrezept?
Digital Labs & Hubs - ein Erfolgsrezept?Digital Labs & Hubs - ein Erfolgsrezept?
Digital Labs & Hubs - ein Erfolgsrezept?Christoph Schmiedinger
 
Schätzen heißt Lügen
Schätzen heißt LügenSchätzen heißt Lügen
Schätzen heißt LügenUlf Mewe
 
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas MödlOOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas MödlThomas Moedl
 
Rails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenRails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenPhillip Oertel
 
Scrum checklist 2013
Scrum checklist 2013Scrum checklist 2013
Scrum checklist 2013Hanser Update
 
Roadmaps und Agile Reporting abseits von Velocity und Story Points (Agile Wed...
Roadmaps und Agile Reporting abseits von Velocity und Story Points (Agile Wed...Roadmaps und Agile Reporting abseits von Velocity und Story Points (Agile Wed...
Roadmaps und Agile Reporting abseits von Velocity und Story Points (Agile Wed...Stefan ROOCK
 
OptaPlanner hilft bei verteilten Schulstandorten
OptaPlanner hilft bei verteilten SchulstandortenOptaPlanner hilft bei verteilten Schulstandorten
OptaPlanner hilft bei verteilten SchulstandortenTorsten Fink
 

Ähnlich wie Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg) (20)

Projekte mittels Scrum und agiler Software Entwicklung meistern
Projekte mittels Scrum und agiler Software Entwicklung meisternProjekte mittels Scrum und agiler Software Entwicklung meistern
Projekte mittels Scrum und agiler Software Entwicklung meistern
 
ASQF Nürnberg - Bitter Scrum
ASQF Nürnberg - Bitter ScrumASQF Nürnberg - Bitter Scrum
ASQF Nürnberg - Bitter Scrum
 
Roadmaps und Agile Reporting abseits von Velocity und Story Points
Roadmaps und Agile Reporting abseits von Velocity und Story PointsRoadmaps und Agile Reporting abseits von Velocity und Story Points
Roadmaps und Agile Reporting abseits von Velocity und Story Points
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
NRWConf 2013 - Effort Estimation in Agile Projects
NRWConf 2013 - Effort Estimation in Agile ProjectsNRWConf 2013 - Effort Estimation in Agile Projects
NRWConf 2013 - Effort Estimation in Agile Projects
 
Das TIB AV-Portal setzt auf das agile Management-Framework Scrum
Das TIB AV-Portal setzt auf das agile Management-Framework ScrumDas TIB AV-Portal setzt auf das agile Management-Framework Scrum
Das TIB AV-Portal setzt auf das agile Management-Framework Scrum
 
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der PraxisResponsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
 
Alles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenAlles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 Minuten
 
Den PEP (Produktentwicklungsprozess) neu denken!
Den PEP (Produktentwicklungsprozess) neu denken!Den PEP (Produktentwicklungsprozess) neu denken!
Den PEP (Produktentwicklungsprozess) neu denken!
 
Metrics we can gain from our (Kanban) system and what we can learn from ..
Metrics we can gain from our (Kanban) system and what we can learn from .. Metrics we can gain from our (Kanban) system and what we can learn from ..
Metrics we can gain from our (Kanban) system and what we can learn from ..
 
UX & AGILE vom SCRUM Stammtisch Graz
UX & AGILE vom SCRUM Stammtisch GrazUX & AGILE vom SCRUM Stammtisch Graz
UX & AGILE vom SCRUM Stammtisch Graz
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
 
Digital Labs & Hubs - ein Erfolgsrezept?
Digital Labs & Hubs - ein Erfolgsrezept?Digital Labs & Hubs - ein Erfolgsrezept?
Digital Labs & Hubs - ein Erfolgsrezept?
 
Schätzen heißt Lügen
Schätzen heißt LügenSchätzen heißt Lügen
Schätzen heißt Lügen
 
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas MödlOOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
 
Rails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenRails und Scrum in großen Projekten
Rails und Scrum in großen Projekten
 
Scrum checklist 2013
Scrum checklist 2013Scrum checklist 2013
Scrum checklist 2013
 
Roadmaps und Agile Reporting abseits von Velocity und Story Points (Agile Wed...
Roadmaps und Agile Reporting abseits von Velocity und Story Points (Agile Wed...Roadmaps und Agile Reporting abseits von Velocity und Story Points (Agile Wed...
Roadmaps und Agile Reporting abseits von Velocity und Story Points (Agile Wed...
 
Agile Methoden in Projekten
Agile Methoden in ProjektenAgile Methoden in Projekten
Agile Methoden in Projekten
 
OptaPlanner hilft bei verteilten Schulstandorten
OptaPlanner hilft bei verteilten SchulstandortenOptaPlanner hilft bei verteilten Schulstandorten
OptaPlanner hilft bei verteilten Schulstandorten
 

Mehr von Stefan ROOCK

Agile Organisation: What, When, How
Agile Organisation: What, When, HowAgile Organisation: What, When, How
Agile Organisation: What, When, HowStefan ROOCK
 
Hauptsache dem Team geht's gut? Setzen! Sechs!
Hauptsache dem Team geht's gut? Setzen! Sechs!Hauptsache dem Team geht's gut? Setzen! Sechs!
Hauptsache dem Team geht's gut? Setzen! Sechs!Stefan ROOCK
 
Agile Organisationen: eine Frage der Haltung
Agile Organisationen: eine Frage der HaltungAgile Organisationen: eine Frage der Haltung
Agile Organisationen: eine Frage der HaltungStefan ROOCK
 
ScALeD: Agile Skalierung jenseits von Skalierungsframeworks
ScALeD: Agile Skalierung jenseits von SkalierungsframeworksScALeD: Agile Skalierung jenseits von Skalierungsframeworks
ScALeD: Agile Skalierung jenseits von SkalierungsframeworksStefan ROOCK
 
Pecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolPecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolStefan ROOCK
 
Nein-Sagen für Product Owner
Nein-Sagen für Product OwnerNein-Sagen für Product Owner
Nein-Sagen für Product OwnerStefan ROOCK
 
Agile Organisationen: eine Frage des Leadership
Agile Organisationen: eine Frage des LeadershipAgile Organisationen: eine Frage des Leadership
Agile Organisationen: eine Frage des LeadershipStefan ROOCK
 
Roadmaps und Agile Reporting abseits von Velocity und Story Points
Roadmaps und Agile Reporting abseits von Velocity und Story PointsRoadmaps und Agile Reporting abseits von Velocity und Story Points
Roadmaps und Agile Reporting abseits von Velocity und Story PointsStefan ROOCK
 
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)Stefan ROOCK
 
Agile Verträge - Vertragsgestaltung für agile Softwareentwicklung
Agile Verträge - Vertragsgestaltung für agile SoftwareentwicklungAgile Verträge - Vertragsgestaltung für agile Softwareentwicklung
Agile Verträge - Vertragsgestaltung für agile SoftwareentwicklungStefan ROOCK
 
Warum die meisten Hackathons den Unternehmen nichts bringen
Warum die meisten Hackathons den Unternehmen nichts bringenWarum die meisten Hackathons den Unternehmen nichts bringen
Warum die meisten Hackathons den Unternehmen nichts bringenStefan ROOCK
 
MbO, OKR und Nordstern
MbO, OKR und NordsternMbO, OKR und Nordstern
MbO, OKR und NordsternStefan ROOCK
 
XP-Days-Kurzvortrag: ALIGNMENT UND VERBESSERUNG MIT DEM NORDSTERN-KONZEPT
XP-Days-Kurzvortrag: ALIGNMENT UND VERBESSERUNG MIT DEM NORDSTERN-KONZEPTXP-Days-Kurzvortrag: ALIGNMENT UND VERBESSERUNG MIT DEM NORDSTERN-KONZEPT
XP-Days-Kurzvortrag: ALIGNMENT UND VERBESSERUNG MIT DEM NORDSTERN-KONZEPTStefan ROOCK
 
Alignment und Verbesserung mit dem Nordstern-Konzept (Kurzvortrag)
Alignment und Verbesserung mit dem Nordstern-Konzept (Kurzvortrag)Alignment und Verbesserung mit dem Nordstern-Konzept (Kurzvortrag)
Alignment und Verbesserung mit dem Nordstern-Konzept (Kurzvortrag)Stefan ROOCK
 
UX und agile Entwicklung - eine Aufgabe für das ganze Team
UX und agile Entwicklung - eine Aufgabe für das ganze TeamUX und agile Entwicklung - eine Aufgabe für das ganze Team
UX und agile Entwicklung - eine Aufgabe für das ganze TeamStefan ROOCK
 
Alignment und Verbesserung mit dem Nordstern-Konzept
Alignment und Verbesserung mit dem Nordstern-KonzeptAlignment und Verbesserung mit dem Nordstern-Konzept
Alignment und Verbesserung mit dem Nordstern-KonzeptStefan ROOCK
 
InnoDays OTTO E-Commerce
InnoDays OTTO E-CommerceInnoDays OTTO E-Commerce
InnoDays OTTO E-CommerceStefan ROOCK
 
Agile Organisationen
Agile OrganisationenAgile Organisationen
Agile OrganisationenStefan ROOCK
 

Mehr von Stefan ROOCK (20)

Agile Organisation: What, When, How
Agile Organisation: What, When, HowAgile Organisation: What, When, How
Agile Organisation: What, When, How
 
Hauptsache dem Team geht's gut? Setzen! Sechs!
Hauptsache dem Team geht's gut? Setzen! Sechs!Hauptsache dem Team geht's gut? Setzen! Sechs!
Hauptsache dem Team geht's gut? Setzen! Sechs!
 
Agile Organisationen: eine Frage der Haltung
Agile Organisationen: eine Frage der HaltungAgile Organisationen: eine Frage der Haltung
Agile Organisationen: eine Frage der Haltung
 
Scrum in cool
Scrum in coolScrum in cool
Scrum in cool
 
ScALeD: Agile Skalierung jenseits von Skalierungsframeworks
ScALeD: Agile Skalierung jenseits von SkalierungsframeworksScALeD: Agile Skalierung jenseits von Skalierungsframeworks
ScALeD: Agile Skalierung jenseits von Skalierungsframeworks
 
Pecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolPecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in Cool
 
Nein-Sagen für Product Owner
Nein-Sagen für Product OwnerNein-Sagen für Product Owner
Nein-Sagen für Product Owner
 
Agile Organisationen: eine Frage des Leadership
Agile Organisationen: eine Frage des LeadershipAgile Organisationen: eine Frage des Leadership
Agile Organisationen: eine Frage des Leadership
 
Roadmaps und Agile Reporting abseits von Velocity und Story Points
Roadmaps und Agile Reporting abseits von Velocity und Story PointsRoadmaps und Agile Reporting abseits von Velocity und Story Points
Roadmaps und Agile Reporting abseits von Velocity und Story Points
 
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
Vertragsgestaltung für agile Softwareentwicklung (OOP 2018, München)
 
Metriken@agile
Metriken@agileMetriken@agile
Metriken@agile
 
Agile Verträge - Vertragsgestaltung für agile Softwareentwicklung
Agile Verträge - Vertragsgestaltung für agile SoftwareentwicklungAgile Verträge - Vertragsgestaltung für agile Softwareentwicklung
Agile Verträge - Vertragsgestaltung für agile Softwareentwicklung
 
Warum die meisten Hackathons den Unternehmen nichts bringen
Warum die meisten Hackathons den Unternehmen nichts bringenWarum die meisten Hackathons den Unternehmen nichts bringen
Warum die meisten Hackathons den Unternehmen nichts bringen
 
MbO, OKR und Nordstern
MbO, OKR und NordsternMbO, OKR und Nordstern
MbO, OKR und Nordstern
 
XP-Days-Kurzvortrag: ALIGNMENT UND VERBESSERUNG MIT DEM NORDSTERN-KONZEPT
XP-Days-Kurzvortrag: ALIGNMENT UND VERBESSERUNG MIT DEM NORDSTERN-KONZEPTXP-Days-Kurzvortrag: ALIGNMENT UND VERBESSERUNG MIT DEM NORDSTERN-KONZEPT
XP-Days-Kurzvortrag: ALIGNMENT UND VERBESSERUNG MIT DEM NORDSTERN-KONZEPT
 
Alignment und Verbesserung mit dem Nordstern-Konzept (Kurzvortrag)
Alignment und Verbesserung mit dem Nordstern-Konzept (Kurzvortrag)Alignment und Verbesserung mit dem Nordstern-Konzept (Kurzvortrag)
Alignment und Verbesserung mit dem Nordstern-Konzept (Kurzvortrag)
 
UX und agile Entwicklung - eine Aufgabe für das ganze Team
UX und agile Entwicklung - eine Aufgabe für das ganze TeamUX und agile Entwicklung - eine Aufgabe für das ganze Team
UX und agile Entwicklung - eine Aufgabe für das ganze Team
 
Alignment und Verbesserung mit dem Nordstern-Konzept
Alignment und Verbesserung mit dem Nordstern-KonzeptAlignment und Verbesserung mit dem Nordstern-Konzept
Alignment und Verbesserung mit dem Nordstern-Konzept
 
InnoDays OTTO E-Commerce
InnoDays OTTO E-CommerceInnoDays OTTO E-Commerce
InnoDays OTTO E-Commerce
 
Agile Organisationen
Agile OrganisationenAgile Organisationen
Agile Organisationen
 

Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)

  • 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
  • 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!
  • 10. Empirisches Management im Review Transparenz Inspektion Adaption Demo Produktinkrement Feedback, Wert?, ROI? Product Backlog anpassen
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 18. Scrum-Produktzyklus Sprint Planning Sprint Sprint Review
  • 19. Diskutiert: War u m b r a u c ht man Release plan ung? Wer braucht wann welche Infor mationen? Aufgabe 5 Minuten
  • 20. 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?
  • 21. Ö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“
  • 22. Ö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“
  • 23. Ö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“
  • 25. Releaseplanung Scope Scopebasierte Planung Ressourcen Zeit zeitbasierte Planung
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. Cumulative Flow Diagram (CFD) geplant konzipiert programmiert modul-getestet integrations-getestet (lieferbar)
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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!
  • 36. Stabilität Effizienz optimieren Instabilität Lernen maximieren Geschäfts-system Innovations-system
  • 37. 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
  • 38. Schätzgenauigkeit low high effort for estimation high precision of estimation low
  • 39. 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)
  • 40. •Varianzquellen verstehen (Workshop) •klassisches Risikomanagement •fähigen Scrum-Master integrieren •positive Varianzen nutzen Tipps zu Varianzquellen
  • 41. Trends Messen statt schätzen (Beyond Estimating), z.B. mit Lean Forecasting Inkrementelle Relaseplanung keine Releaseplanung (für bestimmte Kontexte)
  • 42. 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.
  • 43. Vielen Dank für die Aufmerksamkeit Agil auf allen Ebenen Stefan Roock stefan.roock@it-agile.de Twitter: @StefanRoock