Le modèle Spotify : un modèle à suivre ?

Est-il encore nécessaire de présenter Spotify ? Probablement pas, mais évoquons rapidement quelques chiffres qui lui sont propres et qui montrent son succès. En 10 ans la société suédoise est devenue un géant du net, et domine à l’heure actuelle l’industrie du streaming musical. Elle reste aujourd’hui l’acteur qui a su faire du streaming le modèle de référence avec l’abandon progressive des supports physiques ou numériques.

Quelques chiffres sur spotify

La société créée en 2006 compte aujourd’hui plus de 4000 employés répartis dans 18 pays. Elle possède un catalogue de 30 millions de titres musicaux et compte pas moins de 191 millions d’utilisateurs dont 87 millions d’abonnés payants. 

La société a connu un essor important très vite après sa création. Pour faire face à une croissance exponentielle, avec des effectifs et des utilisateurs toujours en augmentation Spotify a dû trouver un modèle d’organisation souple, agile qui permette à son application de générer de la valeur, de s’adapter en offrant des solutions techniques innovantes dans un secteur très concurrentiel et sans cesse en mutation.

Pour faire face et répondre au mieux à ces contraintes, la société a dû trouver un modèle d’agilité à l’échelle propre devenu célèbre auquel nous allons nous intéresser aujourd’hui.

Réponse apportée et modèle d’organisation.

A leur début, quand la société a démarré et ne comptait que quelques employés, Scrum était utilisé comme modèle de développement. Face une expansion fulgurante du nombre d’abonnés, comme du nombre de développeurs, la société a dû trouver très vite un modèle de développement capable de convenir à une telle croissance des effectifs, jusqu’à plus de 30 équipes internationales travaillant ensemble tout en gardant les bénéfices de l’agilité. 

Cette transformation vient de plusieurs constats :

• Fixer et respecter les règles est une bonne base pour commencer, par la suite il faut savoir les casser et les adapter
• Être et demeurer agile est plus important que d’être organisé en “Scrum”
• Les principes sont plus importants que la pratique 

Partant de ce constat plusieurs transformations sont opérées : 

• Les Scrum Masters deviennent alors des coachs agiles
• Les équipes deviennent alors des squads

Les squads de spotify

Les squads sont la plus petite structure du modèle Spotify. Il s’agit tout simplement d’une équipe complète au sens Scrum, composée d’un PO (Product Owner), d’un SM (Scrum Master), et d’une équipe de développement pluridisciplinaire. Elles sont composées d’au maximum 8 personnes en général toujours colocalisées. Chaque équipe est responsable de la totalité d’une “mission” qui lui est confiée. Cette mission s’inscrit sur le long-terme, et peut concerner des fonctionnalités liées directement au produit ou bien à des parties moins visibles, telles que la gestion de l’infrastructure, le test etc. Chaque équipe est entièrement responsable du développement dont elle a la charge et laissée libre des choix d’implémentation. Cette autonomie permet des prises de décision rapides, faites localement à l’échelle de l’équipe, sans passer par des managers.

Bien que chaque équipe soit autonome, elle ne doit pas perdre de vue l’objectif global d’amélioration du produit. Elle se doit de maintenir une cohésion et synchronisation avec les autres équipes. D’où l’importance d’avoir des objectifs globaux clairs bien définis. Le management global laisse les équipes décider du “comment faire”, pour atteindre ces objectifs, les équipes choisissent et mettent elle-même en œuvre leur solution. 

Ce niveau d’autonomie est tel que chaque équipe auto-organise son agilité. Une équipe peut s’organiser par sprint, un autre au travers de Kaban, certains ont recours à des calculs, estimations de charge et de vélocité, font des démos, au contraire d’autres pas. L’organisation est laissée libre. 

Cette organisation permet l’émergence de “standard” sans les imposer, par “pollinisation”. Ainsi plutôt que d’imposer une technique, un outil, ou de vouloir établir un standard préétabli, les équipes au travers de leurs échanges peuvent voir ce qui marche bien chez les autres et s’en inspirer et le prendre à leur compte. Ainsi les pratiques communes deviennent des standards de fait. 

Chaque équipe est responsable d’un ou plusieurs “systèmes” spécifiques qui gèrent une fonctionnalité particulière (composition de la playlist, recherche de titres, suggestion de titre, monitoring etc.). Ces systèmes sont développés avec l’idée de rester petit, indépendant et avec la possibilité d’interagir avec les autres systèmes via des interfaces clairement définies.

Les tribus, chapitres et guildes

Au-dessus des squads, se trouvent les « tribus », qui sont constituées de plusieurs squads. Elles correspondent à une organisation matricielle. 

De plus chaque personne appartient à la fois à une équipe et à un “chapitre”. Un chapitre regroupe des personnes de différentes équipes par compétence commun (ex : qualité du code, performance, coaching agile, développement web …). Ces chapitres se composent de personnes issues de la même tribu. 

Le but étant de toujours privilégier les échanges qui permettent l’émergence de nouvelles idées et de meilleures solutions, un autre type de regroupement est utilisé : les guildes. Les guildes contrairement aux “chapitres”, regroupent des personnes avec des compétences différentes qui peuvent appartenir à d’autres tribus. Chaque guilde est une petite communauté qui lie différentes personnes, quelle qu’elle soit, autour d’un intérêt commun, tel que “leadership”, “continuous delivery” etc. Chaque membre peut rejoindre et repartir d’une guilde librement. Cette organisation permet de privilégier une organisation en communautés souples, plutôt que de définir des structures rigides et inadaptées.

Apports concrets et bénéfices du modèle Spotify

Reprenons les 4 valeurs de l’agilité et voyons si le modèle ainsi développé par Spotify y répond.

Au travers de ce tableau on constate que Spotify s’inscrit pleinement dans une démarche agile au travers de l’organisation qu’elle a conçu au fil du temps par itération, avec toujours en ligne de mire la recherche de la valeur logicielle au travers de la structure la plus adaptée et la plus fluide possible. Nous sommes donc bien dans un modèle d’organisation agile.

Critique et limites du modèle

Quand il s’agit de modèle d’organisation et de développement logiciel, on peut être tenté de vouloir calquer le modèle Spotify présenté ici, en partant du principe qu’il est bon de reprendre ce qui a fait ses preuves ailleurs et de l’importer avec un certain nombre d’adaptations pour en tirer les bénéfices, et s’approprier ce qui marche chez les autres pour ne pas avoir à réinventer la roue. 

Cependant, il existe de nombreuses contre-indications et limites à ce modèle que l’on va aborder dans cette dernière partie. En voici quelques-unes : 

• Tout d’abord ce modèle est adapté pour les structures avec un grand nombre d’employés et de ressources. Ici on parle de plusieurs milliers d’employés répartis dans plus de 20 pays. Mettre en place ce modèle directement ne semble pas être la bonne solution car la société Spotify a pu le mettre en place au fur et à mesure de sa croissance, et a su l’adapter pour trouver ce qui était le plus pertinent et qui marchait, au fur et à mesure de son expansion. C’est un modèle qui a été obtenu par expérimentation et tâtonnement.  Ce modèle ne peut pas marcher en le transposant directement dans une société de plus de 1000 personnes qui veut se lancer dans l’agilité. L’historique de Spotify montre qu’ils ont commencé petit et construit par touche successive, voire en déconstruisant et cassant certains aspects de leur modèle quand cela est devenue nécessaire. De fait, il existe assez peu de sociétés de la taille de Spotify pour qui le modèle peut être appliqué, ou qui se retrouve dans les mêmes problématiques de croissance avec des contraintes d’agilité. 

• Toujours en ce qui concerne la dimension de l’entreprise, il faut bien voir qu’il faut avoir une certaine taille critique pour mettre en place un modèle d’agilité à l’échelle, que ce soit Spotify ou un autre. Le modèle Spotify n’est pas clair quant à la taille critique qu’il faut avoir pour que les bénéfices soient au rendez-vous. 

• Ce modèle est changeant et se réinvente très rapidement. Ce qui a été décrit ici date d’une organisation de 2012, le modèle a de nouveau évolué pour prendre d’autres formes.  Aujourd’hui il semblerait même que le modèle de squads, tribus, guildes ne soit plus d’actualité. 

• Spotify a longtemps fait preuve de grande tolérance face à l’échec. Prendre, mettre en place des initiatives est fortement encouragé, afin de trouver ce qui peut marcher. Les ratés sont considérés comme faisant partie de l’apprentissage et du processus d’amélioration continue. Cette attitude vis à vis de l’échec peut être vu comme une vraie culture d’entreprise propre à l’ADN de Spotify et retrouver ou importer cet état d’esprit dans d’autre société n’est pas chose aisé quand les enjeux financiers sont importants. 

Copier le modèle Spotify peut être inadapté lorsqu’il s’agit d’une démarche “top-down” avec une direction et un management qui souhaite s’inspirer du modèle (c’est aussi vrai pour toute société qui souhaite se lancer dans l’agilité quel que soit le modèle). Et ce type de démarche, dans les faits, souvent ne marche pas. L’amélioration continue et l’autonomie amène de la valeur et l’efficience quand ce sont les parties prenantes, les développeurs, la base qui est à l’origine des solutions et du modèle qu’elle désire mettre en place. Les organisations imposées tendent à être moins efficace et sujettes à des résistances.

Conclusion

Au travers de ces quelques limites nous avons pu voir que le modèle Spotify a pu faire ses preuves pour l’entreprise qui l’a façonné, répondant aux valeurs de l’agilité et permettant de répondre à des objectifs de conception d’un produit innovant qui apporte de la valeur. Cependant, l’importer dans une autre structure, ou société tel quel n’est jamais chose aisée car il n’y a pas de recette toute faite capable de répondre aux différents enjeux, défis et contraintes du développement logiciel.

S’inspirer, étudier les autres modèles de l’agilité est évidemment la 1ere étape, la 2ème consiste selon moi, à l’instar de Spotify, à ne pas hésiter à solliciter ses employés, les rendre autonomes et surtout créatifs pour qu’ils trouvent un modèle d’organisation ainsi que les meilleures réponses techniques aux problèmes et objectifs qu’ils ont à adresser. Le modèle Spotify marche car ce modèle est supporté et implémenté par ceux-là même qui en sont les premiers concernés, et de ce point de vue il est en total cohérence avec les valeurs de l’agilité.