Parprogrammering for flyt og fokus

(Dette er en oppfølging artikkelen Hvordan vi fikk høyere fart med hyppige prodsettinger og parprogrammering)

Det er noe rart med parprogrammering. Det er en gammel teknikk som er godt kjent og respektert blant utviklere, men som likevel er lite brukt.

Hvis jeg spør, opplever jeg at de fleste er positive til parprogrammering. Spørreundersøkelser hos oss i SpareBank 1 Utvikling viser stor interesse og at de fleste vil parprogrammere mer enn de gjør i dag. Kompetansedeling, læring og at det er sosialt scorer høyt på undersøkelsene.

Likevel er det få som gjør det, selv hos oss. Vi kan også lese om samme type utfordringer andre steder. Hvorfor? Vi ser er at dette går igjen når man spør hvorfor vi ikke parprogrammerer:

• To kan heller jobbe i parallell med oppgavene fordi de vet hvordan de skal løse det hver for seg
• Vi bruker det bare på vanskelige problemstillinger
• Vanskelig på hjemmekontor
• Vi trives best med å jobbe alene
• Vi hjelper hverandre heller litt underveis, og tar resten i Pull Requests
• Vi vet ikke helt hvordan vi kommer igang
• Vi er redd for å blottlegge oss, redde for å dumme oss ut
• Vi ser ingen umiddelbar effekt

Flytsonen

Flyt. Vi har alle vært der, men jeg tror at for oss utviklere er det spesielt. Å være i flyt er fantastisk. Etter litt arbeid med en oppgave glemmer du tid og sted, og konsentrasjonen blir ekstra høy. Du får opp en god del av kodebasen i hodet, og vet hele tiden neste steg før du har utført det. Fingrene flyr over tastaturet. Nye ideer popper lettere opp en vanlig. Du har fokus. Du er motivert. Og ikke minst, du får gjort masse.

De dagene jeg har vært mye i sonen, er de dagene jeg går ut av kontoret med et smil om munnen. Kone og barn får en bedre mann når jeg kommer hjem, og jeg har mer overskudd. Jeg flyr gjennom skogen på løpeturene mine. Jeg sover godt.

Så da er spørsmålet: Burde ikke vi utviklere etterstrebe denne tilstanden mest mulig av tiden?

Har du to minutter?

Slack er fantastisk, det mener jeg. Vi har nesten sluttet med e-post, vi har alle ansatte tilgjengelige på et blunk og vi jobber asynkront over en lav sko. Mye blir løst raskt uten at vi trenger å sette opp egne møter for det.

Men det har en pris.

For hva skjer når du sitter midt inni denne gode flyten, og det plutselig dukker opp popup fra Slack med teksten “Har du to minutter?”

I det du går inn på Slack, så ser du også andre kanaler som lyser som et juletre. Du blir interessert, leser noen tråder og forsvinner enda lenger bort fra det du egentlig holder på med.

Utviklere er ikke datamaskiner.

Forskning viser at det tar ca 15 minutter fra man blir avbrutt til man kommer tilbake der man var i konsentrasjonen.

Når du går tilbake for å jobbe videre, vil du også automatisk tenke på det du ble avbrutt av, og flyten blir enda verre å komme tilbake til.

Resultatet? Du får gjort mindre av det du hadde planlagt, og er mest sannsynlig mindre fornøyd etter arbeidsdagen.

Parprogrammering som verktøy for flyt

Det er så kraftig og så enkelt. Når to sitter sammen og jobber på en oppgave så blir det fullstendig unaturlig at den andre skulle sjekke e-post, Slack, nettaviser, mobilen og andre ting.

En sesjon med parprogrammering kan betraktes som et tradisjonelt møte. Sesjonen legges inn inn i kalenderen for å vise til andre at her er du og den du jobber sammen med er opptatt. Og slik får dere fullt fokus.

Test gjerne med to tastatur mot samme maskin når man parprogrammerer

Men hva med alle meldingene på Slack? Og alt annet som krever tiden din?

Vi tar avtalte pauser ca. annenhver time der vi svarer opp andre meldinger, og vi parprogrammerer heller ikke 7.5 timer om dagen, fem dager i uka. Vi setter av tid til slakk, fordi vi vet det dukker opp uforutsette hendelser hver eneste uke. Og vi liker å hjelpe andre.

Hvordan kommer du igang

Start med å planlegge dagen med den du skal jobbe sammen med.

Slik kan en dag se ut. Jeg har en avtale hos legen og en workshop, Ola har et personalledermøte. Men merk at selve oppgaven har lite fri, den får full fokus og fart hele dagen. Og man får jobbet litt alene også, selv de mest ivrige parprogrammererne liker det iblant.

Selv om man har litt forskjellig agenda, får oppgaven fokus hele dagen

Ferie og oppgaver på vent

Vi har opplevd at når folk jobber alene, drar på ferie eller blir syke, så blir oppgaven satt på vent til de er tilbake. Med parprogrammering kan den andre parten fortsette arbeidet, og lett rulle på andre utviklere.

Og hva blir effekten av dette?

• Oppgaven blir raskere ferdig målt i kalendertid
• Trikkefaktor blir betydelig redusert og vi får høy grad av kunnskapsdeling. Flere kan kodebasen, mindre superhelter som eier hver sin applikasjon, mindre av “den der har Ola jobbet mest med”
• WIP (work in progress) reduseres, vi gjør ferdig oppgaven før vi starter noe nytt

Dobbel flytsone

Tilbake til flytsonen. Vi er nå to utviklere som konsentrerer oss 100% om en oppgave og går inn i flyt. Hvilke konsekvenser får dette? Utviklerne har ofte litt ulik kompetanse, erfaring og måter å se oppgaven på. Man utfyller hverandre og slik oppnår man høyere fart, mindre avbrudd og bedre kvalitet. Og pull requests? De blir ofte overflødige, vi er ferdig diskutert lenge før koden kommer dit. Og vi prodsetter hele tiden.

To utviklere med litt forskjellig erfaring kan ofte komme frem til solide løsninger i et større tempo

Mye av bittelitt istedenfor bittelitt av mye

Har du noen gang pratet med en som har møtt veggen?

Du vil ofte høre at “det ikke var en ting, det var summen av alt”. Jeg opplever at de mest stressa og slitne folka på jobben, er de som driver med for mye samtidig. De som ikke klarer å si nei. Dette resulterer ofte i tidspress, lite fokus og til slutt går det utover kvaliteten på det som blir gjort. WIP (work in progress) blir for høy.

Planlegger man at oppgavene skal gjøres med samarbeid og parprogrammering, setter man automatisk ned WIP. Slik planlegger man altså inn fokus, får bedre flyt og vår erfaring er at vi får gjort mer med skikkelig kvalitet. Dette øker motivasjonen, og motiverte utviklere kan få til hva som helst.

Jeg skrev at de dagene jeg gikk mest fornøyd ut fra kontoret, var når jeg har vært i flyt. Men så hørte jeg kollega Stian Conradsen si at de dagene han gikk hjem og var mest fornøyd, var de dagene han hadde parprogrammert. Hvorfor? “Det er de dagene jeg får gjort mye”, svarte Stian.

Mest sannsynlig kan du sjekke av dette etter en dag med parprogrammering. Du har:

• Opplevd høy kompetansedeling
• Hatt gode tekniske diskusjoner
• Fått fokus og jobbet med bare en sak om gangen
• Vært sosial med en eller flere kollegaer
• Fått gjort mye, og gjort det skikkelig

Så hvorfor parprogrammerer ikke alle hele tiden da?

Jeg tror det er sammensatt, men den største faktoren virker å være at det er vanskelig å komme igang.

Og jeg kan merke det selv noen ganger. Det er mye enklere å bare komme til plassen sin, sette seg ned og begynne å kode på sin oppgave i sitt eget tempo. Ingen som forstyrrer, du kan dypdykke, svare på Slack, prate med kollegaer og jobbe med det du mener er viktigst og i ditt tempo. Og dette mener jeg vi skal fortsette med også, men ikke hele tiden 5 dager i uka.

Parprogrammering krever at du retter deg opp i stolen, konsentrer deg og setter deg skikkelig inn i oppgaven. Det er en intens måte å jobbe på, så ta pauser.

Hvor mye skal vi parprogrammere?

Ikke legg lista for høyt. Hvis teamet som en start setter av tid til parprogrammering et par dager i uka, vil det fort ha stor effekt. Et nyttig tips er at det er lurt å rotere på hvem som jobber sammen. Dette vil ikke bare gi hver enkelt en bedre hverdag og øke kvaliteten på det som blir levert, men det vil ha en positiv utvikling av kulturen i teamet.

Har du lest om hva som er best for teambuilding? Det er ikke at de ansatte drar på rafting, paintball eller gokart. Det er at vi prøver å løse en vanskelig oppgave sammen, gjerne over tid. Da får vi tilbakemelding, det er lett å spørre om hjelp og frykten for å gjøre feil blir borte — teamet får psykologisk trygghet.

Hva er det som stopper deg fra å komme i gang?

Referanser

On Pair Programming fra Martin Fowler’s blog, av Birgitta Böckeler, Nina Siessegger

Hvordan vi fikk høyere fart med hyppige prodsettinger og parprogrammering av Asgaut Mjølne

Flow (psychology) fra Wikipedia

Tegneseriebilde med parprogrammering, fra monkeyuser.com

Tegneseriebilde av fokus, fra monkeyuser.com

Disse formene for teambygging har ingen effekt, fra forskning.no og NTNU

Slik får du hybride team til å fungere fra e24.no av Nils Brede Moe

What happens to psychological safety
when going remote? av Anastasiia Tkalich, Darja Smite, Nina Haugland Andersen, Nils Brede Moe. SINTEF, NTNU, Blekinge Institute of Technology