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

La transformation des équipes ou organisation vers les méthodes agiles et particulièrement Kanban ou ScrumBan prend de plus en plus d’ampleur dans l’écosystème des organisations.

Cette adhésion, ou la volonté d’expérimentation, des organisations aux méthodes Kanban est portée par la capacité d’un système kanban à produire des métriques permettant une visibilité forte sur la capacité des équipes projet à tenir leurs promesses.

Une des métriques les plus intéressantes reste sans conteste la prédictibilité, dont vous pouvez retrouver un retour d’expérience dans l’excellent article de Yannick Quenec’hdu « La Prédictibilité au pays de kanban« .

La prédictibilité est mesurable via deux métriques, le Cycle Time et le Débit des Cartes.

Dans cette première partie, je vous propose une description du calcul de la prédictibilité de votre projet, au travers du Cycle Time.

Le Cycle Time

Le Cycle Time, aussi appelé «Temps de Cycle», permet de mesurer la durée nécessaire à la réalisation d’une fonctionnalité, en partant des travaux d’ingénierie jusqu’à sa validation, en passant par la phase de tests.La date de démarrage du Cycle Time est la date de passage vers les activités d’ingénierie. La date de fin est la date à laquelle la fonctionnalité a été validée, selon la « Définition de Terminé » (Definition of Done).

Exemple :

• Etant donné un développeur devant réaliser la fonctionnalité « En tant que client, je dois m’authentifier afin d’accéder à mon compte dans l’application www.myprofil.fr » ;
• Lorsqu’il prend en charge le développement au 09 Juillet 2013
  Et que la fonctionnalité est validée le 15 Juillet 2013 (selon la Définition de Terminé) ;
• Alors le Temps de Cycle (Cycle Time) est de 5 jours.

Le Cycle Time moyen, sur une période, est obtenu par la somme de tous les Cycle Times de la période, divisée par le nombre de fonctionnalités concernées.

Exemple :

• Cinq (5) fonctionnalités ont été réalisées, sur une somme de Cycle Time de 31 jours.
• Cycle Time Moyen = 31/5 = 6,20 jours/fonctionnalité.

La Prédictibilité par le Cycle Time

La force d’un Management Visuel et d’un processus Kanban est de permettre une mesure de la prédictibilité d’une équipe, au travers des éléments suivants :

3 niveaux de Prédictibilité sont mesurables dans un projet IT :

• Niveau 1 : Temps nécessaire à la réalisation des Stories restantes ;
• Niveau 2 : Temps nécessaire à la réalisation des potentielles anomalies issues des Stories restantes et du ratio d’anomalies générées par Story Done.
• Niveau 3 : Temps nécessaire à la réalisation des anomalies restantes.

Ces 3 niveaux sont représentés par les formules suivantes :

Ces 3 niveaux sont associés afin de permettre la mesure de la prédictibilité d’un projet IT, au travers de la formule suivante :

A partir de cette formule, nous pouvons définir le nombre de mois nécessaires à la réalisation des Cartes restantes, Stories et Anomalies, avec une estimation du nombre de nouvelles anomalies pouvant potentiellement apparaitre et basé sur le Ratio.

De là, à partir de la date de mesure de la prédictibilité, de la date de fin de Release fixée (TTM : Time To Market), nous obtenons la date d’atterrissage estimée et ainsi le nombre de jours d’écart qui sera positif si la date d’atterrissage est inférieure au TTM et négatif dans le cas contraire.

Ci-dessous un exemple de calcul de prédictibilité par le Cycle Time :

La mesure de la prédictibilité par le Cycle Time est un élément important dans l’estimation du temps nécessaire à la réalisation des Cartes Kanban restantes, une aide à la priorisation et à la prise de décisions, dont l’objectif reste de permettre à l’équipe Kanban de tenir ses promesses. Néanmoins, il peut arriver que la mesure de la prédictibilité par le Cycle Time soit faussée, pour les raisons suivantes :

• Mesure des cycle times réalisée de façon non rigoureuse ;
• Cartes Kanban se retrouvant bloquées en phase de développement en raison de problèmes techniques ou d’adhérences externes ;
• Tout autre blocage non imputable à l’équipe de développement.

Dans l’exemple suivant nous pouvons vérifier l’impact d’une mesure faussée du cycle time, que ce soit sur les Stories que sur les Anomalies.

1. La prédictibilité précédente mesurée correspond à celle incluant les perturbations rencontrées dans le traitement des Stories et des Anomalies et fournissant un retard de 21 jours estimé ;
2. La nouvelle mesure de prédictibilité va porter sur un cycle time des Stories et des anomalies, auxquels les jours de blocage ont été retirés.

Nous constatons un écart de 4 jours entres les deux mesures.

Conclusion

La prédictibilité par le cycle time est un outil puissant dans la mesure de la capacité d’une équipe à tenir ses promesses. Elle est une aide forte à la prise de décisions.

Néanmoins, celle-ci se doit d’être utilisée avec discernement et tenir compte des perturbations pouvant influer sur son résultat.

Une analyse reste toujours nécessaire afin d’identifier les causes ayant permis d’obtenir cette mesure et l’impact des perturbations sur celle-ci.

Les mesures présentées dans cet article sont issues d’un projet réel. Les perturbations rencontrées l’ont été sur une instabilité de l’environnement de développement au démarrage du projet. Cette instabilité a été résolue au bout de 2 à 3 semaines, ce qui a permis de débloquer les cartes en attente et également de réduire le cycle time par la suite. C’est sur la base de ce constat qu’il a été décidé de mesurer non pas un nombre de jours d’avance ou de retard, mais une tendance. Dans ce cas précis, la tendance affichée, avec ou sans perturbation est un potentiel retard par rapport à la date de fin de Release fixée, mais qui reste absorbable, soit par une purge des cartes non prioritaires sur cette Release, soit par un renfort raisonnable de l’équipe de développement.

Cet article vous a décrit une manière de mesurer la prédictibilité de votre projet, au travers du Cycle Time. Dans la seconde partie, je vous présenterez comment effectuer une mesure de prédictibilité au travers du débit des cartes kanban.