Le modèle d’équipe en squad de Spotify a été un échec
(jeremiahlee.com)<p>« Spotify lui-même n’utilise pas “the Spotify model”. Vous ne devriez pas non plus l’utiliser. »<br />
Le célèbre livre blanc de Spotify sur le « Scaling Agile », publié en 2012, n’était qu’une ambition et n’a jamais été pleinement mis en œuvre.<br />
Le livre blanc ne reflétait pas la réalité, mais comme il aidait au recrutement, il a été laissé tel quel ; après avoir quitté l’entreprise, l’auteur a voulu rétablir les faits en l’écrivant noir sur blanc.<br />
Un article détaillant ce qui n’allait pas dans ce modèle, ce qu’on peut apprendre des erreurs de Spotify, et quels autres modèles sont recommandés.<br />
<br />
Les co-auteurs de ce livre blanc et les coachs Agile de Spotify avaient déjà, depuis longtemps, dit à des personnes extérieures de ne pas chercher à le reproduire.<br />
« Même au moment où nous avons rédigé ce livre blanc, nous ne faisions déjà plus cela. Ce n’était qu’une ambition partielle et une estimation. Les gens se sont donné beaucoup de mal pour imiter quelque chose qui n’existait pas réellement. »<br />
<br />
Pourquoi cela n’a-t-il pas bien fonctionné ?<br />
<br />
1. Le management matriciel résolvait le mauvais problème<br />
<br />
Les équipes Agile full stack fonctionnent bien. Mais le management sous forme matricielle crée encore plus de problèmes.<br />
→ Les équipes de Spotify avaient une structure durable dans le temps, donc l’avantage consistant à ne pas devoir changer de manager lors d’un changement d’équipe était très limité.<br />
→ Les engineering managers n’étaient responsables que du développement de carrière et ne pouvaient pas vraiment aider à acquérir des compétences relationnelles ou de collaboration.<br />
→ Il n’y avait pas de manager unique responsable des ingénieurs d’une équipe donnée. Le product manager, qui jouait un rôle de mini-CEO, n’avait pas d’équivalent en mini-CTO. En d’autres termes, personne n’était responsable du soutien à l’équipe technique ni de la négociation des priorités. En cas de désaccord au sein de l’équipe technique, le product manager devait négocier avec tous les ingénieurs. Si cela ne suffisait pas, il fallait au minimum négocier avec les engineering managers backend/web/mobile, soit au moins trois personnes, ou faire remonter le sujet au responsable engineering du département.<br />
<br />
[ Ce qu’il faut apprendre des erreurs de Spotify ]<br />
→ Dans les équipes produit-design-technique, les ingénieurs sont généralement plus nombreux ; il faut donc un manager responsable de l’ensemble des ingénieurs afin d’avoir une voie d’escalade en cas de conflit interne.<br />
→ Les product managers doivent avoir un pair de même niveau pour discuter de technique, comme la relation entre un CEO et un CTO. <br />
<br />
2. Une dépendance à l’autonomie des équipes<br />
<br />
Quand l’entreprise est petite, chaque équipe couvre un périmètre de travail varié, et l’équipe qui prend le lead change souvent. <br />
À mesure que l’entreprise grandit, les fonctions dupliquées entre équipes sont regroupées dans de nouvelles équipes afin de gagner en efficacité. <br />
Quand le nombre d’équipes augmente, les changements de lead deviennent moins fréquents, et il devient possible de réfléchir à long terme aux problèmes que chaque équipe doit résoudre.<br />
<br />
→ Spotify n’a pas défini de processus commun pour la collaboration inter-équipes. Chaque équipe participait à sa manière, ce qui a réduit la productivité de l’organisation dans son ensemble.<br />
→ Le « Spotify model » a été formalisé à une époque où l’entreprise était bien plus petite. Il aurait fallu une version ultérieure, adaptée à la suite, mais elle n’est jamais venue. On s’est arrêté au discours sur l’autonomie, sans aller jusqu’au volet sur la collaboration entre équipes.<br />
<br />
[ Ce qu’il faut apprendre des erreurs de Spotify ]<br />
→ L’autonomie a besoin d’alignement. Les priorités de l’entreprise doivent être définies par la direction. L’autonomie ne signifie pas que les équipes font librement ce qu’elles veulent.<br />
→ Un processus de collaboration inter-équipes est indispensable. L’autonomie ne consiste pas à laisser chaque équipe résoudre seule tous les problèmes.<br />
→ La direction doit aussi définir la manière d’évaluer le succès, afin de pouvoir arbitrer les priorités de collaboration entre équipes. <br />
→ L’autonomie implique la responsabilité. Le Product Management doit être responsable de la valeur produit. Chaque équipe est responsable de mener à bien et de « terminer » ce qu’elle ajoute. Une équipe mature doit justifier son indépendance en démontrant sa capacité à optimiser la valeur business, le risque, l’apprentissage et les meilleures prochaines étapes.<br />
<br />
« S’il y avait une seule chose que j’aurais voulu corriger chez Spotify, ce serait de ne pas avoir autant mis l’accent sur l’autonomie. » — Joakim Sunden, ancien coach Agile chez Spotify<br />
<br />
3. La collaboration était supposée acquise, alors qu’elle ne l’était pas<br />
<br />
Spotify a laissé chaque équipe contrôler sa façon de travailler, mais beaucoup de personnes n’avaient pas les bases de l’Agile. <br />
En conséquence, chaque équipe a dû chercher la bonne combinaison en itérant sur l’amélioration de ses processus pour améliorer ses outputs. <br />
Il n’existait pas de langage commun pour évaluer efficacement les problèmes de processus, les solutions ou les résultats. En pratique, ce n’était même pas vraiment de l’Agile, juste du « Not-Waterfall ».<br />
<br />
Spotify avait des « coachs Agile » chargés d’enseigner et de suggérer des améliorations de processus à chaque équipe. L’intention était bonne, mais il n’y avait pas assez de coachs pour aider toutes les équipes. <br />
Le temps que chaque coach pouvait consacrer à une équipe ne suffisait pas pour l’accompagner jusqu’à l’achèvement d’un projet et l’évaluation des résultats. Au final, ils n’étaient responsables de rien.<br />
<br />
[ Ce qu’il faut apprendre des erreurs de Spotify ]<br />
→ La collaboration est une compétence qui demande des connaissances et de la pratique. Les managers ne doivent pas supposer que les gens comprennent déjà les pratiques Agile existantes.<br />
→ Quand l’entreprise atteint une certaine taille, chaque équipe a besoin d’une organisation de support pour l’aider à planifier en interne et permettre la collaboration entre équipes. Le Program Management doit être responsable du processus de planning. Des Program Managers dédiés doivent faire fonctionner les équipes de manière à ce que Product Managers et Engineering Managers puissent exercer leurs compétences respectives tout en collaborant. <br />
<br />
4. Un mythe est difficile à faire évoluer<br />
<br />
Si l’Agile Scrum a introduit des termes comme burndown ou sprint, c’était parce qu’il fallait nommer de nouveaux concepts. <br />
Spotify a introduit de nouveaux termes comme Missions, Tribe, Squads ou Chapter Lead, ce qui a donné l’illusion « d’avoir créé quelque chose qui exige forcément un vocabulaire spécial ». <br />
<br />
Si l’on retire tous ces synonymes inutiles, le modèle Spotify n’est rien d’autre qu’un ensemble de « Cross-Functional Team » avec trop d’autonomie et une structure de management fragile. <br />
Si Spotify avait désigné les idées de ce modèle avec les termes d’origine, alors quand le modèle a échoué, cela aurait pu être perçu non comme un changement d’identité culturelle, mais comme la recherche de processus internes plus efficaces.<br />
<br />
[ Ce qu’il faut apprendre des erreurs de Spotify ]<br />
→ La plupart des entreprises ne peuvent maintenir que quelques domaines d’innovation. Il est rare que l’innovation dans les processus internes différencie réellement une entreprise sur son marché. Étudier le passé peut aider une entreprise à trouver de meilleurs domaines où innover.<br />
→ Optimisez la compréhension. Pour maintenir la productivité de l’organisation, il faut évaluer la valeur de tout ce que les collaborateurs doivent apprendre de nouveau.</p><p>*** Faites plutôt ceci. ( Et bien sûr, il n’existe pas de raccourci. )<br />
<br />
Si vous vous êtes intéressé au modèle Spotify, c’est probablement parce que vous cherchez comment structurer vos équipes. Ne vous arrêtez pas là et continuez à creuser.<br />
D’autres entreprises, qui ont résisté à l’épreuve du temps bien plus longtemps que Spotify, ont beaucoup plus écrit sur le sujet.<br />
<br />
Le Spotify de 2012 n’a pas trouvé comment conserver, dans une grande organisation, la vitesse et l’agilité de petites équipes.<br />
Ils ont dépassé ce modèle fondateur et se sont tournés vers l’extérieur pour trouver de meilleures réponses ; vous devriez faire de même. <br />
<br />
Les recommandations de l’auteur sur d’autres façons de travailler<br />
<br />
- Vous avez plus de 200 personnes dans votre organisation produit-développement-design ? Quand j’étais chez Fitbit, le « Scaled Agile Framework » convenait bien.<br />
- En dessous de 200 personnes, je recommande « Shape Up By Basecamp ». C’est la structure que je compte utiliser pour ma prochaine startup.<br />
- Lisez les livres « Essential Scrum » et « Team Topologies ».</p>
4 commentaires