Agile Delivery Flow: Lever alltid i tide i 3 trinn

Spør man de fleste ledere om den «psykologiske tryggheten» eller «visjonen» (mer om det: Psykologisk sikkerhet ) til deres agile programvareutviklingsteam, er de enige om at disse tingene er viktige, men … Hvis kunden signaliserer at det haster eller tidsfristen nærmer seg, blir alle disse «mykere» variablene vanligvis satt til side. Lederne er først og fremst opptatt av en forutsigbar, fungerende agil leveranseflyt i sitt agile team.

Hvis du tar en titt på Echometer-bloggen vår ( til bloggen vår ) har lest gjennom innholdet vårt, vet du at vi fokuserer mer på å forbedre «myke ferdigheter» i team og organisasjoner. Disse blir ofte undervurdert av beslutningstakere. Men ikke av Scrum Masters og Agile Coaches.

Det Scrum Mastere og Agile Coacher etter min mening igjen undervurderer, er å konsentrere seg om å forbedre leveranseflyten – i utgangspunktet det lederne ønsker. I dagens innlegg beskriver jeg en enkel teknikk for å øke sannsynligheten for å levere i tide og innenfor budsjett igjen og igjen.

Første trinn i forhold til Agile-leveringsflyten din

Jeg snakker om å overvåke Agile-leveringsflyten for oppgavene dine. Hvis du bare gjør noen få ting riktig, vil du kunne levere mye mer forutsigbare resultater. Til og med spredningsdiagrammene for syklustid eller Monte Carlo-simuleringen for beregning av prosjektestimater kan endelig vise gyldige prognoser i stedet for å være helt på jordet (les mer: 9 Agile Måltall for beslutningstakere ).

Det første symptomet som må bekjempes, er at det finnes oppgaver som bare tar noen få dager fra “Planlagt” til “Fullført”, og så finnes det oppgaver som tar mer enn en måned. For å motvirke dette bør du sørge for at en oppgave alltid inneholder den minste mulige leverbare versjonen av den ønskede funksjonen. Uten bjeller og fløyter som ikke er nødvendige for kundens kjerneforespørsel. I bunn og grunn en MVT, Minimum Viable Task. Dette betyr ikke at alle oppgaver blir små. Men det bør hjelpe deg med å nå et stadium der oppgavene maksimalt tar noen uker, i stedet for måneder.

Andre trinn i forhold til Agile-leveringsflyten: WIP i stedet for Velocity

Mange Scrum Mastere eller Kanban-coacher mener at det for en gyldig måling av Velocity osv. er viktig å «right size» oppgaver eller arbeidselementer, der alle arbeidselementer er omtrent like store. Bare da er Story Points (som trengs for å måle Velocity) nyttige for å måle Velocity, fordi de virker mer som en sammenlignbar tidsenhet. 

Men dette er feil: Oppgavene trenger ikke engang å være like store. Du bør ikke anta det, for det er rett og slett for vanskelig å kontrollere Story Point-estimatene. Det eneste du kan kontrollere, er hvor mange nye oppgaver du starter.

Gjør derfor følgende for å bli forutsigbar: Overvåk frekvensen av «nystartede oppgaver» sammenlignet med frekvensen av «fullførte oppgaver». Disse to bør være i balanse. Med andre ord bør «innkommende» og «utgående» frekvens av oppgaver være så nær hverandre som mulig, ideelt sett til og med samsvare.

Et eksempel: Typisk atferd i programvareutviklingsteam er at så snart en oppgave blokkeres, startes en ny arbeidsoppgave. Dette fører til at mange oppgaver er åpne, men uferdige, noe som gjør det mye mer komplisert å oppheve blokkeringen igjen. 

Hvis du i stedet sørger for at det for hver påbegynt oppgave også finnes en fullført oppgave, vil det i Daily bli lettere å fjerne blokkeringer for de få fokuserte oppgavene. Ytelsen deres vil totalt sett bli mer beregnelig – og teamet vil bli mer fornøyd fordi lederen og kundene deres er mer fornøyde.

Noen «positive symptomer» på en sunn agil Agile Delivery Flow

I praksis vil dette føre til følgende atferd:

• • Vi starter ikke nye oppgaver når det fortsatt er mange ting som pågår. 

• • Vi fokuserer på å fullføre det vi har påbegynt før vi begynner på noe nytt.

• • Oppgavene blir aldri eldre enn noen få uker.

• • Hvis det ikke er noen god grunn, jobber vi alltid med den eldste oppgaven.

WIP-grenser (work-in-progress) bidrar også til dette, selv om de ofte ikke er tilstrekkelige. Så snart teamet lærer seg å fokusere på å fullføre oppgaver i stedet for å begynne på nye, vil dere være bedre enn de fleste andre team.

Hvis du bruker Agile Delivery Flow på riktig måte

For å skape klare forventninger: På denne måten kan du fortsatt ikke kontrollere om en oppgave tar to eller tre dager. Men du sørger i det minste for at teamet ditt ikke jobber med så mange oppgaver at 2-3-dagersoppgaver ender opp med å ta en måned.

Hvor mye bedre ville ikke teamet ditt vært hvis du visste at i utgangspunktet alle leveringsforpliktelser ville bli oppfylt i løpet av noen få uker? Dette forutsetter selvfølgelig at du implementerer alle de tingene som er nevnt ovenfor: Fastsettelse av MVT-er, en streng WIP-grense og en forpliktelse til ikke å starte oppgaver på nytt før en annen oppgave er fullført.

Trinn 3: Kom i gang med å forbedre Agile-leveringsflyten

I teorien vet du hva du skal gjøre. Hvordan kan du best komme i gang i praksis? Ved å skape bevissthet og «endringsvillighet» i teamet. I beste fall gjennom selvrefleksjon.

Du må være åpen om disse tallene og sjekke dem regelmessig for å se om forholdet mellom påbegynte og fullførte oppgaver er i balanse. Det kan være en del av etterarbeidet å gå litt dypere og reflektere over hvorfor tallene ikke var i balanse i forrige syklus. 

Jeg kan anbefale å diskutere atferden jeg nevnte med vårt agile retrospektivverktøy Echometer i retrospektivet ditt (les mer): 7 Retrospektive verktøy til sammenligning ). Du kan til og med gjøre dette til en del av arbeidsavtalene eller regelmessige Health Check-møter for å øke bevisstheten ved å stille spørsmålene regelmessig.

Følgende spørsmål er fra vår retrospektive mal for «agile Delivery» (mer om det: 26 morsomme maler for agile retrospektiver ). Vi starter med noen Health Check-påstander og spør teamet om de er enige eller uenige. Deretter følger noen åpne spørsmål:

Agile Levering i ettertid

Health Check-artikler

Når har vår måte å jobbe på ført til en suboptimal arbeidsflyt? (f.eks. uklare, uhensiktsmessige eller ikke fulgte retningslinjer)

Som du kan tenke deg, impliserer det siste punktet i helsesjekken (sjekke årsaken) allerede et potensielt tiltak, noe du kan prøve i én til to agile sprinter for å se om det kan hjelpe dere: Begrensning av antall oppgaver med statusen «Work in Progress».

Legge grunnlaget: Etablere avtaler for teamarbeid

Føler du at teamet ditt ikke er klare for denne typen refleksjon ennå? I så fall bør du først reflektere over «godt arbeid» generelt og deretter fastsette noen grunnleggende regler, såkalte arbeidsavtaler eller Working Agreements. Følgende verkstedmal kan hjelpe dere med dette. Du kan gjennomføre den som en spesiell form for retrospektive i begynnelsen av et prosjekt eller som et ekstra verksted.

Først bør du få en følelse av hvor enige teamet ditt føler seg implisitt – se helsesjekkpunktet for dette. Deretter bør du sjekke dette praktisk med noen åpne spørsmål. Hvert teammedlem må fullføre setningen (se flere spørsmål) med så mange svar som mulig som han/hun kommer på:

Retrospektive teamforpliktelser

Health Check-artikler

Håndtering av konflikter: “Hvis jeg merker at det oppstår en konflikt i teamet vårt, så …”.

Etter at dere har samlet inn svarene, bør dere selvfølgelig prøve å finne mønstre og bli enige om konkrete avtaler om hvordan dere ønsker å samarbeide i fremtiden – i det minste midlertidig som et eksperiment.

Et interessant og kreativt alternativ

Falls dere synes at disse retrospektive metodene virker for “tørre”, finnes det en annen retrospektiv metode som fokuserer på å reflektere over kvaliteten på teamets output ( Fun 54 Retrospektive metoder finner du her ): Retrospektivet “De tre små grisene”. Det er et enkelt alternativ for å begynne å reflektere og forbedre prestasjonene dine, basert på eventyret om de tre små grisene som bygde hus av forskjellige materialer.

Konklusjon – Smidig leveranseflyt

Uansett hvordan du starter, er det viktigste å starte med det første. De teamene som holder et aktivt øye med Agile-leveringsflyten, er de beste teamene.

Mange av ideene du finner her er forresten også godt oppsummert i podcasten “Agile Bites”, som jeg anbefaler på det sterkeste (Til podcasten: Agile Bites). 

God fornøyelse med å utvikle teamet ditt!