Datadrevet og kundeorientert utvikling, sa du?
Å ha en mer datadrevet og kundeorientert tilnærming til utvikling av digitale tjenester og produkter er stadig viktigere for å henge med i en tøff konkurransesituasjon. Dette er noe som gjerne faller seg naturlig for startups og er en tilnærming som de globale teknologi-gigantene er skremmende gode på. Men hvorfor kan det se ut om dette er spesielt krevende å bli god på for etablerte organisasjoner som vår egen? Og hva legger vi egentlig i datadrevet og kundeorientert utvikling?
Bort med antagelsene
Det er her snakk om en tilnærming til digital produkt- og tjenesteutvikling hvor man er drevet av innsikt — og ikke antagelser. Eric Rise gjorde denne tilnærmingen kjent gjennom boken The Lean Startup som ble utgitt i 2011 [2]. Tilnærmingen omtales både som eksperimentdrevet utvikling og hyptesedrevet utvikling, samt at UX miljøet har trykket den til sitt bryst som en del av begrepet Lean UX [8]. Videre i denne artikkelen vil jeg omtale denne tilnærmingen som datadrevet og kundeorientert utvikling, som er mer beskrivende for hva vi ønsker å få til.
Kort fortalt så handler det om å gjøre innsiktsarbeid og eksperimenter mot sluttkunde som en del av oppgaveløsningen. Dette gjøres for å redusere antagelser man tar både før og underveis i utviklingen. Læringen man tilegner seg ved analysen av, og involveringen fra, kunde skal brukes aktivt til å styre valgene man fortløpende tar.
Arbeidet med å realisere noe gjøres veldig forenklet ved hyppige iterasjoner der man bygger noe, man måler hvordan det går og man bruker læringen i videre arbeid med nye iterasjoner. Dette til forskjell fra hva mange tidligere har gjort — bygge masse for så å håpe på det beste.
Målet med å jobbe på denne måten er at innsikt — og ikke antagelser — skal drive utviklingen.
Eksempler på eksperimentering
Når et team har denne tilnærmingen har de typisk en veldig klar visjon eller retning for hvor de skal, men erkjenner at de kun har antagelser om hvordan de skal komme seg dit. Teamet setter derfor typisk opp en hypotese og utfordrer seg selv på hvordan de, med minst mulig ressurser, kan få innsikt som sier noe om denne antagelsen er riktig eller gal. Det er bare kreativiteten til teamet som begrenser hvilke type eksperimenter de kan gjøre. Her er noen eksempler vi har sett i noen av våre team:
- Fiktiv tjeneste / Fake doors: Man lanserer en tjeneste eller funksjonalitet uten at den er (i nærheten av) ferdig. Dette for å tidlig kunne få feedback på hvordan brukere vil ta i bruk tjenesten eller funksjonaliteten. Det som i dag har blitt spleis.no var i starten et lite innovasjonsteam som eksperimenterte med en uferdig tjeneste under fiktivt navn og merkevare.
- A/B testing: Man presenterer flere ulike varianter av en endring til ulike kundegrupper og måler hvordan de ulike alternativene presterer.
- Gradvis utrulling: Man starter i det små med å rulle ut endring til en liten del av brukermassen for så å analysere og gjøre forløpende endringer før man slipper på flere.
- Fake it til you make it I: Lansere en tjeneste tidlig, hvor kunden opplever det som en komplett tjenesten, men som i realiteten krever mye manuell oppfølging i bakkant.
- Fake it til you make it II: Et fint eksempel er også når et team hos oss skulle lage e-post notifikasjon/kvittering til kundene. Det som for kunde så ut som en automatisk generert kvittering, var i realiteten manuelt laget på enklest mulig måte i ulike varianter til ulike kundegrupper. Man brukte først utviklingstid på å implementere den varianten man visste hadde best effekt (mtp aksjoner kunden gjorde etter å ha mottatt kvitteringen).
- Spør kunden: I arbeidet med en ny tjeneste eller ny funksjonalitet er man smart med å jobbe inkrementelt hvor man gir sluttkunde mulighet til å gi feedback mellom iterasjonene.
- Mål adferd: Dagens team har en helt annen mulighet enn tidligere til å bruke data og målinger til å lære om kundenes adferd. Dette brukes aktivt i arbeidet med å stadig og stegvis forbedre løsningene våre.
Hvorfor er dette viktig?
Selv om vi ofte tror vi vet det — så har vi sjelden på forhånd nok innsikt i hvilke problemer kunden ønsker at vi løser og hvordan vi bør løse de. Dette har resultert i at det opp igjennom årene har vært investert utrolig mye penger i antagelser og gjetting. Dette har igjen ført til utvikling av produkter og tjenester som (I) ingen kunder vil bruke, (II) kundene er misfornøyd med eller (III) som må lages helt på nytt.
Ved både å ha langt flere personer i teamene med interesse og fagkunnskap om UX/kundeinnsikt, samt at hele teamet bruker data og innsikt mer aktivt i utviklingen vil vi øke sannsynligheten for at vi lager produkter og tjenester som kundene faktisk vil ha.
Når skal man benytte denne tilnærmingen?
Vi startet med denne tilnærmingen på noen utvalgte prosjekter som gjerne kan kalles interne startups. Dette var grupper som kunne jobbe relativt isolert og gjerne var uavhengig av øvrig organisasjon når det kommer til arkitektur, teknologivalg, løsninger og andre team. De senere årene har vi tatt inspirasjon og læring fra disse interne startups og forsøkt å ha samme tilnærming på noen av de mer etablerte løsningene og teamene våre. Dette har ført til at vi må ha et mer bevisst forhold til når vi bruke hvilken tilnærming.
Illustrasjonen over viser litt grovt sett hvilke ulike modus teamene våre må kunne jobbe på avhengig av hvordan problemet de skal løse.
- Tradisjonell utvikling: Vi gjør lite av dette, men i enkelte tilfeller har vi sterke avhengigheter til store leveranser fra leverandører eller er avhengig av store datamigreringer for å kunne lansere noe. Det jobbes gjerne smidig internt i utviklingsfasen, men i stort er leveransen vannfall.
- Smidig utvikling er tilnærmingen de aller fleste teamene våre jobber i til vanlig. Teamene våre har stor frihet til hvordan de velger å jobbe, men de fleste teamene ender opp med en KANBAN variant med enkelte elementer fra Scrum. I denne modusen vet vi gjerne hva vi skal lage.
- Hypotesedrevet utvikling: Er tilnærmingen som er beskrevet i denne artikkelen. I denne modusen skal vi både finne ut hva vi skal lage — og hvordan vi skal lage det.
I vurderingen om hvordan tilnærming man kan bruke er det god hjelp i modeller som Cynefin (uttalles Ki-NEW-in). Modellen er utarbeidet av Dave Snowden beskriver ulike nivåer av kompleksitet og sier at hvilken problemløsningsmetode vi bør velge, avhenger av problemets kompleksitet. Geir Amsjø har skrevet en fin artikkel om rammeverket her.
Videre i artikkelen vil vi fokusere på hvordan vi har startet å jobbe mot en mer datadrevet og kundeorientert utvikling. En tidlig erfaring var at det ikke er teamene vi må starte med, heller med rammebetingelsene til teamene.
Start med rammebetingelsene til teamene
Selv om det kreves både modenhet og kompetanse i teamene for å jobbe etter denne tilnærmingen er vår erfaring at det viktigste er hvilke rammebetingelser som blir gitt til teamene. I arbeidet med de ulike teamene hos SpareBank 1 som helt eller delvis jobber etter denne tilnærmingen er det to ting som dukker opp som viktige for å lykkes:
- Outcome orientering: Når vi som organisasjon klarer å gi teamene målsetninger og retning — og ikke konkrete bestillinger.
- Hastighet: Når vi som organisasjon klarer å gi teamene den nødvendige hastigheten de trenger for å kunne gjøre eksperimentering som en del av oppgaveløsningen.
Krever store endringer på organisasjonen
Som tidligere nevnt er denne tilnærmingen krevende å rigge seg for når man som organisasjon gjerne sitter på både teknisk og organisatorisk historikk. Litt av årsaken til dette er at ulike deler av organisasjonen må endre seg for at man skal kunne få teamene til å agere på denne måten. Ledelse og “forretningssiden” til teamene må endre tankesett for å oppnå outcome-orientering og IT-delen av organisasjonen må endre seg ganske dramatisk for å kunne gi den nødvendige hastigheten til teamene.
Hvordan bli outcome-orientert?
Det hele starter med at man har kryssfunksjonelle og autonome team. Kryssfunksjonelle ved at man har de fagdisiplinene tilstede i teamet som trengs for å løse det aktuelle problemet, og autonomt ved at gruppen faktisk har mulighet til å løse problemet uten for mye avhengigheter. Diskusjonene om hvor autonomt et team skal være og om det i det hele tatt er mulig at et team er helt autonomt i en kompleks organisasjon er ikke så interessante synes jeg. Det viktige er sette sammen en gruppe med mennesker som sammen kan løse problemet — og fokusere på at denne gruppen har:
- minst mulig avhengigheter til andre løsninger/team
- minst mulig behov for å løpe i organisasjonen etter avklaringer
- minst mulig behov for å spørre om lov utenfor teamet
Når man har et velfungerende kryssfunksjonelt team er det forlokkende for organisasjonen å henvende seg til dette teamet å gi de beskjed om akkurat hva de skal lage. Lag denne tjenesten, gjør denne endringen og så videre. På denne måten utnytter du imidlertid ikke teamet særlig bra. Bruk teamene til det de er gode på — nemlig problemløsning.
Organisasjonen bør heller sikre at man kan kommunisere en tydelig retning til teamene og følge opp team på målsetninger og hva de faktisk oppnår. Når man er tydelig på målsetninger ovenfor teamene gir man med andre ord teamene et problem å løse, snarere enn ferdig løsninger.
Kryssfunksjonelle og autonome team som man måler på outcome har imidlertid med seg noen utfordringer som man må løse:
- Hvordan hindre anarki?
- Hvordan endre tankesettet til ledere og det vi tradisjonelt har kalt “forretningsiden”.
Hvordan hindre anarki?
I en organisering med kryssfunksjonelle og autonome team sikter man gjerne på en nettverksorganisering snarere enn en hierarkisk oppbygning av organisasjonen [12]. Om mer av problemløsningen skjer i teamene vil tydelig retning og strukturert arbeid med målsetninger bli viktig. Vi har innsett at vi av den grunn må bli mer strukturert i arbeidet med målsetninger og retning ovenfor teamet — noe vi for tiden jobber mye med i SpareBank 1 Utvikling.
Henrik Kniberg har i sitt arbeid hos Spotify jobbet med hvordan man balanserer autonomi og alignment og har gjennom dette kommet opp med begrepet alligned autonomi om noe man bør søke å oppnå.
Illustrasjonen og denne videoen beskriver dette godt.
Hvordan endre tankesettet til ledere og “forretningsside”?
Det høres kanskje lett ut å endre tilnærming i organisasjonen slik at man måler teamene på hva de oppnår og ikke hva de gjør. Men i store organisasjoner har man kanskje både personer, roller og hele avdelinger som tradisjonelt har jobbet med hva som skal gjøres. I en organisasjon med team man ønsker agerer mer datadrevet og kundeorientert, må mye av hva som skal gjøres overlates til teamene. Personer, roller og avdelinger som tidligere har gjort dette må jobbe som en del av teamene eller jobbe på en annen måte enn tidligere. Vår erfaring er at dette gjøres best ved starte begrenset, ved å velge ut et prosjekt, et produkt eller et område hvor man blir enig om at man skal jobbe på en litt annen måte enn tidligere.
Hvordan gi teamene nødvendig hastighet?
Om eksperimentering mot sluttkunde skal være en del av oppgaveløsningen til teamene er det en forutsetning at teamene har hastighet. SpareBank 1 Utvikling har jobbet med å få opp hastigheten på teamene i mange år nå, fra å ha kvartalsvise releaser av totaliteten, til nå hvor hvert enkelt team i større grad kan styre sin egen leveransehyppighet av applikasjonene innenfor sitt ansvarsområde.
Da vi gjorde en brainstorming rundt hvilke tiltak vi har gjort de siste årene for å øke hastigheten vår var det veldig lett å komme opp med en lang liste av tiltak og årsaker. Vi har forsøkt å kategorisere endringene vi har gjort og skal liste opp disse samt si noe om rekkefølgen på endringene vi har gjort.
Kategorier av endringer er:
- Arkitektur
- Organisering
- Prosess
- Mennesker
Endringer på vår arkitektur for å sikre hastighet
Vi starter i 2012 en reise hvor vi gikk fra en monolittisk arkitektur over til en mer mikrotjenesteorientert arkitektur. Dette er en reise vi fortsatt er på, og målet har vært det samme hele tiden; løse koblinger. Spørsmålet vi hele tiden har stilt er hvordan arkitekturen vår kan støtte oss i arbeidet med å organisere oss i små grupper som jobber med deler av våre løsninger uten å være påvirket av de andre.
Vi ønsker team som ikke er satt sammen som et resultat av tekniske løsninger, men heller er satt sammen for å levere på et forretningsmessig eller kundeorientert domene.
Endringer på vår organisering for å sikre hastighet
Etter at vi fikk en mer fleksibel arkitektur hvor det var mulig å sette grupper av mennesker til å ta ansvar for ulike deler av løsningene våre, ga det oss noen spennende muligheter når det kommer til å jobbe med organisering. Dette arbeidet var sterkt inspirert av Lean og Lean verdikjedeorientering.
- Hva er det vi egentlig leverer?
- Hva er våre hovedprosesser og hva er støtteprosesser?
- Hvordan kan vi optimalisere for hovedprosessene våre og sørge for at vi er mest mulig effektive fra en idè oppstår til den gir verdi til sluttkunde?
Vi så tidlig at en av de hyppigste årsakene til problemer og tregheter i organisasjonen vår var overleveringer av ulike sorter. De meste smertefulle overleveringene var:
- Overleveringer mellom fagdisiplinene design, utvikling og test
- Overleveringer mellom utvikling og drift
- Overleveringer mellom prosjekt og forvaltning
Det har tatt tid, men for å løse opp i disse problemene har det vært helt naturlig for oss å gjøre en overgang til (I) kryssfunksjonelle team for å løse opp i overleveringer mellom fagdisipliner, (II) fokus på DevOps-praksiser for å løse opp i overleveringer mellom Utvikling og Drift, samt (III) en overgang fra prosjektorientering til produkutviklings-fokus for å fjerne overleveringer mellom prosjekt og forvaltning.
Endringer på våre prosesser for å sikre hastighet
En nøkkel for oss har vært å innføre stadig færre sentrale prosesser og retningslinjer for hvordan teamene skal jobbe. Med en arkitektur og organisering som gjør at teamene kan bli mer selvstendige, kan det også være mer opp til det enkelte team å påvirke hvordan de selv jobber mest mulig effektivt.
Med for mye sentralstyrte prosesser er vi redd for at vi hindrer mye av den kontinuerlige forbedringen vi er avhengig av for å stadig bli bedre. Vi trenger både personer og team som tør å utfordre hvordan vi jobber og ønsker å bidra til at vi stadig tar nye steg i å bli mer effektive.
Her ligger det selvsagt en utfordring i både å fange og å dele erfaringer fra de enkelte teamene slik at vi sammen løfter oss som organisasjon. Vegard Kolbjørnsrud har noen gode poenger i sitt foredrag “Designe smidige og smarte organisasjoner” hvor han påpeker at en organisering i smidige team er bra sted for læring, men at hukommelsen er dårlig.
Endringer på hvordan behandler mennesker for å sikre hastighet
Vi kan gjøre hvilke endringer vi vil på arkitektur, organisering og prosess, men uten at vi har motiverte mennesker som virkelig vil gjøre en innsats for å få dette til å fungere — hjelper det ingen ting. Å være et godt sted som folk vil jobbe starter med at organisasjonen, og særlig ledere, har en grunnleggende tro på at ansatte kommer på jobb for å bidra, lære og levere verdi. Starter organisasjonen med å ha tro på folk, får man ikke ansatte som trenger å gjetes, men får ansatte og team som tenker selv og som utfordrer! Det er bra det!
Hva har inspirert oss?
Om du har lyst til å dykke dypere i disse temaene har jeg her listet et utvalg bøker og noen foredrag som har vært spesielt inspirerende i arbeidet med å lage en stadig bedre utviklingsorganisasjon.
Bøker
- The Toyota Way (Jeffrey K. Liker)
- The Lean Startup (Eric Rise)
- DevOps Handbook (Gene Kim, Patrick Debois, John Willis, Jez Humble)
- Accelerate (Nicole Forsgren, Jez Humble, Gene Kim)
- This is lean (Par Ahlstrom, Niklas Modig)
- The Age of Agile (Stephen Denning)
- The Culture Code (Daniel Coyle)
- Lean UX (Jeff Gothelf, Josh Seiden)
Foredrag
9. Henrik Kniberg, Spotify Engineering Culture (Smidigkonferansen 2014)
10. Jon Kåre Stene, End of Big, hva nå? (Smidigkonferansen 2013)
11. Mary Poppendiek, How do teams know what to do (SpareBank 1 2017)
