Agile Delivery Flow: Lever altid til tiden i 3 trin
Hvis man spørger de fleste ledere om “psykologisk sikkerhed” eller “vision” (mere om det: Psykologisk sikkerhed) i deres agile softwareudviklingsteams, er de enige om, at disse ting er vigtige, men… Hvis kunden signalerer, at det haster, eller deadline nærmer sig, bliver alle disse “blødere” variabler typisk nedprioriteret. Lederne er primært interesserede i et forudsigeligt fungerende agilt delivery flow i deres agile team.
Hvis du tager et kig på vores Echometer-blog (til vores blog) har kigget rundt, ved du, at vores indhold er mere fokuseret på at forbedre teams og organisationers “bløde færdigheder”. Disse undervurderes ofte af beslutningstagere. Men ikke af Scrum Masters og Agile Coaches.
Hvad Scrum Masters og Agile Coaches efter min mening til gengæld undervurderer, er at fokusere på at forbedre delivery flowet - dybest set det, som ledere ønsker. I dagens indlæg beskriver jeg en simpel teknik til markant at øge sandsynligheden for at levere til tiden og inden for budgettet igen og igen.
Første skridt i forhold til dit Agile-leveringsflow
Jeg taler om at overvåge Agile-leveringsflowet af dine opgaver. Hvis du gør bare et par ting rigtigt, vil du kunne levere meget mere forudsigelige resultater. Selv dine spredningsdiagrammer for cyklustid eller din Monte Carlo-simulering til beregning af projektestimater kan endelig indikere gyldige forudsigelser i stedet for at være helt ved siden af (læs mere: 9 Agile Metrikker til beslutningstagere).
Det første symptom, der skal bekæmpes, er, at der er opgaver, der kun tager et par dage fra “Scheduled” til “Completed”, og så er der opgaver, der tager mere end en måned. For at modvirke dette bør du sørge for, at en opgave altid indeholder den mindst mulige leverbare version af den ønskede funktion. Uden klokker og fløjter, som ikke er nødvendige for kundens kerneanmodning. Dybest set en MVT, Minimum Viable Task. Det betyder ikke, at det gør alle opgaver små. Men det bør hjælpe dig med at nå et stadie, hvor opgaverne højst tager et par uger i stedet for måneder.
Andet trin i forhold til dit Agile Delivery Flow: WIP i stedet for Velocity
Mange Scrum Masters eller Kanban Coaches mener, at det for en valid måling af Velocity osv. er vigtigt med “right sizing” af Tasks eller Workitems, hvor alle Workitems er omtrent lige store. Kun da er Story Points (som er nødvendige for at måle Velocity) brugbare til at måle Velocity, fordi de ligner en sammenlignelig tidsenhed.
Men det er forkert: Opgaverne behøver ikke engang at være af samme størrelse. Det bør du ikke antage, for det er simpelthen for svært at kontrollere Story Point-estimater. Det eneste, du kan kontrollere, er, hvor mange nye opgaver du starter.
Så gør følgende for at blive forudsigelig: Overvåg raten af “nybegyndte opgaver” sammenlignet med raten af “afsluttede opgaver”. Disse to bør være i balance. Med andre ord: “Indgangs-” og “udgangsraten” for Tasks bør være så tæt på hinanden som muligt, ideelt set endda stemme overens.
Et eksempel: Typisk adfærd i softwareudviklingsteams er, at så snart en opgave er blokeret, startes et nyt arbejdsemne. Det fører til, at mange opgaver er åbne, men uafsluttede, hvilket gør det meget mere kompliceret at fjerne blokeringen af dem alle igen.
Hvis du i stedet sørger for, at der for hver påbegyndt Task også er en afsluttet Task, vil det i Daily være lettere at fjerne blokeringer for de få fokuserede opgaver. Jeres præstation vil generelt være mere beregnelig - og teamet vil være mere tilfreds, fordi jeres leder og jeres kunder er mere tilfredse.
Nogle “positive symptomer” på et sundt agilt Agile Delivery Flow
I praksis vil det føre til følgende adfærd:
- Vi påbegynder ikke nye opgaver, når der stadig er mange ting i gang.
- Vi fokuserer på at afslutte det, vi har påbegyndt, før vi begynder på noget nyt.
- Opgaverne bliver aldrig ældre end et par uger.
- Hvis der ikke er nogen god grund, arbejder vi altid på den ældste opgave.
WIP-grænser (work-in-progress) hjælper også med dette, selvom de ofte ikke er nok. Når teamet først har lært at fokusere på at afslutte opgaver i stedet for bare at starte nye, vil I være bedre end de fleste teams.
Hvis du bruger Agile Delivery Flow korrekt
At skabe klare forventninger: På denne måde kan du stadig ikke kontrollere, om en opgave tager to eller tre dage. Men i det mindste sørger du for, at dit team ikke arbejder på så mange opgaver, at 2-3 dages opgaver ender med at tage en måned.
Hvor meget bedre ville dit team ikke have det, hvis I vidste, at stort set alle leveringsforpligtelser ville blive opfyldt inden for et par uger? Det forudsætter selvfølgelig, at du implementerer alle de ting, der er nævnt ovenfor: Indstilling af MVT’er, en streng WIP-grænse og en forpligtelse til ikke at genstarte opgaver, før en anden opgave er afsluttet.
Trin 3: Kom i gang med at forbedre Agile-leveringsflowet
I teorien ved du, hvad du skal gøre. Hvordan kommer man nu bedst i gang i praksis? Ved at skabe bevidsthed og “ændringsvillighed” i teamet. I bedste fald gennem selvrefleksion.
Du er nødt til at være transparent omkring disse tal og tjekke dem regelmæssigt for at se, om forholdet mellem påbegyndte og afsluttede opgaver er i balance. Det kan være en del af dit retrospektive arbejde at gå lidt dybere og reflektere over, hvorfor tallene ikke var i balance i den sidste cyklus.
Jeg kan anbefale at diskutere den adfærd, jeg nævnte, med vores agile retrospektive værktøj Echometer i din retrospektive (læs mere: 7 Retrospektive værktøjer i sammenligning). Du kan endda gøre det til en del af jeres arbejdsaftaler eller regelmæssige Health Check’er for at øge bevidstheden ved at stille spørgsmålene regelmæssigt.
De følgende spørgsmål er vores retrospektive skabelon til “agile Delivery” (mere om det: 26 sjove skabeloner til agile retrospektiver). Vi starter med et par Health Check-udsagn og spørger teamet, om de er enige eller uenige. Derefter er der et par åbne spørgsmål:
Agile Levering Retrospektiv
Agile Delivery Flow-retrospektiv: Sådan forløber retroen
Random Icebreaker (2-5 minutter)
Echometer stiller en generator til rådighed med tilfældige check-in-spørgsmål.
Gennemgang af åbne tiltag (2-5 minutter)
Før man går i gang med nye emner, bør man tale om effektivitetskontrol for at se, hvad der er blevet af tiltagene fra tidligere retrospektiver. Echometer viser automatisk alle åbne Action Items fra tidligere retros.
Health Check
Alle teammedlemmer kan besvare Health-Checks anonymt på en skala. Gennemgå derefter resultaterne af Health-Checks sammen og fasthold evt. yderligere kommentarer. Hvis I bruger de samme Health-Checks i flere retrospektiver, kan I også tracke trends over tid i Echometer.
- Vi gør tingene meget hurtigt. Ingen ventetid, ingen forsinkelser.
- Vi kan estimere præcis, hvad vi kan levere i en given cyklus.
- Vores sprintresultater kræver ikke nogen omarbejdning efter sprintet for at blive leveret.
- Vi begrænser vores "igangværende arbejde" for hele tiden at være fokuserede.
Diskuter retro-emner
Brug de følgende åbne spørgsmål til at samle jeres vigtigste indsigter. Først skjult for hver især. Echometer gør det muligt at afsløre hver kolonne på retro-boardet enkeltvis for derefter at præsentere og gruppere feedbacken.
- Hvornår fungerede vores måde at arbejde på virkelig godt?
- Hvad er det største potentiale for forbedring, så arbejdspakkerne kommer hurtigere igennem vores processer (fjerne ventetider, forbedre processer)?
- Hvad var de seneste eksempler på et inkrement, der ikke fungerede/blev leveret ved slutningen af sprinten?
- Hvornår førte vores arbejdsmetode til et suboptimalt arbejdsflow (f.eks. på grund af uklare, uhensigtsmæssige eller ikke fulgte retningslinjer)?
Catch-all spørgsmål (Anbefalet)
For at andre emner også får en plads:
- Hvad vil du ellers gerne tale om i retroen?
Prioritering / Afstemning (5 minutter)
På retro-boardet i Echometer kan I nemt prioritere feedbacken med afstemningsfunktionen. Afstemningen er naturligvis anonym.
Definer tiltag (10-20 minutter)
Via plus-symbolet ved en feedback kan man oprette et linket tiltag. Er du ikke sikker på, hvilket tiltag der er det rigtige? Så åbn i stedet et whiteboard om emnet via plus-symbolet for at brainstorme kerneårsager og mulige tiltag.
Checkout / Afslutning (5 minutter)
Echometer gør det muligt at indsamle anonym feedback fra teamet om, hvor hjælpsom retroen var. Dette resulterer i en ROTI-score ("Return On Time Invested"), som I kan tracke over tid.
Agile Delivery Flow-retrospektiv
Health Check spørgsmål (skala)
Åbne spørgsmål
Som du kan forestille dig, indebærer det sidste punkt i Health Check (kontrol af årsagen) allerede en potentiel foranstaltning, noget du kan prøve i en til to agile sprints for at se, om det kan hjælpe jer: Begrænsning af antallet af Tasks med statussen “Work in Progress”.
At lægge fundamentet: Etabler aftaler for teamwork
Har du en fornemmelse af, at dit team endnu ikke er klar til denne form for refleksion? I så fald bør du først reflektere over “godt arbejde” generelt og derefter fastlægge nogle grundregler, såkaldte arbejdsaftaler eller Working Agreements. Følgende workshop-skabelon kan hjælpe jer med det. Du kan gennemføre den som en særlig form for retrospektive i starten af et projekt eller som en ekstra workshop.
Først bør du få en fornemmelse af, hvor enige dit team implicit føler sig - se Health Check Item for det. Derefter bør du kontrollere dette praktisk med et par åbne spørgsmål. Hvert teammedlem skal afslutte sætningen (se flere spørgsmål) med så mange svar som muligt, som han/hun kan komme i tanke om:
Teamforpligtelser i tilbageblik
Teamforpligtelser i tilbageblik: Sådan forløber retroen
Random Icebreaker (2-5 minutter)
Echometer stiller en generator til rådighed med tilfældige check-in-spørgsmål.
Gennemgang af åbne tiltag (2-5 minutter)
Før man går i gang med nye emner, bør man tale om effektivitetskontrol for at se, hvad der er blevet af tiltagene fra tidligere retrospektiver. Echometer viser automatisk alle åbne Action Items fra tidligere retros.
Health Check
Alle teammedlemmer kan besvare Health-Checks anonymt på en skala. Gennemgå derefter resultaterne af Health-Checks sammen og fasthold evt. yderligere kommentarer. Hvis I bruger de samme Health-Checks i flere retrospektiver, kan I også tracke trends over tid i Echometer.
- Vi har i mit team en fælles forståelse af, hvad 'godt arbejde' er.
Diskuter retro-emner
Brug de følgende åbne spørgsmål til at samle jeres vigtigste indsigter. Først skjult for hver især. Echometer gør det muligt at afsløre hver kolonne på retro-boardet enkeltvis for derefter at præsentere og gruppere feedbacken.
- Håndtering af modstridende prioriteter: Når jeg bemærker modstridende prioriteter, så ...
- Kommunikation af blokeringer: Når jeg ikke kommer videre med en opgave, deler jeg det ved at …
- Håndtering af konflikter: Når jeg opdager, at en konflikt er ved at opstå i vores team, så ...
Catch-all spørgsmål (Anbefalet)
For at andre emner også får en plads:
- Hvad vil du ellers gerne tale om i retroen?
Prioritering / Afstemning (5 minutter)
På retro-boardet i Echometer kan I nemt prioritere feedbacken med afstemningsfunktionen. Afstemningen er naturligvis anonym.
Definer tiltag (10-20 minutter)
Via plus-symbolet ved en feedback kan man oprette et linket tiltag. Er du ikke sikker på, hvilket tiltag der er det rigtige? Så åbn i stedet et whiteboard om emnet via plus-symbolet for at brainstorme kerneårsager og mulige tiltag.
Checkout / Afslutning (5 minutter)
Echometer gør det muligt at indsamle anonym feedback fra teamet om, hvor hjælpsom retroen var. Dette resulterer i en ROTI-score ("Return On Time Invested"), som I kan tracke over tid.
Teamforpligtelser i tilbageblik
Health Check spørgsmål (skala)
Åbne spørgsmål
Når I har indsamlet svarene, bør I naturligvis forsøge at finde mønstre og blive enige om konkrete aftaler om, hvordan I ønsker at samarbejde i fremtiden - i det mindste midlertidigt som et eksperiment.
Et interessant og kreativt alternativ
Hvis du synes, at disse retrospektive metoder virker for “tørre”, er der en anden retrospektiv metode, der fokuserer på at reflektere over kvaliteten af dit teams output (Fun 54 Retrospektive metoder kan findes her): ‘De tre små grise’ retrospektiv. Det er et enkelt alternativ til at begynde at reflektere og forbedre din præstation, baseret på eventyret om de tre små grise, der byggede huse af forskellige materialer.
Retrospektiv om de tre små grise: Sådan forløber retroen
Random Icebreaker (2-5 minutter)
Echometer stiller en generator til rådighed med tilfældige check-in-spørgsmål.
Gennemgang af åbne tiltag (2-5 minutter)
Før man går i gang med nye emner, bør man tale om effektivitetskontrol for at se, hvad der er blevet af tiltagene fra tidligere retrospektiver. Echometer viser automatisk alle åbne Action Items fra tidligere retros.
Diskuter retro-emner
Brug de følgende åbne spørgsmål til at samle jeres vigtigste indsigter. Først skjult for hver især. Echometer gør det muligt at afsløre hver kolonne på retro-boardet enkeltvis for derefter at præsentere og gruppere feedbacken.
- Halmhus: Hvad har vi bygget, som kun lige holder sammen, men som kan vælte hvert øjeblik? 🌱
- Et hus lavet af pinde: Hvad har vi bygget, som er relativt stabilt, men som stadig kan forbedres? 🪵
- Hus af sten: Hvad har vi bygget, som er bundsolidt? 🪨
Catch-all spørgsmål (Anbefalet)
For at andre emner også får en plads:
- Hvad vil du ellers gerne tale om i retroen?
Prioritering / Afstemning (5 minutter)
På retro-boardet i Echometer kan I nemt prioritere feedbacken med afstemningsfunktionen. Afstemningen er naturligvis anonym.
Definer tiltag (10-20 minutter)
Via plus-symbolet ved en feedback kan man oprette et linket tiltag. Er du ikke sikker på, hvilket tiltag der er det rigtige? Så åbn i stedet et whiteboard om emnet via plus-symbolet for at brainstorme kerneårsager og mulige tiltag.
Checkout / Afslutning (5 minutter)
Echometer gør det muligt at indsamle anonym feedback fra teamet om, hvor hjælpsom retroen var. Dette resulterer i en ROTI-score ("Return On Time Invested"), som I kan tracke over tid.
Retrospektiv om de tre små grise
Konklusion - Agil leveringsflow
Uanset hvordan du starter, er det vigtigste at starte i første omgang. De teams, der holder et aktivt øje med deres Agile-leveringsflow, er de bedste teams.
Mange af de idéer, du finder her, er i øvrigt også godt opsummeret i podcasten “Agile Bites”, som jeg varmt kan anbefale (Til podcasten: Agile Bites).
God fornøjelse med at udvikle dit team!
