Postmortem er et nyttig verktøy for å finne ut hvorfor noe feilet. Det er sunt og bra at vi kan lære av feilene våre så de ikke gjentar seg. Men hva om noen fortalte deg på forhånd at prosjektet ditt kom til å feile, hadde du klart å finne ut av hvorfor?

En premortem tar sikte på å gjøre akkurat det: I starten av et prosjekt samler teamet seg til en øvelse der man ser for seg at man er f.eks. 1 år frem i tid, og prosjektet man jobber med har feilet spektakulært. Teamets oppgave er da å finne grunner til hvorfor prosjektet feilet.

Man gjør dette ved å individuelt skrive lapper om alt man kan se for seg at kan gå galt med prosjektet. Så leser alle lappene sine, og man kan diskutere enten hver lapp eller noen utvalgte lapper.

Det at man skal late som at man er i en fremtid der prosjektet har feilet kan kanskje virke litt unødvendig. Men det kan gjøre noe med hvor villige teammedlemmene er til å lete etter feil, når man starter med premisset om at feilen allerede har skjedd, og man bare skal finne den.

For noen kan det også føles tryggere å være "negativ" i en situasjon hvor det å lete etter feil en felles oppgave for hele teamet. I starten av et prosjekt, når alle er gira og entusiastiske, kan det være spesielt vanskelig å fokusere på problemer. Man vil kanskje ikke oppleves som vanskelig, eller som at man ikke er motivert for å få prosjektet til å fungere. En premortem kan gjøre det lettere å ta opp utfordringer som man kanskje allerede har tenkt på, men som man ikke har hatt lyst til å ta opp før.

Så, hadde du klart å forutsi hvorfor prosjektet ditt vil feile? Kjør en premortem og se da vel!

Premortem - eller hvorfor kommer prosjektet vårt til å feile?

Å 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

Vi som er teamledere gjør mye forskjellig. Her er en oppsummering av noe av det vi bruker tid på som teamledere i tverrfaglige produktteam.

Organisasjonen, teamets medlemmer og roller varierer stort fra plass til plass. Har teamet en tech-lead? Har teamet-en produktleder? Er organisasjonen godt kjent med digital produktutvikling? Svaret på dette, og mange flere spørsmål, definerer hva teamlederrollen innebærer. 

I tillegg er den delen av rollen som skjer utenfor teamet ikke alltid så synlig for de som sitter igjen når teamleder løper i møter med folk utenfor teamets trygge rammer. 

Derfor satt vi oss ned en vakker dag i Trondheim i vårt teamleder-forum og diskuterte hva vi legger i en slik rolle. Vi hadde jo flere forskjellige perspektiver og detaljene varierer, men essensen vi kom fram til er denne:

Sikrer teamets retning og mål 🎯

Som teamledere sørger vi for at teamet har en retning og målbare mål som gir mening på kort sikt. Dette målet og denne retningen må i tillegg forstås på samme måte av alle teamets medlemmer. Vi sikrer at teamet kan fokusere på målet og har oppgaver som understøtter dette. Hva, for hvem og hvorfor er kjent for alle i teamet. Og de rundt som trenger å vite det.

Er teamets beskytter 🛡️

Som teamledere beskytter vi teamet ved å avklare antagelser og rammebetingelser, har et blikk på hindringer og risiko teamet kan støte på og er et ansikt for teamet rundt om i organisasjonen. Vi er tilstede der vi behøves, samtidig som vi sørger for at teamet har den nødvendige ro og trygghet for å jobbe effektivt mot målene sine. Som gulvet i teamet fanger vi opp det som måtte glippe og tar ansvar der det trengs. Vi følger opp det organisasjonen mener er viktig rundt teamet, det være seg OKR, budsjetter eller måloppnåelse, samtidig som vi er realistiske i henhold til organisasjonens endringskapasitet når vi dytter i andre retninger.

Fasiliterer passende prosess 📈

Vi sikrer en prosess og metodikk i teamet som passer i henhold til teamets samlede kompetanse og mål, og mulighetene som ligger i organisasjonen. Samtidig er vi gode eksempler for team rundt oss som ønsker å lære. Vi er smøreoljen som sikrer fart og flyt. Som innen- og utenriksminister balanserer vi fokus basert på hva teamet og organisasjonen trenger nå, og beveger oss tilpasningsdyktig inn og ut av roller. Vi samler de som trenger å prate sammen og får dem til å kommunisere med hverandre.

Bygger trygge og robuste folk rundt oss ❤️

Ved å være oss selv og ikke redde for å gjøre feil, ønsker vi å gjøre oss selv og andre rundt oss bedre. Vi ser folkene teamet består av, vet hver enkelts godfot og legger til rette for samskaping av teamets resultater. Som teamledere vet vi at trygghet, tillit og trivsel bygges ved å jobbe og lykkes sammen. Derfor står vi sammen med teamet og deler ærlig gleder og sorger. Vi bygger opp enkeltpersoner ved å være både coach, rådgiver og alt imellom. Vi gir rom for at andre lykkes og gir gjerne fra oss oppgaver.

Tenker på helheten 🌍

Vi er teamets mikrofon. Vi sier fra om muligheter vi ser, og har et forhold til hvorfor teamet eksisterer og hva vi ønsker å få ut av arbeidet. Vi er reflekterte over teamets sammensetning og kapasitet, sett opp mot dagens og framtidens mål. Vi er i forkant, og sier fra heller en gang for mye enn en gang for lite.

For å oppnå alt dette bruker vi folkene i teamet og rundt oss til å hjelpe oss. Vi vet at kun sammen kan vi lykkes.

Og møter. Det blir en del møter óg.

Teamwork

Premortem - eller hvorfor kommer prosjektet vårt til å feile?

Fire utfordringer for digitale produktutviklingsteam i offentlig sektor

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

Hva gjør egentlig en teamleder?