Hvordan løfte en mellomstor elefant

Tekniske løft er som oftest usynlige for brukeren og organisasjonen, men krever både tankearbeid og tid til gjennomføring. Når oppgaven blir såpass stor må den få plass blant alle andre oppgaver. Det kan være vanskelig å forsvare dem fordi de aktivt konkurrerer med funksjonalitet brukere har bedt om.

Hvordan kan vi så få dette gjennom? Du kan være heldig og jobbe i en organisasjon som ser verdien av å sette av tid til denne type oppgaver. Jeg har jobbet i mange team der dette ikke har vært like lett å få til, og har tenkt å fortelle en suksesshistorie der vi fikk gjennomført et halvstort teknisk løft.

Bakgrunn

Vi var flere team som jobbet mot et modent backend-system som etter hvert hadde behov for både videreutvikling og teknisk oppgradering. For å produksjonssette endringer måtte vi levere en pakke til driftsleverandør, som tok seg av alt i både QA og produksjonsmiljø.

Leveranse var en større jobb som ikke hvem som helst kunne gjøre, selv med utførlige skriftlige instruksjoner. Vi måtte levere ulike former for dokumentasjon i leveransepakken, blant annet lister over inkluderte endringer og testrapporter. For å levere alle systemene leverte vi et lite knippe pakker.

For å bygge en pakke brukte vi et sted mellom 1 og 5–6 timer, med flere manuelle steg og selvsagt noe variasjon fra system til system. Feil i leveransen ga mye merarbeid på grunn av automatikk i leveransebyggescript.

Teamene diskuterte jevnlig behovet for å forbedre denne prosessen. Vi ønsket at flere kunne bygge leveransepakkene, at det ble færre feil og lavere risiko ved hver leveranse, og at hver leveranse skulle ta mindre tid. I tillegg ønsket vi å levere alle delene av systemet på samme måte.

De mest erfarne utviklerne som kjente systemet var opptatte, travle og det ikke var så lett å løfte frem dette arbeidet på lik linje med funksjonalitet som skulle ut. Hvordan gikk vi frem for å løfte leveranseprosess slik at vi fikk en bedre hverdag?

Få med de rette folkene

Vi var så heldig at en av utviklerne som hadde vært med siden systemene ble påbegynt fortsatt jobbet med dette systemet. Det gjorde at vi kunne finne ut hvorfor de ulike løsningene fantes.

I tillegg samlet vi utviklere fra teamene som leverte de ulike pakkene, slik at alle delsystemene var representert. Jeg tok hovedansvar for fasilitering og oppfølging av arbeidet, og koordinerte ved behov opp mot resten av organisasjonen. I tillegg deltok en utvikler som hadde erfaring fra tidligere jobb med å automatisere tilsvarende manuelle byggeprosesser.

Vi møtte hverandre jevnlig gjennom hele prosessen som på mange måter ble et miniprosjekt på siden av de andre prosjektene teamene jobbet med.

Finn tid til arbeidet

At vi fikk samlet denne gjengen var første steg på veien til suksess. Det neste steget lå i å frigjøre tid til å jobbe med forbedringsarbeidet. Vi hadde faste møtepunkter slik at vi fikk diskutert både fremdrift og utfordringer, og la opp til å jobbe med konkrete problemstillinger mellom hvert møte.

I begynnelsen var det vanskelig å få gjort oppgavene fordi andre, mer synlige oppgaver ble prioritert høyere. Tilsvarende arbeid og initiativ jeg har vært med i tidligere har strandet omtrent på dette tidspunktet, der det går fra å være prat til faktisk arbeid.

Det er kritisk at de som er involvert i slike initiativ har reell mulighet å gjøre jobben utover å prate om det. For å sikre at vi fikk reell tid til å jobbe med dette tok jeg meg til rette og oppga et timeantall per uke som gjorde at det gikk an å få gjort noe uten at det ble for stort innhugg i andre oppgaver. De ulike deltagerne fikk beskjed om å henvende eventuelle klager de fikk om timebruk til meg, og jeg informerte resten av organisasjonen om at vi kom til å bruke tid på dette initiativet. Ansvaret for timebruk og prioritering falt dermed på meg, slik at de andre utviklerne slapp å bekymre seg for det og kunne prioritere å jobbe.

For å støtte videre opp om dette rapporterte jeg om fremdrift og planer til alle teamlederne slik at de var klar over at dette arbeidet foregikk. På en måte kan man kalle dette initiativet et miniprosjekt som gikk på lav fart over lenger tid.

Gjør arbeidet konkret

I begynnelsen brukte vi mye tid på å kartlegge hvor de ulike smertepunktene i forbindelse med leveranse var. Hovedmålet ble et klikk for å bygge fullstendig leveranse, og dette kom vi frem til tidlig i arbeidet. Vi visste ikke om vi kom til å nå det målet, og heller ikke hvor lang tid det kom til å ta. Det siste steget mot suksess var å lage gode arbeidsoppgaver. Vi valgte oss mindre og konkrete oppgaver som kunne ta oss i riktig retning, og jobbet løst inspirert av de fire stegene i Toyota Improvement Kata.

Som fasilitator ble det viktig å sørge for at alle visste hvilke oppgaver de hadde ansvar for, at det var mulig å jobbe på oppgaven. Dersom den som hadde ansvar for oppgaven ble stående fast brøt vi ned oppgaven ned i mindre og mer håndterbare deler . Et eksempel på arbeidsoppgave kunne være så konkret som “spør om … på Slack i disse 3 kanalene” eller “prøv å hente ut X, Y og Z fra endepunkt A”.

I hvert møte viste vi frem og diskuterte det vi hadde fått gjort siden sist og hvordan vi kunne få fremdrift på de oppgavene vi ikke hadde fått gjort. Som fasilitator tok jeg gjerne på meg å øke bevissthet og skape forståelse for initiativet både hos oss som jobbet med det, men også i resten av organisasjonen. Dette kunne for eksempel være å følge opp spørsmål som ikke ble besvart, eller få noen lenger oppe i organisasjonen til å bidra med informasjon, og generelt bare diskutere arbeidet med andre jevnlig.

Fremdrift vokser eksponensielt

De første rundene jobbet vi mye med å finne ut hvilken dokumentasjon som faktisk var påkrevd fremdeles og hvilken form den måtte ta. Denne type arbeidsoppgaver er ofte uhåndterlige og vanskelig å kvantifisere i mengde arbeid, og det var viktig å bryte disse oppgavene ned i små deler.

Etter vi hadde hentet inn informasjon, måtte vi finne ut hva neste steg skulle være. Det var ikke alltid innlysende å ta avgjørelser basert på informasjon som ikke alltid var hverken entydig eller komplett, også her er det lett for å bli stående fast. I dette tilfellet besto jobben min i å sørge for at en avgjørelse ble tatt, enten det var å innhente mer informasjon, bli enige om et mulig steg videre, eller få godkjenning fra eksterne på avgjørelsen vår.

Vi brukte flere måneder (i kalendertid) på å hente inn nok informasjon om hvilken dokumentasjon som var påkrevd. Antall timer brukt på dette arbeidet var nok ikke så høyt, men det tar tid å nå gjennom til de rette folkene og få stilt de rette spørsmålene. Ofte trengte vi flere runder med oppklaring før vi kunne gå videre.

Parallelt med dette arbeidet gjorde vi noen tekniske eksperimenter for å automatisere de nødvendige rapportene. Vi ryddet også i eksisterende byggescript for å gjøre systemene klare for mer automatikk. Slik fikk vi jevn fremdrift selv om vi ikke hadde alle svarene klare.

Demo av eksperimentene førte til små forbedringer, f.eks. at vi kunne generere en automatisk changelog under bygging ved å hente ut saksnummer og tittel på sak fra Jira. Hver av oss som hadde laget et konkret verktøy tok dette inn i bygg av eget system, før vi brukte parprogrammeringssesjoner til å få inn verktøyet i neste system. Da vi satte igang med dette begynte ballen plutselig å gå fortere, og resultatene kom raskt.

Fra en litt seig start med mye ullent innhentingsarbeid der vi ikke visste helt hvilken retning dette kom til å ta, økte hastigheten voldsomt etter 3–4 måneder. Vi ble litt overrasket over at vi plutselig var ferdige med implementasjonen, gitt hvor mye tid vi brukte på å innhente informasjon og planlegge hvilke steg vi skulle ta.

I sin helhet brukte vi ca 7 måneder på dette initiativet. Vi klarte å bygge og levere systemet med to script, nådde sånn sett alle målene vi satt oss om man leser hovedmålet som “så enkelt som mulig”.

Tips til egne løft

Samlet sett var det tre faktorer som gjorde at vi oppnådde målet vårt.

1. Vi samlet folk som hadde riktig erfaring, riktig kompetanse om systemet, og som hadde mulighet til å gjøre endringene.
2. Vi satte av nok tid til arbeidet, anerkjente at dette krevde reell arbeidstid og sørget for at denne tiden var tilgjengelig.
3. Vi brukte tid på å lage konkrete arbeidsoppgaver, slik at elefanten kunne løftes litt etter litt.

Dette fungerte for vårt team i dette spesifikke prosjektet. Selv om det høres ut som om vi gikk rett på suksess måtte vi prøve og feile litt på veien. Du som har lest helt til slutt får dermed det viktigste tipset helt til slutt: ikke gi opp! Møter du motstand, prøv en annen innfallsvinkel. Lykke til :)