Ce billet a comme objectif d’expliquer mon interprétation du cumulative flow diagram (CFD), un graphique fortement utilisé par les gens qui appliquent la méthode Kanban.

Table des matières

• Introduction
• Lire le travail en cours (WIP)
• Identifier les goulots d’étranglement
• Lire le lead time
• Lire le cycle time (temps de cycle)
• Prédire la fin du projet avec un CFD
  • Option 1 – Utiliser la pente pour la barre Terminé
  • Option 2 – Utiliser le graphique des temps de cycle (Cycle time scatterplot)
  • Option 3 – Générer des probabilités de complétion
• Ressources

Introduction

Vous démarrez une itération de 2 semaines avec 10 tâches à faire. Ignorer tout le reste (récits, heures, burndown, etc) pour l’instant. Votre itération débute le mercredi. Elle dure 2 semaines, c’est-à-dire qu’elle se termine mardi dans 2 semaines. Votre tableau sur le mur ressemble à ceci le matin de la première journée.

On peut aussi le voir de la façon suivante. J’ai 10 tâches dans la colonne À faire, 0 tâche dans les colonnes En cours et Terminé:

Illustrons ces trois couleurs sur un graphique Cumulative Flow Diagram (CFD). Mon axe des X est le temps. Dans notre exemple, ce sont les jours de l’itération. L’axe des Y représente simplement les items dans mon tableau. J’ai 10 tâches sur le tableau alors je m’attends à voir une barre qui monte jusqu’à 10 sur le graphique. En somme, le CFD ressemble à ceci en cette première journée d’itération:

Nous sommes maintenant le premier vendredi de l’itération. Le tableau des tâches ressemble maintenant à ceci:

On peut voir ce tableau autrement. J’ai 2 tâches dans la colonne À faire, 6 tâches sous En cours et 2 sous Terminé. Visuellement, ça ressemble à ceci:

Mon CFD m’indique la même représentation en ce premier vendredi de l’itération. Ma barre bleue À faire a une hauteur de 2 items (10 – 8). Ma barre rouge En cours a une hauteur de 6 items (8 – 2) et ma barre verte, Terminé, a une hauteur de 2 (2 – 0) puisqu’il y a deux items dans cette colonne. En prime, j’ai un historique des jours. Jeudi, j’avais 4 tâches dans la colonne À faire, 4 tâches dans la colonne En Cours et 2 tâches dans la colonneTerminé.

À la fin de mon itération, toutes mes tâches sont dans la colonne Terminé.

Je peux le représenter autrement de cette façon:

Mon CFD à la fin de l’itération ressemblera donc à ceci:

Mon CFD me permet d’avoir un historique des items qui ont bougé sur le tableau pendant l’itération. C’est le premier avantage comparativement à un sprint burndown.

Noter qu’on est aussi en ligne avec la première propriété de la méthode Kanban: Visualize the workflow.

Lire le travail en cours (WIP)

La deuxième propriété de la méthode Kanban est Limit Work-In-Progress (WIP). Dans l’introduction précédente, nous n’avions pas mis de WIP dans notre tableau. On a donc eu environ 6 tâches sous la colonne En Cours pendant toute l’itération. Le CFD nous le montre à la fin de l’itération.

Si on avait assigné un WIP de 2 tâches dans la colonne En cours, on aurait alors eu un CFD avec l’apparence suivante:

La barre rouge qui représente les tâches En cours ne sera jamais plus épaisse que 2 tâches puisque le WIP de cette colonne est 2 tâches.

Un système Kanban en santé aura de minces barres de couleurs. Lorsqu’une barre de couleur grossit, c’est un indicateur qu’il y a quelque chose de bloqué dans cette colonne. On appelle ça un goulot d’étranglement.

Identifier les goulots d’étranglement

Dans le CFD suivant, j’aurais tendance à fouiller ce qui bloque dans la colonne En cours puisque la couleur rouge commence à prendre trop de place face aux autres couleurs. Dans ce cas-ci, je n’ai probablement pas défini de WIP sur ma colonne En cours.

Une fois que l’équipe se définit un WIP pour la colonne En cours, cela ne veut pas dire qu’elle n’aura plus de goulot. Dans le CFD suivant, l’équipe s’est assignée un WIP de 3 pour la colonne En cours. Remarquer que du lundi au mercredi de la première semaine de l’itération, la barre rouge n’a pas monté. L’équipe était bloquée sur ces tâches. Elle a débloqué à la mi-itération lorsque les tâches 5 et les suivantes ont basculé dans la colonne En cours.

Donc, lorsque la barre (ou les barres) de couleur ne montent plus, c’est un signe que quelque chose est bloqué dans notre système Kanban.

Le CFD nous permet aussi de voir ces goulots d’étranglements sur le long terme. Dans le CFD suivant, il y a eu deux goulots d’étranglements. Puisque la propriété 5 de Kanban nous dit Implement feedback loops, on tiendra sûrement une rétrospective si ces goulots se répètent pour en identifier la cause.

Lire le lead time

Pour se comprendre face au terme lead time, je vais prendre la définition de la Lean Kanban University:

This refers to the time a item takes to progress through a process, and is often used synonymously with the more specific customer lead time.

À mes yeux, cela veut dire le temps entre lequel je place une demande dans une liste jusqu’à ce qu’elle sorte de mon processus.

Le CFD nous permet de lire le lead time pour chaque demande. Dans notre introduction, toutes nos tâches sont entrées dans notre système Kanban le mercredi, la première journée de l’itération.

La deuxième tâche a donc un lead time de 3 jours. Elle est entrée le mercredi et en ressort lundi (3 jours = jeudi, vend, lundi)

La sixième tâche a un lead time de 7 jours. Elle est entrée elle-aussi le mercredi. Elle est sortie le dernier vendredi de l’itération (7 jours = jeudi, vend, lundi, mardi, merc, jeudi, vend)

Dans un système Kanban où de nouveaux items entrent pendant que d’autres sortent, le CFD aura l’apparence suivante:

Mon lead time pour mes tâches sera:

• 2 jours (jeudi, vend) pour la 2ième tâche qui entre dans mon processus
• 3,5 jours (lundi, mardi, merc + 0,5 jours) pour la 8ième tâche qui entre dans mon processus
• 4 jours (mardi, merc, jeudi, vend) pour la 11ième tâche qui entre dans mon processus
• 3 jours (jeudi, vend, lundi) pour la 14ième tâche qui entre dans mon processus

Lire le cycle time (temps de cycle)

La définition du temps de cycle, selon le glossaire de la Lean Kanban University, est:

Most often this refers to the lead time through the “operational” part of the process (measured from when work starts until it is ready to be delivered),

À mes yeux, le temps de cycle est le moment entre l’instant où on se met à réaliser une tâche jusqu’à ce qu’elle sorte du processus. En d’autres termes, c’est le volet opérationnel du lead time.

Revenons au graphique précédent pour y lire le temps de cycle des demandes 2, 8, 11 et 14.

On remarque que le temps de cycle est toujours plus petit que le lead time de la demande.

Lead time = Temps d’attente dans le backlog (ou autre queue de priorisation) + temps de cycle

La conclusion est que le lead time et le temps de cycle se lisent de façon horizontale sur le CFD. Le WIP se limit de façon verticale.

Prédire la fin du projet avec un CFD

Bizarrement, j’ai trouvé peu d’information chez les experts Kanban à propos de la reddition de compte lorsqu’on emploie la méthode Kanban. Si on veut utiliser la méthode Kanban comme façon d’exécuter un projet, il faudra s’outiller en conséquence pour informer (et rassurer) les gens qui paient pour le projet.

Option 1 – Utiliser la pente sur la barre Terminé

Dans mon projet, j’ai 10 items à faire. Mon projet commence un mercredi. Les premiers items sont terminés le lundi. J’ai donc une pente de 2 items / jour pour ma zone Terminé (partie verte du graphique ci-bas).

Si je continue cette pente vers la droite, je prédis que mon 10ième item sera terminé vendredi prochain. Cette approche se complique plus le projet avance. Prenons le CFD suivant qui montre un projet qui roule depuis deux semaines. Si le client m’aurait demandé la date de fin du projet à plusieurs moments depuis les deux dernières semaines, je lui aurais donné plusieurs réponses. Mes droites pour ma zone verte change de jour en jour.

Cette première approche pour prédire la fin d’un projet est faible mais au moins, elle permet d’avoir une conversation avec l’équipe.