Hvorfor lykkes du ikke med Spotify-modellen?

I 2012 publiserte smidige coacher i Spotify en bloggpost hvor de beskrev hvordan de skalerte smidig praksis i strømmetjenesten. Her tok de for seg hvordan de organiserte produktutviklingen i autonome, kryssfunksjonelle produktteam med ansvar for hver sine funksjonsområder (Squads), samtidig som samhandling på kryss og tvers av organisasjonen skjedde gjennom blant annet Tribes, Chapters og Guilds. Spotify var midt i en aggressiv vekstperiode, og ble ansett som et vellykket eksempel på digital produktutvikling.

Det vi ser de neste årene er at coacher, konsulenter og andre fagfolk raskt er ute med å anbefale Spotify sin modell som en blueprint på hvordan din organisasjon skal lykkes med å bli mer smidig. Og konsekvensen av dette er at det i mange norske bedrifter nå eksisterer Squads, Tribes, Chapters og Guilds. Dessverre er det ikke like mange som klarer å hente ut effektene fra dette i form av hurtighet og tilpasningsdyktighet. Jeg har gjort meg noen refleksjoner rundt hva som kan være årsaken.

Smidige produktteam er en løsning på et problem eller et behov. Og det er det mange som glemmer å tydelig definere, som en rettesnor som skal veilede gjennom en større omorganisering. Det kan for eksempel være å øke innovasjongraden, korte ned time-to-market, treffe markedet bedre med nye tjenester eller øke eierskap og motivasjon i digital utvikling. Hva du ønsker å oppnå betyr noe for hvordan din produktutviklingsrigg bør organiseres.

Det coachene i Spotify beskrev i sin artikkel er det vi kaller «smidig praksis»; hvilke teamstrukturer og kompetanse de satte sammen, teamstørrelse, hva de kalte de ulike formene for samarbeid og samhandling mellom team. Men smidige praksiser er bare toppen av isfjellet. Smidig produktutvikling består nemlig også av prinsipper og verdier – den delen av isfjellet som ligger under havoverflaten. De mer usynlige retningslinjene for teamene, som påvirker handlingsrommet og hvilket mandat de tar og får. Etablerte prinsipper og kultur kan bli en stor hindring for å lykkes med innføring av produktteam, hvis ikke disse også adresseres og vurderes i lys av det man ønsker å oppnå. Jo lenger ned i isfjellet vi kommer, jo vanskeligere er det å lykkes med et blueprint fra Spotify på smidig praksis.

De dårlige nyhetene er at smidig organisering langt fra en engangsgreie, og det betyr også at arbeidet med smidig organisering vil fortsette i årene etter du har innført ny organisering. Det handler om å bli bedre til å omstille seg kontinuerlig og skape en tilpasningsdyktig organisasjon som kan agere raskt på endringer. Et godt eksempel er NAV som i løpet av fire arbeidsdager klarte å lage en løsning for forskuddsbetaling av dagpenger i lys av Covid-19, og fikk betalt ut en milliard kroner. De sier selv at de ikke hadde klart dette for noen år tilbake, men er nå rigget med riktig teknologi, kompetanse og arbeidsmetodikk. De organisasjonene som er best på dette har endringsdyktighet innbakt i kulturen, og har skapt rom for prøving og feiling både i produktutvikling og organisasjonsutvikling. En åpen delings- og samarbeidskultur med høy grad av tillit gir rom for at prinsipper og smidig praksis kan endres og tilpasses kontinuerlig.

Det er ikke problemfritt å rigge produktteamene for kontinuerlig endring i en ellers byråkratisk organisasjon, og denne problemstillingen er det mange norske bedrifter som nå står ovenfor. En ting er sikkert, hvis du velger å organisere deg for smidig produktutvikling, så må du også verne om den konstruksjonen du skaper, selv når byråkratiet kjemper imot. De som lykkes, er de produktteamene som klarer å skape armslag mot resten av organisasjonen – eksempelvis gjennom å inkludere folk med både organisatorisk og forretningsmessig forståelse i produktteamene med én oppgave; å skape en smidig lunge som gir teamet rom til å puste. I parallell er det naturlig å jobbe med å øke forståelsen i resten av organisasjonen, slik at de mekanismene som jobber imot vil endres over tid.

Det finnes dessverre ingen «one size fits all» når det kommer til organisering av produktteam. Det er ingen «silver bullet». Det handler om å forstå hvilke problemer du forsøker å løse i din organisasjon, og kombinere med dine rammebetingelser. Det er derfor ikke så attraktivt å «steal with pride» her... Vi anbefaler heller å «steal and tweak with pride» - så lenge du husker på hva det er du ønsker å oppnå.