Il était une fois un projet IT en Kanban (Episode 3 : Tenez vos promesses avec la prédictibilité)

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 :

• Il était une fois un projet IT en Kanban (Episode 1) : Du Story Mapping au Kanban) ;
• Il était une fois un projet IT en Kanban (Episode 2 – Part I) : Indicateurs Graphiques ;
• Il était une fois un projet IT en Kanban (Episode 2 – Part II) : Mesurer la performance du système avec les KPI ;
• Il était une fois un projet IT en Kanban (Episode 3) : Tenez vos promesses avec la prédictibilité;
• Il était une fois un projet IT en Kanban (Episode 4) : Améliorer la qualité de vos Stories ;
• Il était une fois un projet IT en Kanban (Episode 5 – Partie I) : Gérer les obstacles – La fiche Kaizen ;
• Il était une fois un projet IT en Kanban (Episode 5 – Partie II) : Gérer les obstacles – Le Kata ;
• Il était une fois un projet IT en Kanban (Episode 5 – Partie III) : Gérer les obstacles – Le A3 Problem Solving ;
• Il était une fois un projet IT en Kanban (Episode 6) : Suivre les adhérences externes.

Ce troisième épisode porte sur l’apport des indicateurs mesurés dans la capacité d’un système kanban à être prédictible.

« C’est bien votre Kanban, mais comment je fais pour planifier mon projet ? ». Cette phrase revient souvent dans la bouche des Managers, sur les projets que j’accompagne vers une transformation Agile en Kanban.

Les DSI, après avoir rêvées devant les bénéfices de l’Agilité, ont maintenant besoins de résultats tangibles et pérennes auxquels les Burndown Chart et Vélocité ne peuvent répondre seuls.

Cela me rappelle l’époque des débuts de l’informatique en France où les « bidouilleurs » étaient les Rois, ensuite le besoin de professionnalisation a amené la mise en place de normes et pratiques de gestion de projets qui ont produit des effets positifs, dans un premier temps, avant d’être écrasées par la lourdeur des processus.

Aujourd’hui c’est au tour de l’Agilité d’évoluer et d’apporter aux Managers et aux équipes Agiles les éléments de visibilité nécessaires au suivi de la performance et au pilotage des projets.

Préambule

Je suis Consultant Agile Xebia et j’interviens actuellement dans l’accompagnement d’un grand groupe vers une transformation Agile à grande échelle, basé sur Kanban, depuis plus de 6 mois.

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)».

Le 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)», ainsi que l’ensemble des indicateurs (KPI) nous permettant de mesurer la performance de notre système « Il était un fois un projet IT en Kanban (Episode 2 – Part II : Mesurer la performance du système avec les KPI) ».

La prédictibilité

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

Dans de précédents articles j’ai décrit en détail le processus de calcul de la prédictibilité, via le Cycle Time et le Débit :

• Mesurer la Prédictibilité en Kanban – Part I : Le cycle time
• Mesurer la Prédictibilité en Kanban – Part II : Le Débit des Cartes

Que cela soit via le Cycle Time ou bien au travers de la mesure du Débit des cartes kanban, la prédictibilité reste sans conteste un atout essentiel dans la capacité d’une équipe à mesurer la capacité de son système à tenir ses promesses.

Dès les premières semaines d’un projet, les éléments mesurés apportent une aide importante dans la prise de décisions.

Contrairement à des projets plus « classiques », la planification et l’identification de la date d’atterrissage estimée ne se fait plus par une estimation subjective ou non du reste à faire, par les développeurs ou au travers d’abaques plus ou moins pertinents. La prédictibilité se base sur une mesure factuelle du temps nécessaire à la réalisation d’une carte kanban et du nombre de cartes réalisables par semaine. À ces constats s’ajoute une prise en compte de la capacité fournie par l’équipe pour réaliser ces cartes et celles projetées sur la suite du projet.

Le projet pilote de notre transformation à grande échelle a été l’occasion de mettre en œuvre ces principes. En voici un retour d’expérience :

1. Une semaine après le démarrage du projet, nos indicateurs de prédictibilité indiquent un retard prévisionnel de plus de cent jours, sur les cartes restantes à réaliser ;
2. Une analyse des causes racines de ce retard potentiel (au travers d’un A3) met en lumière une instabilité des environnements de développement, rendant quasiment impossible une livraison régulière des fonctionnalités de notre produit ;
3. Une action urgente de stabilisation de l’environnement de développement est réalisée dans les deux jours suivants ;
4. Une simulation du cycle time et du débit idéal est réalisée et permet de définir les objectifs de réalisation, afin de tenir les engagements de livraison ;
5. Un suivi hebdomadaire des indicateurs est mis en place, en présence du ScrumMaster, du Product Owner et de l’équipe en charge des tests.

Les décisions prises suite aux réunions de suivi des indicateurs ont permis un renforcement des équipes de tests et de développement, une réduction du cycle time de sept à quatre jours et une augmentation du débit de trois à plus de dix cartes par semaine.

Le résultat de ces actions, réalisées grâce à une vision régulière et factuelle de la santé de notre système ? Une livraison de notre produit avec un jour d’avance et une satisfaction importante du métier, dans la capacité de l’équipe à tenir ses promesses et à livrer un produit de qualité.

L’utilisation de la prédictibilité, dans l’assistance à l’équipe à tenir ses promesses, a également été un élément important dans l’amélioration de la communication entre les différents acteurs du projet (Métier, Product Owner, Delivery, Tests) et dans la satisfaction globale de l’équipe.

Néanmoins, la prédictibilité 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 ces mesures et l’impact des perturbations sur celles-ci.

L’essentiel reste donc bien de mesurer, non pas une date d’atterrissage au jour près, mais bien une tendance de la performance de notre système kanban et la capacité de l’équipe à tenir ses promesses.