Spotify : organisation et pratiques de l’agilité à l’échelle

Depuis ses début en 2006, l’entreprise de streaming musical Spotify a eu à coeur de mettre en place les méthodes agiles au coeur de leur organisation produit. Avec un nombre croissant d’équipes, et l’ouverture de bureau dans différents pays s’est posée la question de la mise à l’échelle de ces pratiques agiles.

Accompagné par des Coachs agiles de renom, Spotify a au fur et à mesure de son histoire créé et fait évoluer son propre modèle d’agilité à l’échelle. Décrit en 2012 par ses créateurs Henrik Kniberg et Anders Ivarsson dans un excellent article disponible ici, ce modèle a depuis inspiré de nombreuses entreprises qui l’ont adopté, avec plus ou moins de succès.

Reproduire à la lettre le modèle Spotify tel qu’il est décrit dans les articles et vidéos de Henrik Kniberg serait cependant une erreur : il a été construit autour d’une culture d’entreprise forte, basé sur l’amélioration continue, et a énormément évolué. On pourra néanmoins s’inspirer des pratiques agiles et lean décrites ci-dessous pour construire un modèle d’organisation pertinent, en expérimentant en fonction de son contexte.

Le modèle Spotify, c’est quoi ?

Le modèle Spotify repose sur un mode d’organisation original, qui permet l’application de principes agiles à l'échelle d’une entreprise internationale.

Squad, Tribe, Chapter & GuildSource : https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Squads et tribus : des équipes autonomes dédiées à la livraison de valeur

Les squads

Les squads sont les unités de base du modèle Spotify. Une squad correspond plus ou moins à une équipe Scrum :

• Taille limitée (7-8 personnes maximum)
• Un Product Owner responsable de la vision d’une fonctionnalité
• Autonomie et auto-organisation
• Stabilité et pluridisciplinarité
• Colocalisation

À la différence d’une équipe Scrum:

• La méthodologie adoptée est à la discrétion de l’équipe (Scrum, kanban, scrumban…)
• Le rôle de facilitation est pris en main par des Coachs agiles, parfois transverses à plusieurs équipes

Les squads sont orientées delivery : chaque équipe est indépendante et a une seule mission à long terme qui touche à un seul bloc fonctionnel. Cela permet à l’équipe de devenir experte dans son domaine, et à l’ensemble de l’organisation d’identifier facilement qui fait quoi. Une squad a l’entière responsabilité de ce qu’ils construisent, de la conception à la livraison et à la maintenance.

Les squads sont encouragées à utiliser les méthodes de Lean Startup pour développer de nouvelles fonctionnalités : Minimum Viable Product (MVP), validated learning et A/B testing font partie des pratiques prônées chez Spotify.

Les Tribus

Une tribu est un ensemble de squads qui travaillent sur un sujet global commun. Réunissant jusqu’à 100 collaborateurs, les tribus partagent une même localisation et dispose d’un Tribe Lead. Celui-ci est chargé de fournir à l’ensemble de sa tribu le meilleur environnement de travail possible.

Le modèle Spotify ne prévoit pas de cérémonie obligatoire pour l’ensemble des tribus, mais recommande des rassemblements informels, afin d’échanger sur le travail de chaque équipe, les outils utilisés, mais aussi pour réaliser des démos et récolter du feedback.

Chapitres et guildes, des communautés dédiées au partage de connaissances

La très grande autonomie promue par le modèle Spotify présente cependant un risque majeur : la perte d’économies d’échelle potentielles. En effet, d’une squad à l’autre, deux employés peuvent rencontrer des problématiques similaires, et la solution du premier pourrait bénéficier au deuxième.

Pour cela, le modèle suggère la mise en place de communautés dédiées au partage de connaissances et de bonnes pratiques : les chapitres et les guildes.

Les Chapitres

Dans le modèle Spotify, chaque personne fait partie d’une squad, dont l’objectif est de livrer de la valeur. Chaque employé fait cependant aussi partie d’un chapitre, qui correspond à un domaine de compétence métier, comme par exemple :

• le product ownership chapter
• le testing chapter
• le agile coaching chapter

Henrik Kniberg définit les chapitres comme “une petite famille de personnes ayant des compétences similaires dans une même tribu”.

Les chapitres se réunissent régulièrement pour discuter de leur problème et partager leurs solutions. Ils disposent chacun d’un Chapter Lead, qui prend le rôle de Manager du chapitre, notamment sur les questions de ressources humaines (développement de compétence, salaires…).

Les Chapter Lead restent cependant membres d’un squad et continuent à participer à la livraison de valeur, et ce afin de garder une bonne connaissance du travail sur le terrain.

Les guildes

Les guildes correspondent à des “communautés d'intérêts” : elles sont communes à l’ensemble des tribus et réunissent des personnes souhaitant partager des outils, des pratiques, des connaissances…

Certaines guildes réunissent l’ensemble des chapitres des différentes tribus sur un sujet particulier (guildes des Products Owners, guildes des testeurs), mais d’autres ont des sujets plus vastes, comme par exemple le leadership, ou le blockchain. Chacun peut rejoindre ou quitter une guilde à n’importe quel moment.

Chez Spotify, les guildes se réunissent généralement 2 fois par an pour des conférences et rencontres sur leur thème de prédilection, et sont animées par un Guild Coordinator. Elles partagent aussi une mailing list, ou autres channels de communication (Slack, Teams…).

Les pratiques du modèle

Limitation des dépendances

Le modèle des squads de Spotify repose sur la limitation au maximum des dépendances entre différentes squads et surtout entre différentes tribus. Chaque squad est entièrement responsable de son domaine fonctionnel, et dispose d’un accès direct aux parties prenantes pour prendre leurs décisions en autonomie.

Le rôle du Leader dans le modèle Spotify est de garantir l’alignement des équipes : il communique le problème à résoudre, ou l’objectif à atteindre, et les squads décident elles-mêmes de la meilleure solution à mettre en place.

Pour identifier clairement les dépendances (et éventuellement, les supprimer), chaque équipe de Spotify remplit régulièrement un tableau des dépendances. Celui-ci liste les dépendances actuelles et futures et leurs statuts (intra ou inter tribus, bloquantes ou maîtrisées…).

Exemple de tableau des dépendances chez Spotify__Source : https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Pour maximiser l’indépendance des équipes, Spotify se concentre aussi sur la relation entre développement et opérations. Pour permettre aux squads de faire leur propre release, Spotify a mis en place des Operations squads. Leur but n’est pas de s’occuper des mises en production à la place des équipes, mais de leur donner tous les outils nécessaires pour le faire eux-mêmes (infrastructure, scripts, routines…)

Spotify lance cependant parfois d’importants projets, qui requièrent la collaboration de plusieurs squads pendant plusieurs mois. Si l’entreprise essaye de limiter au maximum ce genre de projets (en les divisant en plusieurs petits projets, lorsque cela est possible), ils sont parfois nécessaires.

Pour les gérer, Spotify préconise la tenue de daily meetings entre les équipes concernées, et la mise à jour quotidienne d’un tableau des dépendances similaire à celui décrit ci-dessus.

Amélioration continue des équipes et des collaborateurs

Spotify a intégré au coeur de sa culture l’amélioration continue. D’une part, l’entreprise promeut la formation en continu de leurs collaborateurs (formations classiques, workshop, échange de connaissance intra-chapitres et guildes…). Cependant, Spotify va aussi plus loin en mettant en place des artefacts et cérémonies destinés à une amélioration continue et collaborative.

Les Squad Health Checks sont des autos-évaluations trimestrielles qui permettent à l’équipe d’évaluer la qualité des différents aspects de leur travail. Cela permet à l’entreprise de déterminer quel support apporter à chaque équipe, et les points d’amélioration des processus.

Squad Health Check d’une tribu SpotifySource : https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

A l’instar de Google, Spotify prévoit pour chaque collaborateur des squads du Hack Time. Les employés de l’entreprise peuvent dédier 10% de leurs temps de travail à faire ce qu’ils souhaitent : expérimenter de nouvelles méthodes, se former, lancer un nouveau projet, individuellement ou en équipe avec leur squad. Certaines équipes prévoient une demi-journée par semaine dédiée à ce temps fort d’innovation, d’autres préfèrent prévoir une Hack Week toutes les 10 semaines, avec une démo et une soirée de célébration à la fin de la semaine.

L’amélioration continue passe aussi, dans le modèle Spotify, par une culture d’acceptation de l’échec (Fail-Friendly environment). Suivant le motto “Fail Fast, Learn Fast”, le leadership encourage les équipes et les collaborateurs à expérimenter, à prendre des risques, mais surtout à apprendre de leurs erreurs. Les échecs et incidents font l’objet de Post-Mortem, des ateliers qui visent à déterminer ce qui a été appris, et comment éviter le même échec à l’avenir. Spotify encourage ses équipes à avoir un “Fail Wall”, qui permet d’identifier les échecs et de les traiter comme des tremplins pour s’améliorer.

Un autre artefact utilisé chez Spotify est l’Improvement Board. Sur celui-ci sont identifiés les principaux obstacles rencontrés par l’équipe, et les actions mises en place pour les éliminer. Les équipes mettent aussi en place des Definitions of Awesome : différente pour chaque squad, cette définition représente l’objectif-cible de l’équipe en termes de processus de travail.

Improvement board and Definition of Awesome chez SpotifySource : https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

Autres principes Lean-Agile

Spotify a mis au coeur de sa culture d’entreprise et de ses pratiques un grand nombre de concepts issues de la Lean Start-up et du manifeste agile.

Au-delà de sa culture d'expérimentation, l’entreprise recommande l’utilisation de MVP, des versions minimalistes de nouvelles fonctionnalités qui permettent d’être testées rapidement et de récolter du feedback utilisateurs.

Les équipes utilisent des pratiques d’idéation issues du design thinking, puis passent par des cycles PDCA (plan, do, check, act) pour livrer des fonctionnalités pertinentes à leurs utilisateurs. Pour cela, les décisions sont prises en étudiant des données (data-driven decision making) et différentes versions d’une même fonctionnalité sont fréquemment testées à l’aide dA/B tests.

“Without data you’re just another person with an opinion.”

- W. Edwards Deming

Cela passe aussi par leur vision du management : les Managers sont des Servant Leaders (issu du management agile), qui ont le rôle de communiquer le problème qui doit être résolu, et pourquoi, mais aussi d’éliminer les obstacles rencontrés par l’équipe et sur lesquels elle ne peut pas agir d’elle-même.

Ces Leaders restent le plus souvent intégrés dans les équipes, et continue à consacrer une partie de leur temps au delivery, afin de garder contact avec la réalité des métiers. Modèle d’auto-organisation et d’autonomie, la squad choisit de son côté les solutions à apporter aux problèmes du Manager.

Enfin, Spotify se définit comme une organisation “waste repellent” : à l’épreuve du gaspillage. Les pratiques sont constamment réévaluées et remises en question, et ne sont conservées que celles qui apportent de la valeur. Il faudra cependant noter que ces pratiques varient d’une équipe à une autre, et que ce qui ne fonctionne pas pour la première peut marcher pour la seconde.

A retenir

Le modèle Spotify n’a pas été conçu en un jour. Il a évolué au cours des années pour s’adapter à une croissance rapide, et à une augmentation du nombre d’équipe de développement. Le modèle décrit ici continue d’évoluer et d’être amélioré, et les pratiques d’ingénierie de l’entreprise font l’objet d’article sur le blog Labs Spotify.

Il est essentiel de ne pas copier aveuglément les modèles organisationnels qui fonctionnent chez d’autres. La mise à l’échelle de l’agilité dans une organisation produit passe avant tout par une bonne compréhension de son contexte, et par une approche “test and learn”.

Pour aller plus loin et en apprendre plus sur les pratiques d’ingénierie mises en place chez Spotify, on consultera les vidéos d’Henrik Kniberg (Part 1 , Part 2 - durée totale de 27 minutes)