« [..] éliminer le Muri, réduire le Mura et encourager une approche évolutive du changement« . Voilà comment David Anderson a décrit son intention initiale lorsqu’il a transposé le modèle Kanban vers l’IT (Lean and Kanban Benelux 2011). L’objectif d’un système kanban est donc d’éliminer le gaspillage (Muri) et de réduire les irrégularités du système (Mura).

L’atteinte de ces objectifs passe par un suivi au quotidien du système kanban, afin d’identifier les blocages et goulets d’étranglement et améliorer le système sur le long terme. Le suivi du système se base sur différents indicateurs :

• Indicateurs Graphiques ;
• Indicateurs de performance du système ;
• Prédictibilité.

J’interviens actuellement dans l’accompagnement d’un grand groupe vers une transformation Agile à grande échelle, basée sur Kanban, depuis 4 mois environ.

Dans le premier épisode de la série « Il était une fois un projet IT en Kanban« , je vous ai présenté la mise en place d’un Management Visuel Kanban, depuis la phase de Story Mapping « Il était une fois un projet IT en Kanban (Episode 1) : Du Story Mapping au Kanban« .

Cet article est découpé en deux parties, dont la première porte sur la description des Indicateurs Graphiques utilisés dans le suivi quotidien de notre système kanban et la manière dont ceux-ci nous ont permis d’améliorer la performance des différents intervenants, qui sont les Product Owner, la Qualification et l’équipe de développement.

L’objectif est de vous présenter de façon synthétique les graphiques utilisés sur mon projet. L’explication détaillée fera l’objet de billets dans la série « Le Cockpit Kanban ».

Lexique

Afin de faciliter la compréhension de cet article, voici d’abord une rapide définition des principaux termes qui seront utilisés dans cet article :

• Carte = Représente un élément de travail à réaliser dans le système kanban. Cet élément peut être une fonctionnalité, une action technique transverse ou la correction d’une anomalie ;
• Cycle Time = Correspond au temps nécessaire à la réalisation d’une carte, de la phase de Développement à la phase de Tests inclue ;
• Lead Time = Représente la mesure du temps totale de passage d’une carte dans la système kanban, de son entrée (Backlog) à sa sortie (Done) ;
• MMF = Minimum Marketable Feature. Représente les fonctionnalités minimales à réaliser afin d’obtenir un produit viable et exploitable ;
• Feature = Macro-fonctionnalité, regroupant un besoin fonctionnel pouvant être découpé de façon plus granulaire sous forme de Stories.

Cumulative Flow Diagram (CFD) ou Diagramme de Flux Cumulé

Le CFD permet de suivre l’activité d’un système kanban, au travers de la mesure du nombre de cartes dans chaque activité.

La couche supérieure représente les cartes en entrée dans le système (Backlog) et la couche inférieure les cartes ayant été traitées (Done), selon la Definition Of Done.

Entre ces 2 couches, de haut vers le bas, sont représentées les différentes étapes du processus de réalisation du produit.

L’objectif du CFD est essentiellement d’identifier le travail en cours (WIP), ainsi que les goulets d’étranglement pouvant survenir et ainsi de mettre en oeuvre les actions de réduction de ces obstacles.

Le CFD permet également de suivre le temps de passage des cartes dans le système (Lead Time), ainsi que le temps de réalisation (Cycle Time).

Le dernier élément mesurable sur un CFD est le débit produit par le système, c’est à dire le nombre de Carte Terminée (Done), au travers de la couche Done.

Comment lire un CFD :

• Chaque jour, mesurer le nombre de cartes présentes dans chaque étape de votre système kanban ;
• Reporter ces mesures sur votre CFD, en partant de la dernière étape et en remontant vers l’étape d’entrée de votre système ;
• Une surface avec une épaisseur importante indique un goulet d’étranglement entre deux états du projet ;
• Si l’épaisseur de l’état d’entrée (Backlog) est plus importante que celle de l’état de sortie (Done), cela indique que vous ajoutez trop de travail dans le projet par rapport à la capacité de réalisation de l’équipe. Vous pouvez également suivre spécifiquement ces éléments sur un diagramme d’entrées-sorties comme suit :

Le suivi des  Entrées-Sorties de cartes dans le système kanban donne une vision plus synthétique de la santé de notre système kanban.

La partie IN correspond, à un instant donné, au nombre de cartes présentent dans le Backlog et sur lesquelles aucun travail n’a encore débuté. La partie OUT correspond bien entendu au nombre total de cartes terminées (Done), depuis le début du projet.

Une augmentation du nombre de carte en entrée indique la création d’un goulet d’étranglement et un risque potentiel sur la capacité de l’équipe Kanban à délivrer le produit dans un délai court (Lead Time ; Cycle Time). Le problème peut soit provenir de limites non adaptées à la capacité d’absorption du système, soit d’un obstacle empêchant les cartes de passer à l’étape Done.

Dans notre exemple, vous pouvez constater la génération de trois goulets d’étranglement, dont les causes ont été les suivantes :

• Premier goulet : Les cartes ajoutées dans le Backlog ne peuvent entrer dans le WIP (travail en cours), suite à l’impossibilité de sortie des cartes, sur les 14 premiers jours et cela en raison d’un problème technique. Par effet domino, les cartes en WIP se retrouvent toutes bloquées dans les activités du système, pilotée par les limites hautes.
• Deuxième et troisième goulet : Ces deux goulets ont été provoqués par une surcharge du système en introduisant de nouvelles cartes, sans tenir compte des limites hautes fixées.

Sur la suite de notre graphique, les perturbations ont été résorbées, au travers de la priorisation et de la gestion des limites, ce qui a permis à notre système de retrouver une stabilité de fonctionnement.

Les Cartes de Contrôles Done

Le graphique de suivi des Cartes de Contrôle représente, sur le temps, les cartes terminées, avec leur temps de Cycle (Cycle Time), c’est à dire le délai nécessaire à leur réalisation et à leur validation en phase de test.

Cette représentation a pour objectif d’identifier les cartes ayant été bloquées ou ayant rencontré un délai de réalisation trop important par rapport au Cycle Time Moyen.

Pour ce faire, le graphique contient les éléments suivants :
Courbe rouge = Cycle Time Moyen des Cartes Terminées dans le système. Le Cycle Time Moyen correspond à la moyenne du temps nécessaire à la réalisation, de la phase de Coding jusqu’à la phase de Tests.
Courbe verte = Cycle Time Moyen + Ecart-Type des Temps de Réalisation (Cycle Time) des Cartes.
Courbe violette = Cycle Time Moyen + 2*Ecart-Type des Temps de Réalisation des Cartes.
Dans le cadre de ce système, seules les cartes dépassant deux fois l’Ecart-Type (Courbe Violette) font l’objet d’une analyse plus approfondie sur les raisons du retard.

Le suivi des Cartes de Contrôles permet également de définir des objectifs de Cycle Time et d’en suivre la mise en oeuvre.

Dans l’exemple présenté, sur la gauche du graphique, un constat a été fait sur un Cycle Time Moyen trop important pour permettre un respect du TTM projet (Time To Market). La mise en oeuvre des actions de résolution de cet obstacle, réalisé via un A3 (le traitement des obstacles via un A3 sera décrit dans l’épisode 3 de cette série), a permis de constater visuellement sur la droite du graphique une amélioration du Cycle Time des Cartes et une baisse significative du Cycle Time Moyen.

Les Cartes de Contrôles WIP

Une variante au suivi des Cartes de Contrôles a été mise en place sur ce projet, afin de permettre l’identification rapide des cartes en cours de réalisation, dont le temps de cycle venait à dépasser l’Ecart-Type.

L’objectif est de permettre une réactivité plus forte de l’équipe sur les cartes mettant en risque le Cycle Time Moyen, contrairement au graphique standard des Cartes de Contrôle qui représente un état Terminé. Ces deux graphiques sont des outils puissants pour réduire la variabilité des cartes sur un projet.

Les cartes dépassant deux fois l’écart-type sont à traiter en urgence, car elles mettent en risque la performance du système. Les cartes dépassant l’écart-type sont à surveiller.

Premier constat

Le Cumulative Flow Diagram, le suivi des Entrées-Sorties et le suivi des Cartes de Contrôle contribuent à la mesure de la performance de notre système kanban, permettent la mise en place de nos objectifs de réalisation (Cycle Time, Lead Time) et de l’ajustement des limites basses et hautes des activités, afin d’améliorer le flux d’activité et réduire les goulets d’étranglement.

De nombreux éléments peuvent venir perturber la performance de notre système, notamment les anomalies identifiées, soit en Production, soit en phase de Recette des Cartes Done.

Les graphiques suivants vont nous permettre de mesurer cette perturbation, au travers du suivi du Débit des Cartes, du suivi des anomalies entrant dans le système et la progression du MMF (Minimum Marketable Feature).

Histogramme du Débit

L’histogramme du Débit, permet de donner une représentation du nombre de Cartes réalisées (Done) par semaine.

Cette représentation est associée aux éléments suivants :

• En violet = Le nombre total de cartes dans le système kanban ;
• Colonnes bleues = Le suivi du débit cumulé des Stories, réalisé par semaine ;
• Colonnes rouges = Le suivi du débit cumulé des Anomalies, réalisé par semaine ;
• En bleu clair = Permet de projeter le débit prévisionnel sur les semaines à venir, tenant compte des cartes restantes et du débit moyen hebdomadaire.

L’histogramme présenté apporte les informations suivantes :

• L’objectif de débit idéal a été tenu jusqu’en semaine 14 et ensuite dérape sur la dernière semaine, en raison d’une augmentation du nombre d’anomalie ;
• La projection du débit prévisionnel, sur les cartes restant à réaliser indique un dépassement de 2 semaines par rapport au TTM fixé (semaine 15) ;
• L’absence de débit sur les 2 première semaines indique une perturbation du système, ce qui a provoqué une analyse des raisons du blocage, via un A3 (cette notion sera décrite dans le prochain épisode). Ce débit a ensuite progressé continuellement jusqu’à la semaine 15.

Histogramme des Anomalies

L’histogramme de suivi des anomalies permet de donner une représentation hebdomadaire des anomalies générées dans le système kanban.

Les informations données par ce graphique sont les suivantes :

• En bleu = Le nombre d’anomalies corrigées (Done) ;
• En rouge = Le nombre d’anomalies en cours de traitement (WIP) ;
• En vert = Le délai moyen de résolution des anomalies (Cycle Time des Anomalies) ;
• En violet = Le ratio du nombre d’anomalies générées par Carte Terminées (Done), représenté sur un axe secondaire.

Les anomalies ne doivent pas être considérées comme un élément de perturbation du projet. La détection des anomalies tout au long du projet, et leur correction et garant d’une qualité importante du produit lors de la phase de Recette Métier et lors de la livraison en Production.

A contrario un ratio important d’anomalie par Story terminée est le signe d’un niveau faible de qualité du produit réalisé. Dans notre exemple, ce ratio est légèrement supérieur à 0,30, ce qui démontre une bonne qualité des développements, s’appuyant également sur l’association des Stories à des tests au format BDD (Behavior Driven Development). Ce sujet fera l’objet d’un prochain article.

Avancement du MMF

Ce graphique permet un suivi de l’avancement des User Stories et du Reste à Faire, sur les Features faisant partie du Minimum Marketable Feature (MMF) de notre projet.

Le MMF a été identifié lors de la phase de Story Mapping, et a permis dans un  premier temps d’identifier les Feature (ou Epic) minimales à réaliser afin d’obtenir un produit exploitable et apportant une valeur métier suffisante à une utilisation commerciale du produit..

La seconde étape a permis de définir les micro-fonctionnalités (Users Stories) associées à chaque Feature et d’affiner notre MMF. C’est cette dernière priorisation que nous visualisons sur notre graphe, en suivant l’avancement de nos Stories par Feature et en permettant au Product Owner de prioriser les activités de réalisation d’un ensemble cohérent, au travers d’une vision produit.

Conclusion

L’objectif du suivi de ces représentations graphiques reste bien de réduire, voir d’éliminer le gaspillage (CFD ; IN-OUT), le Muri et d’améliorer la régularité du système (Cartes de Contrôles, MMF, Débit), le Mura, au travers d’une amélioration du flux d’activité, d’une réduction des goulets d’étranglement et d’une réduction de la dette technique (perturbations).

La seconde partie de notre épisode portera sur l’utilisation des mesures issues de notre système kanban, au travers des KPI et leur utilisation dans la prédictibilité, la définition des objectifs et même leur capacité à identifier les limites basses et hautes à appliquer sur chaque étape de notre système kanban.

 

Note de l’auteur : J’ai à l’origine créé cet article sur le blog Xebia ou vous pouvez le retrouver.