Ikke jobb mens jeg forstyrrer!
Våren 2015 var jeg på vei til å bli utbrent.
Vi hadde laget ny nettbankplattform som stadig flere av teamene våre tok i bruk. Samtidig var ikke plattformen ferdig. Det var kode vi måtte forbedre, samtidig som nye krav dukket opp.
Selv om mye var likt den gamle plattformen, var også mye annerledes. Teamene trengte hjelp til å forstå detaljene. Det gjorde at utviklingsarbeidet stadig ble avbrutt av pirk på skulderen, meldinger, eposter og møter.
Kombinasjonen av sterkt leveransepress og hyppige avbrudd var i ferd med å spise oss opp. Hvordan skulle vi klare å levere forbedringer raskt og med høy kvalitet, når vi ble avbrutt hele tiden?
Avbruddene gjorde at vi følte at vi fikk gjort svært lite. Situasjonen var uholdbar. Samtidig visste vi at flere av avbruddene var verdifulle for systemet som helhet: Hvorfor skulle folk bruke tid på å finne ut av hvordan detaljene fungerte, eller regne ut hva som ville være beste tilnærming til en ny utfordring i den nye arkitekturen, når vi ofte satt med svaret?
I SpareBank 1 Utvikling bruker vi ofte A3-metoden når vi har vanskelige problemer vi skal løse. Vi valgte å kjøre en A3 på avbruddsproblemet. Hvordan kunne vi hjelpe de rundt oss, og samtidig gjøre utvikling på en bærekraftig måte?
Hvorfor er avbrudd så krevende for utviklere?
Dette er et lurespørsmål.
Avbrudd er ikke spesielt krevende for utviklere. Avbrudd er spesielt krevende for alle som driver med problemløsning.
Alle som jobber med problemløsning bygger mentale modeller av problemdomenet i hodet. Disse modellene har flere abstraksjonsnivåer, som en må ha i hodet samtidig for å klare å resonere rundt problemet, og forhåpentligvis også nærme seg en løsning.
Avbrudd som omhandler andre tema enn akkurat det en jobber med, river ned den mentale modellen. Den må bygges opp igjen, før en kan fortsette med arbeidsoppgaven. Denne kontekstbyttingen er mentalt krevende, og den tar tid. I arbeidet med A3-en, målte vi på de forskjellige typene avbrudd, og lengden på dem. Vi fant forskjellig byttekost for forskjellige typer avbrudd, med i snitt tre minutter for chat, opp til femten minutter for møter.
Hvis det i tillegg er systemutvikling en driver med, og en er midt i en debuggingssesjon for å forstå mer av problemdomenet, så kan byttekosten gå vesentlig opp, siden en i tillegg til å bygge opp den mentale modellen igjen, også må få systemet tilbake i tilstanden en var i, som før en ble avbrutt.
Alle har en begrenset mengde kognitiv kapasitet, som vi kan bruke av hver dag. Gjennom dagen blir den brukt opp. Avbruddene, og tiden det tar å komme seg tilbake til oppgaven en holdt på med, spiser av denne kapasiteten.
Forskjellige typer avbrudd
Vi så at vi trengte håndtere avbruddene forskjellig. Vi har delt dem inn i fire typer:
- Møter — både egne og andres
- Elektronisk kommunikasjon — chat, epost, SMS osv
- Selvpåførte konsentrasjonsavbrudd — tankene spinner avgårde, enten på oppgaver en vet en skal gjøre, eller en kommer på nye oppgaver som trengs å gjøres
- Pirk på skulderen og kapring ved kaffeautomaten — “Har du fem minutter?”
Ta tilbake kontrollen over tiden din
For mange prosjekt- eller teamledere er kalenderen over en drømmedag.
For en utvikler er denne dagen ødelagt før den har begynt. Hun vet at med denne kalenderen kommer hun nesten ikke til å få gjort noe som helst:
- Hun kommer på jobb åtte-halv ni
- Sjekker epost, Slack og nye Pull Requester
- Rekker akkurat starte på utviklingsoppgaven før retroen
- Forbereder seg litt til retroen
- Gjennomfører retroen
- Gjør litt etterarbeid etter retroen
- Rekker kanskje akkurat komme igang igjen med utviklingen før hun skal spise lunsj i elleve-halv tolv tiden
- Kommer tilbake fra lunsj og sjekker epost, Slack og nye Pull Requester
- Rekker akkurat komme igang igjen med utviklingen før hun må forberede seg litt til workshopen
- Gjennomfører workshopen
- Litt etterarbeid etter workshopen
- Rekker kanskje fortsette litt på utviklingsoppgaven før hun går hjem i fire-halv fem tiden
Mer sannsynlig er hun såpass sliten etter totimers workshop, at det heller blir en ekstra kaffekopp og en ny sjekk av epost og Slack før hun går hjem igjen, frustrert over nesten ikke å ha produsert noen ting på en hel dag.
Paul Graham har skrevet en fantastisk artikkel om disse utfordringene. Den heter Maker’s Schedule, Manager’s Schedule.
Slik kunne vi ikke ha det.
Løsningen for oss ble å innføre en fast blokk i kalenderen hver dag:
Vi kan nå bare kalles inn til møter fra 13 og utover. Med denne blokken i kalenderen har vi fått tilbake kontrollen over vår egen tid. Folk kan velge å kalle oss inn til møter også mellom åtte og 13, men da er det vi som bestemmer om vi skal prioritere møtet eller ikke. Er det et viktig møte, ber vi som oftest om at møtet flyttes til etter 13.
Når på dagen bør en ha møter?
Vi har valgt å blokke ut første del av dagen, fordi det er da vi er mest opplagt og jobber best. Det er da det er viktigst å ha sammenhengende tid til å drive med utvikling for oss. Noen jobber best på kveld og natt, men for oss er det de første timene av arbeidsdagen som gjelder.
Møter som krever høy grad av interaksjon og meddeltakelse bør legges så tidlig på ettermiddagen som mulig. Møter som er av typen informasjonsmøter, for eksempel allmøter og demoer, kan gjerne legges mot slutten av dagen.
Hvordan vi har håndtert de andre avbruddstypene går vi nærmere inn på i del to av denne bloggposten.
Takk til Børge Lund for hans humoristiske betraktninger rundt dette temaet, og for tittelen til denne artikkelen.
