Les 4 métriques de flux Kanban / Articles

Cet article va détailler les 4 métriques essentielles de la stratégie Kanban.

Avant d'utiliser ces métriques, l'équipe du système Kanban a besoin avant tout de définir son workflow et notamment d'avoir défini le ou les point(s) de départ de son flux, ainsi que le ou les point(s) d'arrivée. Pour les autres éléments à ne pas oublier dans une définition de workflow, reportez-vous au Kanban guide ici : https://kanbanguides.org/francais/

Les 4 métriques sont : Le WIP, le temps de cycle, le débit et l'âge des éléments en cours.

WIP

Commençons par le WIP qui est le nombre d'éléments qui a dépassé le point de départ, mais pas encore le point d'arrivée. Cette métrique est importante d'un point de vue du flux, de la prédictibilité, mais aussi vis-à-vis du comportement humain :

Le docteur John Little a établi depuis les années 1950 une relation entre le WIP, le temps de cycle et le débit. Cette métrique a donc une influence sur les autres. Dans cette relation mathématique, le WIP est au numérateur, tandis que le débit est au dénominateur, la tendance d'un WIP qui augmente est donc aussi une augmentation du temps de cycle. En d'autres termes sans focus ou la bonne quantité d'éléments permettant de maintenir un débit élevé, il ne faudra pas compter finir les choses rapidement.

Equation de Little : Moyenne du temps de cycle = Moyenne du WIP / Moyenne du Débit

Les changements de contexte induits par de multiples tâches parallélisées et toutes aux mêmes niveaux de priorités sont néfastes. Contrôler le WIP permet d'éviter de rentrer dans ces problèmes (charge mentale trop élevée, erreurs, tension dans les relations, car on devient goulet d'étranglement, etc.). De plus, ces changements de contexte vous font perdre du temps, chaque changement de contexte est un gaspillage supplémentaire et réduit l'efficience. À 2 tâches en parallèle, on ne consacre plus que 40% de son énergie à chaque tâche, 20% sont perdus dans les changements de contexte. À 3 tâches en parallèle, on ne consacre plus que 20% de son énergie à chaque tâche, 40% sont perdus dans les changements de contexte.
C'est une métrique temps réel (Leading metric), ce qui fait d'elle une métrique permettant une conversation au plus tôt et des actions en découlant.

Temps de cycle

Continuons avec le temps de cycle qui est le temps écoulé pour qu'un élément traverse le flux du point de départ au point d'arrivée. Vu qu'il y a possibilité d'avoir plusieurs points de départ et points d'arrivée, il peut donc y avoir plusieurs temps de cycle calculés, à vous de leur donner un nom distinctif pour les reconnaître :

Le temps de cycle est calculé par exemple en jours par la formule : Date de fin - Date de départ +1.
Un temps de cycle se calcule en comptant les week-ends, les jours fériés, etc. Pourquoi ? Parce que les éléments sont des éléments à potentielle valeur qu'attend un client. Votre client ne comptera pas en jour travaillé. Il comptera en jour calendaire, car il s'en fiche de savoir que vous ne travaillez pas le mercredi, samedi ou dimanche ou tout autre jour.
Le temps de cycle est au dénominateur dans l'équation de Little pour sa relation avec le débit. Un petit temps de cycle accroît donc le débit et inversement.
Le temps de cycle sert à faire une projection probabiliste du nombre de jours nécessaire pour réaliser un élément. (par exemple 15 jours ou moins avec 85 % de probabilités)
Le temps de cycle est une mesure de la santé et de la performance du système. Des temps de cycle variant, grandement, sont un signe d'instabilité du système. Un système non stable est non prédictible. Un système non stable cache différentes contraintes qui sont en train de ruiner votre business.
Lorsque le temps de cycle est court, il est possible de vérifier rapidement si nos hypothèses étaient fausses et de collecter du feedback. C'est le point crucial du management de produit agile et de la réussite d'un produit en environnement complexe.
C'est une métrique qui s'obtient que lorsque l'élément est terminé (Lagging metric), ce qui fait d'elle une métrique à analyser a posteriori pour comprendre et chercher des améliorations.

Débit

Poursuivons avec le débit qui est le nombre d'éléments par unité de temps (Ex : jour) qui ont franchi le point d'arrivée :

Le débit est corrélé à la taille des éléments. Il est moins efficace et efficient de faire circuler dans son flux des gros éléments, car le débit sera forcément plus faible. Pour rappel, le débit est au dénominateur dans sa relation avec le temps de cycle. Donc un plus grand débit permet de réduire le temps de cycle et il est important de savoir que nous avions tort (ou raison) le plus rapidement possible et sur le plus de choses possible.
D'ailleurs, "alerte polémique", on ne peut déterminer la valeur sans avoir mis l'élément dans les mains du client, de l'utilisateur. N'est-il pas plus intéressant de se concentrer à terminer le plus d'éléments (même aléatoirement) et voir si on a des bénéfices ? Au lieu de passer des heures au carré à imaginer la valeur potentielle ? (Voir en complément cet article)
Le débit (ou plutôt une plage de débit historique) servira à faire des projections probabilistes sur la date d'atterrissage pour plusieurs éléments avec la technique de simulation de Monte-Carlo. La simulation de Monte-Carlo qui peut aussi se faire pour déterminer de manière probabiliste combien d'éléments pourraient être réalisables à une date donnée.
Un débit variable est moins gênant en termes de prédictibilité que ne l'est le temps de cycle. En effet, aucune hypothèse de la loi de Little (cf article sur la Loi de Little), ne concerne le débit directement. Le débit est soit associé au taux d'entrée (moyenne des deux similaires) ou associé au WIP qui doit rester stable. Donc s'il y a un jour avec un fort débit, il est nécessaire qu'il y ait une équivalence en entrée d'éléments dans le workflow.
C'est une métrique qui s'obtient que lorsque l'élément est terminé (Lagging metric), ce qui fait d'elle une métrique à analyser a posteriori pour comprendre et chercher des améliorations.

Age des éléments en cours

Finissons donc avec l'âge des éléments en cours qui est le nombre de jours (ou autre unité de temps) qu'a passé l'élément non terminé, mais commencé, dans le workflow :

Je finis par cette métrique, car c'est la métrique la plus importante de la stratégie Kanban.
En effet en contrôlant l'âge des éléments en cours, on contrôlera par rebond le WIP dans le flux. La meilleure stratégie pour que quelque chose ne vieillisse pas est de ne pas la démarrer (pas d'augmentation du WIP). La deuxième meilleure stratégie est de finir l'élément (réduction du WIP).
C'est une métrique temps réel (Leading metric), ce qui fait d'elle une métrique permettant une conversation au plus tôt et des actions en découlant. Elle permet d'enclencher une pro activité nécessaire pour l'optimisation du flux.
Elle sert notamment à ajuster le plan de l'équipe et à réagir face à la complexité ou aux incertitudes apparaissant après le début du travail sur l'élément. Si l'élément vieillit trop, faut-il découper ? Se mettre tous dessus ou à plusieurs ? Passer à autre chose, car il y a une dépendance qui nous bloque et qu'on ne peut traiter avant plusieurs jours/semaines ? Abandonner tout simplement ? Ne rien faire et accepter ce vieillissement ? (cf article sur l'utilisation de cette métrique en daily Scrum)
Et enfin, c'est la métrique qui permet la prédictibilité (il faut l'entendre comme un verbe), car on ne devient pas prédictible sans action. C'est le contrôle de l'âge des éléments dans notre flux qui va permettre la prédictibilité.

Voilà, les 4 métriques Kanban ont été passées au crible dans cet article. J'espère qu'il vous aura été utile pour mieux les comprendre et les appréhender.

Si vous voulez un outil vous permettant de collecter facilement ces métriques, tournez-vous vers :