I min forrige artikkel begynte jeg å utforske utfordringene med dårlige vaner i et scrum-team, som før eller senere vil kunne forårsake problemer med leveranser. I denne artikkelen går jeg dypere inn i dette temaet, og fokuserer nå på de funksjonelle prosessene i teamet.
Disse er like viktige som teamets tekniske kompetanse. Selv om teammedlemmene har ekspertise innenfor sine områder, finnes det fremdeles elementer som kan forhindre at de når sitt fulle potensial. Disse problemene kan ofte spores tilbake til prosjektledelsens beslutninger, og deres evne til å skape effektive prosesser som støtter teamet med klare mål og forutsigbare aktiviteter.
Team med sterkt spesialisert kompetanse
La oss se for oss et team med dyktige utviklere, som arbeider uavhengig og leverer avtalt sprintinnhold innen tidsfristen. Selv i et slikt ideelt scenario (som uansett er svært usannsynlig), vil teamet slite med å holde tritt med en stadig voksende backlog dersom kompetansen er for sterkt fordelt mellom teammedlemmene.
Noen eksempler
- Teamet har 1 eller 2 DevOps-ingeniører som tar seg av automatiserte prosesser og plattformtjenester. Resten av teamet har ingen kunnskap om dette. Diskusjoner om disse oppgavene i scrum-møter vil være bortkastet tid for de fleste, mens DevOps-ingeniørene vil finne lite interesse i de mer funksjonelt orienterte oppgavene.
- Teamet har kun én databaseekspert. Avhengig av kompleksiteten i databaseløsningene, kan denne personen fort bli overbelastet, spesielt når prioriteringer tas i betraktning. Andre oppgaver vil dermed også bli satt på vent fordi de er avhengige av data fra databaseoppgavene.
- Når et produkt primært er orientert mot backend-utvikling, vil den ene frontend-utvikleren være der «i tilfelle» (ettersom det fra tid til annen trengs små endringer i brukergrensesnittet). De fleste scrum-møter vil da være bortkastet tid for dette teammedlemmet.
Hva dette fører til
I alle disse tilfellene, vil resultatet være at enten så kaster teammedlemmene bort tiden sin, eller så klarer de ikke å holde tritt med etterspørselen. De hindrer resten av teamet i å starte arbeidet med nye oppgaver, eller de reduserer den totale effektiviteten til teamet fordi for mye tid blir brukt på ineffektive oppgaver i sprinten.
Teamet har fortsatt det samme antall utviklere. Det kan være vanskelig å oppdage at teammedlemmene ikke kan ta på seg alle oppgaver fordi de er for spesialisert. Dermed kan de ikke hjelpe de andre teammedlemmene med oppgaver, selv om de har kapasitet, og prioriteringer tilsier at de burde gjøre det.
Det blir vanskelig for produkteieren å lage meningsfullt sprintinnhold. Produkteieren må ta hensyn til hvor mange som kan jobbe med hver enkelt oppgave, og om flere lignende oppgaver tas inn i sprinten samtidig, noe som kan føre til at teamets kapasitet blir overskredet.
Løsning på dilemmaet
Dette er et dilemma som må løses, og prosjektledere bør være klar over hvilke veier de kan velge. Valget står mellom:
- Å ha mange fullstack-utviklere som kan arbeide med et bredere spekter av oppgaver, men som ikke er spesialister på mange områder. De kan jobbe bredt, men ikke dypt. Dette kan føre til raskere leveranser, men lavere kvalitet.
- Å ha spesialister for hver teknologi, men akseptere begrensningen og jobbe hardere med mer tilpasset sprintinnhold. Dette vil føre til at folk går i dybden og bygger gode oppgaver, men oppgavene må jobbes med sekvensielt, noe som vil ta lengre tid.
Svak produkteier
Dette er ikke nødvendigvis et «prosessproblem», men jeg behandler det som det, fordi det å skape solide oppgaver kan forstås som en prosess som teamet skal etterstrebe.
Med svak mener jeg ikke nødvendigvis personens kunnskap, men heller produkteierens evne til å formulere oppgaver som er forståelige for utviklerne, og som gir mening fra et produktveikartperspektiv. Begge disse er avgjørende for et vellykket scrum-team.
Hvis oppgavene mangler detaljer som utviklerne trenger for å forstå formålet, funksjonsverdien eller tekniske forventninger, kan to scenarier oppstå:
- Utviklere bygger noe annet enn det produkteieren faktisk ønsket. Det er vanskelig å fange opp i løpet av sprinten, fordi produkteieren som regel ikke følger fremdriften på et så detaljert nivå. De forventer som regel bare at ting skal «skje».
- Utviklere bruker mye tid på å avklare oppgavene og diskutere dem gjentatte ganger istedenfor å begynne arbeidet. Dette fører til mange tilleggssamtaler og utsettelse av arbeid. De opprinnelige estimatene for oppgavene blir dermed feil, og det er ikke mulig å fullføre oppgavene innenfor sprinten. Situasjonen gjentar seg gjerne i påfølgende sprinter.
Tid for selvrefleksjon
Det kan være vanskelig å innrømme, men produkteieren bør ta seg tid til å reflektere, se på oppgavene som er laget og sammenligne dette med produktets veikart-visjon, om det i det hele tatt er en sammenheng mellom de to. Hvis ikke, er det det første som må løses. Noen ganger er løsningen å innse at produkteieren er for langt unna teamet og for langt unna sine egne mål.
I et slikt tilfelle må produkteierdelen av teamet endres. Det kan for eksempel være en god løsning å ansette en forretningsanalytiker som er mer orientert mot teamets innhold enn forretningsinnhold (for det har vi allerede en produkteier), selv om det skulle føre til økte kostnader for laget.
Testprosesser uten fast tidslinje
Hva om testaktivitetene ikke er bundet opp til en konkret tidsplan i en scrum-sprint?
Ved første øyekast kan dette se ut som noe positivt for et agilt team. Fleksibilitet er alltid velkomment, og høres bra ut i teorien.
Min erfaring viser at resultatet av denne friheten er mer kaos enn fleksibilitet. Det betyr ikke at løsningen er å skape «fosser i sprinten» med dedikerte testfaser etter utvikling. Det er ikke den riktige tilnærmingen. Du kan lese mer om dette i mine innlegg om strategi for scrumtesting og livssyklus for smidig testing.
Vi kan fortsatt tillate fleksibilitet og velge testplanen som er mest hensiktsmessig for det aktuelle teamet og de produktegenskapene de leverer. Det er likevel to hovedmål som skal oppnås med dette valget:
- Minimere forstyrrelsen av utviklingsarbeidet under testaktivitetene.
- Gjør det til en solid (fra et innholdsperspektiv), pålitelig (fra et hendelsesperspektiv) og gjentagende (fra et forutsigbarhetsperspektiv) aktivitet i teamet.
Hvis disse betingelsene er oppfylt, vil teamet naturlig tilpasse seg testprosessen, og leveransene vil ikke bli påvirket av uplanlagte, langvarige testaktiviteter.
Det som betyr mest er pålitelige og forutsigbare sprintutgivelser, noe som leder meg til det siste punktet i denne bloggen.
Udefinert utgivelsesprosess
Dette er en selvfølge for alle scrum-team, men det er ofte en av de mest undervurderte prosessene.
Ofte vil et scrum-team bare si at utgivelsen skjer etter hver sprint, men dette støttes ikke av en god prosess. Det som da skjer i praksis, er at det oppstår kaotiske og uforutsigbare aktiviteter i løpet av utgivelsestiden. Plutselig er alle opptatt med «utgivelsesoppgaver», og ingen klarer å fokusere på å utvikle nye oppgaver til sprinten. Sprintberegninger er av, og utgivelsen ser ut som en tilfeldig aktivitet sett fra utsiden (som oftest klienten).
Folk er så fokuserte på etterslepet, sprintinnhold, utvikling, testing og presentasjon av resultatene, at de glemmer at når de er ferdige med alt dette, er neste sprint allerede i gang, og de taper allerede tid.
Når er et godt tidspunkt for utgivelse?
Så når skal teamet gjøre selve utgivelsen til produksjon? Det er tross alt det eneste som teller til syvende og sist.
Svaret på det spørsmålet ligger i prosessen, forutsatt at du har en. Avhengig av:
- Kompleksiteten til innholdet teamet produserer i sprintene
- Varigheten av sprinten
- Antall komponenter i systemet som påvirkes
- Antall brukere som benytter seg av og ønsker endringer
En gjentagende utgivelsesprosess bør etableres og følges fremover. De nøyaktige reglene kan være fleksible, men i likhet med testaktiviteter, bør det være en solid vane som er forutsigbar og planlagt for bestemte dager i fremtiden, noe å stole på og referere til.
Valgmuligheter
Mulige former for en slik prosess kan være en av følgende, eller andre:
- Fullfør testingen av funksjonene fra den aktuelle sprinten i løpet av neste sprint, og slipp innholdet på slutten av sprinten (når testingen er ferdig). Dette betyr at hver utgivelse ikke vil inneholde noe innhold fra den aller siste sprinten, men fra de to foregående.
- Den siste sprinten før utgivelse er alltid dedikert til testing av innhold fra de to foregående sprintene.
- Dette betyr ikke at utvikling under «testsprinten» stoppes, men at innholdet som utvikles i den sprinten ikke vil bli inkludert i neste utgivelse.
- Hvis det allerede er gode automatiserte testaktiviteter på plass, kan du prøve å gjøre en utgivelse etter hver sprint. Da må det være en streng prosess med dedikerte personer som fokuserer 100% i de aktuelle dagene. Det skal likevel ikke påvirke resten av utviklingsteamet.
- Du kan også velge å slippe en gang i måneden eller en gang per N måneder, hovedsakelig om det er greit fra sluttbrukernes perspektiv. Dette vil øke testinnsatsen for hver sprint (fordi innholdet blir større for hver utgivelse). Men på den annen side vil det gi færre gjentagende aktiviteter over tid, noe som i dette tilfellet kan være en fordel for teamet. Det vil gjøre det mulig for teamet å bygge flere nye funksjoner mellom utgivelser, selv om funksjonene først kommer til produksjon med lengre mellomrom.
Men som nevnt tidligere, er det ikke så viktig hvilken av disse prosessene som velges. Det viktigste er at teamet følger prosessen og gjør det til en fast vane.
Du kan også lese denne veiledningen til prosess og praksis for utgivelsesadministrasjon.