Varför det förmodligen inte fungerar för dig att kopiera Spotifys Squads and Tribes-modell

Vad är Spotifys erkända problem med den här modellen?

Den här modellen är på intet sätt ett universalmedel. Det har funnits många insikter från de som arbetat på Spotify som förklarar bristerna i deras modell och det verkar som om verkligheten inte har hållit jämna steg med myten om det agila nirvana.

”Det oroar mig när folk tittar på vad vi gör och tror att det är ett ramverk som de bara kan kopiera och implementera. … Vi försöker nu verkligen att betona att vi också har problem. Det är inte bara ”skinande och allt fungerar bra och alla våra grupper är super fantastiska”.”

Anders Ivarsson, medförfattare till Spotifys vitbok

Syfte 1: Ingenjörskultur är inte en organisatorisk struktur

Det ursprungliga innehållet som Spotify släppte och som förklarade deras metod hette Spotify Engineering Culture. Även om de beskrev en organisationsstruktur, handlade det främst om deras ingenjörskultur och deras centrala arbetsprinciper (se nedan för en lista över dessa).

Syfte 2: Modellen var en ambition och den antogs inte fullt ut

När Spotify släppte sin vitbok var den delvis ambition och delvis verklighet. De lade fram en vision för framtiden.

”Inte ens när vi skrev det gjorde vi det. Det var en del ambition och en del approximation. Folk har verkligen kämpat för att kopiera något som egentligen inte fanns.”

Joakim Sundén, agil coach på Spotify 2011-2017

Uppgift 3: Modellen optimerad för fullständig teamautonomi

I takt med att teamen växte i storlek definierade Spotify inte någon gemensam process för samarbete mellan teamen. När varje team hade ett unikt sätt att arbeta, och det inte fanns några riktlinjer för val, blev den övergripande organisationens produktivitet lidande.

Syfte 4: Samarbete mellan team var en antagen kompetens

I takt med att antalet team ökade insåg man att det behövdes dedikerat stöd för att vägleda och strukturera samarbetet mellan teamen. Det krävs dedikerade strukturer eller processer för att team som inte nödvändigtvis är kopplade till varandra ska kunna samarbeta.

”I artiklar eller föredrag som detta kan det framstå som att Spotify är något slags agilt nirvana där allting bara fungerar och det är helt enkelt inte sant.”

Henrik Kniberg, skapare av Spotify-modellen

Håll i minnet att Spotify-modellen skapades för över 10 år sedan, så det är mycket osannolikt att det, mot bakgrund av de problem som identifierats ovan, och kanske andra, är exakt den här modellen som de använder nu. Spotify är ett företag som ständigt lär sig och växer, så de kommer att ha utvecklat denna modell många gånger sedan den ursprungliga vitboken. Det finns dock fortfarande mycket vi kan lära oss, även om man inte bör tillämpa modellen direkt.

Styrkan i Spotify-modellen ligger i dess tekniska principer snarare än i dess organisationsutformning

Den verkliga magin i Spotify-modellen låg i den teknik- och produktutvecklingskultur de skapade för snabba, motiverade, frikopplade agila team. Med tiden utvecklade de några kraftfulla centrala arbetsprinciper som låg till grund för deras höga prestanda:

1. Produktivitet är nära kopplat till motivation – Motivation har större inverkan på produktiviteten än någon annan faktor (se Richard Sheridans Joy Inc). Spotify använder formeln Produktivitet = Ansträngning x Kompetens x Miljö x Motivation.
2. Balansera anpassning och autonomi – Spotify strävar efter att hitta en balans mellan anpassning (central styrning) och autonomi (teamets självorganisering). Cheferna målar upp den stora bilden men talar inte om hur de ska nå dit eller hur de ska lösa problemen.
3. Frikopplade releaser för att minska cykeltiden – Spotify ändrade sin arkitektur för att frikoppla beroenden och göra releaser enklare och snabbare. Detta möjliggjorde mer frekventa produktionsreleaser som kan vara oberoende mellan olika team.
4. Lita på dina medarbetare – Spotify litar på och stödjer sina medarbetare utan att försöka kontrollera dem eftersom de tror att de flesta människor gör vad som är bäst för organisationen.
5. Chefer som tjänande ledare – Det är bättre för chefer att fråga teamen hur de kan hjälpa till, snarare än att fråga folk vad de arbetar med eller när de kommer att vara klara.
6. Maximera värde framför busyness – Teamen genererar idéer, genomför snabba experiment och mäter sedan resultaten. Utifrån detta anpassar de sitt tillvägagångssätt för att maximera värdet. Det är viktigt att de optimerar för att maximera värdet och inte bara produktionen.
7. Förbättringskultur – Grupperna uppmuntras att förbättra sitt sätt att arbeta och har en modell för vad som skulle göra deras liv enklare och bättre. Det finns särskilda resurser tillgängliga för att hjälpa till att förbättra arbetssätten i hela organisationen.
8. Sund kultur läker trasiga processer – Processer kan ofta gå sönder, men en sund kultur leder till att människor löser dessa problem på egen hand.
9. Teamets definition av awesome – Spotify uppmuntrar teamen att prata om och bestämma vad som skulle göra dem awesome. Utan en vision för det fantastiska är det trots allt osannolikt att ni når dit. Spotify-teamen använder sig av regelbundna ”hälsokontroller av teamet” och spårar förbättringar över tid. Fråga: Har era team en definition av ”awesome”? Följer ni teamets hälsa och strävar efter ständiga förbättringar?
10. Medarbetarnas tillfredsställelse är av yttersta vikt – Spotifys personalchef hävdade att 91 % av medarbetarna tyckte om att arbeta på Spotify, vilket han sa var ”naturligtvis inte tillfredsställande”… så högt är ribban som de sätter för sig själva.
11. Misstag är okej – Spotifys vd förklarar att misstag är förväntade när man driver på för innovation. För att mildra detta har Spotify många system inbyggda för att begränsa effekterna av misslyckanden.

”Vi strävar efter att göra misstag snabbare än någon annan”.

Daniel Ek, grundare av Spotify

Som du ser finns det en del bra koncept inbyggda i modellen, men den är inte i sig själv en plan för agil organisationsdesign.

Iterera med hjälp av inspektera och anpassa för att skapa din egen målmodell

Sammanhanget i din organisation, var du utgår ifrån, din kultur, dina mål och många andra faktorer kommer att avgöra den bästa lösningen för dig.

Självklart kan du undersöka och låna idéer från företag som Spotify, Menlo Innovations, Google eller andra högpresterande företag, men det bör bara vara utgångspunkten.

Du måste veta med tydlighet vilket problem du försöker lösa och sedan skapa en plan som bygger på att lösa din unika uppsättning utmaningar.

Inspektera och anpassa är ett kärnkoncept inom agilitet.

Inspektera innebär att använda ett öppet sinne och transparent feedback (oftast utförd vid en retrospektiv) för att ärligt titta på vad som fungerar och vad som inte fungerar. Det kan handla om allt från processer, gruppdynamik, strategi eller ineffektivitet, allt som hindrar gruppens prestationer och minskar deras motivation och ägarskap.

Adaptera är processen där man tar upp teman från introspektion och hittar sätt att bemöta och förbättra dem. Anpassning kräver kreativitet och ansträngning och tar ofta formen av ett experiment. Ett litet test utförs med en delmängd av teamen för att se till att lösningen är genomförbar, innan den rullas ut i hela organisationen.

Denna process upprepas sedan varje gång din organisation förbättras och närmar sig ditt ideala måltillstånd.

Var inspirerad men kopiera inte blint

Det finns mycket att gilla med Spotify-modellen, om du anammar deras tekniska principer och modellerar andan i det de försöker göra.

Sammanhanget är allt, så om du inte är ett svenskt musikstreamingföretag så är det osannolikt att blint kopiera Spotify för att lösa dina problem.

Det är dock mycket osannolikt att blint kopiera modellen kommer att fungera för dig. Det är viktigt att hämta inspiration från flera olika källor om du vill skala agilt i din organisation.

Om du vill skala agilt och har mer än 150 personer i ditt team är två bra skalningsmodeller:

1. Scaled Agile Framework (SAFe)
2. Large Scale Scrum (LeSS)

Om du har färre än 150 personer är Shape Up från Basecamp en bra modell att sträva efter.

Spotify är inte ett agilt nirvana

Jag hoppas att den här artikeln har belyst att den agila ingenjörskulturen på Spotify är mycket mer än att bara skapa squads, chapters, tribes och guilds.

I själva verket är Spotify-modellen främst dess kultur och högkompetenta team, inte dess organisatoriska utformning. Du kan få enorma fördelar genom att anta principerna även utan att införa squads och tribes.

”I artiklar eller föredrag som detta kan det framstå som att Spotify är något slags agilt nirvana där allt bara fungerar och det är helt enkelt inte sant.”

Henrik Kniberg

Den snabba versionen av hur man skalar agilt

Jag kommer att skriva ett helt blogginlägg om detta i framtiden, men för tillfället kommer här den snabba versionen av hur du bör gå till väga för att skala agilt i din organisation:

1. Gör dig klar över vilket problem du försöker lösa.
2. Konsumerar de bästa och mest relevanta delarna av de bästa skalningsmodellerna i branschen, t.ex. SAFe, LeSS, DaD etc. i din måldesign.
3. Utforma ett måltillstånd som tar hänsyn till bästa praxis och som är skräddarsytt för dina unika utmaningar.
4. Företa förändringar i riktning mot din måltillståndsdesign.
5. Inspect and adapt constantly to find improvements based on evidence.
6. Make course corrections based on the feedback.
7. Rinse and repeat steps 4 to 6!