En far og sønn tilbereder en stek sammen. Hver gang utfører faren samme ritualet; en bit blir kuttet av på hver side før den går i panna.
- Hvorfor må vi utføre dette ritualet? spør sønnen.
- Jeg vet ikke helt, svarer faren.
- Bestefar er en veldig god kokk, og han gjør det alltid. Så jeg bare gjør det han gjør. Det gjør sikkert oppskriften bedre på en eller annen måte.
Neste gang bestefaren er på besøk, spør far og sønn ham hvorfor han skjærer av en bit på hver side av steken.
- Sønn, barnebarn. Det gjør jeg ikke lenger. Den eneste grunnen til at jeg skar av biter var for å få skinken til å passe i stekepanna. Den gamle pannen min var for liten.
Det daglige standup-ritualet
Vi har faktisk lignende ritualer i software-utvikling også. En av dem er daglig standup.
Spillbransjen hadde ikke klart seg uten Unity
Hver dag stopper vi det vi driver med og samles i en sirkel. Alle på teamet beskriver hva de gjorde dagen før, hva de skal gjøre i dag, og hvilke hindringer de tror de vil møte.
Vi står oppreist, altså standup, fordi vi håper det vil gjøre møtet kortere og mer aktivt enn hvis vi satt komfortabelt.
Tanken er at vi skal koordinere og rette kursen hver dag. Vi skal bli bevisst på hva andre gjør og hvordan det påvirker oss, og hindre at folk setter seg fast.
Derfor startet vi med standup
Det er her jeg avslører alderen min; jeg var nemlig i software-industrien da daglig standup først ble introdusert tidlig på 2000-tallet. På den tida gjorde standupen store forbedringer.
Standupen kuttet ned på mengden lange status-møter. Den kuttet ned antallet e-poster.
Den styrte også folk vekk fra å jobbe med meningsløse og uproduktive arbeidsoppgaver i lange perioder, uten å bli korrigert.
«Standupen kuttet ned på mengden lange status-møter. Den kuttet ned antallet e-poster.»
Nedsidene
Nå om dagen, derimot, er jeg ikke lenger like stor fan av standup-ritualet.
Her er fire grunner:
#1. Standup bryter konsentrasjon. Ideelt sett vil en utvikler ha så mange uavbrutte arbeidsintervaller som mulig i løpet av en arbeidsdag. Studier viser at avbrudd i konsentrasjon fører til økt antall feil og høyere stressnivå. De viser også at det kan ta mellom 15 til 20 minutter å komme tilbake i konsentrasjon, når man først blir avbrutt.
Derfor lager Opera-eksene Vivaldi
#2. Det er vanskelig å holde korte standups. Standup-er bør holdes til 15 minutter, maks. Uheldigvis er det ikke alltid å lett å gjennomføre dette i praksis. Noen team er store, og det kan ta tid når alle skal snakke. Noen folk har en tendens til å dele for mange detaljer. Av og til forvandles standupen til en lang problemløsnings-sesjon.
#3. Går du glipp av møtet, går du glipp av informasjon. Standupmøter har ikke nok substans til at man gidder å skrive dem ned, derfor er det ingen dokumentasjon på hva som faktisk blir avtalt i disse møtene. Har du influensa i en uke, blir du fullstendig kuttet av fra informasjonen i disse møtene. Jobber du deltid har du samme problemet.
#4. Standup funker dårlig med folk som ikke jobber fra kontoret. Morgen-møter gir ikke helt mening når noen i teamet jobber i andre tidssoner. I tillegg lider often diskusjoner som foregår på tvers av en videosamtale av dårlig tilkoblinger og dårlig lyd. Fysisk kommunikasjon gjennom for eksempel kroppspråk blir også begrenset.
- Du gjør ikke standup riktig!
La oss bare få dette ut av veien.
Ja, jeg er enig i at det er dårlige, og gode, måter å holde standup-møter. For all del, prøv å holde standup-møter. De kan funke bra for (de fleste på) ditt team.
IncludeOS-gjengen tror ikke Linux er egna til alt det brukes til i dag
Men - hvis noe er vanskelig å gjøre rett, kan det være et tegn på at man bør prøve noe annet.
Alternativ: Asynkrone «Slackup»
Tar man bort standup-møter, snakker fortsatt team mye mer sammen i dag enn de gjorde for 20 år siden. Hvorfor? tekst-chat.
Asynkrone verktøy for chat har gitt oss nye muligheter til å kommunisere hva vi gjør i løpet av dagen. Og på en mye mer effektiv måte enn de lange statusmøtene og e-post-trådene vi hadde for 20 år siden.
Programvare som Slack har tatt helt av. Mange software-team bruker det. Utnytter du Slack til det fulle, gir den en «puls» på prosjektet.
Spørsmål om hjelp, commit logger, produksjons-setting, pull requests og designdiskusjoner flyter alle via Slack-kanaler.
Så hvorfor står vi fortsatt i en sirkel hver morgen og forteller hverandre synkront hva vi driver med? Gjerne med team-medlemmer som ikke jobber fra kontoret, over ei dårlig linje.
«Utnytter du Slack til det fulle, gir den en «puls» på prosjektet.»
Å skulle nøste sammen «pulsen» på prosjektet gjennom ørten Slack-kanaler fungerer riktignok ikke så bra. Så hva med å prøve dette: Sett opp en daglig standup-kanal på Slack. Du kan kalle den for eksempel #standup eller #dette-jobber-jeg-med.
Hvert team-medlem går inn der en gang om dagen og skriver en kort paragraf om dagen deres. Du kan godt bruke strukturen fra standup-møter: Hva jobber du med, hvilke problemer trenger du hjelp med og så videre.
Fordelen med å flytte standup til Slack er:
- #1. Alle medlemmer kan sjekke standupen når det passer dem. Da unngår de å måtte avbryte arbeidet sitt.
- #2. Team-medlemmer som ikke jobber fra kontoret kan delta på akkurat samme måte som dem som sitter på kontoret.
- #3. Plutselig har teamet et tekst-arkiv fra tidligere standup-er. Dermed kan du gå tilbake og se hva som har foregått hvis du er ute av kontoret i noen dager.
- #4. Du kan lese gjennom fort, slik at du kaster bort minimalt med tid på irellevant informasjon.
Så, ingen fysiske møter da?
Jeg sier ikke nødvendigvis det.
Fiken blåser i SCRUM og skytjenester
Det kan fortsett være fordelaktig å ha fysiske statusmøter. En time maks, en gang i uka, for eksempel? Da får du fortsatt fordelene med ansikt til ansikt-kommunikasjon: kommunikasjon med kroppspråk, moralbygging i teamet, alt det der.
Så lenge du ikke har et avtalt avbrudd i arbeidsflyten hver dag, om du kan unngå det.
Folk har nok avbrytelser i løpet av dagen. La teamet ditt få konsentrere seg!
Bry deg om hvordan du jobber
Jeg har vært på flere team hvor denne fremgangsmåten har blitt testet ut. Noen likte det og beholdt det, andre forkastet det. Det er helt ok.
Det viktigste er at du bryr deg om hvordan du jobber. Ikke ha ritualer som er vanlig i software-industrien bare fordi «alle andre elsker det». Prøv nye ting, og juster prosessen til å passe teamet.
