Hvordan lede IT-utvikling uten å detaljstyre?

Flere av Kantegas kunder har tatt i bruk eller prøver ut OKR, på den måten at en jobber mot effektmål i stedet for aktivitetsmål (mer om dette under). Noen forsøk har lyktes, andre jobber fortsatt med å finne formen. Vi er flere i Kantega som har gjort oss erfaringer med prinsippene og vi har tro på at dette kan være en god måte å løse utfordringene på.

For min egen del har jeg opplevd at det i praksis er krevende å definere gode og inspirerende mål (Objectives), og ikke minst metrikker (Key Results) som er kvantifiserbare og som en kan måle framgang opp mot. En annen utfordring er tilgang til data som kan fortelle om aktiviteter teamet har gjennomført faktisk har fått en effekt. Tilbakemeldingene er heller ikke alltid entydige. Utfordringene kan bidra til at en faller tilbake til gamle vaner, hvor en leverer funksjonalitet uten å justere basert på feedback. Og denne måten å jobbe på kan jo være effektiv, så lenge løsningen er åpenbar.

Så hvorfor skal en da bruke energi på å innføre OKR?

Håndtere kompleksitet og uforutsigbarhet

Svaret kan være at løsningen ofte ikke er forutsigbar. IT-prosjekter flest preges nettopp av kompleksitet og uforutsigbarhet, noe som krever en arbeidsmåte som består i å prøve ut nye løsninger, observere hvilke som gir den effekten man er ute etter, og korrigere kursen ut fra dette. Hvis en står overfor uforutsigbarhet, så kan en ikke vite om løsningen gir den forventede verdien uten at en legger til rette for læring og skaper rom for å tenke alternativt. Autonomi er for eksempel lurt når det er uforutsigbart hvordan produktet vil bli mottatt, altså når det er usikkert om kundene vil bruke eller ønsker å betale for det løsningen tilbyr. 

For å sitere artikkelen jeg lenket til over: «Hvis markedet er relativt stabilt er det ikke så vanskelig å forutsi om det vi leverer er ønskelig og levedyktig. Men hvis markedet har stor fart er det mye vanskeligere. Man må ta små steg og teste ut. Det betyr at hvis organisasjonen er i et marked med stor fart må teamet ha autonomi til å ta raske beslutninger om hva de tror er ønsket og vil gi levedyktighet».

Hvordan kan ledere legge til rette for autonomi?

Min kollega Kristin Wulff poengterte også nylig at ledere mer enn noen gang trenger kapasitet til å tenke strategisk. Hun oppfordret til å dempe kontrollbehovet og heller legge til rette for koordinering, for eksempel gjennom tverrfaglige team med gjensidig tilpasning. I en kompleks hverdag fungerer dette best. Men forskere i Sintef har funnet at mange ledere fungerer som en brems for autonome team, ofte fordi teamene ikke får den tilliten og friheten som kreves. En av forskernes hypoteser er at mange ledere blir usikre på hvordan de skal lede sine team når de går fra klassisk prosjektstyring til å bruke autonome team.

Men hvordan kan utviklingsarbeidet ledes og koordineres når en ikke kan vite på forhånd hva som er den beste løsningen? Hva er alternativet til å spesifisere og estimere funksjonalitet en ønsker å få utviklet?

Verdibaserte mål

En mulighet kan altså være å definere effektmål for utviklingsarbeidet (verdien en ønsker at teamet skal skape for kunden og organisasjonen) i stedet for aktivitetsbaserte mål (hvilke aktiviteter teamet skal gjennomføre og hva det skal levere).

Enkelt forklart så handler den aktivitetsbaserte tilnærmingen om å utføre en gitt oppgave eller aktivitet til et gitt tidspunkt. For eksempel å lansere en ny versjon av nettbutikken med forbedret design innen en gitt dato. Motsatsen er et effektmål, som konkretiserer verdien aktiviteten tilfører kunden og organisasjonen i form av en kvantifiserbar metrikk (verdibasert KR). For eksempel kan et verdibasert KR være at andelen kunder som kommer tilbake til nettbutikken for å kjøpe flere produkter skal øke fra 20% til 30 %.

Men det er enklere sagt enn gjort å definere gode effektmål som knytter teamets arbeid sammen med virksomhetsmålene. Og om en klarer det er det ikke gitt at ledelse eller team forholder seg til målene etter at de er satt. En åpenbar risiko er at teamet fortsetter å jobbe som før, og at ledelse og andre interessenter fortsetter å stille de samme krav til forutsigbarhet og leveranser som en alltid har gjort. Og det er i denne sammenhengen at OKR-prinsippene kan være til hjelp.

Hva er OKR?

OKR har sin opprinnelse i Intel. Andy Grove utviklet og ledet selskapet basert på prinsippene, og tok Intel gjennom en vellykket overgang fra produksjon av minnebrikker til mikroprosessorer. OKR har senere spredt seg videre til andre selskaper i Silicon Valley, inkludert Google.

I «The Beginner's Guide to OKR» beskriver Felipe Castro OKR (fritt oversatt) som "en enkel tilnærming for å sikre felles forståelse og engasjement rundt målbare og ambisiøse mål”.

Ifølge Felipe Castro er forskjellen på OKR og tradisjonelle planleggingsmetoder at OKR-ene settes, følges opp og evalueres hyppig, og at teamets synspunkter og kreativitet ivaretas ved at de taktiske målene settes i et samspill med ledelsen og andre interessenter. Kortsiktige, taktiske mål (gjerne kvartalsvise) bygger opp under langsiktige, strategiske mål (hvor en gjerne sikter 12 måneder fram i tid). Hensikten er at alle skal gå i samme retning, med klare prioriteringer, i en konstant rytme.

Hva betyr det i praksis?

Rent praktisk kan dette bety (selvfølgelig avhengig av hvordan en har valgt å adoptere OKR) at teamet selv definerer og prioriterer oppgaver og løsninger som de mener er nødvendig for å nå de kortsiktige målene, og at de også innhenter feedback for å finne ut om løsningene hadde den forventede effekten. At teamet jobber mot effektmål gir både flere valgmuligheter, fordi en kan nå målet med ulike midler, og det gir muligheten for å finne andre løsninger dersom noe ikke fungerte som forventet.

Utholdenhet og kontinuerlig forbedring

Det finnes ingen enkel oppskrift på hvordan en tar i bruk OKR, og ambisjonen med denne artikkelen er ikke å tilby dette. Men alle som prøver å innføre OKR vil møte utfordringer, og skal jeg gi et råd er det å se på dette som en endringsprosess som krever utholdenhet og kontinuerlig forbedring.

Utholdenheten kan støttes av det Felipe Castro kaller en OKR-syklus, som innebærer tre steg som repeteres kvartalsvis. For at ikke OKR-ene skal ende opp som nyttårsforsett er en ukentlig innsjekk en del av syklusen. Christina Wodtke foreslår "Monday commitments” og “Friday wins” i en ukentlig rytme for å ivareta både forpliktelse og feiring av de små seirene av kontinuerlig forbedring.

Det finnes mye nyttig litteratur om OKR som kan være til hjelp. Mens «The Beginner's Guide to OKR» nettopp er en enkel og kortfattet introduksjon til OKR, tilbyr «Radical Focus» råd og verktøy for å håndtere utfordringene som teamet vil møte på. «Measure what Matters» er en fortelling om røttene til OKR, og er nyttig blant annet fordi boka behandler bruk av OKR i en større organisasjon.

Mål og mening øker motivasjonen

Samtidig som en må være obs på fallgruvene ved innføring av OKR, så er det viktig å huske på hva en kan oppnå. Det handler ikke bare om å legge til rette for innovasjon og økt verdiskapning for virksomheten. Det kan også bidra til intern motivasjon ved at arbeidet oppleves som mer meningsfylt, og at den enkelte opplever et personlig ansvar for og har kunnskap om resultatene av arbeidet. Noe en altså kan oppnå ved å sette retning, i stedet for å kontrollere og detaljstyre.

Hvor skal en begynne?

Så hvor skal en begynne om en ønsker å innføre OKR? Dette spørsmålet har nok ikke bare ett svar, og krever egentlig en egen artikkel. En god start kan være å få formulert gode og presise mål (som beskrevet i neste avsnitt). Min erfaring er at dette er en krevende øvelse i seg selv. Forbindelsen mellom teamets oppgaver og de strategiske målene kan for eksempel være diffus, og det kan være nødvendig å kartlegge sammenhengene. Jeg har erfart at Impact Mapping kan være et nyttig verktøy til dette formålet. Formulering av “Problem statements” kan også være nyttig for å gi en presis beskrivelse av sammenhengen mellom utfordringer og mål.

Formulering av mål

Dette forarbeidet kan forenkle arbeidet med å definere OKR-ene. Se gjerne denne malen fra Christina Wodtke for hvordan en planlegger og gjennomfører møter hvor det settes mål. Felipe Castro tilbyr et "OKR Cheat Sheet" som beskriver detaljene for hvordan et mål kan beskrives, sammen med noen eksempler.

Målformelen, som krediteres John Doerr, er

I will (Objective) as measured by (this set of Key Results)

Målet (Objective) er kvalitativt. Det bør være inspirerende og enkelt og huske. Mens metrikkene (Key Results) skal være mulig å kvantifisere – det er disse framgangen skal måles opp mot.

Dersom det kvalitative målet er en unik brukeropplevelse, må metrikkene kunne fortelle teamet om innsatsen bringer en nærmere målet. Eksemplet fra tidligere (andelen kunder som kommer tilbake til nettbutikken for å kjøpe flere produkter skal øke fra 20% til 30 %) er et verdibasert KR.

Som nevnt over: Dette verdibaserte målet gir teamet autonomi og rom for å finne ut av hvilke aktiviteter og løsninger som er nødvendig for å nå målet, noe som både bidrar til økt innovasjon og redusert risiko.

Har du erfaring med OKR?

Det finnes altså flere gode grunner for å lede uten å detaljstyre. OKR er ikke fasiten, men kan bidra til å skape det nødvendige rommet for at innovative IT-løsninger kan oppstå. Jeg og andre i Kantega gjør oss nå erfaringer med OKR sammen med flere av kundene våre. Prinsippene er nyttige ledetråder, men innføringen krever både improvisering og at en lærer og tilpasser seg kontinuerlig basert på erfaringer.

Derfor er vi også nysgjerrige på hva andre gjør. Har du erfaringer med, eller planer om å innføre OKR? Del gjerne dine erfaringer og tanker i kommentartråden.

Anbefalt lesning:

• The Beginner's Guide to OKR, av Felipe Castro
• Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results, av Christina Wodtke
• Measure What Matters, av John Doerr