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 un fois un projet IT en Kanban (Episode 1 : Du Story Mapping au Kanban)".
La première partie du second épisode m’a permis de décrire les indicateurs graphiques utilisés dans le suivi quotidien de notre système kanban "Il était un fois un projet IT en Kanban (Episode 2 – Part I : Indicateurs Graphiques)".
La seconde partie de ce second épisode (jusque là vous suivez ? 
) a pour objectif de vous présenter l’ensemble des mesures (KPI) que nous avons mis en place sur notre projet, dans la mesure de la performance de notre système et dans l’aide à la prise de décisions.
Lexique
Afin de permettre une bonne compréhension de cet article, voici d’abord une rapide définition des principaux termes qui seront utilisés dans cet article :
- Carte kanban : 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 total de passage d’une carte dans le 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ée de façon plus granulaire sous forme de Stories.
- Cadence : Période de temps, identique d’une cadence à l’autre, permettant d’effectuer un comparatif de la performance du système entre deux périodes ;
- BDD (Behaviour Driven Development) : Représente schématiquement les tests à réaliser sur une Story. L’objectif est que les développements se basent sur les tests et non plus sur les spécifications.
- Definition of Done (DoD) : Permet de définir les pré-requis à la validation d’une carte kanban, au sein d’une activité. Chaque activité du système kanban est challengée par une DoD ;
- TTM (Time To Market) : Sur notre projet, correspond à la date fixée pour la livraison en Production ;
-
KPI (définition Wikipédia) : (anglais : Key Performance Indicator), sont des indicateurs mesurables d’aide décisionnelle. Un KPI permet de répondre aux objectifs suivants :
- évaluation
- diagnostic
- communication
- information
- motivation
- progrès continu
Préambule
Tout d’abord je souhaitais indiquer que ce qui est décrit par la suite est le résultat du travail d’une équipe de Consultants Xebia (Coachs Agile), intervenant sur cette transformation Agile, qui sont :
- Yannick Quenec’hdu, sans qui rien n’aurait été possible et dont les retours d’expériences sur les KPI et la Prédictibilité en Kanban a été une grande source d’inspiration ;
- Gilles Mantel, qui accompagne Yannick sur le Centre Agile et la mise en place de nos processus ;
- Renaud Chevalier (le bogosse de l’équipe, … après moi
![biggrin]()
) qui a grandement participé à l’élaboration de nos KPI et à la promotion de la vision produit ; - Ludovic Perot et Marc Legardeur, qui accompagnent au quotidien les équipes dans leur transformation Agile.
) qui a grandement participé à l’élaboration de nos KPI et à la promotion de la vision produit ;Le tableau de bord des KPI
Le tableau ci-dessous représente les indicateurs mesurés sur notre projet :
Cliquez sur l'image pour agrandir
Il est découpé en deux parties principales :
- Le suivi des stories fonctionnelles et techniques ;
- Le suivi des anomalies.
Les KPI mises en place permettent une comparaison de la performance entre deux cadences, associée à une mesure de la tendance démontrant une amélioration ou une régression des indicateurs.
Le tableau des KPI contient également une synthèse de la performance des indicateurs mesurés, sur l’ensemble d’une version (Release).
Suivi des Stories fonctionnelles et techniques
Cliquez sur l'image pour agrandir
L’objectif principal de tout projet, qu’il soit Agile ou non, est la création d’un produit apportant une valeur métier (Business Value).
Sur un projet Agile, cette Business Value est portée par des micro-fonctionnalités communément appelées User Story (US).
Ce sont ces US que nous suivons au travers des KPI, mais pas seulement.
Les Users Stories sont des éléments fonctionnels représentant un besoin client, palpables par l’utilisateur final. Néanmoins pour que ce besoin fonctionnel puisse être mis en œuvre, des activités techniques sont souvent nécessaires. Il ne s’agit pas de tâches techniques propres à une User Story, non, celles-là sont à réaliser dans le cadre du développement de l’US, mais d’actions transverses à l’ensemble du projet, telle que la mise en place d’un serveur d’intégration continue, la création d’une architecture ou d’une base de données, …
C’est pourquoi nous mesurons aussi sur notre projet ce que nous appelons les Technicals Stories (Story Technique), même si celles-ci n’apportent pas de valeur métier au sens de l’utilisateur final, mais dont la réalisation reste indispensable à la création de cette Business Value.
Certains vous dirons peut-être qu’une Story Technique ne peut exister et doit être traitée au sein d’une US, mais c’est un débat de méthodologistes dans lequel je n’entrerai pas. Je présente uniquement ce que nous avons mis en place sur notre projet.
Les mesures effectuées nous apportent les informations suivantes sur la performance de notre système kanban :
- La capacité de l’équipe à réaliser les Stories, au travers du Débit mensuel des Cartes kanban ;
- La stabilité du flux d’activité au travers du nombre de Stories en cours (WIP) et entrant dans le système (Accepter) ;
- Le temps moyen nécessaire pour réaliser une Story fonctionnelle ou technique, au travers du Cycle Time (Temps de Réalisation) ;
- Le temps de passage d’une Story dans le système kanban, au travers du Lead Time (Temps de traversée) ;
- La valeur métier produite associée aux Stories fonctionnelles réalisées.
Sur notre exemple, nous constatons une amélioration globale entre la Cadence 5 et la Cadence 6, à l’exception du Lead Time qui a connu une augmentation de 15%. Cela signifie qu’en moyenne les Stories ont mis plus de temps à traverser notre système kanban. Une analyse est donc nécessaire afin d’en identifier la cause et de définir les actions d’amélioration à mettre en œuvre.
La partie "Synthèse", nous donne une vision de l’état de santé de notre système kanban, à un instant T, sur la version complète de notre projet.
Suivi des Anomalies
Cliquez sur l'image pour agrandir
La performance d’un système kanban ne se mesure pas uniquement au travers des Stories embarquées ou réalisées, mais également sur les perturbations apportées par la traitement d’anomalies provenant de cartes validées (Done).
Attention, nous ne traçons dans le système kanban que les anomalies issues de Stories Done et non celles identifiées lors de la phase de Tests. Ces dernières sont corrigées en direct par l’équipe de développement et la Story ne passe à Done que lorsque l’intégralité des corrections a été effectuée et que les critères de la DoD ont tous été respectés.
Les anomalies sont considérées comme un élément de perturbation de notre flux d’activité, car leur arrivée est par définition imprévisible et fait porter un risque sur la capacité du système à les absorber et à l’équipe kanban de tenir ses promesses sur l’objectif fixé.
Les anomalies peuvent aussi mettre en avant un défaut de qualité des développements réalisés et un non respect de la Definition of Done.
Les mesures effectuées nous apportent les informations suivantes sur ces perturbations :
- Le nombre total d’anomalies traitées ;
- Le nombre d’anomalies restant à réaliser dans notre système ;
- Le temps moyen (Cycle Time) nécessaire à la correction d’une anomalie ;
- Le ratio d’anomalie produite par Story Done, ce qui nous renseigne sur le niveau de qualité des Stories, dans le respect des BDD et de la DoD ;
- L’impact financier et humain de ces perturbations (le CJM est ici donné à titre d’exemple et ne reflète pas la réalité, en tous les cas pas en France).
Adapter les limites basses/hautes avec la loi de Little
Cliquez sur l'image pour agrandir
« Comment définir les bonnes limites basses et hautes à appliquer à chaque activité d’un système kanban ? ».
Cette question m’a été posée de nombreuses fois lors de la mise en place du management visuel et lorsque j’expliquais la démarche kanban dans un cadre IT.
J’ai trouvé la réponse dans l’excellent ouvrage "Kanban pour l’IT" de Laurent Morrisseau, qui a été une grande source d’inspiration et de compréhension de la démarche kanban et de sa mise en oeuvre.
Bien que la mise en place des premières limites peut parfois sembler "arbitraire", elle est basée en fait sur des études qui disent qu’en moyenne, une personne ne peut plus être efficace si elle gère plus de 2 sujets en même temps.
Lors de la mise en place de notre système kanban, la limite haute de chaque activité a été donc définie selon la formule suivante : (Nombre d’intervenant sur l’activité * 2) – 1.
Concernant la limite basse, nous avons appliqué la formule suivante : Nombre d’intervenant sur l’activité.
Sur notre activité de développement cela a par exemple donné : (5 développeurs * 2) – 1 = 9 (Limite Haute) et 4 développeurs en pair-programming = 2 (Limite Basse).
Jusque là tout va bien, mais qu’en est-il lorsque les limites ne sont pas adaptées et comment savoir quand les modifier ? La tentation peut être forte de modifier les limites au gré des aléas du projet ou des urgences du moment.
Dans cet objectif d’identifier les limites idéales par activité, j’ai donc utilisé le principe du Cycle Time Moyen et je l’ai appliqué à chaque activité de notre système kanban. Cela m’a permis d’identifier le temps moyen de passage des cartes dans chacune des phases de notre workflow.
J’ai ensuite appliqué la Loi de Little sur chaque activité :
: Temps de traversée moyen (Cycle Time)
: Nombre d’éléments en cours
: Débit moyen
Afin de ne pas utiliser la totalité de la capacité du système, la limite haute a été fixée à 80% de la capacité du système et la limite basse à 20%.
Voici le résultat obtenu au bout de quelques cadences :
Cliquez sur l'image pour agrandir
Cela nous a permis d’affiner notre flux d’activité, en tenant compte non plus du nombre de personnes affecté à chaque phase, mais de leur capacité à faire et de leur disponibilité d’intervention sur notre système kanban.
La limite à 80% de la capacité du système permet d’absorber les éventuelles perturbations et celle à 20% d’assurer un flux continu minimal d’activité.
Le Happy Board
Cliquez sur l'image pour agrandir
Comme vous avez pu le constater, si vous avez eu le courage d’arriver jusque là ;), tous ces indicateurs peuvent devenir vite indigestes pour un Manager ou tout simplement au quotidien pour l’équipe.
C’est pour cela que nous avons ajoutés à nos KPI ce que nous appelons un ‘Happy Board" ou sont affichés de façon synthétique les informations importantes.
L’objectif est de montrer de façon instantanée la santé de notre système kanban, sur les éléments suivants :
- Le pourcentage de Stories réalisées ;
- Le pourcentage de Business Value réalisée ;
- Le niveau de qualité des Stories ;
- Le niveau de maturité de l’équipe sur les pratiques Kanban, issues des audits réalisés au début, à mi-parcours et à la fin de la phase d’accompagnement ;
- Le niveau de satisfaction de l’équipe, mesurée tout au long du projet ;
- Le nombre de jours restant à réaliser sur la version.
Conclusion
L’ensemble des KPI décrit dans cet article nous a permis non seulement de suivre la performance de notre système kanban, mais également de mettre en place les actions d’améliorations de nos processus.
Au bout de quelques semaines (3 à 4), nous avons été en capacité d’adapter nos limites, via la Loi de Little et ainsi améliorer notre flux à 80% de la capacité de notre système.
Tous ces indicateurs représentent néanmoins un état des lieux à un instant T, sur des activités finies. Comment puis-je rapprocher la performance mesurée sur mon système de sa capacité à tenir nos promesses ?
C’est ce que nous verrons dans la troisième et dernière partie de cet épisode, au travers de la prédictibilité en Kanban.