Fra features til outcomes

Reisen med kryssfunksjonelle team fortsetter for SpareBank 1. Det samme gjør behovet for kontinuerlig forbedring. Kontinuerlig forbedring for oss betyr å alltid søke mot bedre arbeidsverktøy, bedre prosesser og mer kompetanse. Derfor ble vi ekstra spente da Mary og Tom Poppendieck kom til oss for å fortelle om sine erfaringer fra teamarbeid, spesielt med fokus på hvordan team jobber målorientert.

Mary og Tom er kjent som forfattere av boktrilogien Lean Software Development og fra en rekke konferanser, blant annet Goto Berlin 2016, hvor Mary holdt keynote om fremtidens programvareutvikling.

Hvordan vet et team hva som skal gjøres? I en tradisjonell scrum-sammanheng med en produkteier/product owner (PO), koker dette ofte ned til en prioritert backlog med features som alle har en eller annen forretningsverdi, eller i beste fall, en verdi også for brukeren. En feature kan sees på som en avgrenset funksjonalitet, enten som en del av allerede eksistere løsning, eller en ny tjeneste. Et eksempel på dette kan være “Endre nedbetalingstid på boliglånet”.

Noen av hovedspørsmålene Mary og Tom tok opp i foredraget sitt, var:

  • Vil det høye fokuset på features bidra til utfordringer med voksende kodebase, og overflødige og unødvendig kompliserte løsninger?
  • Hvilken rolle har egentlig en PO i en slik kontekst?
  • Hvordan vet vi at en PO prioriterer riktig, og at dette gjenspeiler det egentlige bruker- og forretningsbehovet?

Hvis teamene jobber mot outcomes (utfall) i stedet for en prioritert backlog med vilkårlig prioriterte features, kan vi enkere oppnå løsninger som gir brukeren bedre opplevelse og verdi. Autonome team med sterk involvering av kunde og forretning i kombinasjon med hypotesetesting, er viktig for å kunne jobbe mot outcomes. Som et alternativ til tradisjonelle brukerhistorier og kravspesifikasjoner, tester teamet hypoteser før det treffer avgjørelser for neste steg tas. SpareBank 1 har benyttet en slik tilnærming ved utvikling av en ny tjeneste for å søke finansieringsbevis, ved å ta i bruk A/B-testing, som vi skal beskrive nærmere her:

A/B-testing i Team Finansiering

I 2017 lanserte SpareBank 1 en rask og enkel løsning for finansieringsbevis til boliglån. Brukergrensesnittet er utformet konvensjonelt for å være enkelt å forstå. Med noen minutters egeninnsats og en BankID-innloggning, er det mulig for hvem som helst, SpareBank 1-kunde eller ikke, å få utstedt et finansieringsbevis som kan brukes i budrunden til drømmeboligen. Løsningen ble designet, utviklet, testet og produksjonssatt av det kryssfunksjonelle teamet som har ansvar for boliglån i nett- og mobilbanken.

 

En naturlig outcome å fokusere på i et team som har ansvar for en prosess med tydelig start/slutt er konvertering. Konvertering er forholdet mellom antall som starter og sluttfører en prosess. Teamet utviklet en konverteringstrakt/frafallsanalyse (conversion funnel) som viser hvor langt ut i prosessen for finansieringsbevis brukeren kom.

 

 

Teamet merket at mange brukere falt av under søknaden om finansieringsbevis i et visst steg. På dette steget satt teamet opp en A/B-test for å teste to forskjellige løsninger i parallell. A/B-test betyr å eksponere brukerne for forskjellige løsninger, slik at man kan måle bruksmønster og sammenligne disse opp mot hverandre. Teamet benyttet dette til å sammenligne to versjoner av steget hvor frafallsanalysen viste størst frafall. Dette ga teamet et godt grunnlag for å vurdere hvilken løsning som konverterte best.

Dette er et eksempel på hvordan A/B-testing kan understøtte utvikling med fokus på outcomes. Det skiller seg ut fra en tradisjonell toppstyrt featuredrevet tilnærming. Med A/B-testing gjør teamet selv basert på data og erfaringer, beslutning om prioritering.