Spotify contre Fitbit

Je pensais avoir fini avec la série d’articles sur l’importance d’ingénieurs autonomes, mais un article est sorti il ​​y a quelques jours critiquant le modèle Spotify d’Agile à l’échelle, et je ne pouvais pas laisser passer l’occasion d’essayer d’en faire un moment propice à l’apprentissage.

L’auteur critique le modèle Spotify de mise à l’échelle Agile, mais oublie de mentionner que Spotify a construit une entreprise valant désormais plus de 25 milliards de dollars, tout en rivalisant – et souvent en gagnant – à la fois contre Apple et Amazon, deux des meilleures sociétés de produits au monde.

Et puis l’auteur va plus loin et recommande plutôt de considérer le processus adopté chez Fitbit pour la mise à l’échelle Agile, mais oublie de mentionner qu’immédiatement après cela, la valeur de l’entreprise a chuté de plus de 10 milliards de dollars à moins de 2 milliards de dollars.

On parle beaucoup aujourd’hui de se concentrer sur les résultats, mais voici une chance pour les gens de voir assez clairement la différence entre les extrants et les résultats.

Cela dit, cela soulève des questions importantes:

Premièrement, Spotify a-t-il réussi grâce au processus utilisé? Et Fitbit a-t-il souffert du processus utilisé? Il n’y a vraiment aucun moyen de le savoir avec certitude, mais la théorie dans laquelle j’ai argumenté Équipes produit habilitées et La chose la plus importante expliquerait à la fois le succès de Spotify et les difficultés de Fitbit (plus d’informations ci-dessous).

Deuxièmement, même si nous ignorons les résultats commerciaux réels, qu’en est-il des critiques spécifiques du modèle Spotify qui ont été évoquées dans l’article? Sont-ils des critiques justes? Je pense qu’ils le sont, et en fait, en 2013, j’ai soulevé ces mêmes préoccupations auprès des dirigeants de Spotify.

Mais ce que l’article ne mentionne pas, c’est que ce qu’ils ont droite chez Spotify était beaucoup plus important que ce qu’ils avaient mal.

Si vous supprimez toutes les discussions sur les processus Agile, la nomenclature concise et les vidéos intelligentes, le cœur du travail des équipes chez Spotify est l’autonomisation des équipes produit, et en particulier des ingénieurs habilités. En particulier, le niveau de autonomie donné à ces ingénieurs. Chez Spotify, le cadran de l’autonomie est réglé sur 10.

Bien que je sois tout au sujet d’équipes de produit responsabilisées et que j’aime régler le cadran relativement haut sur l’autonomie, il est facile de souligner les inévitables inefficacités qui surviennent lorsque l’autonomie individuelle est si élevée et que la gestion et le leadership sont si bas.

Mais les dirigeants de Spotify m’ont expliqué qu’ils étaient conscients de ce compromis et qu’ils considéraient que c’était un prix acceptable à payer pour les avantages d’équipes et d’ingénieurs pleinement autonomes. Les dirigeants de Spotify m’ont également expliqué que ce choix était en partie le reflet de la culture d’ingénierie suédoise.

J’ai quitté les discussions en croyant pleinement que Spotify aurait besoin d’ajuster sa façon de travailler pour faire face aux conséquences du faible rôle de la direction et du leadership, d’autant plus qu’ils grandissaient (qu’ils ont en effet abordés sous plusieurs aspects, créant cette différence entre ce qui a été évangélisé. et vers quoi ils ont évolué), mais dans l’ensemble, je ne m’inquiétais pas pour eux, car il était clair que leur activité dépendait d’une innovation constante et qu’ils faisaient ce que je considérais les choses les plus importantes pour nourrir cela.

Il convient de noter que j’ai eu les mêmes discussions avec les équipes de Google, où elles ont également réglé le cadran d’autonomie très haut. En fait, c’est Spotify et Google qui ont inspiré ma série d’articles de 2015 sur les compromis liés à l’autonomie: Autonomie vs effet de levier, Autonomie vs mission, Autonomie vs propriété et Autonomie vs initiatives. J’ai également publié des articles pour encourager Spotify et d’autres à élever leur jeu dans la gestion et la conception de produits être aussi bon que leur ingénierie.

À l’inverse, chez Fitbit, la société que l’auteur a citée comme ayant un processus qu’il préférait mise à l’échelle Agile, ils ont adopté l’opposé polaire du modèle d’équipe habilité. Ce processus utilise équipes de livraison plutôt que d’équipes de produits habilitées, et si j’ai raison sur la nécessité de disposer d’ingénieurs réellement habilités pour l’innovation, alors que vous constaterez peut-être une augmentation de production, vous vous attendez à voir une baisse importante de la quantité d’innovation, puis des résultats commerciaux, en particulier sur un marché axé sur l’innovation comme la technologie portable. Et malheureusement pour Fitbit, après avoir adopté ce processus en 2015, c’est précisément ce dont nous avons été témoins.

Le refus de Fitbit est-il dû à ces raisons? Impossible de savoir avec certitude, d’autant plus que je ne travaille pas personnellement avec eux, mais je trouve absolument inexplicable qu’ils passent au processus qu’ils ont fait. Et je crois comprendre que les dirigeants derrière cette décision mal conçue ne sont plus là.

Maintenant, pour être clair, bien que je considère Spotify comme un exemple fort d’équipes de produits responsabilisées, le processus de mise à l’échelle Agile qu’ils ont promu il y a plusieurs années n’est pas ce que je préconise personnellement, ni ce que j’écris dans mon nouveau livre, cependant, c’est essentiel. pour garder tout cela en perspective, et vous pourriez faire bien pire que d’adopter le modèle de Spotify Agile mis à l’échelle.

J’espère donc que les gens ne tireront pas les mauvaises leçons de Spotify et Fitbit. La plupart d’entre nous aimeraient absolument avoir le degré de succès continu que Spotify a gagné.

Plutôt que d’être obsédé par les détails des processus, vous devriez rechercher les vérités plus profondes qui ont alimenté leur dossier d’innovation.