Episode 27: Hva betyr det å feile fort?

«Vi må feile fort!» sier de. Men hva betyr det å feile fort? Hva er alternativet? Hvordan feiler man egentlig fort? Og hva kreves det av ledere som sier at vi må feile fort?

Hei, Martin her, og du lytter til Fimbul!

Du har sikkert hørt påstanden mange ganger før: «Vi må feile fort!»

Enten du er på en konferanse eller du hører en leder i firmaet ditt snakke om hvordan vi arbeider, så hører du det samme budskapet.

«Vi må feile fort!»

Men for at vi skal feile fort må vi først forstå hva det vil si, hva som er alternativet og hva det krever av både ledere og ansatte i et firma som ønsker å feile fort.

Å feile fort er en implisitt forventning om at vi må begå alle feil så raskt som mulig, slik at vi snarest kan komme frem til den løsningen som faktisk fungerer. Det høres enkelt ut. Det høre besnærende ut. Men veien dit er fylt med frustrasjon, fordi det å feile er ubehagelig ved at våre egne antakelser eksponeres og viser seg å være feil. Dessuten er det sjelden slik at vi klarer å finne ut hva som er rett, bare fordi vi forstår hva som er feil.

Før vi snakker mer om det å feile fort, skal vi snakke litt om hva som er alternativet. Hvis vi ikke feiler fort, hva gjør vi da? Feiler vi sakte? Ja, vi gjør faktisk det. Som oftest feiler vi mennesker uansett, og vi gjør det på en saktere og mer smertefull måte enn det vi her snakker om.

I et tradisjonelt miljø der man IKKE snakker om å feile fort, finner man ofte tradisjonelle arbeidsformer og metodikker. Du finner sjelden begreper som «smidig» eller «iterativt» eller «DevOps» eller «team topologies». Ordet «vannfall» gir nok mer riktige assosiasjoner, selv om man selvfølgelig ikke benytter slike merkelapper selv. Man tror nok ikke en gang at man bedriver vannfallsmetodikk, selv om det er det man faktisk gjør.

I slike miljøer arbeider man gjerne ut i fra en idé om at det de TROR faktisk er det som er riktig. Noen får en idé, rådfører seg litt rundt seg i firmaet, får kanskje noen innspill internt eller fra et par kunder. Da har de «forankret bredt», som de ofte sier i slike miljøer. Så planlegger de hvordan ideen skal realiseres, de utvikler og de lanserer, og i denne prosessen ligger en iboende forventning om et bestemt resultat, det man har planlagt for. Og det er her den saktegående smerten kommer inn. Det ligger en forventning om at det de TROR også er riktig, at de vet svaret på forhånd, at det bare er å planlegge godt nok og så utvikle og lansere, så får de det resultatet de ønsket seg.

Men hvor ofte har du opplevd at dette har skjedd? Jeg har jobbet mange steder der dette har vært normal arbeidsform, men aldri har resultatet blitt som vi trodde. Aldri!

Resultatet blir aldri som vi tror fordi vi ikke får brynet ideen vår på virkeligheten før ideen lanseres og testes på ekte mennesker i et ekte produksjonsmiljø. Og det er først da du får de VIRKELIGE tilbakemeldingene, fra kundene, fra dine medarbeidere.

«Åh, er det slik det blir? Nei, det var ikke helt slik jeg tenkte meg det…»

Og hva gjør du da? Hva gjør du når dette er arbeidsprosessen din og du forventer et resultat, men når resultatet ikke blir slik du har planlagt?

Ofte ser vi forskjellige utfall etter dette. Noen velger å leve med et dårlig resultat, fordi dem som skal leve med resultatet er noen andre enn dem som har valgt at det skal være slik. Typisk finner du dette i organisasjoner der dem som bruker løsningen ikke er dem som betaler for den, og som heller ikke har noe alternativ. Jeg skal ikke peke finger på enkeltprosjekter, men det er lett å plukke prosjekter vi leser om i mediene og se at omtrent slik har prosessen deres vært. Et forventet resultat, gigantisk pengebruk, men allikevel lar positive resultater vente på seg. Så sitter man der, i en hengemyr av problemer. Man har brukt så mye penger at det har gått prestisje i prosjektet, og sunk cost fallacy har inntruffet og på en måte rettferdiggjør fortsatt høy pengebruk. Ikke er kundene eller brukerne fornøyd, ikke er prosjektdeltakerne fornøyd, ikke er prosjekteieren fornøyd. Ingen er fornøyd! Hva gjør du da? Noen må gå. Mer penger må bevilges. Men løser du det EGENTLIGE problemet med å sparke noen eller ved å bruke mer penger? Nei, du gjør jo ikke det når det er måten du jobber på som er feil. Kan hende løser du problemet ved å få inn en ny leder eller mellomleder, men det forutsetter at den nye personen evner å se at det kreves en radikal omlegging av arbeidsform i den eksisterende organisasjonen.

Når du står i en slik hengemyr er det ofte for sent. Du har feilet, men du har feilet for sent fordi du ikke har en prosess som legger opp til det motsatte, nemlig å feile fort.

Dermed må vi snakke om hva det vil si å feile fort og hva som er verdien av å gjøre det.

Å feile fort krever ikke noe mindre av oss enn å feile sakte, vi jobber bare annerledes. For vi skal feile uansett, og det å feile er noe som byr oss mennesker i mot. Det er enkelt å snakke om, det er trivielt å legge opp en arbeidsprosess som understøtter det å feile fort, men det å GJØRE det er belastende. Ikke like belastende som når man feiler sakte, men selv det å feile fort sliter på motivasjonen, spesielt når man skal feile gjentatte ganger før man kommer frem til noe som fungerer.

Å feile fort starter med det samme utgangspunktet som det å feile sakte. Vi starter med en idé — en hypotese — om noe. Men i motsetning til det å feile sakte, der vi tror at det vi antar er riktig, så er vi åpne om at det vi tror kan være feil i prosessen med å feile fort.

«Jeg tror at…», sier vi, «… men jeg er høyst usikker på om jeg har rett».

Og det er her prosessene for å feile sakte og å feile fort skiller lag. I et arbeidsmiljø der man feiler fort, driver man lite med planlegging, fordi planlegging i seg selv ikke er verdiskapende. Det er ikke her vi jobber oss frem til svarene, og planlegging gjøres kun av nødvendighet for å understøtte de testene vi skal gjennomføre. I stedet for omfattende planlegging skal det gjøres omfattende testing, fordi vi må teste ideen vår, hypotesen vår, på kunder og brukere. Strukturert, analytisk og ideelt sett på en måte som korrigerer for bias. Og med en test mener jeg ikke i et testmiljø, men i et produksjonsmiljø med ekte kunder og brukere og data. Vi kan gjerne kjøre mindre, kontrollerte tester og brukertester, men ingen tester er så gode som dem du gjør i et ekte produksjonsmiljø med ekte mennesker. Først da får du svaret.

Jeg pleier å si at vi må få båten på vannet snarest mulig, for å se om den holder vann. Det nytter ikke å bygge en gigantisk supertanker på land hvis vannet pipler inn straks den skyves på vannet. I stedet må vi med strikk og binders skyve den spinkle robåten på vannet, se om den tar inn vann. Dersom den tar inn vann må den opp og lappes. Så på vannet igjen. Og igjen. Til den er tett. Først da kan vi bygge videre på den. Jeg vet at slike metaforer er dårlige, men de illustrerer poenget.

I et prosjekt jeg nylig jobbet hadde kunden min ekstremt store svingninger i belastningen på produksjonssystemet gjennom en uke. Jevnt over var belastningen lav, men i korte perioder skjøt lasten i taket med mange tusen prosent, og hele løsningen gikk ned som en konsekvens av dette. I prosjektet var det ledere som ønsket grundig utredning og planlegging så man var sikre på at det ikke skulle gå ned igjen. Jeg, derimot, var enig i målet — altså at løsningen ikke skulle gå ned — men jeg argumenterte for at vi heller testet en hypotese som en av utviklerne hadde, i stedet for å bruke tid og penger på utredning med usikkert utfall. Jeg fikk gehør for mitt forslag og hadde dermed stilt meg lagelig til for hugg. Samtidig måtte jeg forventningsstyre hva som skulle skje: Å teste noe i produksjon impliserer ikke et positivt resultat, det gir oss bare verdifull innsikt vi kan jobbe videre med. Og slik ble det også. Utvikleren gjorde noen tilpasninger i samarbeid med noen på drift, og to dager senere fikk vi testet hypotesen. Denne gangen gikk ikke løsningen ned. Den gikk tregt som sirup, men forble oppe og ga oss verdifull innsikt som dem på drift og utvikling kunne jobbe videre med. Reelle tester og data og innsikt trumfer planlegging og utredning, også selv om testen ikke går bra.

Med å feile fort mener vi hvordan vi kommer oss fra idé og hypotese til et testresultat snarest mulig, uansett hvordan testresultatet blir, fordi testresultatet aldri er slik vi trodde da vi formulerte den opprinnelige ideen og hypotesen. Dette er ikke nye tanker som jeg kommer med her. Dette leser vi om i litteraturen og hører om det på foredrag. Bøker som «The Lean Startup» tar for seg akkurat dette.

Når man jobber i en slik prosess er det lett å bli fartsblind, å utvikle et bias hvor vi tolker resultatet av slike tester til vår fordel, fordi vi hater å ta feil. «Det var da ikke SÅ ille dette, var det det, da?» Da synser vi. Og som jeg pleier å si så skal vi forholde oss til hva vi VET og ikke til hva vi TROR.

Én måte å korrigere for slike bias på, er å bygge inn kontrollmekanismer i arbeidsprosessen. En slik mekanisme kan være så enkelt som å benytte et såkalt testkort der vi formulerer hypotesen og suksesskriterier FØR testen, gjennomfører testen og så sammenholder resultatet med hypotesen. Du finner mer informasjon om testkort i episodenotatene på fimbul.tech. Et slikt testkort er banalt enkelt. Vi formulerer for eksempel:

«Jeg tror at…» og så formulerer du hypotesen din.

Videre skriver du «… Og for å teste dette skal vi…» og så formulerer du hvordan du har tenkt å teste hypotesen din.

Og til sist, men ikke minst, må du tallfeste testen gjennom en formulering «Vi har rett hvis…» og så må du klare å definere hva som er suksess og hva som er feil. Og det er her det blir vanskelig. Dette punktet krever mye mer av oss enn hva vi tror, for det er her kompleksiteten slår inn. Kundene og brukerne oppfører seg på en annen måte enn hva vi hadde forutsett på forhånd, og testen blir vanskelig å måle. Kanskje tester og måler du feil ting? At kundene og brukerne gjør det du tror de skal gjøre, men du finner kanskje ikke ut hvorfor enda flere IKKE gjør som du tror. Du finner kanskje ut hva som feil, men du finner derimot ikke ut hva som er riktig.

Eller vi får de tallene vi trenger, men ser at vi har tatt feil. Skikkelig feil. Denne første iterasjonen der alt går skikkelig i dass er smertefull. Vi visste at vi ikke hadde nok innsikt og kunnskap, men at det stod SÅ dårlig til var uventet. Det å komme seg mentalt ovenpå igjen for en ny iterasjon er ekstremt krevende av et team. Alle må være innforstått med at det er slik prosessen er, at dette er forventet og at nå har vi feilet, vi har feilet fort og det har vært bra.

Jeg husker et sted jeg jobbet for lenge siden, der vi innførte en A/B-test i registreringsprosessen til en nettjeneste. Sammen med en designer og en utvikler, produksjonssatte vi en test fordi vi hadde en hypotese om at en liten endring i registreringsprosessen ville konvertere bedre, altså øke prosentandelen av dem som fullførte registreringsprosessen. Salgssjefen for tjenesten kom løpende og lurte på hva i all verden vi drev med, fordi vi ikke kunne tukle med en av våre viktigste prosesser uten å ha diskutert dette internt først. Men hva var det å diskutere da? Mest sannsynlig ville vi diskutert oss frem til en test, og det var jo nettopp det vi drev med: Vi testet prosessen, men vi testet den i produksjonsmiljøet på ekte mennesker. Og heldigvis viste det seg at den nye prosessen konverterte bedre. Ellers hadde jo argumentasjonen min i akkurat dette tilfellet stått seg litt dårligere. Og hadde testen gått dårlig, ja, så hadde vi fått svar på hypotesen i det minste.

Dermed er vi inne på neste punkt, om hva det krever av ledere i slike arbeidsmiljøer. Ledere forventer resultater. De forventer fremgang. At det vi gjør hele tiden bringer oss fremover. Derfor kan det være smått kleint å høre på ledere som på den ene siden bruker store ord om at vi skal feile fort, men som i hverdagen ellers forventer positive resultater.

Som leder må du gi folkene og teamene dine rom til å feile. Og da mener jeg ikke bare litt, men sånn skikkelig. Enten det er en idé til et nytt forretningsområde, eller det er småforbedringer i eksisterende fungerende tjenester, så skal man som leder aldri gå inn i arbeidet med en antakelse om at resultatet vil bli positivt. Et nytt forretningsområde må testes ut, og du som leder må være åpen på at vi skal teste dette, men at resultatet kan gå i dass. Her feiler mange, for det er så utrolig lett å bli forelsket i egne ideer. Det høres enkelt ut, det er lett for meg å si, for når det kommer til ledermøtet så er det du som leder som skal ta i mot teamet som skal fortelle deg dårlige nyheter. Det er du som skal være raus nok til på forhånd å ha gitt dem rom til å teste og feile, og det er du som skal være raus nok til å motivere dem også igjennom dårlige resultater. Å få negative resultater er vondt i seg selv, og som leder må ikke du gjøre det enda vondere. Jeg har selv overhørt samtaler hvor jeg har hørt høytstående ledere med negativ røst si at «dette har vært en forfeilet strategi». Hva gjør det med motivasjonen til folkene, tror du? Har de lyst til å fortsatt jobbe der? Å jobbe videre med samme problem? Å komme på kontoret igjen i morgen? Slikt skaper bare misnøye. Misnøye er et kulturelt problem, og kulturen kan endres. Som leder er kultur ditt ansvar!

Som du kanskje hører har jeg jobbet i svært forskjellige miljøer. Jeg har jobbet i dem som feiler sakte og jeg har jobbet i dem som feiler fort. Jeg har jobbet med vannfall og jeg har jobbet med smidig. Hvis du nå sitter og grubler over hvordan du kan komme deg fra det ene til det andre, så skal vi snakke sammen. Ta opp telefonen og ring meg på 93055510, eller send meg en SMS eller mail til martin@nivlheim.no. Jeg kjenner dine bekymringer og utfordringer, fordi jeg har vært der selv, og jeg hjelper deg veldig gjerne!

Og så trenger jeg DIN hjelp! Jeg trenger hjelp til å dele erfaringene i Fimbul. Jeg trenger DIN hjelp til å dele Fimbul med minst én venn! Én venn hvor du tenker: «Dette tror jeg du vil ha nytte av!» Be dem om å besøke fimbul.tech.

Tusen takk for at du lytter til Fimbul, og for at du deler! Vi høres!