Les indicateurs kanban sont parfois essentiels dans la création d’un produit en kanban afin de mesurer la prédictibilité, les coûts, le débit voire d’autres éléments. Cela peut vite s’avérer complexe.
Calculez le lead time
Le lead time est le temps que mettra une demande de sa création jusqu’au Done. C’est un élément important car il peut être révélateur de problèmes dans la fluidité de prise en charge des demandes.
Calculez le cycle time
Le cycle time est le nombre de jour où une demande reste dans la partie « work in progress » soit dans le tableau précédent de « in progress » à « done ».
Voici un article complet pour savoir faire de la prédictibilité avancée avec le cycle time :
Article : Mesurer la prédictibilité avec le cycle time
Il est possible par ailleurs de créer plusieurs cycle time différents afin d’affiner vos indicateurs comme le cycle time de maturation des demandes par exemple : on calculera le temps de passage des demandes entre « description » et « todo ».
Cet indicateur peut également être un véritable révélateur de problèmes ou d’amélioration.
Utilisons également le débit (throughtput)
Le débit représente le nombre de demandes arrivées en Done. On peut facilement le représenter en indiquant le nombre total de demandes arrivé en done chaque semaine comme ceci :
Comme vous le voyez, on peut faire une projection en prenant les trois dernières semaines afin de prédire le nombre de demandes Done à l’avenir. En général, je prends uniquement les 3 dernières semaines car l’équipe peut changer (membre supplémentaire ou sur le départ) ce qui aurait un impact sur le nombre de demandes réalisées.
Vous pourrez également faire le même travail en prenant le nombre total de point d’effort arrivé en « Done » à la place du nombre de demande afin de faire une projection sur le nombre de points réalisés.
Nos bugs deviennent un problème
L’avantage d’utiliser ces indicateurs, peut-être révélateur d’un problème grave sur le temps. Le taux de bugs traité devient de plus en plus important et implique de prendre des décisions radicales. En partant du dernier graphique, nous pouvons voir cela facilement :
On comprend vite en voyant ce graphique que le taux de bug augmente et qu’il va devenir problématique si rien n’est fait pour inverser la tendance. Cela peut-être du au manque de tests unitaires ou d’un manque de rigueur dans la qualité du code (voire des tests).
Le diagramme de flux cumulés
Ce diagramme est fort utile car il permet de voir le nombre de demandes qui sont en cours dans chaque colonne du board kanban (de façon cumulée). Voici à quoi peut ressembler un diagramme de flux cumulé aussi appelé Cumulative Flow Diagram (CFD).
Les goulets d’étranglements
Ce diagramme est très intéressant car on peut y voir les goulets d’étranglement au sein de certaines étapes comme ici dans le « in progress » le 14/12. A priori les développeurs ont pris en charge plus de demande que d’habitude sans les terminer. C’est un comportement à risque qu’il faut analyser car si cela continue, on peut se retrouver avec de nombreuses demandes en cours qui ne se terminent jamais.
J’ai vu ce soucis dernièrement et le fait d’avoir 50 choses en même temps fait que les demandes ne se terminent jamais ; évidement cela fait grincer des dents à d’autres niveaux de l’entreprise. Il est impératif d’agir vite quand un goulet d’étranglement apparait et de mettre en place des solutions pour réguler les flux de demandes.
En voyant ce graphique, l’équipe a d’ailleurs travaillé le problème qui est revenu à un flux normal rapidement.
Un backlog qui grossit
Par contre, ce diagramme montre aussi que les demandes s’accumulent et que le backlog grossit de plus en plus avec le temps. Cela montre que l’équipe actuelle n’est pas dimensionnée pour répondre à l’ensemble des besoins.
Mais la stratégie n’est pas forcément de renforcer l’équipe (on en a pas forcément les moyens) mais de mettre des pratiques de priorisation strictes ; en général, les demandeurs comprennent vite qu’une partie des demandes ne seront jamais réalisées.
Le diagramme du Cycle Time by Card (CTC)
Ce diagramme est très intéressant car il impose une rigueur supplémentaire dans la gestion des demandes de votre produit. Nous allons faire un graphique du cycle time de chacune des demandes terminées afin de comparer chacune des demandes entre elles.
Si le cycle time des demandes dépasse 2 fois l’écart type (celui de l’ensemble des cycle time), nous allons analyser si il n’y a pas un soucis dans le développement des demandes. Est-ce que la demande n’était pas trop grosse ? Est-ce qu’il y a eu des interruptions dans le développement de la demande ? Il sera indispensable de s’assurer qu’on aura bien analysé le soucis rencontré pour chacune de ces demandes
Voici comment représenter ces indicateurs kanban :
Il est tout a fait possible d’analyser cela en temps réel pour mettre un point d’attention sur les demandes en « work in progress » qui dépassent de deux fois l’écart type du cycle time afin d’être très réactif.
Conclusion
Nous verrons plus tard d’autres indicateurs kanban mais tous ceux présentés ici devraient vous être d’une très grande aide. N’hésitez pas vous aussi à partager vos indicateurs clés pour analyser le bon fonctionnement ou non du développement de vos produits.
3 Rétroliens / Pings