Veel organisaties hanteren in een of andere vorm een agile manier van werken. Dit houdt in dat er in kleine teams, vaak tussen de vijf en tien mensen, wordt samengewerkt aan een geprioriteerde lijst van verbeterpunten (al dan niet projectmatig). Dankzij deze agile werkwijze wordt er meer bereikt in minder tijd. Maar waar agile voor deze teamgrootte zeer effectief werkt, is de toepasbaarheid voor een groot team beperkt. Steeds meer grote organisaties zijn geïnteresseerd in de voordelen van het toepassen van agile methodieken binnen grotere teams of zelfs organisatiebreed. Maar hoe gebruik je een agile methodologie, die zich richt op het werken in kleine teams, effectief in een grote organisatie met grote teams? In dit aanvullende inzicht beantwoorden we deze vraag door het Spotify-model uit te leggen; een methodologie die is ontwikkeld om agile toepasbaar te maken binnen grote teams of binnen een hele organisatie. Daarnaast worden in dit aanvullende inzicht de principes van het Spotify-model besproken en de valkuilen toegelicht die ervoor zorgen dat het model moeilijk te implementeren is.
Het Spotify-model is vernoemd naar de organisatie waar deze methode is ontstaan en voor het eerst werd gebruikt: Spotify. Het model ontstond tijdens de groei van Spotify. In het begin gebruikte het bedrijf scrum, een agile methode waarbij in een klein team aan een product wordt gewerkt. Naarmate het bedrijf groeide, werden deze teams groter en was de scrum-methode niet langer effectief. Spotify paste de toepassing van de scrum-methode aan de groeiende organisatie aan, aan wat ze zelf de "Spotify Engineering Culture" noemen. Deze methode is tegenwoordig beter bekend als het Spotify-model.
Squads en stammen
Dus bij de ontwikkeling van het Spotify-model werd scrum als uitgangspunt genomen. De scrumteams werden vervangen door squads. Een squad werkt collectief aan de langetermijndoelstelling die aan hen is toegewezen. Hoe ze dit doel bereiken is volledig aan hen. Deze autonomie bevordert innovatie en betrokkenheid van medewerkers. Het volledig zelfstandig bereiken van dit langetermijndoel wordt mogelijk gemaakt door het multidisciplinaire karakter van een squad, dat kennis en expertise biedt van de verschillende aspecten die belangrijk zijn voor het bereiken van dit langetermijndoel. De taken die door de squad worden uitgevoerd, worden kortgesloten met de producteigenaar van de respectieve squad. Net als bij scrum heeft de product owner de taak om de prioritering binnen de squad aan te geven, maar verder bemoeit hij zich niet met de dagelijkse gang van zaken binnen de squad.
In een grote organisatie is het aantal mensen dat aan hetzelfde product of dezelfde service werkt vaak groter dan één squad, dus worden er meerdere squads opgezet voor het product of de service in kwestie. Deze teams vormen samen een tribe. Binnen een tribe wordt een tribe lead aangewezen die verantwoordelijk is voor het faciliteren van een productieve en innovatieve omgeving voor de squads. De meeste squads binnen een tribe werken bijvoorbeeld vaak in hetzelfde gebouw om directe communicatie te vergemakkelijken en ruimte te hebben om te brainstormen en ideeën op te schrijven, bijvoorbeeld door whiteboards te plaatsen.
Welnu, binnen een tribe kunnen squads van elkaar afhankelijk zijn, bijvoorbeeld om een product te ontwikkelen dat bestaat uit enkele deelproducten. De squads werken hierin samen door de deelproducten voor elkaar aan te leveren en door planningen waar nodig aan te passen en af te stemmen met de andere squads, ook tijdens de projecten. Natuurlijk kan het voorkomen dat een aangewezen squad geen tijd heeft om een gevraagd deelproduct op tijd op te leveren. In dat geval kan een andere squad binnen de tribe ervoor kiezen om dit deelproduct zelf te ontwikkelen en het resultaat te laten verifiëren door de aangewezen squad, zodat de gevraagde oplevertermijn wel gehaald wordt. Het effectief overnemen van taken van een andere squad is alleen mogelijk dankzij het multidisciplinaire karakter van squads en de nauwe samenwerking binnen een stam.

Het Spotify-model, geschetst door Spotify zelf.
Kapittels en gilden
Terwijl tribes en squads multidisciplinair zijn, zijn chapters en guilds in plaats daarvan georganiseerd per discipline, vergelijkbaar met een afdeling of business unit in een meer traditionele organisatie. Een chapter wordt gevormd door alle mensen met dezelfde functie binnen dezelfde tribe. Een chapter kan bijvoorbeeld bestaan uit alle architecten die aan hetzelfde product werken, in een of meer teams maar binnen dezelfde stam. Een van de leden van het chapter is de chapter lead. Hij zorgt voor een periodieke bijeenkomst met alle leden van het chapter. Op deze manier kan kennis gedeeld worden, maar ook gezamenlijk nagedacht worden over mogelijke knelpunten waarvoor vakspecifieke kennis en ervaring nodig is. Naast het faciliteren van dit overlegmoment treedt de chapter lead op als coach voor de leden van zijn chapter.
Over het algemeen zijn er gilden. Gilden bestaan uit mensen met dezelfde functie of interesses, zowel binnen als buiten de stam. Gilden houden ook periodieke bijeenkomsten om kennis te delen en elkaar te helpen. Een probleem waarvoor binnen een stam geen oplossing is gevonden, kan bijvoorbeeld worden voorgelegd aan leden van andere stammen. Hierdoor ontstaan nieuwe inzichten die helpen het probleem op te lossen. Ook kan de oplossing voor hetzelfde type probleem in een andere stam helpen bij het oplossen van het huidige probleem. In wezen heeft een gilde dus dezelfde functie als een chapter, alleen bestaat het uit een grotere groep om mee te sparren.
Principes van het Spotify-model
Het Spotify-model is gebaseerd op een reeks principes, door Spotify zelf ook wel het "Agile à la Spotify"-manifest genoemd, waarbij het overkoepelende principe het faciliteren van autonomie voor teams is. Deze principes vormen de basis voor het borgen van de agile werkwijze.
- VOORTDURENDE VERBETERING wat betekent dat er altijd wordt gekeken naar verbeterpunten, zowel op organisatorisch als op persoonlijk niveau. Een voorwaarde hiervoor is een open cultuur waarin elke verandering wordt gezien als een kans om te verbeteren, mensen bereid zijn om nieuwe dingen te proberen en faalangst wordt weggenomen.
- ITERATIEVE ONTWIKKELING om aannames snel te valideren. Hypotheses worden getest en geanalyseerd en de resultaten van deze analyses worden gebruikt om aannames te verbeteren en waar nodig aan te passen. Om gemaakte aannames tijdig aan te passen is het belangrijk om in korte cycli te werken, door Spotify ook wel "short-learning cycles" genoemd, waarin continu getest kan worden.
- EENVOUD is nodig om snel op te schalen en kennis te delen. Dit geldt voor technische aspecten, werkmethoden en de organisatie als geheel. Communicatielijnen zijn zo direct mogelijk en alle overbodige stappen worden genomen. Om complexiteit uit de organisatie te houden, wordt iteratief tijd besteed aan vereenvoudiging. Dit kan zowel binnen squads, tribes, gilden en chapters.
- VERTROUWEN IN WERKNEMERS nodig is om beslissingen te nemen. Ook onderling vertrouwen is belangrijk, zodat medewerkers elkaar de juiste kritische vragen stellen en verbeterpunten aan het licht brengen. Door medewerkers vertrouwen te geven, voelen ze meer verantwoordelijkheid en ontstaan er meer ideeën.
- DIENEND LEIDERSCHAPwaarbij managers zich richten op het coachen, begeleiden en oplossen van knelpunten, in plaats van anderen te vertellen wat ze moeten doen. Dit stimuleert samenwerking om oplossingen te bedenken en ideeën uit te voeren. Er zijn ook regelmatig momenten voor één-op-één coaching om medewerkers te begeleiden. Belangrijk bij dienend leiderschap is dat beslissingen transparant zijn en gedragen worden door de organisatie.
In de principes van het Spotify-model zien we veel culturele aspecten terug. Onder het uitgangspunt "Continu verbeteren" is bijvoorbeeld te lezen dat een open cultuur nodig is om dit te implementeren, en voor het uitgangspunt "Eenvoud" is het advies om de communicatielijnen zo direct mogelijk te houden.
Valkuilen
Ondanks het succes dat het Spotify-model binnen Spotify zelf heeft gehad, kent het model ook een aantal valkuilen waardoor het model kan vastlopen en het niet aan te raden is om het model in een andere organisatie over te nemen.
- De matrixorganisatieDe kans bestaat dat het niet altijd duidelijk is op welk moment de stam- of kapittelleider betrokken moet worden. Om dit te voorkomen, wordt aanbevolen om dezelfde manager aan te stellen voor alle mensen binnen een team met dezelfde functie of op hetzelfde gebied.
- Te veel focus op teamautonomie en geen aandacht of processen voor wat er buiten het team gebeurt. Zorg ervoor dat er overeenstemming is in de hele organisatie, niet alleen binnen teams, en dat er processen zijn voor teamoverstijgende samenwerking.
- Iedereen kan samenwerken, toch? Als niet alle medewerkers bekend zijn met agile principes, kan het hele Spotify-model vastlopen. Het is daarom belangrijk om medewerkers hierbij te ondersteunen, bijvoorbeeld door ondersteuning te bieden bij het plannen, samenwerken en het goed invullen van de teamrollen.
De voorwaarden van het Spotify-model verschillen van de termen in de meeste organisatiemodellen. De overgang naar een nieuw organisatiemodel kan in het begin verwarrend zijn. Het 'laten vallen van managementfuncties' of het vervangen van huidige benamingen, zoals business units, door de termen van het model kan deze verwarring vergroten. Elke (nieuwe) medewerker moet de organisatiestructuur leren kennen, dus maak het niet complexer dan nodig. Je kunt het inzicht hieronder downloaden.

