In dit artikel leggen we – aan de hand van onze eigen ervaringen – het Spotify model uit.

We gaan de volgende thema’s behandelen:

• Wat is het Spotify model?
• Welke uitgangspunten zijn essentieel?
• Welke valkuilen zien we?
• Welke rol heeft de product owner in het Spotify model?
• Wat is de rol van de bedrijfscultuur in het Spotify model?
• Hoe implementeer je het Spotify model? (spoiler alert: er is géén kant-en-klare handleiding om dit in een paar weken of maanden te doen)

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.

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

Scrum master = agile coach

De rol van Scrum master (bewaker van juist 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 in de squads.

Squad

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

Iedere squad heeft een product owner, daarover later meer. En ze zijn verantwoordelijk om hun eigen code naar productie toe te pushen.

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.

Tribes

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 ook de squad zit die de Android app bouwt.

De theorie zegt dat een tribe max 100 personen mag zijn en ook in SAFe zie je een soortgelijk aantal (125) in één train. En daar is een hoop voor te zeggen. Echter, kennen wij ook klanten die met 200+ personen toch één tribe gevoel hebben en waar een minimale overhead genoeg is om tienduizenden ontwikkeluren 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.

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 een 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 (pizza-avond en buddy system) of formeel geregeld via een e-learning systeem en een schalensysteem. En alles daar tussenin is ook denkbaar.

De chapter lead is heel vaak de meest ervaren persoon. Hij/zij is een lichtend voorbeeld voor de rest en vaak 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 vind ik 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.

Autonomie in de squads

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 – deze komt uit onze workshop met als thema ownership – is als volgt:

• Zorg voor een heldere visie en zorg dat iedereen de visie snapt
• Geef heldere kaders en regelruimte (zie kopje ‘Synchronisatie op de kaders)
• Vier successen met iedereen, laat zien waar ze het voor doen
• Geef vertrouwen, leg het mandaat neer in de teams
• 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 in de teams wordt gewerkt en hoe ze onderling samenwerken. De ene squad kan werken via de Kanban methode, terwijl de andere squad een sprintplanning 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 dingen 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.

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.

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.

Micromanagement

Micromanagement is hier de absolute doodsteek. Het vermoord elke vorm van autonomie. Wij zien micromanagement helaas vaak terugkomen en hebben hier een speciale workshop voor ingericht om dit aan te pakken. Wil je daarover meer weten, neem dan contact met ons op. We brengen je graag in contact met klanten die (succesvol) aan de slag zijn gegaan met dit thema. Mooie quote van een collega: “Feed the teams with problems, not with solutions.”

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

Switchen kan lastig zijn

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 productiviteitsverlies is. Dat kan lastig zijn als de squads andere werkprocessen hebben. Collega’s zullen dan sowieso een bepaalde inwerktijd hebben, maar het is ook denkbaar dat de ‘stijl’ van de squad niet past bij het nieuwe lid. Dit kan, als 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?

• 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 eerder artikel 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 dus ook info 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 PO.
• 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 beheer- 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. Ook Een product owner wil onderdeel zijn van alle beslissingen die impact hebben op zijn of haar werkterrein.
• 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 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 aanstippen:

• 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’.

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. We sparren hierover graag met je. Heb je daar behoefte aan, neem dan contact met ons op. We komen er vaak nog dezelfde dag bij je op terug.
• 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.

Direct een product owner inhuren of interesse in de product owner training? Ook hier kunnen we je mee helpen.