Å lage digitale produkter innenfor offentlig sektor handler, direkte eller indirekte, om å implementere politikk. At det tar tid, skal være en del av den politiske prosessen. Det skaper stabilitet, forankring og forutsigbarhet. Men det skaper også utfordringer for de som skal lage løsningene. Når vi driver med digitalisering, kommer den beste læringen om mulighetene, utfordringene og gevinstene når vi jobber med å faktisk lage ting.

Denne avstanden skaper noen utfordringer som gjør digital produktutvikling i offentlig sektor ekstra vanskelig. I denne artikkelen skal vi se på hva disse utfordringene er, hvor de kommer fra, og hva det krever av et team å håndtere dem.

Hvis du ser mange nok team drive med digital produktutvikling i små og store selskaper på tvers av bransjer, er det overraskende hvor gjenkjennbare problemer der står i. Likevel er det noen utfordringer som tar en litt egen form i offentlig sektor.

Her vi skal vi ta for oss fire av disse utfordringene, og si litt om hva et utviklingsteam kan gjøre for å løse dem.

M’en i Minimum Viable Product er svær

Å definere MVPer er vanskelig. Og det blir ikke noe lettere når bestillingen din er å implementere en reform eller et lovverk, som på ingen måte presiserer en del som er mer eller mindre viktig. Eller en del av loven som kan implementeres når kjernefunksjonaliteten bare er i produksjon.

Den spesielle utfordringen i offentlig sektor er at et produkt som ikke er komplett, fort kan være et produkt som er ulovlig. Å finne den vertikalen av produktet som kan lages og testes isolert, samtidig som den totale risikoen er håndtert, krever kreativitet og tett samarbeid mellom utviklere, designere, jurister, fageksperter og ledere.

Hvis teamet ikke klarer å finne en mindre MVP som både er brukbar og lovlig, kan de gjerne ende opp med implementasjonsløp som går over flere måneder og gjerne år før den kan tas i bruk i produksjon. Når løsningen da først går i produksjon, blir overgangen fra en lang produksjonsfase til å jobbe utforskende med eksperimenter, effekt og læring fort vanskelig. Å jobbe utforskende for å skape gode brukeropplevelse og effekt er en annen modus, som krever en annen kultur, prosess og dels kompetanse, enn å være i leveransemodus.

Å håndtere denne overgangen krever en stor grad av bevissthet både i og rundt teamet. Det aller viktigste er at teamet jobber hardt og bevisst med å finne ut hvordan de kan gjøre MVPen sin så liten som mulig, og hvordan de kan begynne å lære så tidlig som mulig. Videre må de ha et konstant fokus på hvordan de kan få noe i produksjon, og begynne å eksperimentere og lære. Det krever også en god dialog med omgivelsene rundt teamet for å håndtere risikoen med å gå i produksjon med noe som ikke dekker alle juridiske krav.

Stor avstand fra utforming av lovverk til produktutvikling

Tanken om det digitale produktutviklingsteamet kommer fra anerkjennelsen av mulighetsrommet ved digitalisering først blir kjent når man jobber i dybden med å implementere produktet. Det står i stor kontrast til en verden der mange sentrale beslutninger om det som skal lages blir tatt før det i det hele tatt er tenkt en tanke om teamet som skal lage det. Når produktutviklingsteamet først er satt og begynner å høste erfaringer, er veien tilbake til å utfordre forutsetningene lang. Det gjør at teamene ender opp med å måtte lage løsninger som er vanskeligere å bruke og bommer på intensjonen bak.



Som regel finnes det et handlingsrom gjennom gode ledere og jurister som støtter teamene i prosessen og dialogen ovenfor interne juridiske miljøer og bestillere i departementet. Dette er en prosess som burde vært bedre forstått og definert: hva kan utfordres, når kan de diskusjonene tas og hva er prosessen for å gjøre det?

Dette må starte med produktutviklingsteamene. Det er de som kjenner hvor skoen trykker, og hvor potensialet ligger. Det krever team som er bevisste på verdiskapning og målene sine. Når de finner muligheter må de vurdere i hvilken grad den er i tråd med intensjonen bak lovverket, og klare å formidle utfordringen og effekten det kan skape. Det forutsetter også at teamet har god støtte fra omgivelsene rundt seg, og klarer å navigere organisasjonen og finne fram til folkene som kan hjelpe dem med å ta vanskelige diskusjoner. For å lykkes med det, trenger de å jobbe godt på tvers av fagområder som teknologi, design og juss.

Vanskelig samarbeid på tvers av ulike fagområder og kulturer

Det begynner heldigvis å bli mer og mer vanlig at produktutviklingsteam settes sammen med bredden av fagområder som trengs for å levere. I offentlig sektor betyr det at teamene ikke bare består av tradisjonelle produktutviklere som designere og teknologer, men også jurister og representanter for faget, som for eksempel saksbehandlere.

Å jobbe så bredt tverrfaglig krever en stor investering i kultur for samarbeid og å forstå hverandre sine perspektiver. Uten bevisst, hardt arbeid for å lykkes med samarbeidet på tvers, ender teamene fort opp med å være flerfaglige heller enn tverrfaglige. I flerfaglige team jobber folk fra ulike fagdisipliner i parallell med hverandre, uten at de i nevneverdig grad klarer å skape ekstra verdi med å jobbe sammen. I tverrfaglige team skjer et mest interessante i grensegangen mellom ulike fagområder, der teammedlemmene bruker perspektivene fra hvert sitt fagfelt til å skape en bedre og mer kreativ helhet enn de kunne gjort hver for seg.

Samarbeidet blir ekstra vanskelig når folk kommer fra veldig ulike bakgrunner. Tidligere betydde «tverrfaglig» typisk samarbeid mellom utviklere og designere, som stort sett kommer fra de samme skolene og har vokst opp med teamarbeid. Jurister og fagspesialister kommer ofte fra studiebakgrunner og miljøer der individuelt arbeid er vanlig, og organiseringen er mer hierarkisk. Da kan møtet med et flatt organisert, smidig og autonomt produktteam by på en kulturkræsj.

Å lykkes med dette samarbeidet krever at alle i teamet går inn med en bevissthet om verdien av å jobbe tverrfaglig, og er villige til å investere i å få teamet til å fungere. Det betyr å bruke tid og krefter på å forstå hverandre sine fagfelt, snakke om samarbeidet og hvorfor det er vanskelig, og å være forberedt på å endre måten man jobber på selv.

I brede tverrfaglige team er det også sannsynlig at man trenger en teamleder som kan olje maskineriet. 

En finansieringsform som ikke legger til rette for læring

Det er skrevet og sagt mye klokt om finansieringsmodellen for prosjekter i offentlig sektor. Og det er vel egentlig ingen som mener måten vi gjør det på i dag funker. Det vanligste er fortsatt prosjektfinansiering, der det settes av en stor pott penger, et sett gevinster som skal realiseres og en frist. Og så er det bare å sette i gang med å levere.

Dette er omtrent det motsatte av de forutsetningene du trenger for å drive god produktutvikling. Gode produkter oppstår når team eier et produkt over lang tid, og kan iterere gjennom å utfordre, teste hypoteser, måle effekt og lære.



For produktutviklingsteamene er dette først og fremst en rammebetingelse det er viktig å forstå og anerkjenne. Det er lov håpe, men samtidig er det nok lenge til statsbudsjettet legger til rette for smidig utvikling. Når det er virkeligheten, er det desto viktigere å alltid ha fokus på hvilket problem er det egentlig vi prøver å løse her, og hvorfor er det verdt å løse? Hva er den underliggende verdien vi prøver å levere til befolkningen?

Heldigvis er det mange ledere i offentlig sektor som er flinke til å jobbe kreativt med både driftsmidler og prosjektfinansiering. Hvis ledere klarer å snu forutsetningene rundt til å være best mulig, og teamene jobber bevisst med å skape verdi, så skal det fortsatt være fullt mulig til å jobbe ekte produktutvikling. Selv om den grunnleggende finanseringen er til hinder heller enn støtte.

Digital produktutvikling er et problem som er verdt å løse

Digital produktutvikling i offentlig sektor er vanskelig. Men det er det i privat sektor også! Selv om utfordringene jeg har beskrevet er ekstra store i offentlig sektor, så finner du du variasjoner samme problemene i de fleste team som driver med produktutvikling.

I moderne team drar vi ikke på jobb for å levere kode eller lage funksjonalitet. Vi drar på jobb for å skape verdi. Det handler om at vi må ta eierskap til problemene vi prøver å løse, og er villige til å jobbe med rammebetingelsene. Spesielt når rammebetingelsene er vanskelige. Noen forutsetninger er vanskelig å gjøre noe med, men det går aldri hvis du ikke prøver.

Offentlig sektor i Norge står ovenfor store effektiviseringsutfordringer i årene som kommer, og mye av løsningen ligger i vellykket digitalisering. For å få til det er vi avhengige av å lykkes med digital produktutvikling.

Så oppfordringen er: ikke gi opp å jobbe for å få det til bedre! Jobb for å få til en MVP som lar dere teste hypoteser og verifisere at løsningene deres virker. Jobb for å lage det riktige produktet innenfor lovverket, og jobb for å justere lovverket sånn at produktet blir riktig. Jobb for å få til det krevende, brede tverrfaglige samarbeidet. Og jobb for å levere på det underliggende målet selv om rammebetingelsene er utfordrende.

For lykkes vi med det, så lykkes vi med å skape bedre tjenester for oss alle, og en mer en mer bærekraftig offentlig sektor i fremtiden.

Fire utfordringer for digitale produktutviklingsteam i offentlig sektor

Retrospektiv. Et gammelt, såre enkelt og supereffektivt verktøy for å skape kontinuerlig forbedring i team. Jeg vil si at retrospektiver, gjort riktig, er et av de beste verktøyene et team har for å bli velfungerende. Men hvorfor gjør ikke alle det da?

Les videre for en enkel innføring i effektive retrospektiver, og noen tips om hvor det ofte går feil!

Vi har sluttet å ha retrospektiver, fordi vi ikke får nok tid til å kode.

… sa ingen team som var i ferd med knekke koden, noen sinne.



Den egenskapen, over noen annen, som går igjen i høytpresterende team jeg har sett, er en velfungerende prosess for retrospektiver. Forklaringen er enkel: i retrospektiven tar teamet tak i ett og ett problem, løser dem og blir litt bedre. Uke etter uke, måned etter måned. Team som gjør dette hyppig, vil over tid ha løst en drøss med problemer.

På den andre siden har du team som enten ikke har retrospektiver, eller som ikke får dem til å fungere. Prosesser gror fast, problemer som dukker opp blir ikke løst og teamet klarer ikke å tilpasse seg endringer i konteksten rundt seg. Teamet står i beste fall stille, men vil også ha en tendens til å bli gradvis verre.

Hva skal til for å lykkes med retrospektiver?

Hvis det er så enkelt som at retrospektiver gir høytpresterende team, så burde vel alle team være høytpresterende? For så vanskelig er det ikke å kalle inn til en retro innimellom. Dessverre er det korrelasjon og ikke kausalitet vi snakker om her: høytpresterende team vil veldig ofte ha en velfungerende prosess for retrospektiver. Det betyr ikke at alle team som har retrospektiver er høytpresterende. Så la oss fokusere på det vi kan gjøre noe med: velfungerende retrospektiver.

Velfungerende retrospektiver har noen enkle, og helt avgjørende, egenskaper:

De er regelmessige og hyppige. Helst annenhver uke. Hver tredje uke er ok, sjeldnere enn det sannsynligvis for sjelden.

Alle i teamet bidrar og kommer med innspill og forslag.

Oppfølgingspunktene er konkrete, har et realistisk omfang og en tydelig person som er ansvarlig for å følge dem opp.

Det er aksept i og rundt teamet for å bruke tid på prosessforbedring.

Medlemmene i teamet er åpne for endring, og er villige til å teste nye ting for å se om det virker.

En enkel retro som virker bra

Jeg holder dritkjedelige retroer.

Det finnes en haug bedre måter å gjøre det på, men i prinsippet holder det plenty med gode gamle mer, mindre, prøv. Og så har jeg funnet gleden i å legge til en fjerde «jeg lurer på» for å ha en plass å la folk spekulere litt uten å mene for mye.



Herfra gjør jeg det veldig enkelt:

Sett av en fast tid, for eksempel fem minutter, der alle skriver lapper for alle kategoriene.

En og en går gjennom lappene sine, presenterer dem og henger opp. Det er lov å stille spørsmål for å forstå, men det er ikke tid for å diskutere lappene enda.

Jeg liker å gruppere lappene underveis, sånn at det blir lettere å holde oversikt over temaer og å finne igjen enkeltlapper etterpå. Pass på å ikke lage for brede kategorier. Det bør være ting det går an å finne tiltak for!

Når alle har presentert lappene sine og de er gruppert, er det tid for å stemme. Tre til fem stemmer per person pleier å fungere bra, men det kommer an på størrelsen på teamet og antallet temaer. Jeg pleier be folk stemme på de grupperte temaene, ikke enkeltlapper.

Tell opp stemmene, og gå gjennom de 2-3 temaene som fikk flest stemmer.

Bli enige om konkrete oppfølgingstiltak for temaene som ble stemt fram. Diskutér og bli enige om forbedringstiltak. Tiltakene trenger ikke være det som står på lappene fra før. Terskelen for å teste noe bør være lav – det er uansett bare for de neste 2-3 ukene. Det er mye bedre å prøve noe, enn å ende opp med å ikke gjøre noen ting. Det har en egen verdi å trene endringsmuskelen!

Bli enige om hvem som følger opp hvert tiltak. Den som er ansvarlig for et tiltak legger det inn langt oppe i backloggen med en gang, sånn at det blir prioritert, synliggjort og ikke glemmes.

Merk at det aller viktigste kommer på slutten: konkretisering av tiltak. Hvis dere ofte går tom for tid uten å ha konkretisert tiltakene, må dere enten sette av mer tid eller begynne med bedre tidsstyring.





Hvor går det feil?

Hvordan vet dere om retrospektiven dere har i dag virker? Den enkle sjekken er: lykkes dere med å løpende implementere forbedringer?

Den vanligste feilen team gjør med retrospektiver er at de ikke klarer å sette konkrete oppfølgingstiltak og gjennomføre dem. Det kan være fordi de går tom for tid, fordi ingen tar på seg å konkretisere, eller fordi teamet ikke er lojale mot det de blir enige om.

Noen vanlige problemer å se etter

Retrospektiven blir lang, gjerne litt klagete, og munner ut i en haug lite konkrete oppfølgingstiltak som ikke blir gjort noe med

Ofte et symptom på at man har retrospektiver for sjelden. Det bygger seg opp for mye gruff som må tømmes ut samtidig. Bruk timeboxer, og sett et lavt maks antall lapper for hver enkelt deltaker, sånn at folk må prioritere det som er viktig.

Ha retrospektiver ofte, gjerne hver andre eller tredje uke, med høy terskel for å avlyse.

De fleste lappene som deles er overfladiske, og gjerne nøytralt positive: «god stemning i teamet!» 

Er det egentlig psykologisk trygghet i teamet? Tør dere være ærlige og snakke om ting dere er uenige om? Ikke mist motet! Start med å gjøre endringer på mindre kontroversielle deler av prosessen, og øv på å snakke om ting som gjør vondt.

Vanskelig å bli enige om oppfølgingspunkter. Folk klarer ikke komme opp med konkrete forslag, eller folk er uenige i hva som er riktig løsning

Handler ofte om dynamikk og psykologisk trygghet i teamet. Bli enige om at tiltakene er eksperimenter som dere tester ut til neste retro. Hvis det ikke virker er det bare å rulle det tilbake igjen! Ta dere tid til å snakke om hvorfor dere er uenige, og hva som gjør at dere ikke er villige til å teste ut en endring.

Ingen ønsker å ta på seg ansvaret for tiltak, eventuelt at samme personer blir sittende med ansvaret hver gang

Ofte et tegn på at teamet føler seg overveldet av mengden arbeid. Noen ganger har et team en ekte frist som gjør at det faktisk ikke er tid til å jobbe med prosess. Mer vanlig er det at teamet er fanget i et nedadgående spiral, med dårlig fungerende prosess og uklare mål, som gjør at teamet opplever at det konstant er veldig travelt. Det er nettopp i slike team at det virkelig er viktig å jobbe med prosess!

Tiltakene man blir enige om blir ikke gjennomført

Folk i teamet opplever ikke at det er akseptert å prioritere tid på prosessforbedringer. Dette handler oftere om følelsen man har selv, enn om hva som faktisk er greit å gjøre. Sørg for å få lagt inn oppfølgingsiltakene i backloggen, og gi dem høy prioritet!

Avslutningsvis

En god prosess for retrospektiver skal være enkelt, og jeg mener det er noe alle team bør klare selv uten ekstern fasilitering. Noen ganger kan det være vanskelig å få til, fordi det er større dysfunksjoner som ligger bak. Som manglende psykologisk trygghet, dårlig ledelse eller uklare rammer og kontekst rundt teamet. I disse tilfellene vil dårlige retrospektiver ofte være et symptom som kan være til hjelp med å forstå at det er et problem i teamet som trenger å løses. Og det i seg selv er verdt veldig mye!

Så oppfordringen min er: har dere ikke retrospektiver i dag? Sett i gang nå! Har dere retrospektiver som ikke virker? Da er det på tide å stille spørsmål om hvorfor – og be om hjelp hvis dere virkelig ikke får det til å sitte. Da er det sannsynligvis andre problemer som også bør løses!

For team som begynner å få sving på retrospektivene sine, så vil jeg på det sterkeste anbefale retrobanken til Sigrid, Emilie, Puru og Ragnhild. Jeg mistenker de holder vesentlig mindre kjedelige retrospektiver enn meg!

Retrospektiver: det enkleste og viktigste verktøyet et utviklingsteam har

Har du kjent på utfordringer med å ta i bruk OKR for et utviklingsteam? Er produktstrategien din for svevende? Er du lei av å høre at vi skal jobbe "tight-loose-tight", når ingen klarer å forklare hva dette egentlig innebærer? Modningsreisen mot målstyrte team er krevende, og den setter betydelige krav til innsatsen man må legge inn for å komme i mål. 

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. 



Process

Fire utfordringer for digitale produktutviklingsteam i offentlig sektor

Retrospektiver: det enkleste og viktigste verktøyet et utviklingsteam har

Modningsreisen mot målstyrte team