Publié par

Il y a 6 ans -

Temps de lecture 11 minutes

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

Cet article fait partie d’une série intitulée « Il était une fois un projet IT en Kanban », débutée en 2013 et décrivant les différentes étapes de l’accompagnement d’un grand groupe vers une transformation Agile à grande échelle, basée sur la mise en place d’un système kanban.

Cette série comporte les épisodes suivants :

La seconde partie de ce second épisode (jusque là vous suivez ? wink) 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écisionnelleUn 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.

Le tableau de bord des KPI

Le tableau ci-dessous représente les indicateurs mesurés sur notre projet :

TableauKPI.png

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

KPIStories.png

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

KPIAnomalies.png

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

PortfolioCT.png

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é :

formula.png

t.png : Temps de traversée moyen (Cycle Time)

Capture-d’écran-2013-10-09-à-16.38.33.png : Nombre d’éléments en cours

Capture-d’écran-2013-10-09-à-16.38.38.png : 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 :

PortfolioCT2.png

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

Happyboard.png

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.

Publié par

Publié par Couthaïer Farfra

18 années d’expériences, dont 14 années en pilotage et direction de projets Mainframe et NTIC (Forfait, Assistance Technique, TMA, Centre de Services). Depuis 2009, j'ai découvert avec enthousiasme le monde de l'agilité, au travers de la réalisation de projets IT Scrum ou je suis intervenu en tant que Scrum Master et Consultant Agile (Crédit Agricole S.A., GENERALI, Banque de France, CNSA). En 2012, j'ai rejoins la société XEBIA ou j'interviens en tant que Consultant et Formateur (BI-SAM ; Voyage SNCF.com ; SFR ; Française Des Jeux ; Europcar ; AXA) sur les pratiques Agile et plus particulièrement le Kanban.

Commentaire

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

  1. Publié par , Il y a 3 ans

    Merci de me répondre sur la question suivantes.
    Qu’est ce que ça veut dire par les mots : Stories fonctionnelles, Les Users Stories, Business Value réalisée ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.