‘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.

Wat is het Spotify Model?

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.

Scrum master = Agile coach

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.

Squad

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.

Spotify model squads

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.

Tribe

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.

Spotify model tribes

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.

Chapter

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.

Spotify model chapter

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.

Guild

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.

Spotify model guild

Welke uitgangspunten zijn essentieel?

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.

Autonomie in de squads

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:

  • Zorg voor een heldere visie en zorg dat iedereen de visie snapt

  • Geef heldere kaders en regelruimte

  • Vier successen met iedereen, laat zien waar ze het voor doen

  • Stimuleer mensen om hun eigen problemen op te lossen

  • Schets welke rol het team heeft in het grotere geheel

  • Zorg dat mensen leren van elkaars fouten

  • Creëer een actieve feedback cultuur

  • Beloon proactief gedrag

  • Wees transparant, open communicatie is heel belangrijk

  • Lead by example

Weinig standaardisatie

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.

Synchronisatie op de kaders

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.

Welke valkuilen zien we?

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 zonder ownership

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? Bekijk onze ownership training voor product owners of lees de blog ‘Ownership binnen de organisatie‘.

Micromanagement

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.

Hiërarchie vs. expertise

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.

Ego

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.

Lastig switchen

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.

De rol van de product owner

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?

  • Onderdeel zijn van een chapter betekent het delen van autonomie. De product owner die gewend is om zelf de ‘shot caller’ te zijn zal dit lastig vinden.

  • Het voegt een laag stakeholders toe. Enerzijds is dat een groep met slimme en betrokken mensen en dat biedt kansen, maar het kan ook een extra laag zijn met mensen die overtuigd moet worden, met alle ellende van dien (politiek, vertraging, suboptimalisatie, etc..).

  • We schreven in een eerdere blog dat élke product owner moet handelen volgens het IMPACT model en zich niet moet beperken tot de Scrum rituelen. Dat blijft grotendeels overeind staan, al is het ook goed mogelijk dat een aantal elementen simpelweg geen relevantie hebben in de squad missie.

  • De teamleden spreken veel mensen bij andere squads en halen daar dus ook informatie op. Dat maakt in potentie het product beter, maar vraagt om een extra inspanning om informatie op waarde te schatten en af te wegen. Dat moet passen in de planning van de product owner.
  • Het kan heel goed zijn dat je als product owner een essentieel onderdeel van een product onder je hoede hebt, maar dat het (tijdelijk) meer in een beheerfase dan in ontwikkelfase zit. Dan hou je tijd over. En misschien zijn er wel meerdere ‘kleinere’ takenpakketten of zijn er juist andere product owners in je chapter die overlopen. Wij zien situaties waarbij één product owner meerdere squads bedient dan ook als een reële optie. We willen wel adviseren om dat in dezelfde tribe te doen om praktische redenen, zoals het hebben van één tribe lead. Minstens net zo belangrijk is dat de product owner zelf onderdeel is van deze besluitvorming.

  • Wij kennen zeer weinig product owners die van zichzelf vinden dat ze uitgeleerd zijn. Een Scaled Agile organisatie zoals het Spotify model biedt enorm veel leerkansen. Naast de mogelijkheid om een echte specialist te worden op een deelproduct, kan het als product owner heel leerzaam zijn om collega’s te hebben die door dezelfde dingen heen gaan. Naast diverse intervisie- en coaching vormen is afkijken hoe iemand een bepaalde situatie aanpakt soms ook een hele goede manier om te leren.

Het belang van bedrijfscultuur

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:

  • Squads moeten de vrijheid krijgen om te bepalen waar ze werken en dat een combinatie van focus- en ontmoetingsplekken toch wel de ondergrens is qua faciliteiten.

  • ‘Lead by example’ is een essentiële stap. ‘The bottleneck is in the top of the bottle’ klinkt cliché, maar blijkt in onze ogen helaas heel vaak een grote kern van waarheid te hebben.

  • Als iedereen de cultuur begrijpt en er naar kan en wil handelen, dan is de kans groter dat er daadwerkelijk duurzame groei gaat ontstaan.

  • Met het gevaar om in herhaling te treden: geen enkele cultuur waar een plek is voor micromanagement is geschikt om enige vorm van ‘Scaled Agile’ te ondersteunen.

  • Vertrouwen wint het altijd van controle in kennisintensieve omgevingen. Scaled Agile betekent ‘Scaled trust’ en niet ‘Scaled control’.

Hoe implementeer je het Spotify Model?

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:

  • Doe het niet alleen. Er zijn tal van bureaus die hier heel veel ervaring mee hebben. Toevallig zijn wij er daar één van, maar wat we vooral willen bereiken met deze tip is dat je het niet op eigen houtje gaat fixen. Daarvoor is het afbreukrisico te groot.

  • Betrek de mensen. De woorden ownership en autonomie komen niet voor niets 10+ keer voorbij in dit stuk. Als je twijfelt aan hun competenties, intenties en mate van ownership, dan moet je eerst dat fixen.

  • Kijk ook naar andere modellen. Dit is geen rigide model dat 100% ingevoerd moet worden. Het SAFe model is in opmars en dat is niet zonder reden.

  • Omarm de dingen die nu goed gaan. Scrum heeft mega veel goede aspecten. Begin dus niet met een leeg blaadje.

  • Voorkom een big bang. Op maandagochtend opeens je werk anders doen werkt niet in kennisintensieve omgevingen. Ga gefaseerd te werk en maak kleine en meetbare projecten. Neem de mensen mee in die projecten en vier de successen. Gooi dus ook niet meteen je hele release model om, maar werk daar naar toe in fases. Je wilt voorkomen dat je klant (nog meer) hinder ondervindt.

Conclusie

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.

Leer technieken waar je morgen mee aan de slag kan!

Trainen bij dé plek voor product owners. Kleine klassen & trainers met +10 jaar ervaring.