Merci à Oliver My d’avoir relayé (il y a déjà un petit moment) un article très intéressant d’un insider Spotify, Jeremiah Lee, qui donne son regard et son analyse vue de l’intérieur du modèle éponyme. Pour aller jeter un œil sur les articles,
l’original en anglais : https://www.jeremiahlee.com/posts/failed-squad-goals/,
et la version française par Olivier : https://oyomy.fr/2020/04/l-echec-du-modele-spotify/.
L’article est intéressant car il pose un point de vue différent sur le retour d’expérience, en supposant un échec, et pose une analyse sur ses raisons. Elle appartient à son auteur mais permet néanmoins de prendre un peu de recul par rapport à ce qui est apparu comme étant « la méthode Spotify ». Un recul nécessaire car Spotify a toujours revendiqué qu’il ne s’agissait pas d’un guide méthodologique mais d’un retour d’expérience sur leur façon de s’approprier l’agilité. Cependant, si l’article nous annonce que le modèle Spotify a échoué, il ne dit pas ce qui se pratique aujourd’hui dans l’entreprise. Il aurait été intéressant de connaitre l’évolution de Spotify depuis que le modèle a été présenté en 2014. Peut-être faudra t’il attendre le témoignage d’un autre insider 😉
Si l’on reprend l’analyse, elle énumère 4 grands problèmes … et apprentissages :
- Le management matriciel a résolu le mauvais problème
- Spotify s’est trop concentré sur l’autonomie de l’équipe
- La collaboration était une compétence supposée
- La mythologie devint difficile à changer
Soit, mais reprenons.
1. C’est vrai, quand on pense agilité ou devops, on ne pense pas à une organisation matricielle. Le manager opérationnel responsable du projet (pattern anti-agile) se retrouve très rapidement à devoir négocier ou gérer des escalades vers n managers transverses qui s’occupent de compétences spécifiques (deuxième pattern anti-agile). Cela complique le modèle et freine la décision opérationnelle.
En revanche la question à mon sens était surtout de savoir quel problème cela était censé résoudre, ce que je n’ai pas réussi à comprendre au travers de l’article. Mais pour l’avoir expérimenté dans une grande structure, le problème qui se pose naturellement quand on transforme une organisation vers l’agilité, et plus encore en devops, est le rôle désormais dévolu aux managers en place, qui traditionnellement sont responsables et décideurs. C’est LE premier grand frein à l’adoption de l’agilité dans les grandes organisations. Une couche transverse concentrée sur la gestion des compétences était une réponse possible.
En revanche lire que le manager transverse a une posture de « servant-leader », est, de mon point de vue, un non-sens. Le servant-leader se met à disposition de l’équipe dans sa globalité pour qu’elle atteigne l’objectif fixé. Hors en suivant l’organisation Spotify, on s’aperçoit qu’on a plusieurs managers transverses pour s’occuper d’une même équipe. Ça ne colle pas avec l’idée du servant-leader.
Je ne suis pas non plus convaincu par le découpage des « responsabilités » mis en avant dans les préconisations de Jeremiah Lee pour remédier au problème. A priori, selon lui, il aurait été nécessaire de positionner le product owner en vrai manager responsable du résultat (on appel ça un chef de projet). Mais en Agile, et en devops, c’est l’équipe qui est responsable, VRAIMENT, du résultat. Et c’est bien pour cela qu’on dit qu’elle est orientée client, car c’est la seule mesure de succès qui compte, et non un objectif intermédiaire porté par un manager d’équipe. Pour moi il y a là également un contre-sens sur les attentes de l’agilité.
2. Ce qui amène au deuxième problème, à savoir l’autonomie. Sur le papier, l’autonomie de la décision est véritablement ce qu’il y a de plus clair et de plus efficace opérationnellement. D’ailleurs, au regard de l’histoire, qu’elle soit militaire ou économique, tous les agents dotés d’une autonomie claire et mus par une vision partagée (même si celle-ci est moralement répréhensible), sont redoutablement plus efficaces que les organisations hiérarchisées ultra-dépendantes de décisions venues d’en haut. L’exemple historique parfait (et horrible) est l’efficacité de l’armée allemande face aux troupes françaises en 1940. Il y a des exemples sociétaux beaucoup plus modernes, mais ils sont trop sensibles et nous écartent du sujet.
Mais c’est vrai que l’organisation de Spotify pose immédiatement la question de la gestion des interdépendances. Rien n’est dit si ce n’est une recherche constante du découplage. SAFe de ce point de vue apporte une réponse très concrète, sans pour autant remettre une organisation transverse en chapeau. Jeremiah Lee met en avant la nécessité du leadership pour traiter ce problème de synchronisation des dépendances. Il utiliserait ce « leadership » non pas pour redonner une vision, mais pour revenir à une pratique de contrôle et de priorisation par le haut. Ce n’est plus du leadership, et à mon sens plus de l’agile non plus.
Et puis bien sûr se pose la question de la capitalisation des connaissances et des pratiques d’une équipe à l’autre. Je m’étonne que l’article ne mentionne pas l’utilité des guildes qui représentent le lien communautaire sur lequel devrait s’appuyer le partage. C’est un sujet très fort que met bien en avant l’article de Willem-Jan Ageling sur le modèle Spotify (<https://medium.com/serious-scrum/you-want-to-adopt-the-spotify-model-i-dont-think-it-means-what-you-think-it-means-7df4316081f> ). Pour Spotify la communauté passe avant la structure organisationnelle.
3. Sur le point de la collaboration, là encore les conclusions de l’article nous ramènent en arrière en mettant en avant que la difficulté à collaborer autour d’un objectif commun serait lié à un problème de compétence agile et donc que la solution serait de remettre une couche de planification au-dessus des équipes. Je ne vois pas vraiment comment il est possible de tirer cette conclusion, d’autant que les pratiques Lean tirées de l’agilité sont d’abord une réponse à l’incapacité chronique des équipes organisées autour d’un plan préconstruit et rigide de communiquer entre elles. L’histoire de l’informatique (et pas que) est jonchée de désastres qui ont pour origine une absence flagrante de collaboration entre les équipes. C’est même d’ailleurs le premier leitmotiv du devops : casser les silos.
Sans doute qu’effectivement l’appropriation de l’agilité et du Lean nécessite un accompagnement. Je pense que le problème de compétence pour Spotify est plutôt à chercher sur le positionnement des coachs internes. Un coach interne est dépendant des décisions de la direction, ce qui peut l’amener à manquer de recul pour remettre en question l’organisation qu’il contribue par ailleurs à mettre en place. Il devient compliquer dans ces conditions de faire évoluer les pratiques et cela participe sans doute à figer les choses. Pour ma part j’adhère plus volontiers à l’approche « SHU HA RI » qu’au coaching interne permanent. Mais j’ai également trouvé pertinente la conclusion de l’étude « ACCELERATE » qui corrèle clairement la compétence agile à l’appropriation par la pratique, à condition de respecter le principe d’amélioration continue systémique. En clair, pour être agile, il faut pratiquer l’agile, et pour paraphraser Jack London, ce n’est pas la destination qui compte, c’est le voyage.
4. Le retour d’expérience de Spotify a fait découvrir un univers lexical qui aura beaucoup contribué à sa popularité. Comme le dit Willem-Jan Ageling cela tient probablement aussi du fait que nombre d’organisations y auront vu un bon moyen de reproduire leur structure matricielle existante par un bon coup de peinture, la rendant ainsi plus moderne et très soudainement Agile. Jeremiah Lee émet le postulat que cette nouvelle façon de nommer des structures, qui avaient déjà des noms communément admis par ailleurs, avait finalement contribué à figer les choses, en empêchant de remettre en cause ce qui faisait désormais partie du mythe Spotify. Sa conclusion est de dire que finalement les mots usuels « services », « managers » reflètent mieux les rôles et responsabilités. De mon point de vue cela sent surtout l’organisation top-down. Et c’est aussi oublier que Henrik Kniberg, le conteur de l’expérience Spotify, insistait sur le fait que le modèle présenté faisait tout sauf mettre en avant des décideurs. On sent bien dans la critique de Jeremiah Lee que c’est bien ce qui lui posait le plus de problèmes. Pour le dire autrement, le monde Agile n’a pas besoin de héros et en écarte même l’idée. Réinventer une mythologie anti-héros, axée sur la valeur collective, est un moyen pour latéraliser les repères des ingénieurs et leur faire accepter de sortir d’une posture individualiste. Hors pour beaucoup de développeurs, y compris chez les jeunes, le mythe du héro, rebelle, hacker, startupper et sauveur de situations critiques, est toujours très fort. Le remettre en cause est perturbant, voir démotivant.
Pour conclure je pense qu’on peut dire qu’il est déjà très intéressant de modérer les attentes que l’on pourrait avoir du retour d’expérience Spotify. Comme l’a préciser Kniberg, le témoignage de 2014 représente une photographie à un instant t de l’évolution de l’organisation Spotify. Il précise également qu’un diagramme organisationnel, même crayonné, n’est qu’une illusion du fonctionnement réel de l’organisation. Le modèle présenté était en fait un support traduisant beaucoup plus la volonté de reprendre des thèmes chers à l’agilité : s’améliorer en continue, décentraliser la décision, privilégier le leadership sur l’autorité managériale, mettre les équipes en situation d’autonomie pour les rendre plus efficaces. L’organisation qui suit n’est qu’un prétexte pour mettre à l’épreuve ces grands principes. En clair Spotify indiquait que leur voyage était en cours, et ils nous ont envoyé une jolie carte postale qui en montrait le meilleur panorama. C’est bien l’intérêt d’une carte postale, non ?
kraftinside.com 