Veel organisaties passen in enige vorm een agile werkwijze toe. Hierbij wordt samengewerkt in kleine teams, vaak bestaande uit vijf tot tien personen, aan een geprioriteerde lijst van verbeterpunten (projectmatig of anderszins). Dankzij deze agile werkwijze wordt meer bereikt in minder tijd. Waar agile echter zeer effectief is voor deze teamgrootte, is de toepasbaarheid ervan binnen grote teams 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 methodiek, die zich richt op werken in kleine teams, effectief in een grote organisatie met grote teams? In deze aanvullende insight beantwoorden we deze vraag door het Spotify-model toe te lichten; een methodiek die is ontwikkeld om agile toepasbaar te maken in grote teams of binnen een gehele organisatie. Daarnaast bespreekt deze aanvullende insight de principes van het Spotify-model en worden de valkuilen toegelicht die ervoor zorgen dat het model lastig te implementeren is.

Het Spotify-model is genoemd naar de organisatie waar deze methode is ontstaan en voor het eerst werd toegepast: Spotify. Het model is ontstaan tijdens de groei van Spotify. In het begin werd scrum gebruikt, een agile methode waarbij in een klein team aan een product wordt gewerkt. Naarmate het bedrijf groeide, werden deze teams groter en werd de scrum-methode niet langer effectief. Spotify paste de toepassing van de scrum-methode aan op de groeiende organisatie, tot wat zij zelf de “Spotify Engineering Culture” noemen. Deze methode staat tegenwoordig beter bekend als het Spotify-model.

Squads en tribes

Bij de ontwikkeling van het Spotify-model werd scrum als uitgangspunt gebruikt. De scrumteams werden vervangen door squads. Een squad werkt gezamenlijk aan de langetermijndoelstelling die aan hen is toegewezen. Hoe zij deze doelstelling bereiken is volledig aan henzelf. Deze autonomie bevordert innovatie en betrokkenheid van medewerkers. Het volledig zelfstandig realiseren van deze langetermijndoelstelling wordt mogelijk gemaakt door het multidisciplinaire karakter van een squad, waardoor kennis en expertise aanwezig is van de verschillende aspecten die belangrijk zijn om deze doelstelling te behalen. De werkzaamheden van de squad worden kortgesloten met de product owner van de betreffende squad. Net als bij scrum heeft de product owner de taak om de prioritering binnen de squad aan te geven, maar bemoeit zich verder niet met de dagelijkse gang van zaken binnen de squad.

In een grote organisatie is het aantal mensen dat aan hetzelfde product of dezelfde dienst werkt vaak groter dan één squad, waardoor er meerdere squads worden opgezet voor het betreffende product of de dienst. Deze squads 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. Zo werken de meeste squads binnen een tribe vaak in hetzelfde gebouw om directe communicatie te bevorderen en ruimte te bieden voor brainstorms en het uitwerken van ideeën, bijvoorbeeld door het plaatsen van whiteboards.

Binnen een tribe kunnen squads afhankelijk van elkaar 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 waar nodig planningen met de andere squads af te stemmen en te coördineren, ook tijdens projecten. Uiteraard 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 opleverdeadline wordt gehaald. Het feitelijk overnemen van taken van een andere squad is alleen mogelijk dankzij het multidisciplinaire karakter van squads en de nauwe samenwerking binnen een tribe.

Chapters en guilds

Waar tribes en squads multidisciplinair zijn ingericht, zijn chapters en guilds juist georganiseerd op basis van discipline, vergelijkbaar met een afdeling of businessunit 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 werken aan hetzelfde product, binnen één of meerdere squads maar binnen dezelfde tribe. Eén van de leden van het chapter is de chapter lead. Deze faciliteert een periodiek overlegmoment met alle leden van het chapter. Op deze manier kan kennis worden gedeeld, maar ook gezamenlijk worden gereflecteerd op mogelijke knelpunten die vakinhoudelijke kennis en ervaring vereisen. Naast het faciliteren van dit overlegmoment fungeert de chapter lead als coach voor de leden van zijn chapter.

Daarnaast zijn er guilds. Guilds bestaan uit mensen met dezelfde functie of interesse, zowel binnen als buiten de tribe. Ook guilds organiseren periodieke bijeenkomsten om kennis te delen en elkaar te helpen. Een probleem waarvoor binnen een tribe geen oplossing wordt gevonden, kan bijvoorbeeld worden ingebracht bij leden van andere tribes. Hierdoor ontstaan nieuwe inzichten die helpen bij het oplossen van het probleem. Ook kan de oplossing voor hetzelfde type probleem in een andere tribe helpen bij het oplossen van het huidige probleem. Een guild heeft dus in essentie dezelfde functie als een chapter, alleen bestaat deze uit een grotere groep om mee te sparren.

Principes van het Spotify-model

Het Spotify-model is gebaseerd op een set principes, ook wel door Spotify zelf 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.

• CONTINUOUS IMPROVEMENT betekent dat er voortdurend wordt gekeken naar verbeterpunten, zowel op organisatieniveau 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 nieuwe dingen te proberen en angst voor falen wordt weggenomen.
• ITERATIVE DEVELOPMENT is gericht op het snel valideren van aannames. Hypotheses worden getest en geanalyseerd en de resultaten van deze analyses worden gebruikt om aannames waar nodig te verbeteren en bij te stellen. Om gemaakte aannames tijdig bij te stellen is het belangrijk om in korte cycli te werken, ook wel “short-learning cycles” genoemd door Spotify, waarin continu getest kan worden.
• SIMPLICITY is nodig om opschaling en kennisdeling snel te faciliteren. Dit geldt voor technische aspecten, werkwijzen en de organisatie als geheel. Communicatielijnen zijn zo direct mogelijk en alle onnodige stappen worden geëlimineerd. Om complexiteit uit de organisatie te houden wordt iteratief tijd besteed aan vereenvoudiging. Dit kan zowel binnen squads, tribes, guilds als chapters gebeuren.
• TRUST IN EMPLOYEES is noodzakelijk zodat zij beslissingen kunnen nemen. Vertrouwen onderling is ook belangrijk, zodat medewerkers elkaar de juiste kritische vragen stellen en zo verbeterpunten naar boven komen. Door vertrouwen te geven aan medewerkers voelen zij zich meer verantwoordelijk en ontstaan meer ideeën.
• SERVANT LEADERSHIP betekent dat managers zich richten op coaching, begeleiding en het oplossen van knelpunten, in plaats van anderen te vertellen wat ze moeten doen. Dit stimuleert samenwerking om samen oplossingen te bedenken en ideeën te implementeren. Er zijn ook regelmatige één-op-één coachingsmomenten om medewerkers te begeleiden. Belangrijk binnen servant leadership is dat beslissingen transparant zijn en worden gedragen door de organisatie.

In de principes van het Spotify-model zijn veel culturele aspecten terug te zien. Zo is bij “Continuous Improvement” een open cultuur een vereiste om dit te kunnen implementeren, en bij “Simplicity” wordt geadviseerd om 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 die ervoor kunnen zorgen dat het model vastloopt en het niet verstandig is om het in een andere organisatie te adopteren.

• De matrixorganisatie, waarbij het risico bestaat dat niet altijd duidelijk is op welk moment de tribe- of chapter lead moet worden betrokken. Om dit te voorkomen wordt aanbevolen om dezelfde manager aan te stellen voor alle mensen binnen een team met dezelfde functie of binnen hetzelfde vakgebied.
• Te veel focus op teamautonomie en geen aandacht of processen voor wat er buiten het team gebeurt. Zorg ervoor dat er organisatiebreed afstemming is, niet alleen binnen teams, en dat er processen zijn voor samenwerking tussen teams.
• 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 hierin te ondersteunen, bijvoorbeeld door begeleiding te bieden bij planning, samenwerking en het goed invullen van teamrollen.

De termen binnen 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 verdwijnen van managementfuncties of het vervangen van bestaande benamingen, zoals business units, door de termen van het model kan deze verwarring vergroten. Iedere (nieuwe) medewerker moet de organisatiestructuur leren, dus maak het niet complexer dan nodig is.