Unngå de vanligste fallgruvene med OKR

Hva er OKR

OKR (Objectives and Key Results) er et målstyringsverktøy som hjelper team med å fokusere på hva de ønsker å oppnå (Objectives) og hvordan suksess måles (Key Results). Dette rammeverket fremmer tydelighet, prioritering og engasjement, og er mye brukt for å sikre at alle i organisasjonen arbeider mot felles mål.

Ifølge Locke & Latham (2002, 2019) fungerer gode mål når de er

• Beskrivende for effekten av arbeidet
• Konkrete og målbare
• Utfordrende, men oppnåelige

Ved å balansere tydelige mål og kvantifiserbare resultater kan OKR skape både retning og engasjement i arbeidet.

Les også andre artikler der Team Agile har skrevet flere artikler om effektmål, målstyring og OKR.

Typiske fallgruver med OKR

Å lykkes med OKR kan være vanskelig, selv om metoden virker enkel. Mange organisasjoner og team syne det er utfordrende å oppnå målene sine og ønskede effekter, fordi det kreves ekstremt mye mer enn å bare sette mål og nøkkelresultater. Basert på vår erfaring ser vi at utfordringene ofte faller inn i tre kategorier:

1. «Vaskefella», når vi bare måler hva vi har gjort ikke hva vi har oppnådd
2. «Tredemøllefella», når OKR er satt, glemt og mangler oppfølging
3. «Brofella», når teamets OKR mangler strategisk forankring og koordinering

Ønsker du å vite hvordan de ulike fellene ser ut, hvorfor de er problematiske, og selvfølgelig hvordan de kan unngås? Les videre!

Vaskefella

Vaskefella oppstår når teamet fokuserer på å måle aktiviteter i stedet for resultater. Dette skjer ofte fordi det er enklere å telle hva som er gjort, enn å vurdere hvilken effekt arbeidet og aktivitetene har hatt. Slike aktiviteter kan inkludere oppgaver som "fullføre tre oppgaver fra backloggen" eller "implementere en ny prosess," men uten å reflektere over den reelle verdien av arbeidet.

Hvordan ser vaskefella ut?

Når for eksempel et team er nye for OKR, er det lett at de bare tar oppgavene på planen, enten det var milepælsplanen eller prosjektplanen og gjør om til «aktivitetsnøkkelresultater». I frykt for at noe skal falle mellom 2 stoler, tror man at man har sikret seg ved å gjøre det slik.

Det jeg mener med «aktivitetsnøkkelresultater», er nøkkelresultater som beskriver en aktivitet, oppgave, utføring, som er sann eller usann, utført eller ikke.

Eksempler på «aktivitetsnøkkelresultater»

• Implementere og dokumentere en ny prosess
• Fullføre tre oppgaver fra backloggen.
• Lansere Søket i PROD
• Implementere en feedback-prosess for saksbehandlere innen kvartalet
• Fullføre minst 3 teknisk gjeld-tasker fra Jira i sprinten
• Gjennomføre nødvendig testing
• Alle ansatte har gjennomført opplæring

Felles for disse er at de kun måler om noe er gjort eller ikke, ingen måling av om man er på rett vei eller adferdsendring. Det er også liten eller ingen vurdering av om arbeidet faktisk har gitt noe endring, verdi eller effekt.

Arbeidsmåten skaper et overfladisk bilde av fremdrift uten å koble innsats til reelle mål.

Vi tror at rotårsaken til «Vaskefella», er at det allerede er besluttet hva teamet skal gjøre og lage.

Hvorfor er dette et problem?

Når man er i «Vaskefella» måler vi ikke effekt, og vi mener at vi da ikke får utnyttet fordelene ved å bruke OKR-rammeverket. Man er så bundet til det som allerede er besluttet skal gjøres, at selv når man observerer at det man antok skulle ha effekt, ikke har det, så skjer det ingen justering og læring.

For eksempel, for en stund tilbake, hadde det blitt besluttet at søkemotoroptimalisering, var en god ide for et team som hadde ambisjoner om å få flere betalende brukere på en ny digital plattform. Det ble laget flere aktivitetsnøkkelresultater rundt denne «gjøre-jobben». Alle disse ble utført, ferdig, sluttført, og grønne og fine på OKR-dashboardet. Likevel hadde de ingen flere brukere, og i hvert fall ikke flere betalende. Teamet ble altfor oppsatt i og fortsette å ferdigstille dette som allerede var besluttet, at man ikke lærte eller justerte underveis.

Man må oppfordre teamet til handlingsrom, autonomi og læring. Da blir det også veldig mye gøyere å jobbe!

Hvordan komme seg ut av «vaskefella»?

For å unngå vaskefella, må teamet flytte fokus fra aktiviteter til effekter. Vi har gode erfaringer med workshop der man nullstiller seg fra alle aktivitetene man har i “backloggen”. Forsøker å glemme alle aktivitetene og featurene man tror vil gi verdi og effekt, og «starter med problemet».

Vi stilte oss spørsmål til teamet

1) «Hvem har problemet»

• Hvem skaper du verdi til?
• Hvem er vi til for?
• Hvem bruker oss?

2) «Hva er problemet»

• Hvilke problemer ønsker de å løse med
  • Produktet
  • Tjenestene
  • Leveransene

Deretter prioriterer man de viktigste problemene og kundene/brukerne, for eksempel i en prioriteringsmatrise.

3) "Hva er målet", altså "Hvordan ser de viktigste problemene ut når de er løst?"

• Beskriv hvordan suksess ser ut

Teamet kan enes og om målet, slik at dette blir teamets ambisjon/objective.

4) Hvordan vet du at du lykkes

• Per mål, beskriv kvantitativt hvordan du vet at du har nådd målet eller er på rett vei
• Bør være en eller annen form for endring av adferd, ikke noe som er gjort, ferdigstilt, utført eller lansert eller levert​

Teamet kan enes og skrive om forslagene på hvordan man vet at man har lykkes, slik at dette blir tilslutt teamets nøkkelresultater.

For å dobbeltsjekke at man ikke får «aktivitetsnøkkelresultater», kan man også gå gjennom nøkkelresultatene, og stille seg spørsmålene

• Beskriver man effekt eller utfall til de man skaper verdi til?
• Beskriver man en eller annen form for endring av adferd​?
• Unngå oppgaver eller handlinger som utføres, ferdigstilles, lanseres osv.
• Er disse kvantitative?
• Er det mulig å måle fremdrift, eller om man er på rett vei?
  • Tidlig
  • Senere
• Dersom man synes det er utfordrende å ikke ha "aktiviteter", så kan man stille seg spørsmålet til aktivitetene:
  • Hva er endringen etter oppgaven er «utført», «ferdigstilt», «lansert»?

Tredemøllefella

Tredemøllefella oppstår når OKR settes, men deretter glemmes og ikke følges opp. Dette skjer ofte fordi teamet ser på OKR som en formalitet, uten å integrere det i hverdagsarbeidet. Ofte skyldes dette mangel på eierskap eller forståelse av hvordan OKR kan brukes som et aktivt verktøy.

Hvordan ser tredemøllefella ut?

Når for eksempel et team som har masse i backloggen, kanskje de er litt bakpå, får beskjed fra ledelsen at nå er det tid for å «levere» inn neste kvartals OKR, er det veldig enkelt at dette arbeidet ikke blir prioritert, og det blir «satt ut», slik at det ikke står i veien for teamets fart. En teamlead, kanskje en testleder og eller en UXer, setter seg sammen og rabler ned et forslag til OKR. Da får man "skjermet" resten av teamet for unødvendige møter. Resten av teamet fortsetter å kode og ha hendene på tastaturet, og bryr seg ikke, har ingen eierskap til ambisjonene eller nøkkelresultatene, og gir tommel opp til å sende det inn til ledelsen. OKRene blir lagt i en skuff, og ikke tatt opp før det er tid for å rapportere på dem. Da setter teamlead, kanskje testleder og eller en UXern seg sammen og pynter litt på tallene. Kanskje man får noen utviklere til å mekke noe på tampen, så det ser greit ut.

Vi tror rotårsaken til «Tredemøllefella» er at OKR blir en "gjøre-jobb" og rapportering, fordi ingen har fortalt hvorfor vi skal jobbe etter OKR-rammeverket.

Hvorfor er dette et problem?

Når man er i «Tredemøllefella», utnytter man heller ikke fordelene med OKR-rammeverket. OKR endrer ingen ting, måler ingen ting, så er det noe vits?

Litt som å kjøpe en tredemølle. Man trodde den skulle gi masse verdi, motivasjon og fokus, men man må sette av tid, innsats og faktisk blod og svette. Det hjelper ikke bare å kjøpe møllen. Man må også vite hvordan den skal brukes og må trene på det.

Akkurat som med OKR. Det hjelper ikke bare å sende en leder på kurs, sende over noen maler, ha noen frister, og tro at resten skal gå av seg selv.

Hvordan komme seg ut av tredemøllefella?

For å unngå tredemøllefella, må man investere i OKR. Man må bygge forståelse og eierskap, OKR må gjøres til en integrert del av teamets arbeid, og man må vise fremgang og feire små seiere.

Gode erfaringer har vist at dette kan gjøres ved

1. Bygg forståelse og eierskap

• Bruk god tid på å forklar hvorfor OKR er viktig og hvordan det hjelper teamet.
• Send flere på kurs, ha flere eksperter i teamet eller teamene man kan lene seg på
• Forklar, lær og “nudge”
  • Forenkle eksempler, og bruk noe de ulike teammedlemmene kan relatere seg til. For eksempel sport, hundeoppdrett, baking, bygging av hus, oppussing osv.
• Involver alle i utformingen av OKR for å sikre eierskap
• Vær ærlig på at det er vanskelig, og teamet må prøve, lære og justere

2. Synliggjør målene

• Hold OKR lett tilgjengelig for hele teamet
• Bruk resultater fra OKR til å justere strategi og innsats
• Diskuter fremdrift på OKR i jevnlige, for eksempel i monday commit, friday wins, standups, planleggingsmøter, demoer og lignende
• Inkluder alle i teamet, og få til en kultur som oppfordrer til handlingsrom, autonomi og læring
• Ha få og enkle motiverende mål som er lett å huske

3. Vis fremgang og feir seire:

• Ha enkle dashboard eller sider lett tilgjengelig som viser fremdriften
• Feir små suksesser underveis for å skape motivasjon

3. Brofella

Brofella oppstår når teamets OKR ikke er koordinert med resten av organisasjonen. Dette skjer ofte når team jobber isolert, uten å ta hensyn til strategiske prioriteringer eller avhengigheter på tvers av organisasjonen. Resultatet er at et team begynner å bygge en metaforisk bro – bare for å oppdage et stykke på vei, at det teamet de er avhengige av bygger en tunnel. Dermed stopper viktige initiativer opp.

Hvordan ser brofella ut?

Et eksempel på et team med denne utfordringen, er et team som begynte kvartalet godt. De satt seg en OKR som var effektbasert, brukerrettet, målbart og ambisiøst. Motivasjonen var på topp.

Men da teamet begynte å jobbe med løsningen, som var en skjemaløsning på nettsiden, innså de raskt at de trengte hjelp fra et annet team som tok imot dataene fra skjemaet. Teamet de var avhengige av hadde imidlertid et annet fokus og prioriteringer, og kunne ikke hjelpe ordentlig før tidligst neste kvartal. Dermed klarte ikke teamet med det veldig gode målet å levere på det. 

Dette illustrerer viktigheten av koordinering og synkronisering mellom team for å sikre at alle trekker i samme retning og kan støtte hverandre i leveransene.

Rotårsaken til Brofella er manglende strategisk forankring og koordinering.

Brofella kan oppstå både om team er ute av sync med hverandre – og om de er ute av sync med organisasjonens retning og overordnede strategi. I eksempelet over burde en god strategi kunne gi svar på hva som er viktigst for teamene og gjøre det enkelt å koordinere. Men i større organisasjoner er det sjeldent så enkelt.

Hvorfor er dette et problem?

I en organisasjon som ikke går helt i takt og vet hvor den vil, sliter med ressurssløsing, fordi team kan jobbe med mål som ikke gir verdi for organisasjonen. Det kan også føre til forsinkelser i teamets leveranser og igjen frustrasjon hos både ledere og interessenter.

Hvordan komme seg ut av brofella?

Avhengigheter, som den beskrevet over, er hverdagen i veldig mange organisasjoner. OKR er ikke en magisk trylleformel som fikser dette, men hvis vi først klarer å sette effektmål som sier hvilken endring vi skal oppnå for målgruppen, er vi i mye bedre stand til å identifisere slike avhengigheter.

En fordel vi hadde i vårt teameksempel, var at vi allerede hadde en strukturert tilnærming til OKR-prosessen og kontinuerlig læring i den. Som OKR-ambassadør og fasilitator, bidro Team Agile til rammene for samarbeidet. Prosessen fulgte logikken i figuren over: Ledelsen kommuniserte sine prioriteringer til teamene, som deretter satte OKR-er og presenterte dem til hverandre og ledelsen, for tilbakemelding og justering (alignment workshop). Deretter var OKR-ene aktive, men vi hadde også en strukturert felles vurdering av resultatene som var oppnådd og en retrospektiv på prosessen.

Basert på læringen fra første kvartal, fasiliterte vi flere spissede workshops for å sikre at team som ofte var avhengige av hverandre var godt koordinert. Vi inviterte også inn sentrale interessenter / ledere til å bidra med prioritering der det var nødvendig.

Slik fikk vi til en OKR-prosess på tvers av mange team som bidro til flere ting:

• En sterk knytning fra teamene til strategisk retning og felles prioriteringer – på tross av komplekse styringslinjer.
• Forenklet koordinering på tvers av team, gjennom både en felles rytme for målsetting og strukturerte workshops for å vurdere og håndtere avhengigheter.
• En effektiv tilbakemeldingsløyfe til ledelse om avhengigheter, behovet for prioritering og teamenes evne til å levere verdi.

Å bruke «tight-loose-tight»-tankegang på OKR-implementering er altså ganske nyttig. OKR-er kan gi en svært nyttig «tight» som tydeliggjør prioritering i starten av en periode. Med en god prosess rundt er denne også bedre koordinert og forankret med ledelse, interessenter og andre team. Det gir bedre forutsetning for reelt handlingsrom i «loose»-fasen. Den første «tighten» blir også bedre koordinert og forankret, noe som Med en strukturert oppfølging i etterkant, oppnår vi også refleksjon om resultater og læringen vi kan trekke ut av dette – altså siste «tight».

For å komme i gang med dette i ditt team, anbefaler vi at du begynner med disse grepene:

1. Vis frem OKR-ene så tidlig som mulig og spør etter andre team sine.
2. Forankre med interessenter og ledere.
3. Begynn – og sett læringen i system!

Slik kommer du i gang

Ved å unngå disse vanlige fallgruvene kan teamet ditt bruke OKR som et effektivt verktøy for fokus og verdiskapning.

Vaskefella​

• Start med problemet > Hvordan ser det ut når vi lykkes?​

Tredemøllefella​

• Investér i OKR og følg aktivt opp​

Brofella​

• Åpen prosess og sett læringen i system​

Sist, men ikke minst for å få andre resultater må du gjøre noe annerledes​..

Lykke til!