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

Health Check Varer

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

Health Check Varer

Håndtering af konflikter: “Hvis jeg opdager, at der opstår en konflikt i vores team, så …

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.

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!