Qu'est-ce que le « Squad Health Check Model » de Spotify ?

De nombreuses entreprises expérimentent différentes approches pour évaluer et visualiser où en sont leurs équipes. Généralement, cela se fait à l'aide de ce qu'on appelle des Maturity Models, c'est-à-dire des modèles de maturité qui représentent une progression à travers différents niveaux.

Les intentions derrière de tels modèles sont généralement positives – par exemple lorsque des managers, des responsables ou des coaches dans de grandes organisations souhaitent mieux comprendre où concentrer leurs efforts en matière d'améliorations et de problèmes, ou lorsqu'ils veulent aider leurs équipes à devenir plus réflexives afin qu'elles puissent elles aussi mieux se concentrer sur leurs propres améliorations.

Cependant, nous préférons l'appeler « Health Check Model » (modèle de bilan de santé) plutôt que « Maturity Model », car ce dernier sonne… eh bien… un peu paternaliste. De plus, la plupart de nos modèles n'incluent pas de progression à travers différents niveaux. Le public cible principal est d'ailleurs l'équipe elle-même, pas le management.

Améliorer une organisation ressemble souvent à un jeu de devinettes (comment savoir ce qui doit être amélioré ? Et comment savoir si quelque chose s'est amélioré ?). Une approche systémique avec une visualisation claire peut réduire ce jeu de devinettes au minimum.

Ok, mais est-ce que ces modèles fonctionnent vraiment ?

Ça dépend. Dans certains cas, ces modèles peuvent être vraiment utiles. Parfois c'est plutôt « bof » – les gens font leur devoir et participent aux ateliers, sondages, etc., mais les données qui en ressortent sont ignorées.

Mais sois prudent. Nous avons déjà vu ce genre de modèles devenir de véritables monstres dans certaines entreprises ; un outil systémique d'oppression qui génère de la sous-optimisation et de la peur. Les managers utilisent le modèle de maturité pour évaluer les équipes et les monter les unes contre les autres, et les équipes cachent leurs problèmes pour faire bonne figure. Et ça, ce n'est vraiment pas bon !

Bien que le préjudice potentiel soit plus probable que le bénéfice potentiel, IL Y A un bénéfice potentiel et il existe des moyens d'éviter le désastre.

Chez Spotify, j'ai expérimenté avec ça pendant quelques années et j'ai trouvé des approches qui fonctionnent plutôt bien (donc plus d'avantages que d'inconvénients) – au mieux elles sont « utiles », au pire « bof », et jusqu'ici elles n'ont jamais été un « désastre ». Nous avons également introduit ce Health Check Model dans plusieurs autres entreprises avec des résultats similaires, alors j'ai pensé qu'il était temps d'écrire un article à ce sujet.

Pour qui le Health Check Model est-il conçu ?

Dans le modèle Health Check d'une Squad (notre terme pour une petite équipe de développement interdisciplinaire et auto-organisée), il y a principalement deux parties prenantes :

• 1) La Squad elle-même

  En discutant des différents indicateurs, les membres de la Squad peuvent mieux comprendre ce qui fonctionne pour eux et ce qui ne fonctionne pas. La grande variété de questions les aide à élargir leur horizon. Peut-être sont-ils conscients des problèmes de qualité du code, mais n'ont-ils pas vraiment réfléchi à la valeur du point de vue du client ou à la vitesse à laquelle ils peuvent apprendre. De plus, les points positifs comme les points négatifs sont mis en évidence.

• 2) Les personnes qui soutiennent la Squad.

  Les managers et coachs qui travaillent en dehors de l'équipe (ou du moins en partie en dehors de l'équipe) obtiennent une vue d'ensemble de tout ce qui fonctionne et de ce qui ne fonctionne pas. Ils peuvent également identifier des tendances entre différentes Squads. Quand on a des dizaines d'équipes et qu'on ne peut pas parler de tout avec chacune, un tel résumé peut aider à déterminer comment utiliser au mieux son temps et avec qui parler de quoi.

Être conscient du problème est le premier pas vers sa résolution. Ce type de visualisation rend beaucoup plus difficile d'ignorer un problème.

Comment nous faisons cela chez Spotify

Nous faisons principalement trois choses :

1. Nous organisons des ateliers au cours desquels les membres d'une squad discutent et évaluent leur situation actuelle selon différents aspects (par exemple la qualité, le plaisir, la valeur, etc.)

2. Nous créons un résumé graphique des résultats

3. Nous accompagnons les squads dans leur amélioration

Nous avons différentes variantes. L'une s'appelle simplement « Squad Health Check Model », d'autres portent des noms comme « Fluent@Agile-Spiel » ou « Quarterly Reflection ». Le « Health Check Model » est une version améliorée de l'enquête trimestrielle « Autonomous Squads » mentionnée en 2012 dans l'article Scaling Agile @ Spotify.

Voici un exemple concret du Health Check Model d'une « Tribe » :

Voici la représentation de 7 équipes (Squads) différentes qui évaluent leur propre situation. Les couleurs montrent l'état actuel (vert=bien, jaune=quelques problèmes, rouge=très mauvais). Les flèches indiquent la tendance (est-ce que ça s'améliore ou ça se dégrade ?).

Si tu regardes attentivement ce diagramme pendant quelques minutes, tu remarqueras plusieurs choses intéressantes :

• Dans les colonnes vous pouvez identifier les principales différences entre les différentes Squads. La Squad 4 est satisfaite de pratiquement tout. La Squad 2 a de nombreux problèmes, mais il y a une tendance positive sur presque tous les points.

• Dans les lignes vous pouvez identifier des schémas systémiques. Chaque Squad prend du plaisir au travail (et la tendance continue même à monter !). La motivation ne semble donc pas être un problème. Cependant, le processus de release pose des difficultés et la base de code n'a pas l'air très saine non plus. Avec le temps, cela affectera certainement aussi le plaisir au travail.

• Dans la vue d'ensemble on peut voir que presque toutes les flèches pointent vers le haut, il n'y a que 2 flèches vers le bas dans tout le diagramme. Cela signifie que le processus d'amélioration (le processus le plus important de tous) semble fonctionner.

Ceci n'est bien sûr qu'une représentation approximative de la réalité (« Tous les modèles sont faux, mais certains sont utiles. » – George Box). C'est donc une bonne idée de tout vérifier une nouvelle fois avant de prendre des mesures concrètes.

Est-ce que tout va vraiment aussi bien pour la Squad 4 ou sont-ils simplement optimistes et ne voient-ils pas leurs problèmes ? La plupart des Squads pensent qu'elles apportent de la valeur à leurs clients – mais comment le savent-elles ? Cette affirmation repose-t-elle sur un vœu pieux ou sur de véritables retours clients ?

La Squad 4 de notre exemple a en fait été constituée seulement une semaine avant la réalisation du Health Check. Elle était donc clairement encore dans la phase d'orientation (également appelée phase de Forming ou phase de lune de miel). C'est pourquoi tant la Squad 2 que la Squad 4 avaient besoin de beaucoup de soutien.

La facilité de livraison était ici un problème majeur. On s'est donc davantage concentré sur des éléments comme le Continuous Delivery (livraison continue) et bientôt, une nette amélioration a pu être constatée.

N'oublie pas qu'il s'agit d'un modèle d'auto-évaluation basé sur l'honnêteté et l'opinion subjective des membres de la Squad. Il ne fonctionne donc que dans un environnement de confiance, où les gens peuvent être sûrs que leurs managers et collègues agissent dans leur intérêt. Collecter les données est assez simple – il s'agit donc principalement de veiller à ce qu'il n'y ait pas de raisons concrètes de ne pas le faire.

Heureusement, chez Spotify, un tel environnement de confiance existe et les managers et coachs veillent particulièrement à faire comprendre qu'il s'agit d'un outil de soutien et non d'évaluation des Squads.

Comment nous collectons les données

Nous avons constaté que les sondages en ligne sont vraiment nuls pour ce genre de choses. La raison principale est qu'ils ne permettent pas de conversation, et c'est justement ce qui a le plus de valeur. Pendant que les membres de la Squad discutent entre eux, tu obtiens des informations supplémentaires, et le coach découvre comment il peut vraiment aider les Squads. Les données seules ne montrent qu'une petite partie du tableau d'ensemble, ce qui peut être trompeur.

Donc nous (généralement les coachs agiles) organisons des ateliers avec les Squads et encourageons une conversation directe sur les différents indicateurs du « Health Check Model ». Une à deux heures suffisent généralement pour cela.

Pour l'animation, nous utilisons un jeu de cartes appelées « Awesome Cards ». Chaque carte représente l'un des indicateurs et contient à la fois un « Example of Awesome » (exemple de quelque chose de génial) et un « Example of Crappy » (exemple de quelque chose qui ne va pas).

Un set se compose généralement d'environ 10 cartes. Voici l'exemple d'un set complet :

Pour chaque question, on demande aux Squads s'ils se situent plutôt du côté « Awesome » ou « Crappy ». Pour les aider à se mettre d'accord sur une couleur pour les indicateurs et la tendance correspondante (stable, tendance à la hausse/baisse), nous utilisons des méthodes d'atelier très basiques comme le Dot Voting.

Voici les cartes en téléchargement PDF

Nous gardons les choses simples avec trois niveaux (vert/jaune/rouge). La définition exacte du code couleur peut varier, mais elle repose sur les affirmations suivantes :

Vert ne signifie pas forcément que tout est parfait. Cela signifie simplement que l'équipe est satisfaite et ne voit pas de besoin majeur d'amélioration pour le moment.

Jaune signifie qu'il y a quelques problèmes à résoudre, mais que ce n'est pas catastrophique.

Rouge signifie que quelque chose ne va vraiment pas et doit être amélioré.

Oui, ce sont des données subjectives. En théorie, chaque Squad est libre d'intégrer également des données objectives (temps de cycle, nombre de défauts, vélocité, etc.). Mais très peu le font. La raison est que les Squads doivent aussi interpréter les données objectives et décider si elles indiquent un problème ou non. Au final, tout est donc subjectif de toute façon. Si quelque chose ressemble à un problème, c'est un problème.

Parfois, nous combinons cela avec des rétrospectives, par exemple en choisissant une carte et en réfléchissant ensuite à des actions d'amélioration.

Quelles questions devrait-on poser ?

Si vous regardez les exemples mentionnés ci-dessus, vous remarquerez que les questions ne sont pas toujours les mêmes. Voici un bon guide :

• Les questions doivent couvrir une large gamme de perspectives différentes.

• Ces questions sont uniquement un point de départ, une présélection à titre d'exemple. Les Squads sont libres de décider s'ils souhaitent supprimer, ajouter ou modifier des questions s'ils pensent que c'est pertinent.

• Essayez de limiter le nombre de questions à environ 10 questions. Avec plus de questions, des chevauchements peuvent rapidement apparaître, c'est pourquoi elles peuvent être supprimées.

Il est important de veiller à ce que les questions portent sur l'environnement dans lequel travaille un Squad, et non sur des données chiffrées (comme la Velocity). Cela rend l'exercice moins menaçant et souligne une fois de plus qu'il s'agit de soutien et d'amélioration – et non d'évaluation.

Notre hypothèse (qu'elle soit vraie ou non) est qu'un Squad a une motivation intrinsèque à réussir et à fournir la meilleure performance possible dans les circonstances données.

À quelle fréquence mesurons-nous la santé des Squads ?

Comme je l'ai dit, nous avons différents modèles sur lesquels nous nous appuyons, donc cela varie beaucoup. Nous n'avons pas encore trouvé d'« intervalle de temps parfait » pour ce genre de choses (et nous ne le trouverons probablement jamais).

Cependant, un rythme trimestriel semble être un bon point de départ. Mensuellement, c'est probablement un peu trop fréquent (les gens trouvent ça vite pénible et les données ne changent pas assez rapidement). Deux fois par an semble trop rare (il peut se passer beaucoup trop de choses en six mois). Mais comme je l'ai dit, cela varie toujours.

Conclusion – Ce à quoi vous devriez penser si vous souhaitez essayer cela

Un tel modèle PEUT aider à faire avancer les améliorations. Mais il peut aussi bouleverser toute une culture d'entreprise si on ne le fait pas correctement ! C'est pourquoi il faut toujours procéder avec prudence.

Voici quelques lignes directrices qui augmentent les chances de succès :

• Soyez clair sur les motivations de l'introduction du modèle. Il doit toujours s'agir d'amélioration, pas d'évaluation.

• Vous devriez collecter les données principalement par communication personnelle et non par des sondages en ligne. Ce processus doit être intéressant et agréable.

• Impliquez les équipes dans l'application du modèle et laissez-les faire des ajustements selon leurs besoins.

• L'adhésion de l'équipe est plus importante que la cohérence des données. Si l'équipe A choisit un ensemble de questions légèrement différent de l'équipe B, ce n'est pas grave (même si le résumé devient un peu moins lisible).

• Veillez à ce qu'il n'y ait aucune incitation à tricher. Il ne devrait y avoir aucune raison pour une équipe de vouloir se présenter sous un meilleur jour que la réalité.

• Trouvez un moyen simple de visualiser les données. Plus la visualisation est évidente et intuitive, plus elle a de chances d'être utilisée.

• Évitez de comparer les équipes entre elles. Si l'équipe A évalue ses points principalement en vert et l'équipe B majoritairement en rouge, cela ne signifie pas automatiquement que l'équipe A est « meilleure ». Cela pourrait tout aussi bien signifier que l'équipe A a un contexte plus simple, qu'elle est plus optimiste ou que l'équipe B est plus honnête concernant ses difficultés. Quelle que soit la raison, cela signifie simplement que l'équipe B a besoin d'un peu plus de soutien. L'attitude du manager devrait être « Comment puis-je aider ? » et non « Pourquoi êtes-vous tellement moins bons que les autres ? ».

• Faites un suivi. Posez des questions comme : « Ce modèle vous aide-t-il ? », « Si nous arrêtions les Health Checks, est-ce qu'ils vous manqueraient ? » ou « Comment pourrions-nous rendre ce modèle encore plus utile ? ». Le modèle (et la façon dont vous l'appliquez) doit être amélioré en continu.