Pourquoi copier le modèle Squads and Tribes de Spotify ne vous conviendra probablement pas

Quels sont les problèmes avoués de Spotify avec ce modèle ?

Ce modèle n’est en aucun cas une panacée. De nombreuses personnes ayant travaillé chez Spotify ont expliqué les lacunes de leur modèle et il semble que la réalité n’ait pas suivi le rythme du mythe du nirvana agile.

« Cela m’inquiète quand les gens regardent ce que nous faisons et pensent que c’est un cadre qu’ils peuvent simplement copier et mettre en œuvre. (…) Nous essayons vraiment de mettre l’accent sur le fait que nous avons aussi des problèmes. Ce n’est pas tout ‘brillant et tout fonctionne bien et toutes nos équipes sont super incroyables’. »

Anders Ivarsson, co-auteur du livre blanc de Spotify

Issue 1 : La culture d’ingénierie n’est pas une structure organisationnelle

Le contenu original que Spotify a publié pour expliquer sa méthode s’appelait Spotify Engineering Culture. Bien qu’ils aient décrit une structure organisationnelle, il s’agissait principalement de leur culture d’ingénierie et de leurs principes de travail fondamentaux (voir ci-dessous pour une liste de ceux-ci).

Issue 2 : Le modèle était une ambition et il n’a pas été pleinement adopté

Lorsque Spotify a publié son livre blanc, il était en partie ambitieux et en partie réel. Ils exposaient une vision de l’avenir.

« Même au moment où nous l’avons écrit, nous ne le faisions pas. C’était en partie une ambition, en partie une approximation. Les gens ont vraiment eu du mal à copier quelque chose qui n’existait pas vraiment. »

Joakim Sundén, coach agile chez Spotify 2011-2017

Issue 3 : Le modèle optimisé pour une autonomie complète des équipes

Au fur et à mesure que la taille des équipes augmentait, Spotify ne définissait pas de processus commun pour la collaboration inter-équipes. Lorsque chaque équipe avait une façon unique de travailler, et qu’il n’y avait pas de directives sur les choix, la productivité de l’organisation globale en souffrait.

Enjeu 4 : La collaboration entre les équipes était une compétence supposée

A mesure que le nombre d’équipes augmentait, il a été reconnu qu’un soutien dédié pour guider et structurer la collaboration entre les équipes était nécessaire. Des structures ou des processus dédiés sont nécessaires pour permettre à des équipes qui ne sont pas nécessairement liées de collaborer ensemble.

« Dans des articles ou des discussions de ce type, on peut avoir l’impression que Spotify est une sorte de nirvana agile où tout fonctionne, ce qui n’est tout simplement pas vrai. »

Henrik Kniberg, créateur du modèle Spotify

N’oubliez pas que le modèle Spotify a été créé il y a plus de 10 ans, il est donc très peu probable, à la lumière des problèmes identifiés ci-dessus, et peut-être d’autres, que ce soit le modèle exact qu’ils utilisent actuellement. Spotify est une société qui apprend et se développe en permanence, elle a donc dû faire évoluer ce modèle à plusieurs reprises depuis le livre blanc initial. Cependant, il y a encore beaucoup à apprendre, même si vous ne devez pas appliquer le modèle directement.

La puissance du modèle Spotify réside dans ses principes d’ingénierie plutôt que dans sa conception de l’organisation

La véritable magie du modèle Spotify résidait dans la culture d’ingénierie et de développement de produits qu’ils ont créée pour des équipes agiles rapides, motivées et découplées. Au fil du temps, ils ont développé quelques principes de travail fondamentaux puissants qui ont sous-tendu leur haute performance :

1. La productivité est étroitement liée à la motivation – La motivation a un impact plus important sur la productivité que tout autre facteur (voir Joy Inc de Richard Sheridan). Spotify utilise la formule Productivité = Effort x Compétence x Environnement x Motivation.
2. Équilibre entre alignement et autonomie – Spotify s’efforce de trouver un équilibre entre alignement (direction centrale) et autonomie (auto-organisation des équipes). Les managers brossent un tableau d’ensemble mais ne disent pas aux gens comment y parvenir ou comment résoudre les problèmes.
3. Les versions découplées pour réduire la durée du cycle – Spotify a modifié son architecture pour découpler les dépendances et rendre les versions plus faciles et plus rapides. Cela a permis des mises en production plus fréquentes qui peuvent être indépendantes entre les équipes.
4. Faites confiance à vos employés – Spotify fait confiance à ses employés et les soutient sans essayer de les contrôler parce qu’ils croient que la plupart des gens font ce qui est le mieux pour l’organisation.
5. Les managers en tant que leaders serviteurs – Il est préférable pour les managers de demander aux équipes comment ils peuvent aider, plutôt que de demander aux gens sur quoi ils travaillent ou quand ils auront terminé.
6. Maximiser la valeur plutôt que l’affairisme – Les équipes génèrent des idées, font des expériences rapides, puis mesurent les résultats. À partir de là, elles affinent leur approche pour maximiser la valeur. Il est important de noter qu’elles optimisent pour maximiser la valeur et pas seulement le rendement.
7. Culture d’amélioration – Les équipes sont encouragées à améliorer leur façon de travailler et disposent d’un modèle pour ce qui rendrait leur vie plus facile et meilleure. Des ressources dédiées sont disponibles pour aider à améliorer les méthodes de travail dans l’ensemble de l’organisation.
8. Une culture saine guérit les processus cassés – Les processus peuvent souvent se briser, mais une culture saine conduira les gens à réparer ces problèmes par eux-mêmes.
9. Définition de l’awesome par l’équipe – Spotify encourage les équipes à parler et à décider de ce qui les rendrait awesome. Après tout, sans une vision de l’awesomeness, vous avez peu de chances d’y arriver. Les équipes de Spotify procèdent régulièrement à des « bilans de santé de l’équipe » et suivent les améliorations au fil du temps. Q : Vos équipes ont-elles une définition de l’excellence ? Faites-vous un suivi de la santé de l’équipe et vous efforcez-vous de vous améliorer en permanence ?
10. La satisfaction des employés est de la plus haute importance – Le responsable du personnel de Spotify a affirmé que 91% des employés aimaient travailler chez Spotify, ce qui, selon lui, n’est « bien sûr pas satisfaisant »… telle est la barre élevée qu’ils se fixent.
11. Les erreurs sont acceptables – Le PDG de Spotify explique que les erreurs sont attendues lorsque vous poussez l’innovation. Pour atténuer cela, Spotify a beaucoup de systèmes intégrés pour limiter les effets des échecs.

« Nous visons à faire des erreurs plus rapidement que n’importe qui d’autre ».

Daniel Ek, fondateur de Spotify

Comme vous pouvez le voir, il y a de grands concepts intégrés dans le modèle, mais ce n’est pas un modèle de conception organisationnelle agile en soi.

Itérez en utilisant l’inspection et adaptez pour créer votre propre modèle cible

Le contexte de votre organisation, votre point de départ, votre culture, vos objectifs et bien d’autres facteurs détermineront la meilleure solution pour vous.

Bien sûr, vous pouvez rechercher et emprunter des idées à des entreprises comme Spotify, Menlo Innovations, Google ou d’autres entreprises très performantes, mais cela ne devrait être que le point de départ.

Vous devez savoir avec clarté quel problème vous essayez de résoudre et ensuite créer un plan basé sur la résolution de votre ensemble unique de défis.

Inspecter et adapter est un concept central de l’agile.

Inspecter consiste à utiliser un esprit ouvert et un feedback transparent (le plus souvent effectué lors d’une rétrospective) pour regarder honnêtement ce qui fonctionne et ce qui ne fonctionne pas. Cela peut être n’importe quoi, des processus, de la dynamique d’équipe, de la stratégie ou des inefficacités, tout ce qui entrave la performance de l’équipe et réduit sa motivation et son appropriation.

Adapter est le processus qui consiste à prendre les thèmes de l’introspection et à trouver des moyens d’y répondre et de les améliorer. L’adaptation demande de la créativité et des efforts et elle prend souvent la forme d’une expérience. Un petit test est effectué avec un sous-ensemble des équipes pour s’assurer que la solution est viable, avant qu’elle ne soit déployée dans toute l’organisation.

Ce processus est ensuite répété chaque fois que votre organisation est améliorée et se rapproche de votre état d’être cible idéal.

S’inspirer mais ne pas copier aveuglément

Il y a beaucoup à aimer dans le modèle Spotify, si vous adoptez leurs principes d’ingénierie et modélisez l’esprit de ce qu’ils essaient de faire.

Le contexte est tout, donc à moins que vous ne soyez une entreprise suédoise de streaming musical, copier aveuglément Spotify a peu de chances de résoudre vos problèmes.

Cependant, il est très peu probable que copier aveuglément le modèle fonctionne pour vous. Il est important de s’inspirer de sources multiples, si vous voulez faire évoluer l’agilité dans votre organisation.

Si vous voulez mettre à l’échelle agile et que vous avez plus de 150 personnes dans votre équipe, alors deux bons modèles de mise à l’échelle sont :

1. Scaled Agile Framework (SAFe)
2. Large Scale Scrum (LeSS)

Si vous avez moins de 150 personnes, Shape Up de Basecamp est un excellent modèle auquel aspirer.

Spotify n’est pas un nirvana agile

J’espère que cet article a mis en évidence que la culture d’ingénierie agile chez Spotify est bien plus que la création d’escouades, de chapitres, de tribus et de guildes.

En fait, le modèle Spotify, c’est principalement sa culture et ses équipes de haute compétence, et non son design organisationnel. Vous pouvez obtenir d’énormes avantages en adoptant les principes même sans mettre en œuvre les squads et les tribus.

« Dans des articles ou des discussions comme celle-ci, on peut avoir l’impression que Spotify est une sorte de nirvana agile où tout fonctionne, ce qui est tout simplement faux. »

Henrik Kniberg

La version rapide de la façon de mettre à l’échelle agile

J’écrirai un article de blog entier sur ce sujet à l’avenir, mais pour l’instant, voici la version rapide de la façon dont vous devriez procéder pour mettre à l’échelle agile dans votre organisation:

1. Décidez clairement du problème que vous essayez de résoudre.
2. Consommez les parties les meilleures et les plus pertinentes des meilleurs modèles de mise à l’échelle de l’industrie, par exemple SAFe, LeSS, DaD, etc. dans votre conception cible.
3. Concevez un état cible qui prend les meilleures pratiques adaptées à votre ensemble unique de défis.
4. Faites des changements vers votre conception d’état cible.
5. Inspect and adapt constantly to find improvements based on evidence.
6. Make course corrections based on the feedback.
7. Rinse and repeat steps 4 to 6!