Wat is het Spotify model?

‘Kijken welke werkwijze het beste werkt’ hebben ze ook bij Spotify gedaan. Met die inzichten hebben zij zelf een model ontwikkeld dat nu ook buiten de organisatie wordt gebruikt. We gaan je introduceren in de wereld van het Spotify Model: de kernprincipes, de valkuilen die op de loer liggen, en de cruciale rol van zowel de product owner als de algehele bedrijfscultuur. En voor diegenen die popelen om dit model zelf te implementeren: verwacht geen eenvoudige afspeellijst die je blindelings kunt volgen. Implementatie vereist tijd, inzicht en bovenal afstemming op de unieke ritmes van jouw organisatie.

Het Spotify Model is – zoals je al vermoedde – bedacht door Spotify. Zij groeien erg hard en kwamen daardoor rond 2012 steeds vaker in situaties terecht dat meerdere teams aan hetzelfde stuk product werkten. Dat zorgde voor veel complexiteit en de Scrum rituelen gingen knellen, wat gezamenlijk zorgden dat releases minder vaak en minder goed gebeurde. En dat ging uiteindelijk ten koste van de waarde voor de gebruiker.

Deze situatie van snelle groei van development teams – die we nu vaak ‘Scaled Agile’ noemen – besloot hen over te gaan tot een ander model. Een model waarbij o.a. de Scrum rituelen optioneel werden voor elk team. En dat werd uiteindelijk omgedoopt tot het Spotify Model.

Dit model bestaat uit een aantal basisprincipes, maar we gaan eerst de structuur behandelen. Er wordt gewerkt met squads, tribes, chapters en gildes.

Een hele belangrijke noot is dat dit model boven alles Agile is. Twee vergelijkbare organisaties kunnen het om zeer legitieme redenen compleet anders inrichten en daar in de loop der tijd iteraties op doorvoeren. Meer tips over implementeren en optimaliseren vind je onderaan dit artikel.

De rol van Scrum master (bewaker van de juiste uitvoering van de Scrum rituelen) wordt vervangen voor een Agile coach. De belangrijkste nuance zit hem in het feit dat een coach als doel heeft om het team dermate vakvolwassen te krijgen dat de coach steeds minder nodig is. Zeker in Nederland zien we vaak dat de Scrum Master een soort van workload-coördinator is. Een Agile coach is een Agile expert die als missie heeft om zijn/haar kennis van de processen over te dragen aan de individuen binnen de squads.

Een squad is op hoofdlijnen gelijk aan een Scrum team; het is een clubje mensen (tussen de 7-10 personen) met een product owner die verschillende expertises combineren om een waardevol (deel)product te maken. Daarbij zijn ze waar mogelijk zelf-organiserend, en in sommige situaties zelfsturend.

Een squad heeft een missie die onderdeel is van de productstrategie. Een voorbeeld van een squad missie is het bieden van een zo goed mogelijke check-out flow op de IOS app. Of het 24/7 bereikbaar houden van de belangrijkste functionaliteiten van de dealer login, en ga zo maar door… Er is dus sprake van een afgekaderd domein, maar samenwerking met andere squads zal onvermijdelijk zijn. Ze mogen zelf bepalen hoe dingen worden gebouwd (dat kennen we al van Scrum) en mogen nu ook zelf bepalen met welke andere teams ze samen gaan werken.

Een tribe is niets meer en niets minder dan een verzameling van squads die om logische wijze bij elkaar horen. De squad die de IOS app bouwt, zal vermoedelijk in een tribe zitten waarin zich ook een squad bevind die de Android app bouwt.

De theorie zegt dat een tribe maximaal 100 personen mag zijn, en ook in SAFe zie je een soortgelijk aantal (125) in een train. En daar is een hoop voor te zeggen. Echter kennen wij ook klanten die met 200+ personen toch een tribe gevoel hebben en waar een minimale overhead genoeg is om tienduizenden ontwikkel-uren om te zetten naar waarde voor de klant.

Formeel heeft een tribe één leider. En die leider zorgt er voor dat de tribe voldoende gesynchroniseerd is. In de praktijk zorgt een gezonde tribe goed voor zichzelf. Er worden actief en zonder te veel gestandaardiseerde processen relevante kennis en vaardigheden gedeeld, waarbij de ‘tribe lead’ meer een ‘stamoudste’ is; als de seniors in de tribe er niet uit komen, dan vragen ze advies bij de tribe lead. Desondanks zal je er niet aan ontkomen dat een tribe lead een aparte functie is bij een senior persoon. Vaak wordt deze functie gecombineerd met een grote verantwoordelijkheid rondom het product of bepaalde P&L verantwoordelijkheid.

Een chapter is een verzameling van alle mensen met een bepaalde expertise of set competenties. Stel, je hebt 20 Scrum teams en elk team heeft één UX-er. Dan zal het UX-chapter bestaan uit 20 man.

Het bestaansrecht van een chapter is verbinding op kennis en vaardigheden. Mensen willen worden geïnspireerd op hun eigen vakgebied en actief van elkaar leren. Afhankelijk van de senioriteit van het chapter en de bedrijfscultuur wordt dit informeel gefaciliteerd (bijvoorbeeld een pizza-avond en buddy system) of formeel geregeld via een e-learning systeem en een schalen systeem. En alles daar tussenin is natuurlijk ook denkbaar.

De chapter lead is vaak de meest ervaren persoon. Hij/zij is een lichtend voorbeeld voor de rest en meestal op de hoogte van ‘the latest and greatest’. De chapter lead is bijna altijd ook de leidinggevende van de leden in zijn of haar chapter.

Een gilde vinden wij persoonlijk de coolste naam. Minstens net zo belangrijk is dat dit het meest flexibele geheel is van de structuur. De vergelijking met een community is vaker gemaakt en voelt in onze ogen ook als logisch. Het is iets waar je bij wilt horen, omdat je een bepaalde interesse deelt met je collega’s. Zo kan de Gilde ‘Mobile’ bestaan uit allerlei verschillende mensen uit verschillende tribes of chapters. En het kan zijn dat iemand nu tot een bepaalde gilde wilt behoren, maar over een tijdje niet meer.

Het begrijpen van deze balans tussen vrijheid en structuur is cruciaal voor het succes van het model. Wij beschrijven de 3 belangrijkste uitgangspunten die het model ondersteunen in het succes.

Een erg belangrijk uitgangspunt binnen het Spotify model is autonomie. Laat de teams zelf beslissen binnen de kaders van de overstijgende productstrategie, beslissen over hoe ze werken, waar ze werken, met wie ze werken, hoe ze kwaliteit borgen, hoe ze innoveren, en noem het maar op… Als je de squads niet vertrouwt om dat zelf te organiseren, dan is de kans groot dat je als management de juiste voorwaarden niet hebt geschapen. De lijst die wij hanteren is als volgt:

Er is geen ivoren toren die bepaalt hoe er binnen de teams wordt gewerkt en hoe ze onderling samenwerken. De ene squad kan werken via de Kanban methode, terwijl de andere squad een sprint planning ziet als methode om werk te prioriteren. Het is allemaal OK, zolang de squad missie maar wordt gezien als Noorderzon. In de praktijk gaan goede dingen vanzelf overgenomen worden door (het gros van) de andere squads. Als tribe lead kan je er voor kiezen om hier een verbindende rol te hebben om dit proces te versnellen.

Autonomie en zelforganisatie werkt alleen als er hele duidelijke kaders zijn. Op de plekken waar wel kaders gelden, is frequente synchronisatie essentieel. Iedereen moet weten welke kaders er waarom zijn en hoe de ‘overhead’ kan faciliteren op het moment dat de kaders onduidelijk of onhaalbaar zijn.

Enkele voorbeelden van kaders zijn SLA reactietijden op support, hoeveel tijd een squad mag investeren in de periodieke hackathon en welke documentatie-eisen er zijn om ISO compliant te blijven.

Elk voordeel heeft zijn nadeel. Er zijn best wel wat dingen die de moeite waard zijn om goed over na te denken. Sommige kwam Spotify zelf ook tegen, daarom willen we je er van te voren voor waarschuwen.

Autonomie is één van de mooiste gereedschappen in elke toolbox. Het begint met het geven ervan vanuit de leads naar de squads. Maar die moet dan ook worden omarmd en gefaciliteerd. Wanneer mensen niet gewend zijn om als ‘owner’ te denken en handelen, dan zullen ze daar in het begin veel support bij nodig hebben. Vaak heeft het management net zo veel support nodig als de squads zelf om niet terug te vallen in oude patronen. Want oude patronen slijten lastig. Meer weten over ownership? Lees de blog ‘Ownership binnen de organisatie‘.

Micromanagement is hier de absolute doodsteek. Micromanagement vermoord elke vorm van autonomie. Wij zien micromanagement helaas vaak terugkomen. Een mooie quote van een collega: “Feed the teams with problems, not with solutions.”

Als tribe lead heb je een bepaalde rol richting een teamlid, maar als chapter lead ook. Een dergelijke situatie neigt naar een matrix structuur. Wat gebeurt er als de chapter lead en tribe lead niet op dezelfde pagina zitten? Dat kan leiden tot vertraging en suboptimalisatie. En politieke skills krijgen dan soms meer gedaan dan technical skills. Al met al is het belangrijk om in ieder geval heldere escalatie-paden af te stemmen.

Je Ego is de allerslechtste stakeholder die je ooit gaat tegenkomen. Hoe meer ego er speelt in de squads, hoe minder goed dit model werkt. Fouten toegeven, andere helpen en zelf om hulp durven vragen zijn randvoorwaarden om in dergelijke Agile omgevingen te kunnen excelleren als individu en als team. Als je ego in de weg staat, dan gaat de motor vastlopen.

Ego’s in de top is zo mogelijk nog gevaarlijker omdat het hele tribes op slot kan zetten. Wanneer de gebruiker steeds minder centraal gaat staan bij belangrijke beslissingen, dan worden de verkeerde dingen gebouwd om de verkeerde redenen. Voor je het weet ben je duizenden uren kwijt en – nog veel belangrijker – is de productstrategie vervuild en krijgen de squads een flinke knauw in hun motivatie.

Een gestandaardiseerde werkwijze heeft als voordeel dat je gemakkelijk personen in een andere squad kan zetten als het product daar om vraagt, zonder dat er productiviteit verloren gaat. Toch kan dat lastig zijn als de squads andere werkprocessen hebben. Collega’s zullen zeker een bepaalde inwerktijd hebben, maar het is ook denkbaar dat de ‘stijl’ van de squad niet past bij het nieuwe lid. Dit kan wanneer het een switch voor langere tijd is problemen geven.

Elke squad heeft een squad missie. Rondom die missie is een grote rol weggelegd voor een afgebakende verantwoordelijkheid. Dat betekent dat het team binnen de missie en de productstrategie zelf bepaalt wat er gebouwd gaat worden. Daarin is en blijft de product owner de aangewezen man/vrouw voor deze mooie taak.

Wat is er dan anders in Scaled Agile omgevingen?

Het is verleidelijk om hier uitgebreid te betogen over het risico van een ongezonde bedrijfscultuur en welke change-management-modellen van toepassing zijn om die cultuur te veranderen. Maar het zou misplaatst zijn om de honderden boeken over dit onderwerp plat te slaan in één of twee alinea’s. Desondanks willen we toch wat dingen naar voren brengen:

De transitie maken van een Scrum organisatie naar een Scaled Agile situatie zoals het Spotify Model is leuk en leerzaam en kan een mega positieve impact hebben om je bedrijfscultuur, je klanttevredenheid, je medewerker verloop, winstgevendheid en ga zo maar door. Maar het is ook een pittig traject dat tijd kost en verander bereidheid vraagt van de teams, maar zeker ook bij het management.

Elke transitie is anders en daarom bestaat er ook geen goede checklist. En we weten ook dat het logisch is om te denken dat als je dit éénmaal regelt, het voor altijd geregeld is. Maar dat is niet zo. Onze ervaring is dat het continue verandert, en dat moet je omarmen.

We willen je graag tot slot een aantal tips geven:

Is het vertrekpunt van je transitie een traditionele projectorganisatie of een SCRUM organisatie met lage maturity? Dan zijn de uitdagingen nog een stuk groter. In dat geval raden we je zeker aan om eens een vrijblijvende kop koffie met ons te plannen zodat we kunnen begrijpen wat je ambities zijn en of hoe we je daar bij kunnen helpen.

Onze missie is om dé perfecte product owner match te vinden. Of je nu zelf die product owner bent die een nieuwe uitdaging zoekt, of je zoekt de perfecte match voor jouw team – via ons uitgebreide netwerk en met persoonlijk advies wijzen we je de weg. Vind jouw perfecte match.