La bonne façon de définir des métriques agiles

Les indicateurs agiles sont des instruments de mesure employés pour évaluer la progression et la réussite d'une équipe projet utilisant la méthodologie agile.

Ces indicateurs, lorsqu'ils sont pertinents et bien définis, offrent une vision claire des performances, de la qualité, de l'efficacité des tests, ainsi que de l'efficience générale de l'équipe et de son évolution au fil du temps.

L'objectif principal de ces métriques est de guider les équipes dans l'identification des points à améliorer, et de faciliter la prise de décisions fondées sur des données concrètes, permettant ainsi de créer de meilleurs produits à mesure que l'équipe progresse.

Il est fréquent que les entreprises adoptent des métriques qui ne sont en réalité que des "métriques de vanité", ou des chiffres bruts qui augmentent de façon linéaire. Bien qu'elles puissent paraître flatteuses sur un tableau de bord, elles sont souvent inutiles pour l'équipe elle-même.

Au lieu d'aider l'équipe à progresser, ces métriques servent principalement à alimenter des rapports destinés à la direction, qui prend ensuite des décisions stratégiques. Malheureusement, l'équipe se retrouve alors dans l'incompréhension quant à l'origine de ces décisions.

Pour que ces métriques "fallacieuses" donnent bonne impression, les équipes finissent par adapter leurs processus, ce qui donne l'illusion d'une amélioration. Cependant, la performance de l'équipe ne progresse pas réellement.

Indicateurs fondamentaux

Il existe plusieurs approches pour catégoriser les indicateurs. L'une des plus basiques est la distinction entre une approche descendante et une approche ascendante.

➡️ Descendante : La direction définit les indicateurs que les équipes doivent atteindre, l'objectif étant de se situer dans les zones vertes de ces mesures. L'avis de l'équipe n'est pas pris en compte, car l'objectif principal est le suivi des indicateurs par la direction.

➡️ Ascendante : L'équipe identifie les domaines où elle souhaite s'améliorer et choisit les métriques qui lui permettront de suivre ses progrès. Ces indicateurs permettent à l'équipe de démontrer concrètement à la direction l'impact positif de ses actions sur son travail au fil du temps.

Définition d'un bon indicateur

Quelles sont les caractéristiques d'un bon indicateur et comment le définir ?

La caractéristique la plus essentielle est sa capacité à induire un changement de comportement. Autrement dit, chaque analyse de l'indicateur doit clairement indiquer les actions nécessaires pour améliorer les résultats au sein de l'équipe.

De plus, un bon indicateur doit être simple à comprendre. Si vous ne parvenez pas à l'expliquer clairement en quelques phrases pour que tous les acteurs concernés le comprennent, c'est qu'il y a un problème.

Un indicateur pertinent est comparable dans le temps. Prenez des mesures à différents moments et comparez les résultats. Si vous ne pouvez pas établir de comparaison, remettez en question la pertinence de l'indicateur.

Enfin, privilégiez les ratios ou les pourcentages aux chiffres absolus. Par exemple, "10 nouveaux défauts ouverts durant le sprint" est peu parlant. Cela dépend du fait de savoir si d'habitude il y en a 1 ou 100.

Voici quelques exemples d'indicateurs qui, selon moi, répondent à ces critères. Ils sont spécifiquement adaptés aux équipes agiles et divisés en trois catégories principales : performance, qualité et moral.

Catégories d'indicateurs

Indicateurs de performance

Ces indicateurs visent à évaluer la capacité de l'équipe à réaliser les tâches planifiées lors d'un sprint. Il s'agit également de détecter les éventuels problèmes de sur-engagement ou d'écarts par rapport à la norme d'un sprint à l'autre.

Dans le contexte de la performance agile, l'équipe doit s'efforcer de livrer le contenu prévu auquel elle s'est engagée au début du sprint.

Cela n'empêche pas d'être flexible en remplaçant certaines tâches pendant le sprint, mais cela doit résulter d'une négociation et non d'un simple ajout. La capacité de l'équipe n'augmentera pas simplement parce qu'on a ajouté de nouvelles tâches au sprint.

Cet indicateur permet de surveiller ce type de situations et de sensibiliser tous les membres de l'équipe à l'importance de protéger leur capacité de travail pour le sprint.

Ceci renforce la fiabilité et la prévisibilité de l'équipe.

#1. Capacité du sprint par rapport aux points d'histoire livrés

Analysez l'historique de la capacité des sprints en comparaison avec le nombre de points d'histoire (SP) livrés au cours de chaque sprint.

• De légères variations d'un sprint à l'autre sont acceptables. Des écarts importants dans un sens ou dans l'autre signalent un problème.
• La capacité totale d'un sprint correspond à la somme des journées disponibles de chaque membre de l'équipe. Par exemple, une équipe de 10 personnes disponibles durant tout le sprint aura une capacité totale de 100.

Vérifiez la capacité du sprint par rapport au nombre de SP complétés d'un sprint à l'autre. Si l'équipe s'engage (lors de la planification) sur un nombre de SP largement supérieur à ce qu'elle peut accomplir habituellement, signalez ce risque.

L'objectif est de prévoir un nombre de SP total égal ou inférieur au total de SP complété par sprint.

Il est possible de terminer plus de SP que prévu si l'équipe a achevé toutes les tâches planifiées avant la fin du sprint et qu'elle dispose encore de capacité pour en prendre d'autres.

• Si l'équipe livre régulièrement moins de SP que prévu, elle doit ajuster sa planification et prévoir moins de SP lors du sprint suivant.

Des outils comme monday.com, Atlassian Jira ou Asana permettent d'enregistrer et d'extraire facilement les points d'histoire pour chaque tâche d'un sprint. Ils peuvent même générer cette information automatiquement après chaque planification de sprint.

#2. Tableau d'avancement (Burndown chart)

Il s'agit de l'un des indicateurs que la plupart des équipes Scrum ont tendance à cacher sur leur tableau de bord. Il est vrai que cet indicateur peut sembler superflu et que l'équipe y prête rarement attention. Le manager, lui, préfère souvent s'attarder sur l'aspect visuel des tâches et souligner qu'elles n'avancent pas (car elles sont toutes ouvertes pendant tout le sprint).

Cependant, il est important que l'équipe consulte le tableau d'avancement pour son propre bénéfice. Si toutes les tâches restent ouvertes jusqu'au dernier jour du sprint, cela crée de l'incertitude au sein de l'équipe quant à la réalisation des objectifs du sprint.

• Examinez votre tableau de sprint pour les tâches terminées.
• Demandez à l'équipe pourquoi des tâches courtes restent ouvertes, même si elles ont été commencées dès le début du sprint.
• Travaillez avec l'équipe pour éviter de laisser les tâches ouvertes plus longtemps que nécessaire.
• Le tableau d'avancement idéal est généralement un concept théorique, mais plus on s'en approche, plus la gestion des tâches est efficace.

Les outils de gestion agiles tels qu'Asana peuvent générer automatiquement un tableau d'avancement pour chaque sprint.

Source : asana.com

#3. Achèvement de l'objectif du sprint

Cet indicateur mesure le pourcentage d'objectifs de sprint atteints lors de chaque sprint.

Les objectifs de sprint sont documentés séparément (par exemple, sur une page Confluence ou Jira) pour chaque sprint. Il faut indiquer si chaque objectif a été atteint ou non.

Même si l'équipe n'a pas terminé toutes les tâches d'un sprint, elle peut tout de même atteindre l'objectif du sprint (par exemple, si seules des tâches secondaires sont manquantes).

L'objectif est d'atteindre 100 % des objectifs de sprint à chaque sprint. Si ce n'est pas le cas, il faut identifier les obstacles rencontrés par l'équipe.

• S'il y a trop de tâches en parallèle dans chaque sprint, réduisez-leur nombre.
• Si trop de tâches ad hoc sont ajoutées pendant le sprint, limitez ces ajouts afin de ne pas perturber les objectifs initiaux du sprint.
• Si les objectifs de sprint sont trop ambitieux ou trop difficiles, simplifiez-les. Il est inutile de fixer des objectifs élevés si vous ne les atteignez pas à la fin du sprint.

Indicateurs de qualité du code

Ces indicateurs permettent de suivre l'évolution de la qualité du code au fil du temps. Ils contribuent à maintenir des processus de développement sains et à réduire le temps consacré à la résolution des problèmes, ainsi que les temps d'arrêt des développeurs causés par les délais d'exécution du code lors des activités de développement et de test.

Source : azuredevopslabs.com

#1. Tests automatisés

Chaque développeur doit créer des tests unitaires automatisés pour chaque modification qu'il apporte au code.

• Mesurez la couverture du code par des tests automatisés - utilisez Azure Pipelines ou SonarCloud pour exécuter les tests. Visez une couverture de 85 %. Au-delà de 90 %, ce n'est plus vraiment efficace.
• Assurez-vous que la création automatisée des tests unitaires fait partie de la définition de "terminé" pour les nouvelles tâches.
• Intégrez l'amélioration de l'ancienne couverture de test de code dans les tâches de dette technique du backlog.

#2. Complexité du code

Évaluez la complexité inutile du code qui s'accumule au fil du temps et corrigez-la en créant des tâches de dette technique. Essayez également de l'empêcher de se produire.

Définissez des normes de codage et des directives pour que les développeurs les suivent. Assurez-vous qu'ils respectent ces règles afin de minimiser l'augmentation de la complexité du code. Mettez régulièrement à jour ces directives en fonction de l'expérience de l'équipe.

Identifiez les "odeurs de code" - signes de problèmes potentiels dans le code, tels que le code dupliqué, les méthodes longues et les variables inutilisées.

Les revues de code par les pairs doivent permettre de vérifier que les normes de codage sont appliquées au nouveau code.

Utilisez des outils tels que les tableaux de bord et les rapports d'Azure Ado ou SonarCloud pour détecter les problèmes de code.

#3. Étapes manuelles lors du déploiement

Suivez le nombre d'étapes manuelles que l'équipe doit effectuer pour publier le code dans les environnements de test ou de production.

• L'objectif est d'atteindre zéro étape manuelle à terme.
• Créez des tâches de dette technique si nécessaire pour faire passer le pipeline de déploiement/version à un niveau d'automatisation optimal. Réduisez progressivement les étapes manuelles restantes d'un sprint à l'autre.

Indicateurs de moral

Ces indicateurs mesurent l'opinion de l'équipe sur son travail et sur les processus qu'elle gère au quotidien.

#1. Réalisation des actions issues de la rétrospective de sprint

Vous pouvez suivre le nombre d'éléments d'action réellement réalisés lors du sprint suivant.

• Le Scrum Master doit consigner les résultats de la réunion rétrospective sur les pages de l'équipe afin de suivre les éléments d'action convenus.
• L'équipe doit ensuite suivre les progrès.
• La gestion de projet peut alors vérifier si les éléments d'action progressent ou ce qui empêche l'équipe de les terminer. Il faut ensuite adapter l'environnement pour permettre à l'équipe de progresser sur les actions convenues.

Au moins 33 % ou 1 (la valeur la plus élevée étant retenue) des éléments d'action du sprint précédent doivent être mis en œuvre lors des sprints suivants.

Si le pourcentage est inférieur, des changements sont nécessaires pour permettre à l'équipe de mettre en œuvre les améliorations convenues.

Les outils de gestion de projet proposent des modèles prêts à l'emploi pour les activités rétrospectives de sprint. Voici un exemple provenant de monday.com :

Source : monday.com

#2. Collaboration d'équipe

Mettez en place la programmation en binôme.

• Formez des binômes par tâche pour que les membres de l'équipe travaillent ensemble, partagent leurs observations, leurs connaissances et leurs succès. Créez des sous-tâches sous des tâches attribuées à différents membres de l'équipe.

Suivez les revues de code initiées par les pairs.

• Les pairs sont invités à ou prennent l'initiative d'examiner le travail d'un autre membre de l'équipe.

Ces indicateurs peuvent être extraits du tableau monday.com/Asana/Jira à partir des sous-tâches.

Au moins 50 % des tâches d'un sprint doivent être partagées par les membres de l'équipe. Si le pourcentage est inférieur, recherchez-en les raisons et prenez les mesures appropriées.

Pour les revues de code volontaires par les pairs, suivez les tâches avec des sous-tâches dédiées. 20 % des tâches de code revues de cette manière est un bon début. Au fil des sprints, encouragez et motivez l'équipe à travailler davantage en collaboration et à augmenter ce pourcentage jusqu'à 50 % de tâches de code par sprint comme objectif.

#3. Dette technique vs nouvelles tâches fonctionnelles

Source : atlassian.com

Offrir à l'équipe la possibilité de résoudre ses propres problèmes de dette technique augmentera sa satisfaction au travail.

• À l'inverse, l'accumulation de problèmes de dette technique sans plan pour les résoudre démotivera l'équipe à long terme. La solution deviendra plus instable, complexe et difficile à corriger sans refonte complète.

L'équipe sait mieux que quiconque ce qui ne fonctionne pas correctement dans la solution, même si les parties prenantes ou les utilisateurs finaux ne le perçoivent pas. Ces tâches ont un impact important sur l'équipe de développement elle-même. Pour les parties prenantes, elles peuvent être invisibles. Il est donc crucial de permettre à l'équipe de travailler sur des tâches qui faciliteront leurs activités de développement.

L'objectif est de suivre l'évolution des tâches de dette technique résolues au fil du temps et de vérifier si l'arriéré de ces tâches augmente ou non.

L'équipe peut étiqueter les tâches comme "TechDebt" dans le backlog et les prioriser afin qu'elles puissent être sélectionnées lors des sprints.

En fonction de l'état du projet et du nombre de dettes techniques identifiées dans le backlog, assurez-vous que l'arriéré de dette technique n'augmente pas de plus de 10 % d'un sprint à l'autre.

Priorisez les tâches de dette technique et incluez-les dans les sprints pour contrôler la croissance de l'arriéré de dette technique. L'équipe devrait consacrer entre 10 et 20 % de son temps à ces tâches lors de chaque sprint.

Derniers mots

Chaque projet aura besoin d'indicateurs, que ce soit parce que la direction les exige ou parce que l'équipe souhaite évaluer son propre succès.

La meilleure approche est de commencer à créer votre propre bibliothèque d'indicateurs, afin de pouvoir les choisir et les utiliser en fonction de vos besoins. Il faut toujours privilégier les indicateurs qui induisent un changement de comportement.

Ensuite, identifiez les processus dysfonctionnels qui peuvent nuire à vos sprints.