Hvis du spør de fleste ledere om "psykologisk trygghet" eller "visjon" (les mer her: Psykologisk sikkerhet) i sine agile programvareutviklingsteam, er de enige om at disse tingene er viktige, men... Når kunden signaliserer at det haster, eller når tidsfristen nærmer seg, blir alle disse "mykere" variablene vanligvis lagt på hylla. Ledere er først og fremst opptatt av en forutsigbar og velfungerende leveranseflyt fra sitt agile team.
Hvis du tar en titt på Echometer-bloggen vår (til bloggen vår), vet du at innholdet vårt har en tendens til å fokusere på å forbedre de myke ferdighetene i team og organisasjoner. Disse blir ofte undervurdert av beslutningstakere. Men ikke av Scrum Masters og Agile-coacher.
Igjen, det jeg tror Scrum Masters og Agile-trenere undervurderer, er fokuset på å forbedre leveringsflyten – i utgangspunktet det ledere ønsker. I dagens innlegg beskriver jeg en enkel teknikk for å øke sannsynligheten for å levere på tid og 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-coacher mener at en gyldig måling av hastighet osv. er avhengig av "riktig størrelse" på oppgaver eller arbeidselementer, der alle arbeidselementer har omtrent samme størrelse. Først da er story points (som er nødvendige for å måle hastighet) nyttige for å måle hastighet, fordi de fremstår 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.
Så gjør følgende for å bli forutsigbar: Følg med på hvor mange "nye oppgaver som startes" i forhold til hvor mange "oppgaver som fullføres". Disse to bør være i balanse. Med andre ord bør "entry"- og "exit"-frekvensen for oppgaver være så lik som mulig, ideelt sett til og med den samme.
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 du starter, også er en fullført oppgave, vil du være bedre i stand til å løse de få fokuserte oppgavene i det daglige. Den samlede prestasjonen din vil bli mer forutsigbar –, og teamet vil bli lykkeligere fordi lederen din og kundene dine vil bli lykkeligere.
Noen "positive symptomer" på en sunn, smidig Agile-leveranseflyt
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. Hva er nå den beste måten å komme i gang på i praksis? Ved å skape bevissthet og "endringsvilje" 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.
De følgende spørsmålene er vår retrospektive mal for "smidig leveranse" (les mer: 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
Vi gjør ting veldig raskt. Ingen venting, ingen forsinkelser.
Vi kan estimere nøyaktig hva vi kan levere i en gitt syklus.
Sprintresultatene våre krever ingen omarbeiding etter sprinten for å kunne leveres.
Vi begrenser vårt "pågående arbeid" for å være fokuserte til enhver tid.
Åpne spørsmål
Når har vår måte å jobbe på virkelig fungert godt?
Hva er det største forbedringspotensialet for at arbeidspakkene skal gå raskere gjennom prosessene våre (eliminere ventetider, forbedre prosesser)?
Hva var de siste eksemplene på et inkrement som ikke fungerte/ble levert ved slutten av sprinten?
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 skjønner, innebærer det siste punktet i Health Check (Sjekke rotårsaken) allerede en potensiell handling, noe du kan prøve i en eller to agile sprints for å se om det kan hjelpe deg: Begrens antall oppgaver med statusen "Work in Progress".
Legge grunnlaget: Etablere avtaler for teamarbeid
Har du en følelse av at teamet ditt ennå ikke er klart for denne typen refleksjon? I så fall bør dere først reflektere over "godt arbeid" generelt og deretter etablere noen grunnregler, såkalte arbeidsavtaler. Følgende workshopmal kan hjelpe deg med dette. Du kan gjøre det som en spesiell form for retrospektiv i begynnelsen av et prosjekt eller som en ekstra workshop.
Først bør du få en følelse av hvor samlet teamet ditt implisitt føler seg – se Health Check-elementet. Deretter bør du sjekke dette i praksis 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
I teamet mitt har vi en felles forståelse av hva "godt arbeid" er.
Åpne spørsmål
Håndtering av motstridende prioriteringer: "Hvis jeg oppdager motstridende prioriteringer, så ...".
Kommunisere blokkeringer: "Hvis jeg kjører meg fast i en oppgave, deler jeg det med ...".
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
Hvis disse retrospektive metodene virker for "tørre" for deg, finnes det en annen retrospektiv metode som fokuserer på å reflektere over kvaliteten på teamets resultater (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.
Åpne tilbakemeldingsspørsmål
Halmhus: Hva har vi bygget som akkurat holder sammen, men som kan velte når som helst? 🌱
Et hus av pinner: Hva har vi bygget som er relativt stabilt, men som likevel kan forbedres? 🪵
Hus av stein: Hva har vi bygget som er bunnsolidt? 🪨
Konklusjon – Agile Leveringsflyt
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.
For øvrig er mange av ideene du finner her også godt oppsummert i podcasten "Agile Bites", som jeg kan anbefale på det varmeste (Til podcasten: Agile Bites).
God fornøyelse med å utvikle teamet ditt!
