« Mesurer et gérer le flux ». Derrière cette proposition se cache la troisième des six pratiques de la Méthode Kanban, telle que proposée par David J. Anderson.

Dans ce second article de ma série consacrée à la description des KPI Agile, je vais vous décrire les principaux KPI utilisés en Kanban et vous présenter le fichier que j’ai mis en place pour effectuer ces mesures, plus quelques autres…

Le premier article, était consacré aux principaux KPI mesurés sur un mode Scrum. Vous pouvez le consulter ici.

Les principaux KPI Kanban

Le Cycle Time

Le Cycle Time ou « Temps de cycle », permet de mesurer le temps que met un élément de travail (on parle de « Carte » en Kanban) pour passer d’une étape à l’autre d’un système Kanban (représente le flux d’activité d’une équipe ou d’un processus. On parle également de Value Stream).

Quel Cycle Time mesurer ?

Le cycle time est multiple dans un système Kanban et peut être mesuré sur chaque étape du flux de travail. Vous pouvez également effectuer une mesure sur un ensemble d’étapes de votre flux, correspondant à une phase d’activité particulière, comme décrit dans l’exemple ci-dessous.

Personnellement, lorsque j’accompagne une équipe, je commence toujours par faire une mesure de Cycle time par phase, plutôt qu’étape par étape (souvent fastidieuse pour une équipe qui débute). Pour cela, je propose à l’équipe de saisir sur la carte Kanban, 3 dates : la date de début de travail, la date de début de la phase de réalisation, la date de Done. Cela me permet de mesurer le temps moyen que met une carte pour passer la phase de montée en maturité et ensuite combien de temps elle met pour passer la phase de réalisation, jusqu’au Done.

Par la suite, dans le cadre de l’amélioration continue du système kanban, on pourra rentrer à l’intérieur d’une phase et analyser le Cycle Time de chacune des étapes, afin d’identifier celles faisant perdre de l’efficience au système. Par exemple, lorsque le Cycle Time moyen de la phase de réalisation est trop important, l’équipe vérifie si celui des files d’attente n’est pas trop important. Si c’est le cas, alors nous devons peut-être revoir la limite haute mise sur l’activité ou vérifier pourquoi l’activité suivante ne permet pas d’avoir un débit plus fluide, comme par exemple des anomalies récurrentes en phase de tests qui ralentissent le rythme et nécessitent une action d’amélioration de la qualité.

Cycle Time, classe de services, granularité et prédictibilité

La Méthode Kanban n’est pas réservée qu’aux projets IT, mais à tous les types d’activité, comme les RH, la Comptabilité, Le Marketing, le Commercial. Idem pour les activités IT de maintenance ou d’architecture. Les travaux menés dans chacune d’elles sont variables et ne peuvent être mesurés par un Cycle Time identique. Vous pouvez donc utiliser ce que l’on nomme les classes de services, en regroupant les cartes Kanban par type de travaux et en mesurant un Cycle Time moyen pour chaque groupe.

Pour ce qui concerne les projets logiciels où les travaux restent assez similaires, j’utilise le Cycle Time pour aider l’équipe à affiner le poids de chaque carte Kanban (l’effort à fournir), afin d’arriver à une granularité suffisamment fine pour rendre les travaux prédictibles. La première fois que j’ai mis en oeuvre cette méthode, c’était sur l’un des projets pilote de la transformation Agile AXA France et cela a permis, en plus de la qualité de l’équipe, de livrer le produit avec 1 jour d’avance sur le timing et un niveau de qualité maximal.

Le Lead Time

Le Lead Time, ou temps de passage, permet de mesurer le temps que va mettre un élément de travail pour traverser l’ensemble des étapes d’un workflow (ce que l’on nomme généralement la value stream), du début de son traitement jusqu’au Done (fin de travail).

Sur la réalisation/gestion d’un produit ou d’une activité, vous pouvez avoir plusieurs value stream et donc plusieurs Lead Time à mesurer. Si je prends l’exemple de l’industrie automobile, les value stream pourraient être :

• Prise de commande en concession ;
• Fabrication du véhicule en usine ;
• Livraison du véhicule en concession ;
• Administratif (carte grise, plaque, …) et Remise des clefs au client.

Chacune de ces value stream représente un processus particulier, gérée par des acteurs différents. La somme des Lead time permet de mesurer le temps total entre la commande d’un élément et sa mise à disposition de l’utilisateur final.

Le Lead Time est une aide pour rendre plus efficient le flux d’activité, mais est également une aide à la priorisation des travaux à faire entrer dans le(s) système(s) Kanban. Il permet également d’aider à une meilleure gestion de la capacité à faire de l’équipe.

Le Débit des cartes

Cet indicateur permet de mesurer le nombre moyen de cartes qui est traité par période (semaine, jours, mois), au sein d’un système Kanban.

Le débit des cartes est une aide à la mesure de la prédictibilité d’un système, à la condition d’arriver à avoir un niveau de granularité suffisamment fin entre les cartes. Le débit peut également être mesuré par classe de service.

Auprès des équipes que j’accompagne, je propose toujours une mesure du débit, par semaine, associée à un travail sur l’amélioration du niveau de granularité des cartes. Au bout de quelques semaines (en général 8 semaines) nous arrivons à un débit moyen régulier, permettant une bonne prédictibilité qui devient une aide à la priorisation des travaux.

La Loi de Little

A partir de la mesure du Débit des cartes et le Lead Time moyen vous pouvez mesurer l’encours moyen (Work In Progress – Travail En Cours) se trouvant dans votre système Kanban.

La formule est la suivante : WIP = Débit * Lead Time

La Loi de Little a pour objectif de réduire les files d’attente, en identifiant le WIP idéal devant se trouver dans le système, pour que celui-ci soit stable et permette une livraison régulière et rapide des éléments de travail.

Vous pouvez consulter le page wikipédia, plus détaillée, ici.

L’Efficience (Valeur Ajoutée)

L’efficience (ou Valeur Ajoutée) représente le temps passé sur une carte, dont son déduits tous les temps d’attente. Par exemple, pour une carte ayant un Lead Time de 20 jours, si la sommes des temps d’attente (file d’attente, buffer) est de 11 jours, alors l’efficience de la carte est de 9 jours, soit 45%. L’objectif de l’équipe, dans le cadre de son processus d’amélioration continue, sera de chercher les moyens de réduire ces temps d’attente et améliorer l’efficience des cartes traitées.

Le Ratio Anomalie/Carte Done

Cet indicateur permet de mesurer le niveau de qualité des cartes validées (Done). Nous allons mesurer le nombre d’anomalies identifiées suite à la livraison de ces cartes et ainsi définir le nombre moyen d’anomalies qui est généré à chaque fois qu’une carte est Done.

Cet indicateur est très important, à la fois pour mesurer le niveau de qualité des cartes et également pour la mesure de la prédictibilité. Généralement, on mesure toujours la date d’atterrissage sur les cartes restant à réaliser ou en cours de réalisation. Là, on va ajouter à ces cartes le ratio du nombre d’anomalies moyen qui est généré par carte réalisée . Cela donne une estimation plus précise et met en avant l’importance de la qualité dans la maturité des cartes et dans les pratiques d’ingénieries logicielles.

Mon outil de mesure des KPI Kanban

En 2013, j’ai participé au lancement de la transformation agile d’AXA France, sous la direction experte de Yannick Quenec’hdu. J’avais en charge l’accompagnement de l’un des projets pilote. Nous avions proposer une démarche basée sur ScrumBan, associant les pratiques Scrum (rôles, certains cérémonials) et Kanban. A cette époque, nous n’avions aucun outil digital pour gérer et mesurer le flux, ce qui a eu l’avantage de mettre en place un management visuel efficace, avec une équipe distribuée, mais qui rendait les mesures complexes à réaliser. J’ai donc décidé de créer un fichier excel permettant d’effectuer toutes les mesures des KPI que nous voulions utiliser. Ce fichier a été d’une grande efficacité dans la mesure de l’efficience du système et dans l’aide à la décision des membres de l’équipe. Ce fichier n’a pas cessé d’évoluer depuis. Je me propose de vous le présenter rapidement.

Gérer le flux d’activité

Le premier onglet permet de gérer le flux d’activité, en contenant une image du management visuel de l’équipe.

Les zones en couleur représentent les différentes étapes du système Kanban. A chaque fois qu’une carte passe dans une nouvelle étape, la date de passage est saisie dans la colonne correspondante. Ces informations seront ensuite utilisées pour effectuer les mesures des KPI présentés précédemment.

Paramétrer votre flux

La première difficulté que j’ai rencontrer est que ce fichier ne pouvait être efficace que s’il était capable de s’adapter au flux de valeur de chaque équipe. C’est pourquoi j’ai créé un onglet de paramètrage, permettant de charger n’importe quel flux venant d’une source externe comme Jira par exemple.

Il suffit juste d’extraire les informations nécessaires au calcul des KPI et les importer dans le premier onglet. Vous n’avez alors qu’à indiquer dans quelle colonne se trouve chaque information. Les données obligatoires sont en rouge dans l’image ci-dessus. Vous pouvez mesurer jusqu’à 2997 lignes.

Le Happy board

Le Happy Board permet d’afficher une information synthétique des principaux KPI, ainsi que du niveau de maturité agile de l’équipe et de sa santé.

Le troisième indicateur (en partant de la gauche) affiche le nombre de cartes qui auraient pu être réalisées si le ratio d’anomalies avait été de zéro.

Le quatrième indicateur indique la marge entre la date d’atterrissage estimée et la deadline fixée sur le projet (ici une avance de 9 jours). Une valeur négative correspond à un retard potentiel.

La mesure des KPI et de la prédictibilité

Cet onglet permet d’effectuer les opérations suivantes :

• Partie basse : mesurer les indicateurs décrits plus haut, à la fois sur 2 cadences, pour comparaison, et sur une période donnée que l’utilisateur peur saisir à sa convenance.
• Partie haute : Effectuer une mesure de prédictibilité, soit par le Cycle Time moyen, soit par le Débit de carte par semaine. L’utilisateur a la possibilité d’effectuer différentes simulations. Je ne conseille pas d’utiliser la mesure de prédictibilité par le Cycle Time, tant que celui-ci n’est pas stabilisé, c’est à dire tant qu’il y a une forte disparité entre les Cycle Time des différents types de cartes. Pour vérifier cette granularité, j’utilise le tableau ci-dessous, qui indique le CT par taille de carte.

On voit, sur cet exemple, que le nombre le plus important de cartes (user stories, dans notre cas) se situe entre un effort de 2 à 5 points et que le Cycle Time moyen est entre 6,64 et 9,22 jours ouvrés, soit un écart de 2,58 jours ouvrés. Ici, le niveau de granularité est assez bon pour permettre une mesure de prédictibilité via la Cycle Time et une comparaison avec la prédictibilité par le Débit. Dans notre exemple, cela fait une date d’atterrissage entre le 17 février et le 7 mars, soit une marge d’erreur de 13 jours ouvrés.

Vous le voyiez, il ne s’agit pas d’une science exacte, mais surtout d’une estimation permettant à l’équipe de prendre les décisions adéquates pour la tenue de leurs objectifs.

La parking lot des Features

Cet onglet permet de mesurer l’avancement des Features (macro-fonctionnalités) inscrites dans la Release (la version) de notre produit. L’avancement est à la fois global et par cadence.

C’est un indicateur qui a été particulièrement apprécié par les Managers et le Product Owner, notamment pour avoir une vue synthétique de l’avancement des travaux sur la Release.

Le Control Chart

Ce graphique permet d’afficher, par jour, les cartes Done avec leur Cycle Time correspondant. Ici nous avons choisi de mesurer le Cycle Time sur le phase de réalisation. Sur ce graphique, on voit parfaitement un CT perturbé sur le début de la Release, avec des livraisons espacées  ensuite. L’équipe a ensuite progressivement réussi à réduire son CT, qui est devenu moins perturbé, avec des livraisons régulières et quotidiennes.

Les Entrées-Sorties

Ce graphique permet de vérifier, de façon simple, si le WIP (Work In Progress – Travail En Cours) du système Kanban n’augmente pas de façon trop importante, ce qui aurait pour risque de perturber la capacité de l’équipe à délivrer rapidement de la valeur, avec le niveau de qualité attendue.

On mesure donc, ici, le nombre de cartes entrant dans le système Kanban (en phase de travail), ainsi que le nombre de cartes sortant de ce système (Done). L’objectif étant, que lorsqu’une carte entre, au moins une carte devrait être sortie. J’y ai ajouté la mesure du nombre de cartes entrant dans le backlog du produit, afin de voir les travaux attendant l’équipe et non encore rentré dans leur système.

Le graphe du débit des cartes

Ce graphique permet de mesurer, par semaine, le débit par type de carte traité, avec une projection sur les cartes restant à faire.

Le Cumulative Flow Diagram (CFD)

Le Cumulative Flow Diagram (CFD) ou Diagramme de Flux Cumulé est un graphique de mesure standard du Kanban. Il pourrait être comparé au BurnUp Chart de Scrum, mais apporte bien plus d’informations.

Il indique le nombre de cartes présentes dans chaque étape du système Kanban, en partant du Backlog et en allant vers le Done. A un instant T, on peut donc savoir :

• Combien de cartes sont dans le WIP
• Le Temps pour une carte de passer d’une étape à l’autre ou pour passer tout le flux
• Le nombre de carte dans chaque étape du flux.

Conclusion

Comme vous le voyez, les KPI Kanban sont une source importante dans l’aide à l’amélioration continue du flux et du travail d’une équipe et également une aide à la prise de décision, afin de permettre à l’équipe de tenir ses promesses.

Ce qui me plait c’est que, contrairement aux KPI Scrum (c’est mon avis), les indicateurs Kanban se basent sur des mesures factuelles du travail de l’équipe et de sa capacité à faire.

Lorsque j’accompagne une nouvelle équipe de développement logiciel, nous débutons toujours avec les pratiques Scrum et durant les premiers sprints, je mesure les KPI Kanban, afin de leur permettre une transition en douceur vers le ScrumBan (lorsqu’elle le souhaite), en ayant des éléments factuels de leur capacité à faire et ainsi pourvoir plus facilement mettre en place des limites et aider l’équipe à mesurer sa performance.

J’espère que cet article vous aura permis d’avoir une meilleure visibilité sur les KPI Kanban et leur utilité. Pour ceux qui souhaitent que je leur présente l’outil que j’utilise, vous n’avez qu’à me contacter via le site http://www.agile4me.com.

Pour aller plus loin …

Voici une liste d’articles sur les KPI Kanban :

Il était une fois un projet IT en Kanban (Episode 2 – Part II) : Mesurer la performance du système avec les KPI

Mesurer la Prédictibilité en Kanban – Part I : Le Cycle Time

Mesurer la Prédictibilité en Kanban – Part II : Le Débit des Cartes

Il était une fois un projet IT en Kanban (Episode 3) : Tenez vos promesses avec la prédictibilité

Retour d’expérience de pilotage en kanban d’une équipe infra, par Laurent Morisseau

Quid de la vélocité en Kanban ?, par Laurent Morisseau

Kanban Key performance indicator, par Yannick Quenec’hdu