Vi befinner oss i et paradigmeskifte: Vi lager digitale produkter etter en metodikk som er radikalt annerledes enn hvordan vi gjorde det tidligere. Tidligere var det klassiske prosjekter som var standarden. Nå er det autonomi, målstyring og kontinuerlig leveranse som står i fokus. Omstillingen er mer omfattende enn mange innser når man starter. I denne artikkelen skal jeg ta for meg hvorfor dette er en totalolmveltning, hvilken kompetanse man trenger for å lykkes med det, samt hvordan modningsreisen typisk ser ut.

Hvorfor er omstillingen en totalomveltning?

Omstillingen er så omfattende fordi vi snur om på veldig mye, både i og rundt utviklingsteam. La oss starte med målbildet vårt, som ofte beskrives som «tight-loose-tight»: Vi ønsker at teamet har en tydelig definert retning og eierskap til det overordnede målbildet (den første tighten). Deretter skal teamet jobbe autonomt med å dekomponere dette målbildet til tiltak som vil bringe oss nærmere (loose, det er ikke detaljstyrt hva teamet jobber med). Avslutningsvis skal effektene (merk, ikke leveransene) som teamet leverer måles og følges opp (den siste tighten). Dette kan visualiseres som følger:

La oss hoppe noen år tilbake. Gigantprosjekter var standarden innenfor IT, hvor kravspesifiseringen om nøyaktig hva som skulle lages var jobbet med i årevis før en eneste kodelinje ble skrevet. Det var ikke uvanlig at leverandører skrev hundrevis av sider i en tilbudsprosess, og det kontraktuelle grunnlaget bestemte hva som skulle lages. Dersom prosjektet gikk skikkelig dårlig kunne man i verste fall havne i retten, hvor det ble diskutert hva man hadde laget sammenlignet med hva man hadde blitt enige om at skulle bli laget.

Fra perspektivet til et utviklingsteam hadde man tilnærmet ingen innflytelse på hva man skulle gjøre. Teamets ansvar var å implementere det som hadde blitt bestemt. Det var følgelig også streng kontroll på leveransene til teamet, for å sikre at disse var i tråd med det man hadde blitt enig om på forhånd. Når implementasjonsjobben var ferdig, gikk teamet videre til andre oppgaver. Det var ikke aktuelt at de skulle jobbe med gevinstrealisering eller måloppfølging. Ansvaret for det lå på utsiden av teamet, gjerne hos leder- eller strategifunksjoner høyere opp i virksomheten. Med andre ord hadde ikke teamet noe forhold til sine effekter. Vi kan beskrive dette som "loose-tight-loose" og visualisere det som følger:

Når vi ser dette historiske perspektivet opp mot målbildet ser vi at transformasjonen krever en totalomveltning av hvordan vi jobber. Dette krever ny kompetanse og kunnskap i teamene, samt i resten av virksomheten som er involvert i digital produktutvikling.

Hvilke fagfelt må vi beherske for å forsere dette gapet?

Vi må ha inngående kompetanse på fagfeltene som lar oss jobbe målstyrt og effektdrevet. I korte trekk er det tre fagfelt som utmerker seg som sentrale, som vi vil se nærmere på: Målstyring, hvordan jobbe med hypoteser, og hvordan være datadrevet.

1. OKR

Litt forenklet kan man si at målstyring handler om å styre etter mål, heller enn å styre etter leveranser. Objectives and Key Results (OKR) er rammeverket alle har hørt om, og som typisk brukes for å operasjonalisere målstyring for utviklingsteam. Det er skrevet mye bra om hva som utgjør gode ambisjoner og gode nøkkelresultater, og vi går derfor ikke videre inn på det her.

Et moment jeg opplever at er underkommunisert, er hvor lang tid det tar fra et team starter med OKR for første gang, til man får en betydelig effekt ut av det. En svært dyktig kollega fortalte meg en gang at dette gjerne ligger på mellom 12 og 24 måneder for et team. Jeg tror det stemmer ganske bra. Ofte er man svært reaktiv i starten, og det beholdes gjerne en predefinert backlog parallelt med OKRene i en lang periode. Gradvis lærer man seg å dekomponere nøkkelresultatene til tiltak. Disse tiltakene erstatter den tradisjonelle backlogen over tid.

Når samtlige oppgaver er utledet som tiltak fra nøkkelresultater er man i mål. Å komme dit krever kontinuerlig innsats og støtte fra både teamet og aktørene rundt: Det holder ikke å bare vente og tenke at det vil gå seg til over tid. For å lykkes med OKR i praksis må vi tenke på sammenhengene mellom hva vi ønsker (ambisjonene), hvordan vi måler om vi er på rett vei (nøkkelresultatene) og hva vi gjør (tiltak). Et sentralt verktøy som hjelper oss å konkretisere og tydeliggjøre disse sammenhengene er:

2. Hypotesedrevet metodikk

En sentral utfordring for å mestre bruken av OKR er det store gapet mellom et nøkkelresultat og gode tiltak. Et nøkkelresultat kan eksempelvis være å øke kundetilfredshet med en tjeneste, få flere kunder, eller øke bruken av tjenesten. Disse er brede av natur, og det er i teorien en mengde tiltak som vil bidra. Hvordan finner vi da de tiltakene som treffer best? I min erfaring er hypoteser et svært nyttig verktøy for å utlede gode tiltak fra nøkkelresultater.

Gode hypoteser baserer seg på kvalifiserte gjetninger om hva vi tror om brukerne og kundene. Her er vi også inne på selve kjernen i hvorfor tight-loose-tight er et målbilde: Det er folka i teamet som er best posisjonert for å komme med disse kvalifiserte gjetningene. Over tid vil de bygge opp en forståelse for både domenet, brukerne og kundene. Dette er en betydelig investering, og noe vi bør få verdi for.

Selve gevinsten i tight-loose-tight er nettopp det å få utnyttet potensialet som ligger i teamet. Grunnlaget for gode hypoteser baserer seg på både kvalitativ og kvantitativ innsikt, som tar oss videre til vårt siste fagfelt:

3. Datadreven

Du må bli datadreven for å få den kvantitative innsikten som trengs for å finne de beste hypotesene. Videre er det essensielt at vi har kvantitative data for å måle effekten i andre enden. Så langt har fagfeltene fokusert mye på den første tighten og loosen i midten, men den siste tighten er også viktig: Det er her vi følger opp at teamene har levert på det de har forpliktet seg til. Dette lener seg svært tungt på at man er datadrevet. De gode nyhetene er at dette er relativt enkelt å komme i gang med: Det finnes mange gode verktøy for å registrere, visualisere og følge opp data.

Datadrevenhet har vært i vinden de siste årene, som gjør at kompetansen man trenger er lett tilgjengelig. Merk at selv om det er lett å komme i gang med å jobbe med data, er det ikke lett å bli datadrevet. Det er i seg selv en betydelig modningsreise, og utenfor omfanget til denne artikkelen.

Samtlige teammedlemmer bør ha en grunnleggende forståelse for disse tre fagfeltene, og hvordan teamet er ment å jobbe. Lykkes man ikke med det vil det være vanskelig å nå målbildet om å drive tight-loose-light produktutvikling. Som en kollega skrev i en bloggpost allerede i 2013:

«Jeg vil jobbe med utviklere, ikke programmerere!»

Alle i teamet må bidra med sin kunnskap, og ikke utelukkende være en ekspert på sitt fagfelt. Det holder ikke at en teamleder eller produkteier har god kontroll: Da er vi nesten tilbake til der vi startet med en bestiller! Min hypotese er at dette vil være essensiell basiskompetanse for alle som lager digitale produkter om få år.

Hvordan ser modningsreisen typisk ut?

I modningsreisen mot målbildet om målstyrte team vil et team som regel gå i en del fallgruver. Min erfaring er at man veksler mellom overslag mot for mye autonomi og for mye kontroll. En typisk modningsreise ser ut omtrent som følger:

La oss se nærmere på disse 4 stadiene:

1. LTL (loose-tight-loose)

Beskrivelse: Dette er utgangspunktet vårt. Vi får bestillinger, og teamet har lite forhold til både de overordnede målene og effektene deres produkter har.

Utfordringer: Vi utnytter ikke potensialet i teamets kunnskap om brukerne, kundene og domenet. Vi har ikke fått tydeliggjort retningen for teamet, og teamet har ikke eierskap til sine effekter.

Hva bør man jobbe med? Overordnede mål må defineres og tydeliggjøres. Teamet må ta del i oppgaveutformingen. Effektene som teamets produkter har må synliggjøres.

2. LLL (loose-loose-loose)

Beskrivelse: Vi skal jobbe med autonome team, og har skjønt at det er viktig å involvere teamet i å definere oppgavene de skal jobbe med. Dessverre er ikke retningen forstått, og vi har ikke fått på plass gode koblinger enda. Teamet har kanskje definert OKRer, men de brukes i liten grad til proaktiv utledning av oppgaver: Det teamet jobber med var bestemt uavhengig av OKRene (og gjerne før de ble satt). Vi har heller ikke fått på plass målinger enda, i alle fall ikke på en måte som gjør at det er disse teamet blir målt på.

Utfordringer: Dette kan beskrives som «hjemme alene-fest», og er et typisk overslag mot autonomi. Autonomi uten retning og ansvarliggjøring er ikke godt nok. Ambisjonen må være myndiggjorte team, ikke full autonomi.

Hva bør man jobbe med? Tydeliggjør de overordnede målene og retningen teamet jobber mot. Invester i forståelsen av hypoteser og jobb mot å bli datadrevet. Husk at kvalitative data, eksempelvis det man får fra klassisk innsiktsarbeid, er vel så verdifullt som kvantitative. Dette kan hjelpe til å tette gapet i en fase hvor teamet jobber med å få til en god rigg for kvantitative data. Ansvarliggjør teamet på å måle og kommunisere sine effekter.

3. TTL (tight-tight-loose)

Beskrivelse: En svært vanlig motreaksjon på «hjemme alene-festen» er å gå tilbake til overslag mot kontroll. Som regel er man enige om at hovedårsaken til autonomioverslaget var at retningen ikke var godt nok definert. Det jobbes godt med dette, men parallelt vil ledere ofte gå tilbake til bestillinger for å føle at de har kontroll. Typisk har man ikke fått til feedback loopen ordentlig enda, det vil si ansvarliggjøringen av teamets evne til å levere på retningen som er satt. Dette følger naturlig ettersom retningen ikke var godt nok forstått.

Utfordringer: Ettersom teamet jobber etter bestillinger får vi ikke utnyttet deres kunnskap fullt ut. Mangel på gode data rundt effekter, samt kommunikasjon av disse, gjør at det blir vanskelig å måle teamet på dette heller enn utførte leveranser.

Hva bør man jobbe med? Å tydeliggjøre koblingene mellom teamets OKRer og retning ved hjelp av hypoteser vil bidra til at ledere kan slippe kontrollen og likevel føle seg trygge: Teamet har vist en forståelse for hva som skal oppnå, og har en klar tanke om hvordan de skal bidra. Videre må teamet jobbe med å bli datadrevne: Både for å understøtte hypotesene, samt kommunisere effektene de oppnår. Sistnevnte vil være viktig for at ledere skal føle at de ikke trenger å bestille leveranser.

4. TLT (tight-loose-tight)

Beskrivelse: Vi har fått på plass gode målinger og kommunikasjon rundt effekter. Retningen er godt forstått og ligger til grunn for teamets OKRer, som brytes ned løpende og proaktivt i tiltak av teamet selv. Gradvis forsvinner behovet for bestillinger, da teamet finner ut av hva som er de rette oppgavene å jobbe med på bakgrunn av hypoteser. Vi har gode metrikker og god kommunikasjon rundt teamets effekter som følge av at vi er datadrevet. Ledelsen måler teamet på deres effekter, heller enn leveranser.

Ikke alle modningsreiser er like, og fallgruvene skissert over er ikke de eneste man kan havne i. Jeg har valgt å trekke frem de jeg har observert flest av, og konkretisert disse så godt det lar seg gjøre. Som nevnt innledningsvis er min opplevelse at omfanget og varigheten på en slik modningsreise undervurderes. Derfor er vi tjent med å begynne å sette ord på dette og diskutere. Helst så tydelig som mulig med faktiske eksempler, heller enn overordnede buzzwords: Eksempelvis er det noe helt annet å lese om OKR-rammeverket og å operasjonalisere det i praksis for et utviklingsteam.

For de som befinner seg i starten av modningsreisen mot målstyrte team, og de som akkurat har begynt: Vær tålmodig! Dette er en krevende transformasjon, og det vil ta tid. Underveis vil teamene og andre interessenter ha overslag i flere retninger. Dette er en naturlig del av læringsprosessen, og noe man må gjennom for å komme i mål.

Det grunnleggende premisset for målbildet er som nevnt verdien som ligger i kunnskapen til teammedlemmene. Vi ønsker å få utnyttet dette til det fulle, og stoler på at de kjenner mulighetene bedre enn noen andre. I tillegg vil denne måten å jobbe på være mer motiverende: Teammedlemmene får større eierskap til det de jobber med i kraft av at de blir ansvarliggjort, og ved at de får innsikt i formålet til teamet. Dette gir mer produktive og effektive team, noe Google fant i Project Aristotle og som Dan Pink skriver om i Drive (se Drive oppsummert på YouTube).

Digitalisering har et mye større potensiale enn å "sette strøm på papiret": Vi kan revolusjonere måten tjenestene våre fungerer på. En viktig forutsetning for å utnytte dette potensialet er målstyrte og myndiggjorte team. Vi må slutte å tenke at X timer fra en utvikler skal gi Y kodelinjer. Kodelinjer gir ikke verdi i seg selv, og derfor er det heller ikke dette teamene bør styres ut fra. Noen ganger er det beste en utvikler kan gjøre å ta på seg en refleksvest, gå ut og møte kundene. Det blir ikke mange kodelinjer av det, men det er likevel svært verdifullt!

De som sitter tettest på, er de som får den største ekspertisen. Vår jobb er å tilrettelegge for dem. Det gjør vi ved å ha målstyrte team.