L’agilité à grande échelle avec le modèle Spotify

Spotify avait mis en place un modèle agile à grande échelle devenu très célèbre appelé le modèle Spotify. Nous allons profiter de cet article pour en voir les principes.

Ne pas tout appliquer à la lettre

Henrik Kniberg et Anders Ivarsson ont mis en place le modèle Spotify sur lequel ils ont communiqué dessus en 2012. Ce modèle a changé depuis et s’est adapté pour amener l’organisation a être tous les jours de plus en plus optimale.

Henrik avait d’ailleurs rappelé infoQ  :

Ce n'était pas une re-fondation, mais plus un débit continu de petits processus et améliorations itératives. Nous 
avons grandi pendant trois ans, et la manière de travailler aujourd'hui a naturellement évolué au fil du temps.

Nous allons voir les principes de base car ils sont selon moi très intéressants dans certaines structures mais n’oubliez pas que l’agilité vous conseille toujours d’adapter les méthodes au contexte.

Se fixer sur une méthodologie et ne pas en sortir même si certains points semblent pas adaptés à 100% n’a pas de sens.

Faisons des squad

Les squad dans le modèle Spotify sont des équipes de 5 à 7 ingénieurs et d’un Product Owner totalement autonomes  comme ci ensemble ils créaient une startup. En général, on met un coach Agile en soutient de ces squad. Une squad est l’équivalent des feature team qu’on rencontre dans d’autres méthodes. On fait en sorte que cette Squad soit pluridisciplinaire.

Pour les adorateurs du Lean startup, vous pourrez rajouter quelques personnes dans le but de rendre ces squad 100% autonomes en essayant de ne pas dépasser les 10 personnes. Cette recommandation personnelle ne fait pas parti du modèle Spotify présenté en 2012.

Chaque Squad peut utiliser la méthodologie agile ou apparentée agile de son choix voire celle qui est la plus adaptée au besoin : scrum, scrumban, kanban, lean startup en complément,…..

Squad Spotify
Spotify squad dans le modèle Spotify

Il est utile de faire un suivi de la santé de l’équipe afin de pouvoir améliorer les points qui ne sont pas encore optimals. D’ailleurs nous avons vu ça avec le modèle de santé des équipes dans un précédent article appelé le Squad Health Check model chez Spotify.

N’hésitez pas à voir comment cela fonctionne en allant lire mon article sur le sujet : lire le modèle de santé des équipes

Les chapitres (chapters)

Dans chaque Squad, nous avons des compétences équivalentes. Nous allons  rassembler 1 personne de chaque squad d’une tribue ensemble pour créer un chapitre pour qu’ils puissent permettre d’aligner chaque squad sur une même vision commune.

Un rassemblement d’une heure par semaine entre chaque chapitre peut permettre dans les grandes structures d’avoir une meilleure vision globale et de ne pas voir chaque Squad partir chacune dans leur coin sans aucune cohérence globale.

Chapter Spotify
Chapter dans le modèle Spotify

Les tribus (tribes)

Les tribus représentent plusieurs Squads de 5 à 8 qui travaillent ensemble sur un même thème global. Il est conseillé de ne pas dépasser des tribus de 80 personnes afin de garder un dimenssionement raisonnable.

Tribe Spotify
Tribe dans le modèle Spotify

Les guildes (guilds)

Les Guilds dans le modèle Spotify rassemblent les personnes de mêmes compétences dans l’ensemble de l’entreprise pour qu’ils puissent régulièrement partager ensemble sur des sujets similaires afin de s’aligner sur une même vision.

Elles vont pouvoir créer des non-conférences ensemble pour s’accorder sur les projets, les objectifs et les résultats.

Guild Spotify
Guild dans le modèle Spotify

De l’amélioration continue en pagaille

Spotify ne lésinait pas sur l’amélioration globale des projets bien que ces concepts sont présents dans certaines entreprises Agile :

  • formation : former les équipes grâce à des formations classiques, des BBL, des workshop de partage…
  • questions & réponses : le CEO se met à disposition pour une séance de question/réponse
  • hack day ou hack week : sessions pour développer quelque chose de différent qui pourrait apporter un jour à l’entreprise.
  • adds-on : 20% du temps de chacun est consacré à s’améliorer soit 1 journée chaque semaine.
  • le public post-mortem : on se rassemble 1 journée complète pour partager sur une vision sur un incident qui s’est passé. Ce principe se rapproche des 5 questions sur un incident pour obliger d’aller chercher plus loin le problème réel d’un incident.

Conclusion

J’espère que ce petit point sur le modèle Spotify vous permettra peut-être de créer un modèle agile de grande ampleur de qualité. Aujourd’hui, le modèle Spotify a évolué mais vous pouvez voir si certaines de ces pratiques peuvent être pratiques dans votre organisation.

English term : Spotify model

6 Replies to “L’agilité à grande échelle avec le modèle Spotify”

    1. Hello,

      Il est plutôt conseillé qu’un collaborateur travaille dans une seule team ; certaines personnes n’arrivent pas à switcher facilement d’un projet à l’autre et cela perturbe leur productivité. Cependant certaines personnes semblent stimulées par le changement de projet si on est sur 2 projets maximum et en ont leur motivation augmentée.
      Je conseille de voir si la personne est plutôt du deuxième type mais il faut cependant limiter à 2 projets. Mais c’est pas évident à gérer surtout si le temps partagé entre les deux projets changent à chaque itération.
      Par simplicité on éviterait de partager la ressource mais le contexte ne le permet pas toujours. On a tous été un jour confronté à ça.

      Maintenant quelqu’un qui a des compétences transverses, je préfère le sortir des squad pour en faire une personne transverse (ou une squad transverse si ils sont plusieurs dans le même domaine ; exemple des devops). C’est aussi un schéma qui peut être intéressant sur certains domaines totalement transverses à l’ensemble des projets mais on sort de la squad (de type feature) ; mais cette adaptation agile fonctionne bien aussi.

Leave a Reply

Your email address will not be published. Required fields are marked *