På JavaZone i Oslo Spektrum tok utvikler Asgaut Mjølne i Sparebank 1 Utvikling et oppgjør med den klassiske måten mange utviklere jobber på der utviklerne typisk får tildelt hver sin oppgave – som ingen andre føler ansvar for.
Ifølge Mjølne er det ofte i standups veldig mye personfokus i stedet for teamfokus: Hvordan går det med din oppgave, og når blir du ferdig? Kommer vi i mål med oppgaven din?
– Det er helt håpløst å jobbe slik, sa Mjølne.
Inspirert av NAV, som har sluttet med pull requests, bestemte Sparebank 1 seg høsten 2021 for å teste ut å jobbe på en helt ny måte – med mye mer bruk av parprogrammering.
– Denne måten å jobbe på har i veldig stor grad redusert pull requsts, og vi får mye mer fokus og flyt, sa Mjølne.
Hjelp av SINTEF-forskere
Sparebank 1 har jobbet tett med forskere i SINTEF for å bedre forstå effekten av parprogrammering, og få hjelp til å implementere strategien.
– Vi har forsket mye på hva som gjør at utviklere er fornøyde. Én ting som går igjen, er muligheten til å ha flyt – enten det er i 2, 3 eller 4 timer. Det varierer fra person til person, men er viktig å få til, sa Nils Brede Moe, sjefforsker på SINTEF Digital.
Nettopp det med å komme i flytsonen er vanskeligere når man ikke driver med parprogrammering, hevder både SINTEF-forskeren og Asgaut Mjølne.
«Når det er to som sitter sammen og programmerer så har du tatt vekk alle forstyrrelser!»
– Når det kommer en popup i Slack om at du må se på en pull request, så mister du fokus. Når det er to som sitter sammen og programmerer så har du tatt vekk alle forstyrrelser! argumenterer Mjølne.
Han forklarer det med at når man parprogrammerer så er det som et lite møte der man sitter og jobber sammen. Da sjekker man normalt ikke Slack-meldinger. Den typen avbrudd bør unngås, mener Moe i SINTEF.
– Det kan ta 10-20 minutter å komme tilbake til oppgaven. Det er viktig å tenke over det med avbrudd. Det går det an å styre, og parprogrammering er en teknikk for det.
– Blir du avbrutt 3-4 ganger i løpet av en time, får du faktisk ikke gjort nesten noen ting, sier Moe.
Tester par-koding: - Fascinerende!
Anbefaler å teste ut
Ifølge Mjølne er det ikke slik at alle i Sparebank 1 sitter og parprogrammerer hele tiden. Men de gjør det mye mer enn før, og så er det noen perioder med soloprogrammering innimellom.
– Parprogrammering er veldig intensivt, så man orker ikke gjøre det hele dagen, legger Moe i SINTEF til.
Det er alltid slik at noen er positive til parprogrammering, mens andre helst ikke vil gjøre det. Ønsker man å begynne med parprogrammering er det derfor viktig at dette ikke er noe ledelsen trer nedover hodene til utviklerne. Det må være noe utviklerteamene må få ta styringen på selv, mener Moe.
– Folk vegrer seg litt hvis man sier at NÅ skal vi drive med parprogrammering. Man må slutte å prate, og bare gjøre det.
Moes tips er at man inngår en avtale med gruppen om å prøve det i for eksempel fire uker. Så får man kanskje inn noen som er eksperter, diskuterer litt og finner ut hva som er vanskelig.
– Alle skjønner jo parprogrammering. Men hvorfor er noen negative og noen positive? Så har man en diskusjon, og setter igang i en begrenset periode. Det kan de fleste være med på, sa Moe.
I Sparebank 1 gjorde de nettopp dette i over en periode på noen uker, feiret litt med boller underveis – og avsluttet med "retro" og middag for å gå gjennom hva som fungerte og ikke fungerte.
Sjekker hverandres kalendere
Mjølne sier utviklerne i Sparebank 1 har begynt å jobbe mye mer som et team etter at de begynte å parprogrammere mer. I stedet for at det er en haug med oppgaver med et navn bak hver oppgave, føler nå alle et mer felles ansvar for at de ulike oppgavene blir gjort.
Slack brukes hyppig, og det er ikke uvanlig at det kommer meldinger på Slack der utviklere spør om de skal bidra på ett eller annet kodeprosjekt.
– Med parprogrammering spør man folk om de trenger hjelp til å få ferdig sin oppgave. Det gir en veldig fin teamfølelse, sier Mjølne.
Han forteller at han ofte starter dagen med å sjekke kalenderen til seg selv og en kollega han ofte parprogrammer med, for å se om de kan få inn en parprogrammerings-økt i løpet av dagen.
– Når man er vant til parprogrammering og sitter og koder alene, blir det noen ganger sånn at jeg tenker: Hva ville Ola gjort her?
Det at utviklere jobber sammen på mer, har en rekke fordeler, mener Mjølne.
I tillegg til at det er lettere for andre å ta over hvis noen drar på ferie eller er borte, er parprogrammering bra når man får inn nye utviklere. I stedet for at en nyansatt skal få en vanskelig oppgave i fanget og prøve å løse det alene, blir den nye straks en del av teamet.
– Onboarding er en stressende situasjon. Å føle at man mestrer det, gjør at stresset går ned og det er større sjanse for at man blir lenge i selskapet, sier Moe.
Nå jobber annenhver nye utvikler hos NAV hjemmefra
Det tekniske må være på plass
Sparebank 1 ønsker å jobbe etter smidige prinsipper og gjøre ferdig oppgaver før man begynner på noe nytt. Det skal være korte feedback-looper og man skal "prodsette" ofte.
– Dette hadde vært nesten umulig å gjøre alene, sa Mjølne.
Etter å ha testet ut den nye måten å jobbe på, viste det seg at i stedet for en masse Jira-saker tilegnet ulike utviklere, så var hadde de kun én Jira-sak etter én måned.
– Det var 50 commits på én Jira-sak. Da fant vi ut at vi ikke trengte Jira heller.
For å kunne jobbe på denne måten er det ifølge Mjølne veldig viktig å ha en del tekniske løsninger på plass. Du må blant annet ha bra monitorering og logging, alarmer, autoskalering, "feature flags" og enkel tilbakerulling hvis noe går galt.
«Vi sitter nå og koder med hvilepuls.»
Når alt dette er på plass, er hans og Sparebank 1s erfaring at man jobber raskere med færre feil og lavere risiko.
– Denne måten å jobbe på gjør at vi har lite feil. Vi sitter nå og koder med hvilepuls, sier Mjølne.
SINTEF-forskeren mener noe av det viktigste parprogrammering kan føre til, er mer motiverte utviklere.
– Det er motiverte utviklere du vil ha. At de mestrer dagen og får ned stress, og kan release til 1 million kunder uten å bli stresset. Motiverte utviklere er også opptatt av læring, og det er en veldig selvforsterkende prosess, sier Moe.
