← Tous les articles

Temps de cycle et délai de livraison : cinq erreurs de métriques de flux qui persistent

By XNM Technologies · October 25, 2021 · 4 min read
Temps de cycle et délai de livraison : cinq erreurs de métriques de flux qui persistent

Quand les équipes hybrides et à distance ont pris de l'ampleur durant la reprise post-pandémie, beaucoup d'équipes Scrum ont cherché de meilleurs signaux que la vélocité. Les métriques de flux, formalisées dans le Kanban Guide for Scrum Teams que scrum.org publie avec Daniel Vacanti, étaient la réponse évidente. Le problème, c'est que le temps de cycle et le délai de livraison sont faciles à définir et étonnamment faciles à mal mesurer, et une mauvaise métrique de flux est pire que rien, car elle porte l'autorité d'un chiffre.

Commençons par les définitions, car la moitié de la confusion réside ici. Le temps de cycle est la durée qu'un élément de travail passe dans votre flux, du moment où le travail commence réellement jusqu'à son achèvement. Le délai de livraison, au sens courant de la prestation de service, est le temps écoulé entre la demande ou l'engagement et la livraison; il inclut donc l'attente qui survient avant que quiconque y touche. Le délai de livraison est ce que ressent votre partie prenante. Le temps de cycle est ce que votre équipe maîtrise. Les confondre mène chaque fois à la mauvaise conversation.

Les erreurs qui trompent discrètement les équipes

  1. Ne mesurer que la partie active. Les équipes déclenchent souvent le chronomètre lorsqu'un développeur prend un élément en charge et ignorent les jours passés dans le backlog ou dans une colonne « prêt ». Le tableau de bord paraît sain pendant qu'un demandeur attend deux semaines pour quelque chose qui a exigé deux jours de travail. Mesurez l'attente, pas seulement l'effort.

  2. Prendre les moyennes pour des promesses. Le temps de cycle n'est pas distribué normalement; il a une longue traîne. Annoncer une moyenne de sept jours masque l'élément qui en a pris trente. Utilisez plutôt des percentiles. Dire « 85 % de nos éléments se terminent en neuf jours ou moins » est honnête et prévisible d'une façon qu'une moyenne n'est jamais.

  3. Des points de départ et de fin incohérents. Si une personne lance le chrono au raffinement et une autre au premier commit, vos données ne sont que du bruit. Convenez exactement de la transition du tableau qui démarre le temps de cycle et de celle qui le termine, notez-le, et appliquez-le toujours de la même manière.

  4. Laisser le travail en cours enfler. Selon la loi de Little, le temps de cycle moyen augmente avec la quantité de travail en cours. Les équipes à distance qui ont tiré plus d'éléments pour paraître occupées d'un fuseau à l'autre ont vu leurs temps de cycle grimper pour des raisons sans rapport avec le travail lui-même. Limitez le travail en cours et le temps de cycle baisse souvent de lui-même.

  5. Manipuler le tableau. Scinder un élément pour réinitialiser le chrono, ou faire reculer des cartes pour garder de beaux chiffres, détruit la seule valeur de la métrique. Les données de flux servent à l'équipe pour inspecter et adapter, pas à un gestionnaire pour classer les gens. Dès qu'elles deviennent une cible, elles cessent d'être une mesure.

Faites mériter leur place à ces métriques

Les métriques de flux ont leur place au sein des événements Scrum existants, pas dans un rapport séparé que personne ne lit. Apportez un nuage de points du temps de cycle à la rétrospective de sprint et demandez ce que les valeurs aberrantes avaient en commun. Utilisez les percentiles de délai à la planification de sprint pour fixer des attentes réalistes avec le Product Owner plutôt que de deviner. Pendant le Daily Scrum, un graphique du vieillissement du travail en cours indique aux développeurs quel élément risque de devenir la prochaine aberration aujourd'hui, alors qu'il est encore temps d'agir.

  • Définissez les points de départ et de fin une fois, par écrit, et ne les changez jamais en douce.

  • Rapportez des percentiles, pas seulement des moyennes, et montrez toujours la distribution complète.

  • Suivez le délai de livraison pour la partie prenante et le temps de cycle pour l'équipe, sans jamais les mélanger.

  • Plafonnez le travail en cours avant de chercher à optimiser quoi que ce soit d'autre.

Utilisés honnêtement, ces chiffres transforment une frustration vague en une question précise et réparable. Le but n'est jamais un plus joli graphique; c'est une attente plus courte et plus prévisible pour ceux qui dépendent du travail.

Si vos équipes de livraison ont besoin d'aide pour transformer les données de flux en décisions auxquelles la direction peut se fier, le conseil en réalisation de programmes et de projets de XNM peut vous aider à les mettre en place et à bien les lire.