Cinq métriques agiles que vous ne détesterez pas

Les statistiques et les tableaux sont des outils puissants. Utilisez-les sans hésiter, chers agilistes. Sans hésiter. 

Dan Radigan Dan Radigan
Browse topics

Les métriques restent un sujet sensible.

D'un côté, nous avons tous participé à un projet où aucune donnée, quelle qu'elle soit, ne faisait l'objet d'un suivi quelconque. Il était difficile de savoir si l'équipe était dans les temps pour la livraison ou même si elle se perfectionnait avec le temps. D'un autre côté, beaucoup d'entre nous ont eu la malchance de travailler sur des projets où les statistiques étaient brandies comme des armes, pour dresser les équipes les unes contre les autres ou pour justifier l'obligation de travailler un week-end. Il n'est donc pas surprenant de constater que la plupart des équipes entretiennent avec les métriques une relation d'amour/haine.

Mais ce n'est pas une fatalité. Le suivi et le partage de métriques Agile utiles peuvent dissiper la confusion et mettre en lumière les progrès (et les contretemps) de l'équipe tout au long du cycle de développement. Voici comment.

Connaître votre business

Le mot « Terminé » ne révèle que la moitié de l'histoire. Le tout est de développer le produit adéquat, au moment adéquat et pour le marché adéquat. Pour garder le cap tout au long du programme, il est nécessaire de collecter et d'analyser certaines données en cours de route. Dans n'importe quel programme Agile, les métriques métier et Agile doivent impérativement faire l'objet d'un suivi. Les métriques métier déterminent si la solution répond aux besoins du marché, tandis que les métriques Agile mesurent les aspects du processus de développement.

Les métriques métier d'un programme doivent être ancrées dans sa feuille de route.

Pour chaque initiative de la feuille de route, ajoutez plusieurs indicateurs clés de performances (KPI) correspondant aux objectifs du programme. De plus, prévoyez des critères de réussite pour chaque exigence produit ; par exemple, un taux d'adoption par les utilisateurs ou un pourcentage de code couvert par les tests automatisés. Ces critères de réussite serviront aux indicateurs Agile du programme. Plus l'équipe apprend, mieux elle peut s'adapter et évoluer. 

Comment utiliser les métriques agiles pour optimiser votre livraison

Les métriques Agile abordées ci-dessous se focalisent sur la livraison du logiciel. Que votre équipe soit Scrum ou Kanban, chacune de ces métriques agiles aidera l'équipe à mieux comprendre son processus de développement, ce qui facilitera la livraison du logiciel.

burndown de sprint

Les équipes Scrum organisent le développement en sprints limités dans le temps. Au début du sprint, l'équipe prévoit la quantité de travail qu'elle sera capable de réaliser pendant celui-ci. Ensuite, un rapport d'avancement (ou burndown) de sprint présente le suivi du travail réalisé tout au long du sprint. L'axe X représente le temps et l'axe Y montre la quantité de travail qu'il reste à réaliser et qui est mesurée soit en story points, soit en heures. L'objectif est de terminer tout le travail prévu avant la fin du sprint.

Une équipe qui honore régulièrement ses prévisions fait la meilleure des publicités pour Agile au sein de l'entreprise. Mais que cela ne vous incite pas à trafiquer les chiffres en déclarant une tâche achevée avant qu'elle ne le soit réellement. Cela peut sembler positif à court terme, mais à long terme, cela ne fera qu'entraver l'apprentissage et l'amélioration. 

Anti-schémas à surveiller
  • L'équipe termine très rapidement, sprint après sprint, parce qu'elle s'engage à réaliser trop peu de travail.
  • Sprint après sprint, l'équipe ne parvient pas à honorer ses prévisions parce qu'elle s'engage à réaliser trop de travail.
  • La ligne d'avancement affiche des chutes soudaines plutôt qu'une progression graduelle parce que le travail n'a pas été divisé en tâches granulaires.
  • Le Product Owner allonge ou modifie le cahier des charges en cours de sprint.

Burndown d'epic et burndown de version

Les burndown d'epic et de version montrent l'avancement du développement sur un corpus de travail plus long que le burndown du sprint. Les équipes Scrum et Kanban s'en servent comme guide de développement. Dans la mesure où un sprint (pour les équipes Scrum) peut contenir des tâches issues de plusieurs epics et versions, il est important d'assurer à la fois le suivi des différents sprints et des epics et versions.

Une « dérive des objectifs » désigne l'introduction de nouvelles exigences dans un projet déjà défini. Par exemple, si l'équipe livre un nouveau site web pour l'entreprise, la dérive consistera à demander de nouvelles fonctionnalités alors que les exigences initiales ont déjà été ébauchées. Dans un sprint, l'acceptation d'un tel phénomène n'est pas recommandée. En revanche, dans les epics et les versions, le changement du cahier des charges est une conséquence naturelle du développement Agile. Au fur et à mesure que l'équipe avance dans le projet, le Product Owner peut décider d'accepter ou de supprimer certaines tâches en fonction de ce qui est appris. Les burndown d'epic et de version permettent de sensibiliser tout le monde aux flux et reflux du travail au sein de l'epic ou de la version. 

Anti-schémas à surveiller
  • Les prévisions d'epic et de version ne sont pas actualisées au fur et à mesure que l'équipe avance dans le travail.
  • Aucun progrès n'est constaté sur une période de plusieurs itérations. 
  • Les objectifs connaissent des dérives chroniques qui peuvent être le signe que le Product Owner ne comprend pas parfaitement le problème que le corpus de travail tente de résoudre.
  • Le cahier des charges s'allonge trop rapidement par rapport aux capacités d'absorption de l'équipe.
  • L'équipe ne fournit pas de livraisons incrémentielles tout au long du développement d'une epic.

Vélocité

La vélocité désigne la quantité moyenne de travail qu'une équipe Scrum réalise pendant un sprint. Mesurée en story points ou en heures, elle est très utile pour les prévisions. Le Product Owner peut utiliser la vélocité pour prévoir à quelle vitesse l'équipe peut terminer le backlog. En effet, le rapport montre le suivi du travail prévu et achevé sur plusieurs itérations. Plus il y a d'itérations, plus les prévisions sont précises.

Imaginons que le Product Owner souhaite atteindre 500 story points dans le backlog. Nous savons que l'équipe de développement réalise généralement 50 story points par itération. Le Product Owner peut, de façon raisonnable, supposer que l'équipe aura besoin de 10 itérations (environ) pour terminer le travail requis.

Il est important de surveiller l'évolution de la vélocité dans le temps. Les nouvelles équipes peuvent s'attendre à une augmentation de cette vélocité au fur et à mesure de l'optimisation des relations et du processus de travail. Les équipes déjà en place peuvent surveiller leur vélocité afin de garantir l'homogénéité des performances dans le temps et vérifier si une modification particulière du processus a permis des améliorations ou non. Une baisse de la vélocité moyenne est généralement le signe qu'une partie du processus de développement de l'équipe est devenue inefficace et doit être abordée lors de la prochaine rétrospective.

Anti-schémas à surveiller

Lorsque la vélocité est irrégulière sur une période prolongée, revoyez toujours les pratiques d'estimation de l'équipe. Lors de la rétrospective de l'équipe, posez les questions suivantes :

  • Certains défis liés au développement ont-ils été ignorés au moment de l'estimation de ce travail ? Comment pouvons-nous mieux diviser le travail pour déceler certains de ces défis ?
  • L'équipe subit-elle une pression extérieure du métier pour dépasser ses limites ? En conséquence, l'adhésion aux bonnes pratiques de développement en souffre-t-elle ?
  • En tant qu'équipe, faisons-nous preuve d'excès de zèle dans les prévisions pour le sprint ? 

La vélocité est unique pour chaque équipe. Si l'équipe A présente une vélocité de 50 et l'équipe B une vélocité de 75, cela ne signifie pas que l'équipe B a un débit plus élevé. Comme la culture d'estimation  est unique pour chaque équipe, sa vélocité le sera aussi. Résistez à la tentation de comparer la vélocité de différentes équipes. Mesurez le niveau d'effort et le travail réalisé en fonction de l'interprétation spécifique des story points par chaque équipe. 

Graphique de contrôle

Les graphiques de contrôle se focalisent sur la durée du cycle des tickets pris individuellement, à savoir la durée totale écoulée entre l'état « en cours » et l'état « terminé ». Les équipes qui présentent des durées de cycle plus courtes auront tendance à avoir un débit plus élevé, alors que les équipes qui présentent des durées de cycle régulières sur plusieurs tickets seront plus prévisibles en ce qui concerne la livraison du travail. Si la durée de cycle constitue une métrique principale pour les équipes Kanban, les équipes Scrum peuvent également retirer certains avantages d'une durée de cycle optimisée.

La mesure du temps de cycle est une façon efficace et flexible d'améliorer les processus de l'équipe. En effet, les résultats des changements sont notables presque immédiatement. L'équipe peut alors les ajuster dans la foulée. L'objectif final est d'obtenir un temps de cycle court et régulier, indépendamment du type de tâche (nouvelles fonctionnalités, dette technique, etc.).

Anti-schémas à surveiller

À première vue, les graphiques de contrôle peuvent sembler inconstants. Ne vous inquiétez pas si des données sont aberrantes. Cherchez à en déduire les tendances. Voici deux aspects à observer :

  • Augmentation de la durée de cycle : une augmentation de la durée de cycle mine l'agilité durement gagnée de l'équipe. Lors de la rétrospective de l'équipe, prenez le temps d'analyser cette augmentation. Exception : si l'équipe a étendu sa définition de l'état « terminé », la durée de cycle s'allongera probablement aussi.
  • Durée de cycle irrégulière : l'objectif est de parvenir à une durée de cycle régulière pour les tâches qui présentent des valeurs similaires en termes de story points. Passez en revue le graphique de contrôle afin de vérifier la cohérence des valeurs de story points. Si la durée de cycle est irrégulière sur les petites et les grandes valeurs de story points, passez du temps, lors de la rétrospective, pour examiner les mauvaises estimations et améliorer les améliorations ultérieures. 

Diagramme de flux cumulé

Le diagramme de flux cumulé est une ressource clé pour une équipe Kanban, car il l'aide à garantir la régularité du flux de travail en son sein. Avec le nombre de tickets sur l'axe Y, le temps sur l'axe X et les couleurs pour indiquer les différents états du workflow, il identifie visuellement les lacunes et les goulots d'étranglement, et fonctionne conjointement avec les limites WIP.

Le diagramme de flux cumulé devrait être (plus ou moins) fluide de gauche à droite. Les bulles ou les creux, quelle qu'en soit la couleur, montrent les insuffisances et les goulots d'étranglement. Si le diagramme en comporte, recherchez les façons de fluidifier les bandes de couleurs sur le diagramme.

Anti-schémas à surveiller
  • Les tickets bloquants créent d'importants goulots d'étranglement dans certaines parties du processus et un vide dans d'autres.
  • Croissance non maîtrisée du backlog dans le temps. En conséquence, les Product Owners ne clôturent pas les tickets obsolètes, ni ceux dont la priorité est trop basse pour qu'ils soient traités. 

Encore plus de métriques

Les bonnes métriques ne se limitent pas aux rapports décrits ci-dessus. Par exemple, la qualité est une métrique importante pour les équipes Agile. Et de nombreuses métriques traditionnelles peuvent être appliquées au développement Agile.

  • Combien de défauts sont identifiés...
    • pendant le développement ?
    • après la livraison aux clients ?
    • par des intervenants extérieurs à l'équipe ?
  • Combien de défauts sont reportés à une version ultérieure ?
  • Combien de demandes arrivent du support client ?
  • Quel est le pourcentage de couverture des tests automatisés ?

Les équipes Agile doivent également se pencher sur la fréquence et la rapidité des livraisons. À la fin de chaque sprint, l'équipe doit livrer le logiciel en production. À quelle fréquence cela se produit-il ? La plupart des builds sont-ils livrés ? Dans la même veine, combien de temps faut-il à l'équipe pour livrer un correctif d'urgence à la production ? La livraison est-elle simple pour l'équipe ou nécessite-t-elle des efforts héroïques ?

Les métriques ne sont que l'une des composantes de la culture d'une équipe. Elles fournissent une perspective quantitative sur les performances de cette dernière et définissent des objectifs mesurables pour elle. Mais même si elles sont importantes, n'en faites pas une obsession. Il est tout aussi important d'écouter le feedback de l'équipe pendant les rétrospectives pour renforcer la confiance au sein du groupe, améliorer la qualité du produit et accélérer le développement tout au long du processus de livraison. Utilisez à la fois le feedback quantitatif et qualitatif pour favoriser le changement.