Kaizen, deel 4: continu verbeteren met kaizenteams.pptx
Scrum voor Dummies by kenan ilgor
1.
2. GEEN GARANTIE VOOR SUCCES!
Maar wel garantie om alle issues & risico’s zsm te
identificeren
Falen met Scrum gaat beter dan met traditionele methoden.
Zonder verrassingen aan het eind van het project
Scrum invoeren is verandermanagement/risicomanagement
5. 3 ROLLEN
Product Owner
Development Team
Scrum Master
6. PRODUCT OWNER 1/3
Eigenaar van de business case/probleem en verantwoordelijk voor 1 product
Vertegenwoordigt de stakeholders/business en hakt knopen door
Verantwoordelijk voor wat, binnen budget, deadline
Legt over met partners, marketing, etc.
Geen bottleneck! Moet 100% beschikbaar zijn
Backlog Management
Backlog is een communicatiemiddel en is openbaar
Prioriteren van de items met hoogste waarde & relatief de laagste kosten.
Quickwins!
Zorgen voor een schatting inspanning door het Development Team
7. PRODUCT OWNER 2/3
Stakeholder Management
Bepalen van alle stakeholders mbv een brainstorm sessie. Denk aan
architecten, wetgeving, sales, beheer etc.
Inplannen van meetings; Sprint Planning en Sprint Review (demo)
Zorgen dat ze naar de Daily Scrum komen
Development Team
Inplannen van vaste momenten voor meetings/werkafspraken
Gebruiken van technieken bij schattingen inspanning. Bijv. Planning
Poker
Zorgen voor een eenduidige interpretatie en goedkoopste
implementatie
8. PRODUCT OWNER 3/3
Release Management
Zorgen voor een korte releaseperiode met minimale mogelijke set
van eisen
MMF: Minimal Marketable Features
MVP: Minimal Viable Product
Stellen van mijlpalen
Voortdurend uitleggen van waarom je product/visie
Laat je stakeholders aan het woord tijdens Sprint Planning meetings
Zorgen voor een nauwe samenwerking met de Scrum Master
Zsm een versie op de Acceptatieomgeving krijgen
9. DEVELOPMENT TEAM
Multidisciplinair, 5-9 personen en tijdelijke inhuur is mogelijk
Vaste teams
Werken met “story points” ipv echte tijd
Doen alles van A tot Z
Bepalen hoe/wie gaat het doen
Afgeven van schattingen
Autonoom/zelfsturend
10. SCRUM MASTER
Zorgen dat Scrum goed wordt toegepast
Team kennis laten maken met Scrum (bv. mbv XP Game)
Proactief en faciliterend voor het Development Team & Product Owner
Helpen met Daily Scrum (stand-up) en formuleren van eisen
Wegnemen van belemmeringen, ook bv. trage internet, geen ruimte etc.
5 Scrum Principes
Toewijding: iedereen neemt zijn verantwoordelijkheid
Focus: werken aan 1 product, 1 sprint, 1 item tegelijk in 1 team
Openheid: Transparantie
Respect: Respect voor ervaring/achtergrond en toon interesse
Moed: Beetje lef kan geen kwaad bij verbeteringen/veranderingen
11. 2 LIJSTEN
Product Backlog (input voor Sprint Backlog)
Release Burndown Chart (input voor Sprint Burndown Chart)
Sprint-lijsten worden bijgehouden door het Development Team!
12. PRODUCT BACKLOG 1/6
Product Owner is de eigenaar
Lijst van alle taken (eisen & wensen) om het product te kunnen
maken
Dynamische lijst met prioriteiten en schattingen
Bestaat uit “Product Backlog items” = user story (functionele eis)
“wat” wordt beschreven en niet “hoe”
Communicatiemiddel
Product Backlog bestaat uit:
Wensen (features)
Eisen (qualities)
Problemen (bugs, issues)
13. PRODUCT BACKLOG 2/6
Prioriteren
Gebruik echte sortering! Geen MoSCoW met allemaal must-have’s
Houd je lijst kort. Cluster de zaken die bij elkaar horen samen met
alle stakeholders (mbv “Silent Clustering”)
Waarde voor business bepaalt de volgorde
Een redelijk project heeft max. 80 items
Bij onduidelijke items vraag 5x waarom?
User story: “Als een (rol) wil ik (wens/feature) zodat
(voordeel/benefit)”
Begin met de benefits en acceptatiecriteria bij een user story
14. PRODUCT BACKLOG 3/6
Inschatten
De hele Backlog moet worden ingeschat in story points (bv. mbv
Planning Poker / Wideband Delphi)
Je schat niet alleen je eigen werk maar van het hele team
Bepaal waarde van een “story point” in dagen.
Bijv. Story point = 1,5 mandag. In 1 week met 4 personen heb je 20
mandagen dus 20x1,5= 35 story point. Als per week 35 punten
gehaald kan worden, is dat de velocity (snelheid) van het team
http://www.scrum-institute.org/Effort_Estimations_Planning_Poker.php
15. PRODUCT BACKLOG 4/6
Product Backlog Refinement
Initiële schattingen en nieuwe stories behandelen
Splitsen naar nieuwe onderdelen en oude weggooien ivm minder
ballast en archief
Spike: een beperkte hoeveelheid tijd om een probleem te begrijpen.
Deze tijd wordt niet meegeteld voor de velocity
Inplannen direct na Daily Scrums of vaste tijdstippen
16. PRODUCT BACKLOG 5/6
Sprint Backlog
Deze lijst wordt tijdens de Sprint Planning gemaakt
Bovenste items of items die een thema vormen worden gekozen
Aantal items worden bepaald adhv de velocity. Gebaseerd op de
behaalde resultaten van de laatste sprint. Update de nieuwe sprint
met bezetting (vakantie, ziekte, training)
Items worden vertaald naar taken die het “hoe” beschrijven
Werkverdeling en voortgang wordt bewaakt: To Do, Doing, Done
Team kan onderling indicatie geven in punten of uren
Voor rapportages maak foto van het bord ipv Excel
17. PRODUCT BACKLOG 6/6
Definition of Done
Opgesteld door Product Owner en het Development Team
Eisen die altijd gelden bijv. Documentatie bijwerken, Functionele test,
Performance test, Code review, Gebruikersacceptatietest
Hang de Definition of Done naast de Sprint Backlog
Performancetest tools: JUnit, NUnit, FitNesse, Cucumber, JMeter
Testen in sprint 6 betekent, testen 1 t/m 6
19. BURNDOWNS
Product Owner is de eigenaar
Bijhouden van voortgang
Voortgangsrapportage = MBWA (Management By Walking
Around – Genchi Genbutsu)
Release Burndown is voor het bewaken van de voortgang
Sprint Burndown is voor het bewaken van de voortgang
binnen een sprint
23. SPRINT PLANNING I – WAT?
Scope bepalen met de stakeholders (vaak het bovenste gedeelte
Backlog)
Velocity is de hoeveelheid werk voor een sprint
Wel ruimte overlaten voor items die wegvallen/erbij komen bij de 2e
meeting
24. SPRINT PLANNING II – HOE?
Implementatie/oplossing bepalen
Werkverdeling
Analyse/uitzoekwerk krijgt geen punten (spike)
Een story valt vaak uiteen in 5 delen. Kleine taken van 2-4 uur zijn
ideaal om te managen
Indien nodig kunnen de taken in uren geschat worden
Team spreekt haar commitment uit aan de Product Owner
25. DAILY SCRUM (STAND-UP)
Openbaar, staand, cirkelvorm, dichtbij Scrum Bord, max. 15 minuten
Wat heb je sinds de vorige Daily Scrum gedaan?
Wat ga je vandaag doen?
Zijn er belemmeringen?
Invulling van de dag aangeven, geen voortgangsrapportage of
verantwoording maar synchroniseren!
Weet wat je gisteren gedaan hebt
Het Scrum bord wordt door het team bijgewerkt, dus niet alleen door
de Scrum Master
Er is geen voorzitter. Team moet onderling vergaderen
26. VOORBEELD SCRUM BORD
Scrum Bord wordt vaak ingedeeld in 3 blokken:
Sprint Backlog, Sprint Burndown en Definition of Done (DoD)
27. SPRINT REVIEW (DEMO)
Einde van de sprint
Demo aan de stakeholders (gebruikers/business). Interactief houden en liever een
stakeholder achter de PC zetten
Probeer tijdens de demo’s 1 PC en 1 omgeving te gebruiken
Zoveel mogelijk feedback krijgen van de Product Owner en de stakeholders
Sprinten verbeteren
Team moet bereid zijn om elk moment in de sprint een demo te kunnen geven,
namelijk van de “done” items op de testomgeving
Geen resultaten laten zien van de niet “done” items
Niet verdedigen maar parkeren! Bespreek het offline
Acties bepalen o.a. wel/niet naar productie gaan, extra Refinement sessie nodig
Bug Het werkt niet / Change Het werkt wel, alleen anders
28. SPRINT RETROSPECTIVE (RETRO)
Lessons Learned
Continu verbeteren. Efficiëntie is leuk maar effectiviteit veel beter!
Actielijst bespreken (vorige retro’s) en nieuwe acties bepalen
RETRO (Agile Retrospectives)
Setting the Stage
Gather Data
Generate Insights
Decide What to Do
Ook handig in 2 delen vergaderen. Met en zonder de Product Owner
Retro technieken zijn handig. Bijv. Mad, Glad, Sad mbv Post-Its op het bord
Goede dingen ook bespreken en mensen bedanken!
30. WAAROM SCRUM? 1/2
Meer waar voor je geld
duidelijk items, sneller oplevering, belangrijkste punten eerder oppakken
Meer controle
snellere feedback
Tevreden gebruikers
dmv Sprint Reviews mening/feedback krijgen
Hogere kwaliteit
ivm iteraties vaker verbeteren
Business case validatie
na een paar weken weet je of het product haalbaar is tov alleen papierwerk
Meer aansluiting bij opdrachtgever
geen afstand tussen opdrachtnemen er klant
31. WAAROM SCRUM? 2/2
Minder bureaucratie
focus en transparantie
Schalen van kleine organisaties
ideaal voor organisaties zonder processen
lef, focus, autonomie
Kennisdeling
door samenwerking met verschillende disciplines
het leren op je specifieke vakkennis wordt minder, aparte kennissessies zijn
erg relevant
Meer lol
autonomie, passie & vakmanschap.
samenwerken met teamleden en klanten
32. AGILE MANIFESTO
Mensen en onderlinge interactie boven processen & tools
Werkende software boven complete documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven volgen van een plan
33. LETS SCRUM…!
Meer informatie:
Scrum voor Dummies – Michael Franken
https://www.scrum.org/Scrum-Guide
http://www.scrum-institute.org/index.php