Hvis du spørger de fleste ledere om "psykologisk sikkerhed" eller "vision" (læs mere: Psykologisk sikkerhed) i deres agile softwareudviklingsteams, er de enige om, at disse ting er vigtige, men... Når kunden signalerer, at det haster, eller deadlinen nærmer sig, bliver alle disse "blødere" variabler typisk lagt på hylden. Ledere er primært optaget af et forudsigeligt fungerende agilt leveringsflow fra deres agile team.
Hvis du tager et kig på vores Echometer-blog (til vores blog), ved du, at vores indhold har en tendens til at fokusere på at forbedre de bløde færdigheder i teams og organisationer. De bliver ofte undervurderet af beslutningstagere. Men ikke af Scrum Masters og Agile-trænere.
Igen tror jeg, at Scrum Masters og Agile-trænere undervurderer fokus på at forbedre leveringsflowet –, som er det, lederne dybest set ønsker. I dagens indlæg beskriver jeg en simpel teknik, der markant øger 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-trænere mener, at en gyldig måling af hastighed osv. afhænger af den "rigtige størrelse" af opgaver eller arbejdsemner, hvor alle arbejdsemner har omtrent samme størrelse. Først da er story points (som er nødvendige for at måle hastigheden) brugbare til at måle hastigheden, fordi de mere 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 antallet af "nye påbegyndte opgaver" sammenlignet med antallet af "afsluttede opgaver". Disse to skal være i balance. Med andre ord skal "indgangs-" og "udgangsraten" for opgaver være så tæt som muligt, ideelt set endda den samme.
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 opgave, du starter, også er en afsluttet opgave, vil du være bedre i stand til at fjerne blokeringen af de få fokuserede opgaver i det daglige. Din samlede præstation vil være mere forudsigelig –, og teamet vil være gladere, fordi din leder og dine kunder vil være gladere.
Nogle "positive symptomer" på et sundt agilt Agile-leveringsflow
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. Hvad er nu den bedste måde at komme i gang på i praksis? Ved at skabe bevidsthed og "forandringsparathed" 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 for "agil levering" (læs mere her): 22 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
Health Check Varer
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.
Åbne spørgsmål
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 har vores måde at arbejde på ført til et suboptimalt workflow? (f.eks. uklare, uhensigtsmæssige eller ikke fulgte retningslinjer)
Som du kan gætte, indebærer det sidste punkt i Health Check (Kontrol af grundårsagen) allerede en potentiel handling, noget du kan prøve i et eller to agile sprints for at se, om det kan hjælpe dig: Begræns antallet af opgaver med status "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" i almindelighed og derefter etablere nogle grundregler, såkaldte arbejdsaftaler. Den følgende workshopskabelon kan hjælpe dig med dette. Du kan gøre det som en særlig form for retrospektiv i begyndelsen af et projekt eller som en ekstra workshop.
Først skal du få en fornemmelse af, hvor forenet dit team implicit føler sig – se Health Check-elementet. Derefter bør du tjekke dette i praksis 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 kommer i tanke om:
Teamforpligtelser i tilbageblik
Health Check Varer
I mit team har vi en fælles forståelse af, hvad "godt arbejde" er.
Åbne spørgsmål
Håndtering af modstridende prioriteter: "Hvis jeg opdager modstridende prioriteter, så ...
Kommunikation af blokeringer: "Hvis jeg sidder fast i en opgave, deler jeg det med ...
Håndtering af konflikter: "Hvis jeg opdager, at der opstår en konflikt i vores team, så ...
Når I har samlet svarene, skal I selvfølgelig forsøge at finde mønstre og blive enige om konkrete aftaler om, hvordan I vil arbejde sammen i fremtiden – i det mindste midlertidigt som et eksperiment.
Et interessant og kreativt alternativ
Hvis disse retrospektive metoder virker for "tørre" for dig, 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.
Åbne feedback-spørgsmål
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? 🪨
Konklusion – Agile 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.
I øvrigt er mange af de ideer, du finder her, også godt opsummeret i podcasten "Agile Bites", som jeg varmt kan anbefale (Til podcasten: Agile Bites).
God fornøjelse med at udvikle dit team!
