Marc Bless - ATCS: Agile Team Coaching System - OOP 2014 (agilecoach.de)

coach.deagile

Das Agile Team Coaching System

Marc Bless

OOP 2014

http://www.agilecoach.de

coach.deagileAgenda

• Vorstellung

• Motivation

• Agile Team Coaching System im Überblick

• Agile Coaching Tools Compendium

• Agile Team Assessment Models

• Agile Coaching Cycle


coach.deagile

Vorstellung

Wer ist dieser Mann dort vorne?


coach.deagile

Motivation


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.deagile

Agile Team Coaching System

im Überblick


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.deagile

Agile Coaching Tools Compendium


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


„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


„Team Split“, befürwortet eventuell die Scrum-Fraktion

„Pair Programming“, schlagen möglicherweise die XPler vor



Team XYZ, 28.01.2014


Coaching-Tools: WIP-Limit auf jeweils oberste zwei Stories und maximal 4 Tasks setzen (Team hat 5 Entwickler)


coach.deagile

Agile Team Assessment Models


coach.deagileZiele eines Teams

Welches Ziel hat ein agiles Team überhaupt?



Team XYZ, 28.01.2014

Ziel: ?




coach.deagileZiele eines Assessments

+Zusta

nd

ermitte

ln

Lücke = Basis für weiteres Coaching



Team XYZ, 28.01.2014

Ziel: ?


Hypothese: jeder Entwickler arbeitet in seinem ehemaligen Spezialgebiet, es gibt kaum Know-How-Transfer; Gesamtziel ist bei den Entwicklern nicht im Blick




Team XYZ, 28.01.2014

Ziel: verlässliche Sprint-Ergebnisse





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


Team XYZ, 28.01.2014


Indikator: (1) geblockte Tasks werden innerhalb eines Tages entblockt; (2) Team diskutiert über entstehende Engpässe; (3) Team koordiniert täglich die offenen Aufgaben




Team XYZ, 28.01.2014





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


Team XYZ, 28.01.2014



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


Team XYZ, 04.02.2014



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


Team XYZ, 04.02.2014




Beobachtung: geblockte Tasks bleiben länger als einen Tag geblockt

CHECKInspect


Team XYZ, 04.02.2014




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]

Marc Bless - ATCS: Agile Team Coaching System - OOP 2014 (agilecoach.de)

Business

Transcript of Marc Bless - ATCS: Agile Team Coaching System - OOP 2014 (agilecoach.de)