Mesurer le flux et la valeur

Cette publication est l’épisode 3 sur 9 de la série « De la preuve à l’action — L’agilité incarnée ». Elle conserve la distinction de la source entre références établies, retours d’expérience anonymisés et cas pédagogiques simulés.

Introduction — Choisir des mesures qui améliorent les décisions

Cas pédagogique — données simulées. Chez My Little Old Cie, une équipe augmente le nombre de story points terminés alors que l’adoption et la satisfaction diminuent. Le scénario ne démontre pas que les estimations sont inutiles ; il montre qu’une mesure d’activité ne peut pas remplacer une mesure de résultat.

Une métrique professionnelle possède une finalité explicite : éclairer une décision, détecter un risque ou évaluer une hypothèse. Lorsqu’elle devient un objectif isolé, les comportements tendent à optimiser le chiffre plutôt que le système.

Le statut particulier de la vélocité

La vélocité et les story points ne font pas partie de la définition de Scrum [2]. Une équipe peut néanmoins les utiliser comme technique interne de prévision si les règles d’estimation restent stables et si les chiffres ne servent ni à évaluer les personnes ni à comparer les équipes.

La vélocité ne mesure pas la valeur, la productivité ou la qualité. Une hausse peut correspondre à davantage de travail livré, à une modification de l’échelle d’estimation ou à une dégradation des critères de finition.

Combiner quatre familles de signaux

Evidence-Based Management propose quatre Key Value Areas — Current Value, Unrealized Value, Time to Market et Ability to Innovate — pour relier objectifs, expérimentation et mesure de la valeur [4].

Cette partie commence par les métriques de flux, poursuit avec la mesure des résultats et se termine par l’articulation de Scrum et Kanban. L’objectif n’est pas de construire un tableau de bord exhaustif, mais de sélectionner le plus petit ensemble de signaux capable de provoquer une meilleure décision.

Chapitre 8 — Mesurer et améliorer le flux

De l’activité au flux

Une équipe peut être entièrement occupée tout en livrant peu. Lorsque plusieurs éléments avancent en parallèle, chacun peut rester bloqué dans une file d’attente, une validation ou une reprise. Le flux s’intéresse au mouvement du travail jusqu’à un résultat utilisable, et non au taux d’occupation des personnes.

Le Kanban Guide définit Kanban comme une stratégie d’optimisation du flux de valeur. Il repose sur trois pratiques : définir et visualiser le workflow, gérer activement les éléments de travail et améliorer le workflow [3].

Les quatre métriques de flux

Les points de départ et d’arrivée doivent être explicitement définis. Deux équipes peuvent employer le terme Cycle Time tout en mesurant des segments différents ; leurs chiffres ne sont alors pas comparables.

Lead Time et attentes

Le Lead Time désigne généralement le délai entre une demande et sa livraison. Le Cycle Time mesure un segment plus resserré, à partir du démarrage effectif du travail. La différence peut révéler l’attente avant engagement, mais cette interprétation dépend des politiques de workflow.

Une mesure utile distingue donc :

• le moment où la demande devient visible ;
• le moment où l’équipe s’engage à la traiter ;
• le moment où le travail commence ;
• le moment où le résultat devient utilisable.

Ces définitions doivent rester stables dans le temps. Une évolution du chiffre n’a de sens que si la méthode de mesure n’a pas changé.

Flow Efficiency : un indicateur complémentaire

La Flow Efficiency rapporte le temps de travail actif au temps total de traversée. Elle peut aider à rendre visibles les attentes, mais elle exige une mesure fiable du temps actif et ne fait pas partie des quatre métriques obligatoires du Kanban Guide.

Il n’existe pas de seuil universel. Une valeur basse peut signaler des files d’attente, mais son interprétation dépend du type de travail, des contrôles nécessaires et de la précision des données.

Visualiser la distribution, pas seulement la moyenne

Une moyenne de Cycle Time masque souvent une dispersion importante. Les prévisions doivent s’appuyer sur des données historiques comparables et exprimer une probabilité : par exemple, « 85 % des éléments de cette classe de service ont été terminés en douze jours ou moins ».

Ce type de prévision ne garantit pas la date d’un élément particulier. Il décrit le comportement observé du système et doit être recalibré lorsque le workflow, la taille des éléments ou la capacité changent.

Cumulative Flow Diagram

Un Cumulative Flow Diagram représente l’évolution du nombre d’éléments dans chaque état du workflow.

• Des bandes relativement stables suggèrent un flux maîtrisé.
• Une bande qui s’élargit signale une accumulation.
• Une augmentation durable de la distance entre travail commencé et travail terminé signale une hausse du WIP.

Le graphique ne fournit pas, à lui seul, la cause du problème. Il oriente l’enquête vers les politiques, compétences, dépendances ou décisions qui ralentissent le flux.

Réduire les délais sans déplacer le problème

Quatre leviers sont généralement testables.

1. Limiter le WIP afin de terminer avant de commencer davantage.
2. Réduire la taille des éléments pour accélérer le feedback et diminuer le risque.
3. Rendre les politiques explicites afin de réduire les attentes et les interprétations contradictoires.
4. Traiter les dépendances et automatiser les contrôles répétables sans affaiblir les exigences de qualité.

L’amélioration doit être évaluée sur l’ensemble du système. Accélérer le développement tout en saturant la revue ou le test déplace seulement la file d’attente.

Relier flux, qualité et résultats

Les métriques de flux décrivent la capacité de livraison ; elles ne démontrent pas la valeur produite. Elles doivent être rapprochées de la qualité, de l’adoption, de la satisfaction et des résultats métier.

Les recherches DORA utilisent également un ensemble équilibré de métriques de débit et d’instabilité pour éviter qu’un gain de vitesse masque une dégradation de la fiabilité [8]. Le principe est transposable : aucune métrique isolée ne doit devenir l’objectif unique du système.

Chapitre 9 — Mesurer la valeur sans transformer la métrique en cible

Output, outcome et impact

Un output décrit ce qui a été produit : fonctionnalité, version, campagne ou document. Un outcome décrit un changement de comportement ou de résultat observable. L’impact relie ce changement à un enjeu plus large.

Ces niveaux sont complémentaires. Un outcome sans output ne peut pas être produit, mais un output terminé ne garantit aucun effet utile.

Formuler une hypothèse mesurable

Une hypothèse professionnelle relie une intervention, une population, un résultat attendu, un délai et une condition d’arrêt.

Si nous simplifions la configuration des workflows pour les nouveaux administrateurs, le taux de première configuration réussie devrait augmenter dans les quatre semaines. Nous arrêterons ou réviserons l’intervention si le taux d’erreur ne diminue pas.

Cette formulation sépare l’intention de la certitude. Elle autorise l’apprentissage sans présenter le résultat attendu comme acquis.

Evidence-Based Management

Evidence-Based Management relie objectifs stratégiques, expérimentation et mesure de la valeur au moyen de quatre Key Value Areas [4].

• Current Value : valeur actuellement obtenue par les utilisateurs, clients et parties prenantes.
• Unrealized Value : valeur potentielle qui pourrait justifier un investissement.
• Time to Market : capacité à livrer et apprendre dans un délai utile.
• Ability to Innovate : capacité à produire de nouvelles possibilités sans être paralysé par les contraintes internes.

Ces dimensions évitent d’optimiser un résultat immédiat en dégradant la capacité future. Une hausse d’adoption accompagnée d’incidents, de délais ou d’une dette croissante doit être interprétée comme un signal contradictoire.

OKR, North Star Metric et limites

Un OKR peut rendre un objectif et ses résultats attendus explicites. Il devient contre-productif lorsqu’il est utilisé comme engagement certain, mécanisme de rémunération ou justification a posteriori.

Une North Star Metric peut aider à concentrer l’attention sur un comportement créateur de valeur. Elle ne remplace pas les métriques de garde-fou : qualité, sécurité, satisfaction, équité ou soutenabilité.

Le principe connu sous le nom de loi de Goodhart rappelle qu’une régularité statistique tend à se dégrader lorsqu’elle devient un instrument de contrôle [14]. La parade consiste à utiliser un ensemble équilibré de signaux et à surveiller les comportements induits.

Instrumenter avec proportion

Trois niveaux d’instrumentation sont généralement nécessaires.

1. Processus : dates de début et de fin, blocages, reprises, files d’attente.
2. Produit : événements d’usage, parcours, erreurs, performance et disponibilité.
3. Feedback : entretiens, support, observations et enquêtes.

La collecte doit répondre à une décision identifiable. Accumuler des événements sans gouvernance crée du coût, du bruit et des risques de confidentialité.

Qualité des données

Avant d’interpréter une variation, il faut vérifier la définition, la population, la période, le volume et les changements d’instrumentation. Une corrélation ne démontre pas la causalité et une moyenne peut masquer des segments opposés.

Un tableau de bord professionnel associe à chaque métrique :

• une définition et une unité ;
• une source et un responsable ;
• une fréquence de mise à jour ;
• une décision qu’elle éclaire ;
• une métrique de garde-fou.

De la mesure à la décision

La mesure n’a de valeur que si elle modifie une action. Une revue utile aboutit à l’une de ces décisions : poursuivre, amplifier, ajuster, arrêter ou collecter une information manquante.

Le nombre d’indicateurs doit rester limité. Lorsque tout est prioritaire et mesuré, aucun signal ne guide réellement l’arbitrage.

Chapitre 10 — Articuler Scrum et Kanban

Une complémentarité, pas un compromis

Le guide Kanban pour les Scrum Teams décrit comment ajouter une stratégie d’optimisation du flux sans retirer les éléments de Scrum [11]. Les Sprints, responsabilités, événements, artefacts et engagements restent applicables.

Kanban apporte un workflow explicite, une gestion active du WIP, des métriques de flux et une amélioration fondée sur les données. Scrum apporte une cadence d’inspection, un Product Goal, un Sprint Goal et un Increment conforme à la Definition of Done.

Définir le workflow de la Scrum Team

Le workflow doit représenter le parcours d’un élément depuis le point d’engagement jusqu’à sa finition. Il précise :

• les états traversés ;
• les critères d’entrée et de sortie ;
• la manière dont les blocages et urgences sont traités ;
• les limites de WIP ;
• les unités mesurées.

Le tableau peut évoluer à l’intérieur du Sprint. Le Sprint Backlog reste un plan par et pour les Developers.

Utiliser les métriques pendant les événements

Éviter quatre dérives

Sprints transformés en mini-cascade. Analyse, développement et test restent séquentiels. La visualisation rend le problème visible, mais seule une modification du système réduit les attentes.

Limites de WIP décoratives. Une limite dépassée sans discussion n’est plus une politique. Les exceptions doivent être explicites et rares.

Métriques converties en objectifs. Imposer un Throughput ou un Cycle Time cible peut favoriser le découpage artificiel et l’abandon de la qualité.

Kanban utilisé pour éviter le Sprint Goal. Le flux soutient l’objectif du Sprint ; il ne remplace pas la cohérence produit.

Critère de réussite

L’articulation est utile lorsque la Scrum Team termine davantage de travail engagé, détecte plus tôt les risques et améliore sa prévisibilité sans dégrader la Definition of Done.

Le résultat doit être vérifié localement. Aucune combinaison de cadres ne compense une dépendance structurelle, une architecture fragile ou l’absence d’objectif produit.

Sources

1. Manifesto for Agile Software Development, Kent Beck et al., 2001.

2. Le Guide Scrum, Ken Schwaber et Jeff Sutherland, version française, novembre 2020.

3. The Kanban Guide, Kanban Guides, mai 2025.

4. Evidence-Based Management Guide, Scrum.org, 2024.

5. Unskilled and unaware of it, Justin Kruger et David Dunning, Journal of Personality and Social Psychology, 1999.

6. Psychological Safety and Learning Behavior in Work Teams, Amy C. Edmondson, Administrative Science Quarterly, 1999.

7. Certified Tester Foundation Level — CTFL v4.0, ISTQB, page et syllabus officiels.

8. DORA metrics, DORA, guide officiel des indicateurs de performance de livraison logicielle.

9. Shape Up, Basecamp, ressource officielle en ligne.

10. Org Topologies — Mapping, Org Topologies, ressource officielle de cartographie.

11. The Kanban Guide for Scrum Teams, Scrum.org, guide officiel.

12. Turn the Ship Around!, L. David Marquet, page officielle de l’ouvrage.

13. Managing the Development of Large Software Systems, Winston W. Royce, actes IEEE WESCON, 1970.

14. Problems of Monetary Management: The U.K. Experience, Charles A. E. Goodhart, 1975.

15. Theory in Practice: Increasing Professional Effectiveness, Chris Argyris et Donald A. Schön, 1974.

16. Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin et Janet Gregory, Addison-Wesley, 2009.

17. Thinking, Fast and Slow, Daniel Kahneman, Farrar, Straus and Giroux, 2011.