Hvorfor har vi egentlig standup?

- Ingen tvil om at det syndes mye mot det daglige møtet, mener Aleks Gisvold i Acando.

📸: Daniel Cheung / Unsplash
📸: Daniel Cheung / Unsplash Vis mer

«Hvorfor har vi egentlig standup?»

Dette spørsmålet har du helt sikkert hørt mange ganger. Kanskje sitter dere på puben etter jobb, og deler historier og erfaringer fra hverdagen i prosjekt. Klisjéen om å klage på hvor «smidig» bedriften er, eksisterer ikke fordi det er så innmari morsomt, men fordi de samme problemene gjentar seg, igjen og igjen og igjen.

«Stand-up-møte» eller «daily scrum», som det egentlig heter, har lenge vært en kilde til frustrasjon, tap av fokus og i noen tilfeller humor. Det er ikke tvil om at det syndes mye mot det daglige møtet.

«Opp av stolen, din latsabb, det heter jo standup!»

Jeg er vel ikke den eneste som har hørt teamets hobby-komiker dra vitsen om «hvorfor heter det egentlig standup?». Det at det kalles standup, eller at man tror det er et krav at man skal stå på bena, er et godt eksempel på hvor lavt kunnskapsnivået er rundt det daglige møte for synkronisering.

Formålet med det daglige kvarteret er, og har alltid vært, at gruppemedlemmene skal snakke sammen for å stimulere samarbeid. De oppdaterer hverandre, slik at de kan forstå hverandres situasjon, utfordringer og fremdrift. Det at alle møtes i sirkel, fremmer også en oppfordring om å se hverandre, og enklere kunne tilby hverandre hjelp. Man er løsrevet fra andre oppgaver og gjøremål, og man kan konsentrere seg om oppgavene man løser og skal løse.

Standup, eller statusmøte?

Her oppstår også problemene. Når det snakkes om fremdrift og utfordringer, har mange snudd formålet med møtet til å bli en statusrapportering til glede for ledelsen. Noen av prosjektledelsens oppgaver er å ha kontroll og oversikt, og ingenting er bedre enn å stå midt mellom alle deltakerne, og få de ferskeste nyhetene rett fra kilden. Men denne fellen må man for enhver pris unngå å falle i.

Leser man «The Scrum Guide», kommer det tydelig frem at fokuset ligger på selvorganisering, inspeksjon og transparens mellom deltakerne. Prosjektleder er ikke nevnt med et ord.[Ikke ta det som et argument for å fjerne prosjektlederen. Det ville vært en alvorlig feiltolkning.]

«Hvorfor er det da sånn at prosjektledere og scrum mastere ikke følger guiden?»

Hvorfor er det da sånn at prosjektledere og scrum mastere ikke følger guiden med rot i det smidige manifest? Prosjektlederen er det kanskje vanskelig å skylde på, for h*n nevnes jo ikke i guiden. Allikevel er det naturlig å stille spørsmål. Er Scrum bare et markedsføringsgrep og en syndebukk for hvorfor prosjektet går over budsjett, igjen? Er det bare å velge og vrake, og vri og vende på velkjente verktøy, og på den måten håpe at man bygger det neste store mesterverk? Hva med å gjøre det etter boken, istedenfor å skrive sin egen formel.

Møter man en prosjektleder som er ekstra frempå, ender «standup» i et statusmøte, med rapportering på detaljer. Er det nære månedsrapporteringen kan det raskt føre til en ekstra nøye gjennomgang. Mister man fokus et sekund eller to, er det lett å forveksle utspørringen på standup med gårsdagens episode av Making a Murderer. Raskt har det som skulle være en informativ synkronisering sklidd over til at de andre deltakere ikke gir et fullstendig bilde av situasjonen. De er nervøse for å skape en uønsket reaksjon hos ledelsen, og svarer unøyaktig eller legger skjul på at de står fast med en oppgave. Formålet med møtet går tapt fordi spørsmålet «hvorfor står du fast?» blir stilt, fremfor å fokusere på «hvordan kan vi hjelpe deg å komme videre?».

Så enkelt, men allikevel så krevende

Det er så mange måter et daglig scrum-møte kan gå galt på, og mange skjønner det ikke selv. Favoritten blant litt late utviklere er ofte «planken». Man får trent litt, samtidig som møtet bare tar 90 sekunder, fordi ingen klarer stå i planken lenger enn det. Fantastisk. Alle rakk helt sikkert å dele masse på de 14 sekundene de fikk tildelt. Det er tydelig at dette er et grep for å forhindre at møtet varer i 15–20 kanskje til og med 30 minutter. Spørsmålet er om de 10 minuttene man sparte på et raskt møte går tapt i manglende stimulering av samarbeid. Jeg tror vi vet svaret.

Mitt beste tips for å motvirke for lange møter er å utstyre scrum master med en bunke post-it lapper og en penn. Så fort diskusjonen sklir ut, kuttes den ut, og det noteres på en lapp «Ola og Kari — diskuter React 16.8». På den måten kan man kutte diskusjoner, uten å kutte ned på samarbeidet mellom deltakerne. Dersom deltakerne må løpe i andre møter, eller går til lunsj etter møtet, er diskusjonen bevart.

Når skal man ha møtet?

Det siste evige problem rundt «standup» er å bestemme et godt tidspunkt. Her finnes det ingen bedre løsning enn å høre det fra møte-eksperten Victoria Stray, førsteamanuensis ved Universitet i Oslo. Stray har viet utallige timer med forskning, så du kan spare timesvis på mer effektive møter, og lære god tips for å legge til rette for en god arbeidshverdag. Det er ikke mulig å oppsummere Stray uten å miste verdifull informasjon, og jeg anbefaler kronikken hennes i Aftenposten fra september 2018.

«De har bestemt seg for et tidspunkt, og Gud forby at de endrer det.»

Den største feilen jeg hører om fra kolleger og bekjente ute på prosjekt er at teamet ikke tør å bytte tidspunkt for standup. De har bestemt seg for et tidspunkt, og Gud forby at de endrer det. Hvis man skal løpe maraton, og får en stein i skoen etter to kilometer, så stopper man og tar den ut. De 30 sekundene det tar å få ut steinen, er en mye mindre skade enn 39 påfølgende kilometer med smerte og etter hvert gnagsår.

For en utviklings- eller prosjektleder er det kanskje vanskelig å endre noe som «fungerer så bra», men spør deg selv: Hvem fungerer det best for? Det kan fort være at man holder oversikt og kontroll over et tog på vei mot stupet. Følelsen av å ha oversikt og å kunne peke på hvor det gikk galt overskrider motet til å tørre å gi teamet litt friere tøyler og stole på at dere sammen kan oppnå det best mulige resultatet. På kort sikt føles det skummelt å vike fra planen og gi fra seg kontroll, men man skal ikke alltid jobbe seg mot lyset i enden av tunnelen, noen ganger skal man sprenge en ny vei ut. Smidig utvikling handler om å eksperimentere, feile og forbedre seg. Bruk kunnskapen til å bli sterkere og bedre rustet.

Tør å gjøre feil, lær av feilene, tør å sprenge en helt ny vei ut av tunnelen!