Cinq indicateurs 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

Les indicateurs 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 indicateurs une relation d'amour/haine.

Mais ce n'est pas une fatalité. Le suivi et le partage d'indicateurs agiles 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 indicateurs métier d'un programme doivent être ancrés dans sa feuille de route.

Pour chaque initiative de la feuille de route, ajoutez plusieurs indicateurs clés de performances 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 indicateurs agiles pour optimiser votre livraison

The agile metrics discussed below focus on the delivery of software. Whether you are a scrum or kanban team, each of these agile metrics will help the team better understand their development process, making releasing software easier.

Sprint burndown

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 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 graphiques d'avancement d'epic et de version montrent l'avancement du développement sur un corpus de travail plus long que le graphique d'avancement 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 responsable produit peut décider d'accepter ou de supprimer certaines tâches en fonction de ce qui est appris. Les graphiques d'avancement 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 responsable produit ne comprend pas parfaitement le problème que le corpus de travail tente de résoudre.
  • Le cahier des charge 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.

Velocity

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 responsable produit 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 ? 

Each team’s velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it doesn't mean that team B has higher throughput. Since each team's estimation culture is unique, their velocity will be as well. Resist the temptation to compare velocity across teams. Measure the level of effort and output of work based on each team's unique interpretation of story points. 

Tableau de contrôle

Control charts focus on the cycle time of individual issues–the total time from "in progress" to "done". Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for kanban teams, scrum teams can benefit from optimized cycle time as well.

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 du temps de cycle : une augmentation du temps 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 du statut « terminé », le temps de cycle s'allongera probablement aussi.
  • Temps de cycle irrégulier : 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 diagramme de contrôle afin de vérifier la cohérence des valeurs de story points. Si le temps de cycle est irrégulier sur les petites et les grandes valeurs de story points, prenez le temps, lors de la rétrospective, d'examiner les mauvaises estimations et d'améliorer les améliorations ultérieures. 

diagramme cumulatif

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 statuts du workflow, il identifie visuellement les lacunes et les goulots d'étranglement, et fonctionne conjointement avec les limites WIP.

Le diagramme de flux cumulatif 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 d'indicateurs

Les bons indicateurs ne se limitent pas aux rapports décrits ci-dessus. Par exemple, la qualité est un indicateur important pour les équipes agiles. Et de nombreux indicateurs traditionnels peuvent être appliqués 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 agiles 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 indicateurs ne sont que l'une des composantes de la culture d'une équipe. Ils fournissent une perspective quantitative sur les performances de cette dernière et définissent des objectifs mesurables pour elle. Mais même s'ils sont importants, 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. 

Up Next
Advantage