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 sine 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 leveringsflyt i sitt agile team.

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

Det Scrum Master og Agile Coaches etter min mening undervurderer igjen, er å fokusere på å forbedre leveringsflyten – i utgangspunktet det ledere ø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 Masters eller Kanban Coaches tror at for en gyldig måling av Velocity osv. er det viktig å “størrelsesjustere” 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 raten av “nystartede oppgaver” sammenlignet med raten av “fullførte oppgaver”. Disse to bør være i balanse. Med andre ord bør “inngangs-” og “utgangsraten” for 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 oppgave som startes også er en oppgave som fullføres, vil det i Daily bli lettere å fjerne blokkeringer for de få fokuserte oppgavene. Ytelsen deres vil generelt være 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 “agil levering” (mer om det: 22 morsomme maler for smidige 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: Begrense antall oppgaver med status “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 workshopmal kan hjelpe dere med det. Dere kan gjennomføre den som en spesiell form for retrospektive i begynnelsen av et prosjekt eller som en ekstra workshop.

Først bør du få en følelse av hvor enige teamet ditt implisitt føler seg – se helsesjekkpunktet for dette. Deretter bør du sjekke dette praktisk med noen åpne spørsmål. Hvert teammedlem må avslutte setningen (se flere spørsmål) med så mange svar som mulig som de/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 hvert fall midlertidig som et eksperiment.

Et interessant og kreativt alternativ

Hvis du synes at disse retrospektive metodene virker for «tørre», finnes det en annen retrospektiv metode som fokuserer på å reflektere over kvaliteten på teamets leveranser ( 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.

Oppsummering – Agil 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 for øvrig også godt oppsummert i podcasten «Agile Bites», som jeg anbefaler på det varmeste (Til podcasten: Agile Bites). 

God fornøyelse med å utvikle teamet ditt!