coach.deagileAgenda
• Vorstellung
• Motivation
• Agile Team Coaching System im Überblick
• Agile Coaching Tools Compendium
• Agile Team Assessment Models
• Agile Coaching Cycle
coach.deagileSituation
Agile Coach Team+
was nun?
Bauchgefühl
zufällige Effekte=
coach.deagileProblem
Suche nach
„Best Practices“
Radical
Scrum The ULTIMATE A G I L E PRACTICES Guide
Wir wissen nicht, was
funktioniert!
coach.deagileWir wissen nicht, was funktioniert!
In wie vielen
Fällen helfen
uns Best
Practices?
coach.deagileWir wissen nicht, was funktioniert!
Wir halten
uns im
gesamten
System auf!
coach.deagileEmpirische Prozesskontrolle
Wie kann agiles Coaching systematisch durchgeführt
werden in einem komplexen, nicht planbaren Umfeld? ?
coach.deagileATCS in einem Satz
Das Agile Team Coaching System
ist eine strukturierte Methode,
um agile Teams systematisch zu coachen,
sowie messbare und nachvollziehbare
Ergebnisse im Coachingprozess zu erzielen.
coach.deagileATCS Bestandteile
Agile Team Assessment Models
Agile Coaching Tools Compendium
Agile Coaching Cycle
Agile Coaching Structure
coach.deagile
Team XYZ, 28.01.2014
Agile Coaching Structure
Roter Faden dieser Session: unser Arbeitsmittel
coach.deagileWas ist ein Coaching Tool?
• Hilft einem Team dabei, eine andere Perspektive einzunehmen, um anderes Verhalten zu erzeugen.
• „Agile Coaching“: zielgerichteter Einsatz von Werkzeugen, um das Team einem angestrebten (agilen) Zustand näher zu bringen
coach.deagileArten von Coaching Tools
• Training/Ausbildung - Vermittlung grundlegender Kenntnisse, Prinzipien und Theorien
• Beratung - konkrete Hinweise geben auf Praktiken und Methoden
• Mentoring - Rolle einnehmen und zeigen, „wie es geht“
• Coaching - Optionen und Perspektiven aufzeigen
coach.deagile
„Das Team hat immer viel zu viele Tasks parallel in Arbeit. Welches Coaching Tool nehmen wir denn jetzt?“
„Keine Ahnung, welche gibt es denn?“
coach.deagileAgile Coaching Structure
Team XYZ, 28.01.2014
Beobachtung: zu viele parallele Tasks in Arbeit, die sich über mehrere Tage nicht bewegen; nur Bruchteile der vorgenommenen Arbeit werden am Sprint-Ende geliefert (viel Halbfertiges)
Coaching-Tools: ?
coach.deagile
Prioritized Backlog Appreciation Sharing Wins The Leadership Gift Community of Practice Camps Limit WIP Lean Coffee Hot Topics Topic of the Day Brown Bag Sessions Book Circles Validated Learning Minimum Viable Product
„Limit WIP“, sagen vielleicht die Kanban-Vertreter
coach.deagile
Topic of the Day Brown Bag Sessions Book Circles Validated Learning Minimum Viable Product Lean Canvas Sit with the Team Team Split Mentoring Advising Training Education Marshmallow Challenge Kata
„Limit WIP“, sagen vielleicht die Kanban-Vertreter
„Team Split“, befürwortet eventuell die Scrum-Fraktion
coach.deagile
Mentoring Advising Training Education Marshmallow Challenge Kata Dojo Backlog Release Planning Meeting Pair Programming Backlog Grooming Story Splitting User Story Mapping User Stories
„Limit WIP“, sagen vielleicht die Kanban-Vertreter
„Team Split“, befürwortet eventuell die Scrum-Fraktion
„Pair Programming“, schlagen möglicherweise die XPler vor
coach.deagileAgile Coaching Structure
Team XYZ, 28.01.2014
Beobachtung: zu viele parallele Tasks in Arbeit, die sich über mehrere Tage nicht bewegen; nur Bruchteile der vorgenommenen Arbeit werden am Sprint-Ende geliefert (viel Halbfertiges)
Coaching-Tools: WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler)
coach.deagileAgile Coaching Structure
Team XYZ, 28.01.2014
Ziel: ?
Beobachtung: zu viele parallele Tasks in Arbeit, die sich über mehrere Tage nicht bewegen; nur Bruchteile der vorgenommenen Arbeit werden am Sprint-Ende geliefert (viel Halbfertiges)
Coaching-Tools: WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler)
coach.deagileZiele eines Assessments
+Zusta
nd
ermitte
ln
Lücke = Basis für weiteres Coaching
coach.deagileAgile Coaching Structure
Team XYZ, 28.01.2014
Ziel: ?
Beobachtung: zu viele parallele Tasks in Arbeit, die sich über mehrere Tage nicht bewegen; nur Bruchteile der vorgenommenen Arbeit werden am Sprint-Ende geliefert (viel Halbfertiges)
Hypothese: jeder Entwickler arbeitet in seinem ehemaligen Spezialgebiet, es gibt kaum Know-How-Transfer; Gesamtziel ist bei den Entwicklern nicht im Blick
Coaching-Tools: WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler)
coach.deagileAgile Coaching Structure
Team XYZ, 28.01.2014
Ziel: verlässliche Sprint-Ergebnisse
Beobachtung: zu viele parallele Tasks in Arbeit, die sich über mehrere Tage nicht bewegen; nur Bruchteile der vorgenommenen Arbeit werden am Sprint-Ende geliefert (viel Halbfertiges)
Hypothese: jeder Entwickler arbeitet in seinem ehemaligen Spezialgebiet, es gibt kaum Know-How-Transfer; Gesamtziel ist bei den Entwicklern nicht im Blick
Coaching-Tools: WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler)
coach.deagileSoziale/Team Assessments
•Tuckman Model
•5 Dysfunctions of a Team
•Drexler-Sibbet Model
• uvm...
coach.deagile
Phase
Zustand
Tuckman Model
Forming Storming Norming Performing
Orientation Dissatisfaction Integration Production
coach.deagile5 Dysfunctions of a Team
Absence of TRUST
Fear ofCONFLICT
Lack ofCOMMITMENT
Avoidance ofACCOUNTABILITY
Inattention toRESULTS
Invulnerability
Artificial Harmony
Ambiguity
Low Standards
Status & Ego
coach.deagileDrexler-Sibbet Team Performance ModelTM
• 7-stufiges Team-Entwicklungs-Modell
• Abdeckung aller Team-Phasen: Von individueller
Zugehörigkeit, über Vision und Arbeitsvereinbarungen bis zur
Auflösung
• darf hier aus Copyright-Gründen nicht gezeigt werden
‣Suche nach „Drexler-Sibbet Team Performance Model“
coach.deagileMethodische/Agile Assessments
•Scrum Checkliste von Henrik Kniberg
•Scrum Test von Ken Schwaber
•+15 Team
• uvm...
coach.deagileScrum Checkliste von Henrik Kniberg
Prozess wird kontinuierlich verbessert
Definition of Done (DoD) vorhanden
DoD erreichbar in jeder Iteration
Team berücksichtigt DoD
Die Quintessenz
Auslieferung lauffähiger, getesteterSoftware alle 4 Wochen (oder kürzer)
Auslieferung des am meisten benötigten Geschäftswertes
Demo wird nach jedem Sprint durchgeführt
Lauffähige, getestete Software wird gezeigtFeedback von Stakeholdern & PO wird aufgenommen
Retrospektive wird nach jedem Sprint durchgeführt
Resultiert in konkreten VerbesserungsvorschlägenEinige Vorschläge werden tatsächlich umgesetzt
Ganzes Team + PO nehmen teil
Team hat einen Sprint Backlog
Hochgradig sichtbar
Täglich aktualisiert
Gehört ausschließlich dem Team
Sprint Planning Meetings werden durchgeführt
PO nimmt teil
Ganzes Team nimmt teil
Resultiert in einem Sprint Plan
Ganzes Team glaubt, dass der Plan erreichbar ist
PO ist mit Prioritäten zufrieden
PO liefert aktuelle PBL
Iterationslänge 4 Wochen oder kürzer
Immer pünktlich beendet
Team von außen nicht gestört oder kontrolliert
Iterationen sind timeboxed
PO hat ein Product Backlog (PBL)
Oberste Einträge sind nach Geschäftswert priorisiert
Oberste Einträge sind geschätzt
PO versteht den Zweck aller Backlog Einträge
Oberste Einträge klein genug, um in einen Sprint zu passen
Schätzungen wurden vom Team erstellt
Klar definierter Product Owner (PO)
PO ist ermächtigt, zu priorisierenPO hat das Wissen, zu priorisierenPO hat direkten Kontakt mit dem TeamPO hat direkten Kontakt mit StakeholdernPO spricht mit einer Stimme (falls PO ein Team ist)
Team-Mitglieder sitzen zusammen
Ist dies erreicht, kann der Rest der Checkliste ignoriert werden.
Zentrale Scrum-Elemente. Ohne diese sollte es nicht Scrum genannt werden.
Kernelemente von Scrum
PO hat eine Product Vision im Einklang mit dem PBLPBL und Product Vision sind hochgradig sichtbar
Jeder im Team nimmt an Schätzungen teil
PO verfügbar, wenn das Team schätzt
Team-Mitglieder haben keine festgelegten Rollen
Team hat alle Fähigkeiten, um Backlog Einträge ’Done’ zu bekommen
Team hat einen Scrum Master (SM)
Ganzes Team kennt oberste 1-3 Hindernisse
SM hat Strategie, wie oberstes Hindernis behoben werden kannSM fokussiert das Entfernen von HindernissenEskalation zum Management falls Team nicht beseitigen kann
Velocity wird gemessen
Velocity beinhaltet nur Einträge mit Status ’Done’
PO nutzt Velocity zur Release Planung
Team hat einen Sprint Burndown Chart
PBL Einträge werden in Tasks runtergebrochen in einem Sprint
Schätzungen laufender Tasks werden täglich aktualisiert
Hochgradig sichtbar
Täglich aktualisiert
PO nimmt teil (wenigstens ein paar mal pro Woche)
Alle Einträge im Sprint Plan haben eine Schätzung
SM sitzt beim Team
Daily Scrum findet jeden Tag zur gleichen Zeit am gleichen Ort statt
Sprint Tasks sind geschätzt
Relative Größe (Story Points) statt Zeit wird geschätzt
Maximal 15 Minuten
Jedes Team-Mitglied weiß, was an was anderen arbeiten
Das meiste hiervon wird normalerweise benötigt, aber nicht immer alles. Ausprobieren!Empfohlen aber nicht immer notwendig
Daily Scrum wird durchgeführt
Ganzes Team nimmt teil
Probleme & Hindernisse kommen zum Vorschein
Chief Product Owner vorhanden (falls viele POs)Abhängige Teams führen Scrum of Scrums durchAbhängige Teams integrieren in jedem Sprint
Skalierung
Spaß haben! Hohes Energie-Level.
Überstunden sind selten und werden freiwillig geleistetDiskutieren, kritisieren und experimentieren mit dem Prozess
Positive Hinweise
Scrum Checkliste
http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)
die inoffizielle
Henrik Kniberg
PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done
Team liefert normalerweise das, was es zugesagt hat
Wesentliche Hinweise einer guten Scrum-Implementierung.
Fundamental wichtig für jede Scrum-Skalierung.
Maximal 9 Personen pro Team
Zum Scheitern verurteilte Iterationen werden frühzeitig abgebrochen
Ger
man
tran
slat
ion
by M
arc
Bles
s –
http
://m
arcb
less
.blo
gspo
t.com
coach.deagileScrum Test von Ken Schwaber
http://www.xpdays.de/twiki/pub/XPDays2011/JustWhenYouThoughtYouKnewScrum/XP_Day.pdf
Using$KPIs$provides$a$high6level$proxy$of$actual$value$delivered$by$soUware$products$
November$17,$2011$ Copyright$Scrum.org$2011$ Slide$25$
InnovaRon$Rate$
Strategic$Alignment$Index$
On6Product$Index$
Product$Availability$ Usage$Index$
Installed$Version$Index$
29%$ 50%$ 80%$ 99%$ 35%$ 70%$
$1$
$$0.29$$
$$0.15$$ $$0.13$$ $$0.13$$$$0.05$$ $$0.03$$
Source:$Forrester$and$Advanced$Development$Methods$
coach.deagile+15 Team+15TEAMThe development team has 7+/-2 people and is cross-functional, with all the skills necessary to deliver a story inside a sprint
There is a product vision, expressed as an elevator pitch, and a list of SMART requirements prioritized by business value
There is a product backlog with enough stories to fill 1-2 sprints, that all meet the Definition of Ready
The team and PO meet regularly to groom stories. Everyone in the development team estimates stories before committing to them
The Definition of Done has been agreed between the PO and development team, and consists of a checklist of up to 10 points
Preparing a Backlog
The team takes from the top of the backlog at least 6-10 stories of about the same size into every 1-2 week sprint
During the sprint, the team works on at most 2-3 stories at any one time until the story is done
Stories are broken down into tasks that are small enough to be completed in 1-2 days, tracked on the team's task board
The team meets every day around the task board, for a short (max 15 min) standup to plan the day's activities
There is an impediment backlog managed by the ScrumMaster. Impediments are quickly resolved by the team or the ScrumMaster
Sprint Behaviors
There is a sprint burndown that uses estimation points and is updated daily. Points only burn down when stories are done
The team is continuously improving quality and the process, using the Active Learning Cycle during the retrospective
The team delivers on its commitment with at least 90% predictability (ratio of accepted to committed estimation points)
At the end of every sprint the team delivers a potentially shippable product, that can be released or used internally
Shared code ownership is actively pursued by the team, for example, by pairing or trending the bug count to zero
Delivering a Shippable Product
Copyright 2007-2013 - agile42 LLChttp://de.slideshare.net/davesharrock/giving-teams-the-roots-to-grow-and-wings-to-fly
coach.deagileEigene Assessments
• Bauen Sie sich für jedes Team ein eigenes Assessment anhand der aktuellen Ziele
• Bewertung der erwarteten Werte, Praktiken, Verhaltensweisen, etc.
Ask the Team: • Retrospektive als wertvolles Selbst-Assessment des Teams
nutzen
coach.deagileAgile Coaching Structure
Team XYZ, 28.01.2014
Ziel: verlässliche Sprint-Ergebnisse
Indikator: (1) geblockte Tasks werden innerhalb eines Tages entblockt; (2) Team diskutiert über entstehende Engpässe; (3) Team koordiniert täglich die offenen Aufgaben
Beobachtung: zu viele parallele Tasks in Arbeit, die sich über mehrere Tage nicht bewegen; nur Bruchteile der vorgenommenen Arbeit werden am Sprint-Ende geliefert (viel Halbfertiges)
Coaching-Tools: WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler)
coach.deagileAgile Coaching Structure
Team XYZ, 28.01.2014
Ziel: verlässliche Sprint-Ergebnisse
Indikator: (1) geblockte Tasks werden innerhalb eines Tages entblockt; (2) Team diskutiert über entstehende Engpässe; (3) Team koordiniert täglich die offenen Aufgaben
Beobachtung: zu viele parallele Tasks in Arbeit, die sich über mehrere Tage nicht bewegen; nur Bruchteile der vorgenommenen Arbeit werden am Sprint-Ende geliefert (viel Halbfertiges)
Hypothese: jeder Entwickler arbeitet in seinem ehemaligen Spezialgebiet, es gibt kaum Know-How-Transfer; Gesamtziel ist bei den Entwicklern nicht im Blick
Coaching-Tools: (1) WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler); (2) im Review nur auf fertige Ergebnisse fokussieren; (3) im Daily-Scrum ein Thumb-Voting zur Zuversichtlichkeit des Teams durchführen; (4) paralleles Entwickeln, Testen und Integration von Anfang an im Planning berücksichtigen
coach.deagile
Agile Coaching Cycle
coach.deagileAgile Coaching Cycle
PLANIntend
DOApply
CHECKInspect
ACTAdapt
Ziele und Coaching Tools festlegen
Coaching Structure anwenden
Zustand identifizieren
Ziele anpassen
coach.deagileAgile Coaching Structure
Team XYZ, 28.01.2014
Ziel: verlässliche Sprint-Ergebnisse
Indikator: (1) geblockte Tasks werden innerhalb eines Tages entblockt; (2) Team diskutiert über entstehende Engpässe; (3) Team koordiniert täglich die offenen Aufgaben
Coaching-Tools: (1) WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler); (2) im Review nur auf fertige Ergebnisse fokussieren; (3) im Daily-Scrum ein Thumb-Voting zur Zuversichtlichkeit des Teams durchführen; (4) paralleles Entwickeln, Testen und Integration von Anfang an im Planning berücksichtigen
PLANIntend
DOApply
coach.deagileAgile Coaching Structure
Team XYZ, 04.02.2014
Ziel: verlässliche Sprint-Ergebnisse
Indikator: (1) geblockte Tasks werden innerhalb eines Tages entblockt; (2) Team diskutiert über entstehende Engpässe; (3) Team koordiniert täglich die offenen Aufgaben
Coaching-Tools: (1) WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler); (4) paralleles Entwickeln, Testen und Integration von Anfang an im Planning berücksichtigen
CHECKInspect
coach.deagileAgile Coaching Structure
Team XYZ, 04.02.2014
Ziel: verlässliche Sprint-Ergebnisse
Indikator: (1) geblockte Tasks werden innerhalb eines Tages entblockt; (2) Team diskutiert über entstehende Engpässe; (3) Team koordiniert täglich die offenen Aufgaben
Coaching-Tools: (1) WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler); (4) paralleles Entwickeln, Testen und Integration von Anfang an im Planning berücksichtigen
Beobachtung: geblockte Tasks bleiben länger als einen Tag geblockt
CHECKInspect
coach.deagileAgile Coaching Structure
Team XYZ, 04.02.2014
Ziel: verlässliche Sprint-Ergebnisse
Indikator: (1) geblockte Tasks werden innerhalb eines Tages entblockt; (2) Team diskutiert über entstehende Engpässe; (3) Team koordiniert täglich die offenen Aufgaben
Coaching-Tools: (1) WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler); (4) paralleles Entwickeln, Testen und Integration von Anfang an im Planning berücksichtigen
Beobachtung: geblockte Tasks bleiben länger als einen Tag geblockt
PLANIntend
DOApply
CHECKInspect
ACTAdapt
Ziele und Coaching Tools festlegen
Coaching Structure anwenden
Zustand identifizieren
Ziele anpassen
coach.deagile
Ende. Fragen?
coach.deagilecoach.deagile
Marc Bless [email protected]