Hopp til hovedinnhold

Prosess og rådgivning / 6 minutter /

Kan vi ha autonome team uten at de blir til siloer?

En suksesshistorie om å jobbe hos Vipps.

Det er mange ting som kan føre til at autonome team blir frakoblet og isolert fra hverandre. I denne artikkelen vil jeg skrive om en spesiell type avhengighet som oppstår på tvers av autonome team i en typisk IT-organisasjon.

Denne avhengigheten handler om gjenbruk av brukeropplevelse. Altså gjenbruk av kode og design, som er typisk i front-enden for en webløsning eller mobilapp. Som utvikler opplever jeg at man kan bli for “låst” til sitt autonome team, som igjen skaper siloer i organisasjonen.

Når dette skjer er det veldig vanskelig å jobbe med delt kode. Jeg vil forklare hvordan jeg opplever disse utfordringene, og gi et innblikk i hvordan vi organiserer oss hos Vipps.

Lik brukeropplevelse fra ulike produkter og team

Nedenfor ser du skjermbilder av fem ulike betalingsskjermer i Vipps:

Skjermbilder: 1. Regningsbetaling, 2. Faste betalinger, 3. Betaling i butikk, 4. Vennebetaling, 5. Netthandel
Skjermbilder: 1. Regningsbetaling, 2. Faste betalinger, 3. Betaling i butikk, 4. Vennebetaling, 5. Netthandel

Skjermbildene ligner ganske mye på hverandre. Dette kan tyde på at vi har mye delt kode i Vipps. Likevel representerer hver skjerm sitt eget produkt, med egne funksjoner. Hver skjerm fra eksemplet over tilhører faktisk hvert sitt team. Vi har ett team som jobber med faste betalinger, ett som jobber med netthandel, og så videre.

Skjermene har hver sin produkteier, de har hver sin backend med ulike type integrasjoner – og i noen tilfeller har de hver sin UX-designer.

Hva har dette å si for meg som apputvikler og selve appen? Hva innebærer det at vi har én kodebase som deles på tvers av mange produkter og team?

Før jeg svarer, ønsker jeg å fortelle om hvordan vi var organisert i Vipps da jeg startet i 2018.

I starten

Da jeg begynte i Vipps var alle apputviklerne i samme team, og alle jobbet på alt. Vi var ikke organisert slik at vi hadde dedikerte utviklere som skulle jobbe på enten vennebetaling, regninger, oppgjør, netthandel, og så videre.

Produkteiere for de ulike produktene måtte legge igjen “bestillinger” til appteamet - sånn kort forklart. Svaret på spørsmål som “når kan dere starte på funksjon X” var helt opp til oss, og var en avveining vi gjorde basert på den totale mengden “bestillinger” i backloggen.

Fordeling av oppgaver i teamet ble ofte basert på hvem som var ledig, og hvem som trengte en oppfriskning på domenet bestillingen hørte til.

Alle apputviklere kunne litt om alt. Fra vårt ståsted hadde vi god oversikt over hva som foregikk i organisasjonen, fordi vi satt i krysningspunktet mellom alt som skulle utvikles.

Team Flaskehals

Omsider fikk appteamet et nytt kallenavn: “Team Flaskehals”. Autonome team som inneholder alle roller, unntatt apputviklere, blir ikke særlig autonome - i hvert fall ikke når produktutviklingen i organisasjonen i stor grad omhandler en app.

Produkteierne følte seg frakoblet apputviklerne. Det var uoversiktlig og vanskelig å følge med på hvem som jobbet på hva. Ulike funksjoner ble utviklet av forskjellige apputviklere, som skapte forvirring. Vi fikk stadig flere produkter, og flere produkter ga flere produkteiere, flere designere, flere backendutviklere, og så videre.

Det endte med at det satt en stakkars backendutvikler og lurte på hvorfor han ble sendt til apputvikler A for å diskutere en gitt funksjon, for å så bli sendt til apputvikler B for avklaringer på en annen funksjon - som kanskje var omvendt av hva han måtte forholde seg til i forrige måned.

Omorganiseringen

Omsider kom forandringer. Apputviklerne ble splittet ut i hvert sitt team hvor de skulle sitte i tett samarbeid med backend, UX, produkteier, og så videre. Nå skulle vi ha autonome team, på skikkelig. Nedenfor har jeg laget en illustrasjon som viser en forenklet inndeling av noen team og hvordan vi nå ble organisert.

Illustrasjon av omorganisering: Dedikert tverrfaglig team som jobber på hver sin avdeling.
Illustrasjon av omorganisering: Dedikert tverrfaglig team som jobber på hver sin avdeling.

I en slik organisering, vet produkteierne hvem de skal forholde seg til. Med minst én dedikert apputvikler i hvert produktteam, er nå blitt enklere for produkteierne å prioritere og koordinere arbeidet på tvers av fagdisipliner.

Det blir også enklere for UXere og backendutviklere å vite hvem de skal samarbeide med på app-siden til en hver tid.

En ny avhengighet oppstår

I omorganiseringen oppstår en ny type avhengighet. På tvers av samtlige autonome team, med sine tilhørende produkter, gjenbrukes en stor mengde kode. Selv om apputviklerne er satt ut i hvert sitt autonome team (og ikke lenger jobber i et samlet Appteam) så jobber man fortsatt i samme kodebase.

Vi har bare én app (per plattform). Selv om vi nå har en apputvikler som er dedikert til å jobbe på regninger, så betyr ikke det at man ikke ønsker å gjenbruke kode som også brukes av for eksempel vennebetaling (så sant det lar seg gjøre).

De som jobber på backend i et autonomt team jobber som oftest på kode som kun angår de produktene som teamet har ansvar for. De som jobber på appen jobber i større grad på kode som angår mange produkt og mange domener.

Hvilke avhengigheter er viktigst?

Er det slik at noen avhengigheter er viktigere enn andre? For å svare på det har jeg laget en tabell som viser hva slags avhengigheter jeg har til folka rundt meg:

Avhengigheter til andre apputviklereAvhengigheter til andre i mitt produktteam
Kunnskap- og kompetansedeling relatert til plattformspesifikke funksjoner til iOS eller AndroidFinne de riktige problemene man skal løse for sluttbruker
Kodegjennomgang (code review)Prioritere hvilke problem man skal jobbe på først
Jobbe på teknisk gjeld og forbedringer i fundamentet til appen (sikkerhet, autentisering, etc)Forstå problemet man skal løse
Diskutere beste løsning på problemet man skal løseDelta og bidra i designprosessen, spør og gi tilbakemelding på skisser
Gjør avsjekk på og teste at endringer man har gjort ikke ødelegger for andreDelta i utforming og design av APIer
Være med å teste og og legge til rette for at appen er testbar for alle
Bidra med innsikt i form av kvantitative data som appen samler gjennom analyseverktøy

På venstresiden ser du avhengigheter og avklaringer jeg som apputvikler trenger å gjøre med andre apputviklere. Dette er utviklere som ofte jobber på helt andre produkter enn meg selv.

På høyresiden ser du avhengigheter og avklaringer jeg som apputvikler trenger å gjøre med andre innenfor samme team, som jobber på samme produkt som meg, men i andre roller: backend, UX, QA, produkteier, og så videre.

Så, hvilke avhengigheter er viktigst? Kanskje det går an å svare på det ved å se på hvor det går mest tid?

Å bruke mest tid på samarbeid med apputviklere i andre team

La oss si at jeg bruker mer tid på venstresiden i tabellen over. Det vil si at jeg i løpet av en dag bruker mer tid på å få hjelp og sparre med andre apputviklere, også de utenfor produktområdet mitt. Hvis det er tilfellet så vil jeg jo føle meg ganske alene i produktteamet, hvis jeg er den eneste apputvikleren i det produktteamet? Det er jo ingen andre her i mitt produktteam som kan hjelpe meg med det jeg bruker mest tid på.

Jo lengre tid det går hvor jeg sitter på min øy og jobber med mitt produkt, desto mer frakoblet blir jeg fra de andre apputviklerne – og jo vanskeligere blir det for meg å hjelpe og få hjelp av andre apputviklere.

Da står jeg der på min egen øy og ser over til naboøyen og observerer at “oj, der borte skjer det mye rart jeg ikke har fått med meg” - men likevel skal vi dele kode på tvers av øyene og skape en konsistent og god brukeropplevelse for sluttbrukeren. Til slutt er det ingen som tør å gjøre endringer i delt kode i fare for å skape problemer for andre som jobber med noe man selv ikke forstår.

På det tidspunktet slutter man å dele kode og lager heller egne versjoner for lignende brukeropplevelser. Til slutt har man skrevet samme kode for samme brukeropplevelse om og om igjen, og da begynner brukerne å oppleve inkonsistens og føler seg usikker på hvorfor lignende oppgaver skal gjøres på ulike måter.

Å bruke mest tid på samarbeid innad i mitt autonome team.

La oss si at jeg heller bruker mer tid på høyresiden i tabellen over. La oss si at dagene stort sett består av å avklare ting med produkteier, sparre og avklare ting med backendutviklere og delta i designprosessen sammen med UX-personer. Da er det jo en fordel at jeg jobber dedikert med et team og blir skikkelig god på ett domene?

Hvis dette er det jeg bruker mest tid på så er det jo kjempeviktig å jobbe tett sammen med andre roller i teamet!

Så hva bruker jeg egentlig mest tid på? Det avhenger så klart på hvor man er i produktutviklingen og hva slags problemer man prøver å løse, men stort sett bruker jeg mer tid på venstresiden, altså samarbeide med apputviklere. Jeg erfarer likevel at mange ikke-tekniske personer både hos Vipps og tidligere kunder mener det er naturlig å bruke mer tid på høyresiden, og mange forstår ikke hva som skjer på venstresiden i tabellen i det hele tatt.

Det man bruker mest tid på er også viktigst, eller?

For meg har det alltid vært viktigere å jobbe på riktig problem framfor riktig løsning (selv om det også er viktig). Hvis du kommer til meg og sier “Hei Johannes, jeg ser et problem, og jeg har løsning, og jeg vil at du skal lage den”, så er jeg neppe med på leken.

Om du derimot sier “Hei Johannes, jeg ser et problem, ser du også samme problem? I så fall, skal vi finne en løsning sammen?” så er jeg garantert med på leken.

På venstresiden i tabellen snakker man mye om løsning. På høyresiden ser man mer på problemer.

Når utviklere ikke er dedikert til å jobbe med et produktteam eller område, er det lett å gå i fellen der man ukritisk lager det man får beskjed om. Da blir man i overkant fokusert på løsning, og glemmer å spørre seg selv om man jobber på riktig problem.

Det er sammen med produktteamene at jeg som utvikler kan involvere meg og stille de viktige spørsmålene som “er dette egentlig det problemet vi bør fokusere på” og “hvorfor gjør vi dette”?

Forandring fryder?

Da Vipps endret sin måte å organisere apputviklerne sine på oppstod det mange “misforståelser”. Jeg putter misforståelser i hermetegn fordi det var stort sett snakk om selvlagde misforståelser. Utsagn ble ofte kastet ut med en god dose galgenhumor:

“Sitter du fast med koden din? Ja det var synd, jeg kan dessverre ikke hjelpe deg fordi jeg skal jo bare jobbe med vennebetaling - og du jobber jo med netthandel!”.

Samtidig var det litt reelt. Er man presset på tid og har en ivrig produkteier som gjerne skulle hatt ny funksjonalitet ut i vennebetaling-produktet så raskt som mulig, er det vanskelig å forsvare at man bruker tiden sin på å hjelpe dem som jobber med netthandel med å løse en bug som gjør at folk ikke får betalt bussbillettene sine.

Det ble fort tydelig for oss at vi måtte beholde appteamet som et eget team, men i tillegg ha dedikerte apputviklere for hvert enkelt produktteam. Det må være greit at apputviklerne bruker tid på å samarbeide med og hjelpe andre apputviklere i andre produktteam og en enkel måte å tydeliggjør det var å beholde appteamet på organisasjonskartet.

Illustrasjon av omorganisering i Vipps, med appteamet på organisasjonskartet under produktteamene.
Illustrasjon av omorganisering i Vipps, med appteamet på organisasjonskartet under produktteamene.

Vipps sin løsning - en hybrid

Hos Vipps har vi altså både et appteam hvor alle apputviklerne er samlet i et team (per plattform, iOS og Android), i tillegg til flere produktteam som består av én eller flere dedikerte apputviklere.

Utover ukentlige rutinemessige vaktmesteroppgaver som omhandler release av app, support og håndtering av (tekniske) incidents, tas det ingen prioriteringer eller avgjørelser om hvem som jobber på hva og når i appteamet. Alt som angår prioriteringer og hvem som gjør hva blir tatt i hvert produktteam, og hvert produktteam har minst én apputvikler.

Likevel har vi beholdt appteamet for at apputviklerne skal kunne samarbeide på tvers av produkter som har delt brukeropplevelse. I appteamet har vi daglige korte statusmøter og bra fokus på kodegjennomgang (code reviews) som gjør det enkelt for meg å se hva andre produkter innfører av funksjonalitet på kode jeg også bruker (til et helt annet produkt).

Aksept, tillit og kommunikasjon

Der jeg sitter i mitt produktteam opplever jeg at produkteier og andre teammedlemmer har aksept for at jeg har behov for å følge med på hva som skjer i andre team, spesielt når det er snakk om brukeropplevelse som gjenbrukes på tvers av flere team og produkter.

Videre opplever jeg at produkteier og teammedlemmer har tillit til at jeg kan styre min egen tid, og at jeg klarer selv å finne en god balanse mellom å jobbe med det som angår mitt produktteam og jobbe med det som angår delt brukeropplevelse på tvers av flere team.

Det er ingen formelle krav eller rutiner for å låne og dele på utviklere som igjen krever en rekke møter og lange diskusjoner, som til slutt ender opp i krangling. Dette er viktig for framdrift og baserer seg mye på tillit, men er vanskelig å gjennomføre uten en åpen og god dialog.

Nøkkelen til suksess for mitt team og alle som sitter rundt meg er at vi er enige om måten vi ønsker å jobbe på. Dette er en prosess som tar tid og den går ikke akkurat fortere av at alle, skal få alle, til å se ting fra sin side.

Hos Vipps har jeg lært at det er først og fremst dem som er villig til å se ting fra andre sitt perspektiv som klarer å skape progressjon og framgang i en slik prosess.

Hvorfor er dette relevant for dem som jobber på webløsninger?

En webløsning kan deles opp i flere biter for å slippe å ha én stor kodebase. Man kan deploye hver sin bit hver for seg. Man kan gjenbruke kode på en litt annen måte og man har litt andre verktøy i verktøykassen sin.

Men - i mine øyne har man egentlig mange av de samme utfordringene når man skal lage en webløsning. Selv om man kan sette opp et designsystem som kan gjenbrukes i hver bit, så ønsker man likevel å lage konsistente og gjenbrukbare brukeropplevelser utover det man ser rent visuelt.

Komponentene man lager skal altså ikke bare ligne på hverandre rent visuelt og med tanke på form, farge og layout, de skal også håndtere tilstand og tilby funksjonalitet på lik linje på tvers av ulike produkter og deler av løsningen.

Som et eksempel så skal universell utforming i tabeller og nedtrekkslister være like god og konsistent for brukeren i alle deler av løsningen. Som frontend-utvikler av en webløsning har man samme utfordring med å være alt for “låst” til ett produktteam - frakoblet fra de andre frontend-utviklerne - og samtidig gjenbruke kode og skape helhetlig brukeropplevelse som sørger for at ting som universell utforming er like gjennomtenkt og god i hele løsningen.

Bør alle organisere seg som Vipps?

Det finnes ingen fasitsvar på hvordan man best bør samarbeide for å skape helhetlig og konsistent brukeropplevelse i en webløsning eller mobilapp. Å ha et eget appteam (eller frontendteam), i tillegg til tverrfaglige autonome produktteam, passer nok ikke en hver IT-organisasjon i Norge.

Jeg håper likevel at jeg har klart å gi innsikt og perspektiv som kan være til nytte for deg som leser dette i møte med disse utfordringene hvor du selv jobber.