Waarom het kopiëren van Spotify’s Squads and Tribes Model waarschijnlijk niet voor jou zal werken

Wat zijn Spotify’s zelfverklaarde problemen met dit model?

Dit model is zeker geen wondermiddel. Er zijn veel inzichten van mensen die bij Spotify hebben gewerkt die de tekortkomingen van hun model uitleggen en het lijkt erop dat de realiteit geen gelijke tred heeft gehouden met de agile nirvana mythe.

“Het baart me zorgen als mensen kijken naar wat we doen en denken dat het een framework is dat ze gewoon kunnen kopiëren en implementeren. … We doen nu echt ons best om te benadrukken dat we ook problemen hebben. Het is niet allemaal ‘glimmend en alles werkt goed en al onze teams zijn super geweldig’.”

Anders Ivarsson, co-auteur van de Spotify whitepaper

Issue 1: Engineering culture is geen organisatiestructuur

De oorspronkelijke content die Spotify uitbracht om hun methode uit te leggen, heette Spotify Engineering Culture. Hoewel ze een organisatiestructuur schetsten, ging het vooral over hun engineeringcultuur en hun kernwerkprincipes (zie hieronder voor een lijst daarvan).

Issue 2: Het model was een ambitie en het werd niet volledig overgenomen

Toen Spotify hun white paper uitbracht, was het deels ambitie en deels realiteit. Ze stelden een visie voor de toekomst op.

“Zelfs op het moment dat we het schreven, waren we er nog niet mee bezig. Het was deels ambitie, deels benadering. Mensen hebben echt moeite gehad om iets te kopiëren dat niet echt bestond.”

Joakim Sundén, agile coach bij Spotify 2011-2017

Issue 3: Het model geoptimaliseerd voor volledige teamautonomie

Toen de omvang van de teams groeide, definieerde Spotify geen gemeenschappelijk proces voor samenwerking tussen teams. Toen elk team een unieke manier van werken had, en er geen richtlijnen waren voor keuzes, leed de productiviteit van de totale organisatie eronder.

Issue 4: Samenwerking tussen teams was een veronderstelde competentie

Toen het aantal teams groeide, werd erkend dat toegewijde ondersteuning nodig was om de samenwerking tussen teams te begeleiden en te structureren. Toegewijde structuren of processen zijn nodig om teams die niet noodzakelijkerwijs met elkaar verbonden zijn in staat te stellen samen te werken.

“In artikelen of gesprekken als deze kan het overkomen dat Spotify een soort agile nirvana is waar alles gewoon werkt en dat is gewoon niet waar.”

Henrik Kniberg, bedenker van het Spotify-model

Bedenk dat het Spotify-model meer dan 10 jaar geleden is bedacht, dus het is zeer onwaarschijnlijk dat dit, in het licht van de hierboven gesignaleerde problemen, en wellicht ook andere, precies het model is dat ze nu gebruiken. Spotify is een bedrijf dat voortdurend leert en groeit, dus ze zullen dit model sinds de oorspronkelijke whitepaper al vele malen hebben aangepast. Toch kunnen we nog veel leren, ook al moet je het model niet direct toepassen.

De kracht van het Spotify-model zit in de engineeringprincipes en niet zozeer in het organisatieontwerp

De echte magie van het Spotify-model zat in de engineering- en productontwikkelingcultuur die ze creëerden voor snelle, gemotiveerde, ontkoppelde agile teams. In de loop der tijd ontwikkelden ze een aantal krachtige kernprincipes die hun hoge prestaties onderbouwden:

1. Productiviteit is nauw verbonden met motivatie – Motivatie heeft een grotere impact op productiviteit dan welke andere factor ook (zie Richard Sheridan’s Joy Inc). Spotify hanteert de formule Productiviteit = Inspanning x Competentie x Omgeving x Motivatie.
2. Evenwicht tussen afstemming en autonomie – Spotify streeft naar een evenwicht tussen afstemming (centrale sturing) en autonomie (zelforganisatie van het team). Managers schetsen de grote lijnen, maar vertellen de mensen niet hoe ze daar moeten komen of hoe ze de problemen moeten oplossen.
3. Ontkoppelde releases om de doorlooptijd te verkorten – Spotify heeft zijn architectuur veranderd om afhankelijkheden te ontkoppelen en releases eenvoudiger en sneller te maken. Dit zorgde voor frequentere productiereleases die onafhankelijk van teams kunnen worden uitgevoerd.
4. Vertrouw op je mensen – Spotify vertrouwt en ondersteunt zijn mensen zonder ze te willen controleren, omdat ze geloven dat de meeste mensen doen wat het beste is voor de organisatie.
5. Managers als dienende leiders – Het is beter voor managers om teams te vragen hoe ze kunnen helpen, in plaats van mensen te vragen waar ze mee bezig zijn of wanneer ze klaar zullen zijn.
6. Maximaliseer waarde boven drukte – Teams genereren ideeën, voeren snelle experimenten uit en meten vervolgens de resultaten. Op basis hiervan passen ze hun aanpak aan om de waarde te maximaliseren. Belangrijk is dat ze optimaliseren om de waarde te maximaliseren en niet alleen de output.
7. Verbetercultuur – Teams worden aangemoedigd om hun manier van werken te verbeteren en hebben een model voor wat hun leven gemakkelijker en beter zou maken. Er zijn speciale middelen beschikbaar om de manier van werken in de hele organisatie te helpen verbeteren.
8. Gezonde cultuur heelt gebroken processen – Processen kunnen vaak breken, maar een gezonde cultuur zal ertoe leiden dat mensen die problemen vanzelf oplossen.
9. Teamdefinitie van awesome – Spotify moedigt teams aan om te praten over en te beslissen wat hen awesome zou maken. Immers, zonder een visie op ontzagwekkendheid is het onwaarschijnlijk dat je er zult komen. Spotify-teams maken regelmatig gebruik van ’team gezondheidschecks’ en ze houden verbeteringen bij in de loop van de tijd. V: Hebben jullie teams een definitie van ‘geweldig’? Houden jullie bij hoe gezond jullie team is en streven jullie naar voortdurende verbetering?
10. Tevredenheid van medewerkers is van het grootste belang – De Head of People van Spotify beweerde dat 91% van de medewerkers het leuk vindt om bij Spotify te werken, wat volgens hem “natuurlijk niet bevredigend” is… zo hoog ligt de lat die ze voor zichzelf leggen.
11. Fouten maken is OK – De CEO van Spotify legt uit dat fouten maken wordt verwacht als je innovatie nastreeft. Om dit op te vangen heeft Spotify veel systemen ingebouwd om de effecten van mislukkingen te beperken.

“We streven ernaar om sneller fouten te maken dan wie dan ook”.

Daniel Ek, oprichter van Spotify

Zo zie je maar, er zitten een aantal mooie concepten in het model ingebouwd, maar het is geen blauwdruk voor agile organisatieontwerp op zich.

Iterate using inspect and adapt to create your own target model

De context van uw organisatie, waar u vandaan komt, uw cultuur, doelstellingen en vele andere factoren zullen bepalen wat voor u de beste oplossing is.

U kunt natuurlijk ideeën onderzoeken en lenen van bedrijven als Spotify, Menlo Innovations, Google, of andere goed presterende bedrijven, maar dat zou slechts het startpunt moeten zijn.

U moet helder weten welk probleem u probeert op te lossen en vervolgens een plan maken dat is gebaseerd op het oplossen van uw unieke set uitdagingen.

Inspecteren en aanpassen is een kernconcept van agile.

Inspecteren is het gebruiken van een open geest en transparante feedback (meestal uitgevoerd tijdens een retrospective) om eerlijk te kijken naar wat werkt en wat niet werkt. Dit kan van alles zijn, van processen, team dynamiek, strategie of inefficiënties, alles wat de prestaties van het team belemmert en hun motivatie en betrokkenheid vermindert.

Aanpassen is het proces van het nemen van de thema’s van het introspecteren en het vinden van manieren om erop te reageren en ze te verbeteren. Aanpassing vergt creativiteit en inspanning en neemt vaak de vorm aan van een experiment. Een kleine test wordt uitgevoerd met een subgroep van de teams om er zeker van te zijn dat de oplossing levensvatbaar is, voordat deze wordt uitgerold over de hele organisatie.

Dit proces wordt vervolgens herhaald elke keer dat uw organisatie is verbeterd en dichter bij uw ideale staat van zijn komt.

Geïnspireerd zijn, maar niet klakkeloos kopiëren

Er is veel te zeggen voor het Spotify-model, als je hun engineeringprincipes overneemt en modelleert naar de geest van wat ze proberen te doen.

Context is alles, dus tenzij je een Zweeds muziekstreamingbedrijf bent, is het onwaarschijnlijk dat het klakkeloos kopiëren van Spotify je problemen zal oplossen.

Het is echter zeer onwaarschijnlijk dat het klakkeloos kopiëren van het model voor jou zal werken. Het is belangrijk om inspiratie te putten uit meerdere bronnen, als je agile wilt schalen in je organisatie.

Als je agile wilt schalen en meer dan 150 mensen in je team hebt, dan zijn twee goede schaalmodellen:

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

Als je minder dan 150 mensen hebt, dan is Shape Up van Basecamp een prima model om naar te streven.

Spotify is geen agile nirvana

Ik hoop dat dit artikel duidelijk heeft gemaakt dat de agile engineering-cultuur bij Spotify veel meer is dan alleen het creëren van squads, chapters, tribes en guilds.

In feite bestaat het Spotify-model vooral uit zijn cultuur en hooggekwalificeerde teams, niet uit de organisatorische opzet. Je kunt enorme voordelen behalen door de principes over te nemen, zelfs zonder squads en tribes in te voeren.

“In artikelen of gesprekken als deze kan het overkomen dat Spotify een soort agile nirvana is waar alles gewoon werkt en dat is gewoon niet waar.”

Henrik Kniberg

De snelle versie van hoe je agile kunt schalen

Ik zal hier in de toekomst een hele blogpost over schrijven, maar voor nu is hier de snelle versie van hoe je agile moet gaan schalen in je organisatie:

1. Geef helder welk probleem je probeert op te lossen.
2. Opneem de beste en meest relevante delen van de beste schaalmodellen in de industrie, zoals SAFe, LeSS, DaD etc. in je doelontwerp.
3. Ontwerp een doelstaat die de beste praktijken op maat neemt voor jouw unieke set uitdagingen.
4. Maak veranderingen in de richting van je doelstaatontwerp.
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!