Hvordan lage en «tykk MVP»?

For at verdisløyfa — eller verdistrømmen om du vil — faktisk skal realisere verdi trengs det å bygges flere biter flere steder, det er ikke nok med en liten første rakett.

Først «tykk MVP» — hva er det?

Hvorfor oppstår behovet for en “tykk MVP”, er det ikke bare å finne frem “kniven”?

Noen oppdrag er som å være på en supertanker, noen er som å kjøre speedboat. En offentlig etat som er midt inne i digital omstilling er mer det første, det er ikke bare-bare å kjøre “full speed ahead” og snu skuta når det passer akkurat ditt produktteam, samtidig så haster det ofte med den digitale transformasjonen av dagens prosesser. I en stor virksomhet er det ofte mye Work-In-Progress på mange ulike systemer samtidig og mange interessenter, som gjør at Rett-I-Prod med en MVP ikke funker som i Lean Start-up-boka.

Det juridiske løpet er som regel også mer omfattende når jobben til de digitale produktene i etaten faktisk i stor grad skal levere nettopp det — juridisk etterlevelse. Det er fagpersoner som skal gjøre en jobb i et fagsystem, basert på lovverk og instrukser, og de og systemene skal gjerne behandle sensitive opplysninger om oss samfunnsborgere. Det er ikke uten grunn at NAV for eksempel nå har produkt-firkløver-team der juristen er det fjerde bladet 🍀.

Med prosjekter blir det gjerne…

… estimering og reestimering, runder med forankring av scope på tvers av virksomheten, rapportering, milepælsplaner og leveransebeskrivelser. Før det blir gjort en eneste PR. Veien til produksjon og ekte brukere virker litt lang. Men det er grep vi kan ta for å få opp smidigheten og ned «prosjekteffekten»:

Hva må til for å lykkes med en «tykk MVP»? Hvor er det vi jobber med å ta ned risikoen?

• Vi må lykkes med implementering. Om vi ikke lykkes med innføring og opplæring, og de ansatte ikke tar løsningen i bruk som tiltenkt da har vi ikke skapt endring eller verdi. Vi tror at vi må opp på et visst nivå både i mengden funksjonalitet og god brukskvalitet for å sikre at implementeringen blir vellykket.
• Vi må også involvere fagsiden hele veien, vi må tenke på opplæring og gjennomføring av implementering.
• Vi har en gitt sekk med penger. Så hvis vi ikke sjekker av forbruk underveiskan vi risikere å ikke ha levert en fullverdig nok første løsning når vi skal i produksjon. Det betyr at vi jobber mye med å definere riktig scope underveis og avklaringer rundt det.Her er tydelig kommunikasjon rundt scope og milepæler helt essensielt.
• For å kunne ta inn læring og gjøre endringer må vi gjøre læring sammen der vi kan. Vi har allerede fått innsikt sammen som har endret prioriteringene og rekkefølgen på delleveransene våre. For at alle skal være med på endringene, er det mest effektivt å gjøre denne læringen i fellesskap. I praksis så skyver vi litt på bitene vi tror at har mindre verdi å lage.
• Rundt og på toppen av prosjektet har vi en styrings- og forankringsrigg. Så sammen med å utøve smidighet innenfor en ramme, må vi i tillegg være rågode på å fasilitere og kommunisere på kryss og tvers av riggen — sånn at vi klarer å holde kursen sammen.
• Den rollen eller egenskapen kan kanskje kalles å være en «optimal enabler» for å låne et uttrykk fra kollega Stine. Den går mye ut på å dele kunnskap på en pedagogisk måte og sørge for å skape gode forum der nødvendig innsikt og avklaringer kan skje.

Dette har vi gjort

«Prosjekt» og tykk MVP trenger ikke nødvendigvis å bety fossefall i praksis. Selv om vi er i gang med en «tykk MVP» har vi trykket smidig-brillene så godt vi kan innpå nesa:

Vi har blant annet:

• Holdt en større kick-off for å sikre god forankring opp og ned, og på kryss og tvers — og sikre eierskap til det vi skal lage. Her var det med folk fra to utviklingsteam og produkteiere og ledere. Formatet vi kjørte var lyntaler fra ulike fagområder inspirert av Google Design Sprint. Vi gjorde også en team-oppgave med å definere “Kongstanken vår” — et mål å bli omforent om, og hva vi skal se etter (hva vi kan måle) for å vite at vi er på rett vei. Her tok vi utgangspunkt i Linda sitt Målkanvas. Vi planlegger en ny kick-off når vi skal i gang med neste bølge/større delleveranse.
• Gjort mer innsikt enn planlagt. Vi har besøkt felten som et tverrfaglig team, og fått nyttig innsikt.
• Møter og forankringsrunder: slidene fra disse blir bærebjelker i forankringsprosessene på kryss og tvers av interessenter og team og sørger for at de viktige avklaringene skjer. Når det er et fagsystem man jobber med, er gjerne brukerne internt ansatte ledet av interne ledere. Den interne innsikten og feedbacken er veldig relevant for løsningen, sammenlignet med om vi for eksempel skulle laget en app som kan brukes av alle og enhver.
• Vi bygger en “Teknisk PoC” og første bølge av MVP’en nesten samtidig. For å ta ned den tekniske risikoen har vi gått i gang med en teknisk PoC først for å teste integrasjoner, samtidig som vi har MVP’en i bakhodet (der MVP = første versjon vi kan gå i produksjon med til utvalgte brukere).

Vi kommer til å lansere gradvis

I smidig ånd kommer vi til å gå først ut til et område med en gruppe brukere og lære fra disse først, og så gradvis gå bredere ut. Håpet er at vi kan ha levende effektmålinger på det vi lager i produksjon etterhvert, i tillegg til kvalitativ innsikt fra brukerne.

The Amazing Yen

Å jobbe med en «tykk MVP» utfordrer definitivt mitt produktutviklings-muskelminne, og det er ikke helt opplagt hvordan man skal få det til på en god måte i praksis.

Men det er ikke umulig…!