Fra tungrodd byråkrati til Lean UX

Jeg har vært så heldig å være med på reisen til SpareBank 1 Utvikling som har gått fra å være et tungrodd byråkrati til å omfavne Lean UX (og andre smidige utviklingsmetodikker) i løpet av de 4 siste årene. Jeg vil prøve å dele noen erfaringer og peke på noen faktorer som gjorde at det føltes tungrodd, og hva som ble gjort for å endre på dette.

Ingen ønsker byråkrati, men jeg er ganske sikker på at du som jobber i en stor organisasjon vil kjenne igjen ingrediensene i den litt kraftige gryteretten som dette er.

Det er 5 hovedingredienser i ethvert “Slow IT” prosjekt:

1. Ta en stor bolle med Byråkrati. Dette utgjør basisen i enhver slow IT gryte! Masse møter uten agenda og med så mange som mulig med på hvert møte.
2. La dette koke over svak varme og legg til detaljert planlegging av de neste 6–12 måneder med konkrete beskrivelser av leveranser. Denne oppgaven gjøres av maks 1 person, ikke bruk tverrfaglige team til planleggingen, de vil bare stille masse spørsmål man ikke har svar på. Vær så konkret som mulig med tydelige milepæler, men ikke så tydelig at du får skylda om de ryker. Det er bedre å love en konkret leveranse “25. September kl 12:32” og så la den deadlinen ryke. Det verste oppdragsgivere vet er usikkerhet når du spør om penger. Og husk å ikke ende opp med den som får skylda for å ha “tuklet med det”.
3. Dryss over funksjonalitet som oppdragsgiver liker og som kanskje noen som har litt makt har etterspurt i en mail en gang. Enda bedre er om det finnes sinte e-poster eller sitater fra en kunde som irriterer seg over noe. Dette er kundeinnsikt som må (mis)brukes.
4. Mens dette godgjør seg i perioden august-desember, pass på å kopiere enhver konkurrents funksjonalitet som dukker opp i nyhetsbildet og få dette inn i kravspekken til neste år. Det er klart at om konkurrenten har tatt seg bryet med å lage noe så har de helt sikkert gjort et grundig og bra arbeid for å komme frem til nettopp dette. Det kan også hende at noen har tipset deg om dette på mail.
5. Til slutt kan det serveres som løsning på strategien som blir levert fra ledelsen i Desember, uavhengig av hva som faktisk står i strategien, så er det du har laget svaret på den, dette fikser du lett.

Som du ser er dette en rett som kan serveres i enhver større organisasjon og spises daglig både til frokost, lunsj og middag. Merk at dette er kaloririk kost og kan føre til at man blir slapp, lei og tiltaksløs over lang tids inntak.

I SpareBank 1 ble vi lei av å delta i denne kokkekonkurransen hver høst. På ett tidspunkt hadde vi en faktisk “meny” på over 100 ulike funksjonaliter hvor alliansebankene fikk velge selv ala-carte. Så satte man en strek når budsjettet var brukt opp og så startet kampen om å sende funksjonalitet over eller under denne streken.

OK, nok mat-metaforer, la meg fortelle litt om hva som ble gjort for å fikse dette.

Hvordan bli mer “Lean”?

I de siste årene har som nevnt SpareBank 1 jobbet for å bli mer smidige og bruke Lean. Det er ikke som å skru på en bryter når andre arbeidsformer ligger dypt i organisasjonskulturen. Så løsningen har vært en miks av å prøve å forsterke det som fungerer og lære av feilene man gjør.

Spink — en suksesshistorie

Spink er appen er for barn mellom 6 og 12 år og deres foreldre. Da vi jobbet med første versjon av Spink appen jobbet vi med å unngå alle punktene nevnt i Slow IT kokkeleringen. Byråkrati ble holdt til et minimum. Teamet besto av kun 7 personer (pluss noen støttespillere) ledet an av Anne Gundersen (UX lead) og Marit Andreassen (prosjektleder). De rapporterte ikke til et vell av råd eller komiteer. De søkte ikke om penger for 12 måneder, men i første omgang kun for 4 måneder. De baserte seg på å få finansiert ytterligere arbeid så snart prosjektet var i gang og resultatene kom. Så på pkt. 1 og 2 var tilnærmingen at man skulle jobbe med å sette opp hypoteser om barns bruk av penger (og deres foreldres behov for å lære barn om penger).

Prosjektet startet faktisk som en klassisk funksjonalitetshenvendelse. Bankene ønsket å oppdatere en 2 år gammel app som lå i appstore, men som hadde fått litt lite kjærlighet det siste året. Brukergruppen var gått ned til nesten null og appen hadde bugs og mangler som ikke ble fikset. “Lommepengeappen” var laget slik at foreldre kunne holde styr på ukepengene som barnet fikk, samt belønne for å gjøre husarbeid. Det første teamet gjorde var å spørre seg om dette var riktig problemstilling; var det virkelig slik at barn fikk ukepenger for å gjøre husarbeid? Undersøkelser som teamet gjennomførte, konkluderte med at det gjør norske barn ikke (dvs. det er iallfall under halvparten av barna som gjør dette), men det dukket opp andre behov som viste seg å ha sterkere støtte i dataene. Teamet tok utgangspunkt i barn og foreldres reelle behov.

Barn trenger et betalingsmiddel for å f.eks. betale for is og cola i kiosken på fotballkampen. Siden foreldre ikke har kontanter, så er det ikke så lett å bare få penger i hånden. Dersom barnet hadde et bankkort, så måtte de likevel spørre foreldrene om hvorvidt de hadde penger på konto til å handle, fordi de ikke hadde en måte å se saldo på. Foreldre på sin side uttrykte at de manglet måter å lære barn om økonomi på nå som kontanter var på vei ut og pengene blir kun “digitale”.

(Marit Andreassen var PL på prosjektet i denne perioden og skrev en veldig bra artikkel om dette: Utfordringen — Hvordan lære barn verdien av penger?)

Teamet utviklet en MVP og knyttet til seg barn og deres foreldre som betabrukere. I denne perioden startet man med ansatte i banken og trakk etterhvert inn reelle kunder. De jobbet i et år med å jobbe hypotesedrevet og la til funksjonalitet basert på betabrukernes data om bruk samt direkte tilbakemeldinger underveis. Prosjektet ble finansiert i kortere tidsrom av gangen. Dette gjorde at teamet hele tiden måtte bevise at prosjektet hadde livets rett, ved å vise til konkret måloppnåelse underveis i prosessen. KPIene som ble nådd sørget for at prosjektet gikk videre og både oppdragsgiver og kunder var fornøyde hele veien.

Hvorfor var dette prosjektet så “Lean” og “Mean”?

Som nevnt var byråkratiet holdt til et minimum. Størrelsen på teamet var begrenset til 2 designere, 2 utviklere, prosjektleder, produkteier og ansvarlig fra bank (totalt 7 personer). Teamet rapporterte direkte til en styringsgruppe som hadde makt til å handle på vegne av SpareBank 1 bankene. Viktigheten av å ha oppdragsgiver tett på i prosessen, uten å ta over styringen, er noe som gjør at teamet kan ta raske beslutninger.

Planlegging var lagt opp annerledes. Man satte opp noen hypoteser om hva kundene trenger og dette ble testet grundig med kundeinnsikt. Brukertesting av prototyper, intervju med barn og foreldre, intercom med direktekontakt med barn og foreldre i appen mm. Planlegging var heller ikke gjort i et vakuum av 1 prosjektleder eller produkteier, men ble planlagt med bidrag fra hele teamet.

Funksjonalitet som ikke ble brukt i løsningen ble tatt bort eller endret fortløpende. Det ble eksperimentert med flere ulike funksjoner underveis, men ingen funksjonalitet ble innført uten et minimum av kundeinnsikt på forhånd.

Kopi av konkurrenters funksjonalitet var heller ikke et tema i prosjektet. Både fordi man brukte egen innsikt til å lede vei mot neste behov som skulle tas tak i, og fordi SpareBank 1 var den første i markedet med et skikkelig tilbud til barn i Norge. Det finnes noen svenske og danske varianter som man har sett på, men som ikke har gitt noe energi til å endre mye på retningen Spink har tatt.

Strategien bak Spink (og måten man jobber med andre prosjekter på samme måte som Spink) gjør at strategi er noe teamene leverer på kontinuerlig. Det er ikke et dokument som er laget en gang for alle av ledelsen og lagt i en skuff til neste år. Prosjektene har strategien som et utgangspunkt og en retning (med mål, KPIer og OKRer). Når teamet jobber med å nå sine mål og for å dekke et faktisk kundebehov, så vil man måle dette kontinuerlig og vha. Innsikt hva som er det neste som man bør jobbe med. Strategien kan så justeres hvis innsikt tilsier at den er feil.

Bakgrunn

Frem til Mars i år var jeg leder for Designavdelingen i SpareBank 1 og jeg hadde gleden av å bli invitert til Y-konferansen i 2019 for å holde foredraget «From Slow IT to Lean Mean Hypothesis Machine in 3 years». I foredraget trakk jeg frem noen egenskaper som kjennetegner en treg IT organisasjon og hva som er bra med å bli litt mer “Lean” som er hovedpunktene i dette blogginnlegget.

Nå er jeg Fagleder UX og Partner i Sans som er et designbyrå lokalisert i Oslo og Bergen. Og vi er på jakt etter flere UX designere og nye kunder. Ta kontakt!