5 métriques Agile pour suivre et améliorer la performance de votre équipe de développement

15 février 2021
Par Alexandre Walsh, VP Ingénierie
Temps de lecture 🕒 7 min

Vous vous êtes engagé à améliorer la performance de votre équipe de développement? Parfait! Maintenant vous cherchez un point de départ pour vous mesurer afin d'observer vos progrès? Dans cet article de blogue, je vous explique l'importance de certains indicateurs de performance à surveiller pour mieux avancer.

En effet, se fier uniquement à votre intuition et votre expérience c'est risquer de passer à côté d'éléments importants. Utiliser les données est essentiel pour cibler vos prochaines interventions et vous fier à des faits! Il existe un large éventail de métriques Agile et si plusieurs d'entre elles sont pertinentes, d'autres n'ont pas d'importance. En explorant quelques-unes de ces métriques, je vais vous faire part de ce qui, selon moi, influence grandement les performances de livraison des équipes de développement logiciel.

Des mesures axées sur la vitesse

Le temps de cycle

Le temps de cycle reflète la durée entre le début d'une tâche et sa fin, c'est-à-dire le moment où elle est considérée comme terminée (Done). Lorsqu'un développeur s'assigne une tâche, par exemple dans Jira ou Azure DevOps, le chronomètre démarre. Dès qu'il l'amène à "Done", le chronomètre s'arrête. 

Il s'agit d'un indicateur de performance assez simple à mesurer et qui en dit long sur le processus de l'équipe, car elle capture tous les temps d'arrêt, les réunions, les imprévus, les serveurs qui cessent soudainement de fonctionner, etc. Si vous n'avez pas l'habitude de mesurer le temps de cycle, notre coach Agile Antoine Lefrançois a partagé quelques idées pour bien commencer dans cet article de blogue.  

De manière générale, on souhaite une tendance stable ou décroissante pour la métrique du temps de cycle. Dans l'exemple ci-dessus, l'équipe de direction pourrait interpréter qu'une tâche prend environ 5 jours pour être achevée. Notez ici que l'on considère 5 jours et non 5 jours ouvrables . En effet, les imprévus, les variations dans la complexité des tâches et les week-ends sont tous pris en compte dans le temps de cycle. L'avantage de cet indicateur de performance est qu'il permet une meilleure communication entre les développeurs et les parties prenantes.

Le débit

Cette métrique illustre simplement le nombre d'éléments achevés pour une période donnée. Attention, il s'agit bien du nombre d'éléments, à ne pas confondre avec le nombre de story points. Par exemple, lorsqu'une tâche est terminée, un bogue ou une histoire d'utilisateur, nous ajoutons un élément au flux. J'aime l'inspecter sur une base hebdomadaire. Encore une fois, si mesurer le débit est une nouvelle habitude pour vous, voici quelques conseils de notre coach Agile, Antoine Lefrançois.  

Ici, on recherche une tendance stable ou croissante. Là encore, la mesure du débit permet de saisir tous les imprévus, les changements d'équipe, etc. Étonnamment, vous constaterez que dans de nombreux cas, la variabilité n'affecte pas le débit comme on pourrait le penser.

La métrique du débit peut être utile pour l'équipe de gestion afin de prévoir les dates de livraison. Par conséquent, on utilisera une simulation selon la méthode Monte-Carlo plutôt que d'utiliser la moyenne. Le développement de logiciels n'est pas un secteur déterministe : on ne peut donc pas s'attendre à obtenir le même résultat chaque fois qu'on répète la même expérience. C'est pourquoi les probabilités nous permettent de faire des prédictions dans le futur afin d'avoir des équipes plus stables et prévisibles.

Par exemple, on pourrait déterminer à la suite d'une simulation que nous avons 60% de chances de respecter une date de livraison X si on doit produire 20 articles. J'aime souvent utiliser une analogie météorologique pour comparer. Autant il est impossible de garantir un temps 100% ensoleillé samedi prochain, autant on se fit aux probabilités pour tenter de garantir une date de livraison.

De plus, lorsqu'on utilise le concept de probabilité, la discussion devient plutôt intéressante : on peut introduire la notion de risque dans notre stratégie. On peut aussi se poser des questions en équipe. Par exemple, est-ce qu'on veut être plus agressifs et miser sur un 60% de chances de respecter notre date de livraison ou on vise un niveau de confiance plus élevé, comme 85% par exemple?

Le niveau de service attendu

Cette mesure est ma préférée, car elle reflète la prévisibilité de l'équipe. Elle nous donne une indication du caractère aléatoire de la livraison des éléments.

L'indicateur de performance est obtenu en insérant toutes les données en relation avec le temps de cycle dans un graphique comme celui qui est ci-dessus. Dans l'exemple, on peut voir que 85% des tâches sont réalisées en 4 jours ou moins. Ce pourcentage représente le 85e percentile. L'utilisation du concept de percentile est très intéressante, car il n'est pas dilué par les valeurs aberrantes.

Pour l'équipe de direction, chaque décision a nécessairement un impact sur la prévisibilité de l'équipe. Le résultat de la performance de l'équipe se reflète ici. Sachez donc que plus la livraison des éléments est aléatoire, plus l'impact sur la prévisibilité de vos livraisons, et donc sur votre feuille de route, est négatif.

C'est pourquoi on vise la stabilité de l'équipe de développement: afin d'avoir un taux de confiance élevé dans les dates de livraison et que ces dernières ne soient pas aléatoires.

Des mesures axées sur le moral de l'équipe

La culture d'une entreprise a un impact direct sur les performances de livraison des équipes. C'est pourquoi je vous suggère d'interroger continuellement chaque membre de vos équipes sur leur moral de façon anonyme en utilisant une échelle de réponses standardisées. Les questions doivent porter sur leur niveau de stress, leur motivation ou leur alignement sur le projet, par exemple.

Dans l'exemple ci-dessus, alors que l'équipe semble avoir un bon moral, je peux rechercher les raisons pour lesquelles les gens semblent moins alignés ou plus stressés. Ces métriques aident le Scrum Master ainsi que l'entreprise à cibler leurs prochaines interventions.

Par exemple, si la feuille de route n'est pas régulièrement partagée avec l'équipe, la direction que prend le projet n'est pas claire et le stress peut augmenter. Dans un tel cas, l'équipe de développement aura du mal à hiérarchiser les urgences et se trouvera dans une impasse pour définir la portée des tâches. Le résultat? Un temps de développement plus long, puisque les développeurs ne comprennent pas ce qui est nécessaire (must-have) et ce qui ne l'est pas (nice-to-have).

Mesurer le pouls d'une équipe Agile aide grandement à faire des liens entre l'augmentation du stress ou le manque d'alignement et son impact sur les indicateurs de performance de vitesse et de qualité. Pour de nombreux développeurs de logiciels, il est tentant de toujours dire oui aux heures supplémentaires et de jouer les héros. Mais n'oubliez pas l'impact que ce réflexe peut avoir sur la performance de l'équipe.

Équilibrer les indicateurs de performance axés sur la vitesse avec des mesures de qualité

Si la rapidité de l'équipe est importante, il est primordial de maintenir un rythme régulier sur une base continue. C'est pourquoi on utilise également des mesures axées sur la qualité.

L'étude DevOps de Google a mis en lumière les quatre métriques clés qui permettent de prédire de meilleures performances en matière de livraison de logiciels. Le délai d'exécution, la fréquence de déploiement, le temps moyen de rétablissement (MTTR) et le taux d'échec des changements permettraient donc de mesurer les performances de l'équipe.

Cependant, il faut se rappeler que ces métriques ne mesurent pas directement la qualité. Afin d'améliorer ces quatre paramètres, vous devrez inévitablement introduire davantage de qualité dans vos activités. Il est également essentiel d'investir dans l'automatisation et l'infrastructure de votre développement logiciel pour l'améliorer. Ces mesures sont très intéressantes et peuvent être utiles pour comparer nos performances à celles des autres joueurs du domaine.

Je suis conscient que chaque organisation est différente et que certaines de ces mesures vous parleront plus que d'autres. Ce que j'apprécie dans les métriques décrites ci-dessus, c'est qu'elles me facilitent la vie lorsque je parle à des chefs d'entreprise ou à des gestionnaires, parce qu'on parle soudainement un langage commun. Ces métriques favorisent donc une communication sans failles au sein de l'équipe. Comme je parle davantage en termes de temps et de probabilité, et moins en sprints et en story points, j'ai un peu moins l'air d'un extraterrestre vivant sur une autre planète. 👽

N'hésitez pas à me contacter au awalsh@nexapp.ca si vous avez des questions ou à me laisser vos commentaires! Vous pouvez aussi partager cet article avec les personnes qui cherchent à introduire le suivi des métriques dans leur organisation et qui pourraient souhaiter en savoir plus sur Axify.

Rendez-vous dans la communauté!