Publié par

Il y a 6 ans -

Temps de lecture 6 minutes

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 :

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 :

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.

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

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

  1. Publié par , Il y a 6 ans

    Bonjour Couthaïer, et encore merci pour la soirée French Kanban User Group, très instructive. La prédictibilité m’a donné à réfléchir. J’ai quelques remarques:

    1. Pour garantir un débit cohérent, la taille des cartes doit être sensiblement le même.
    => Considérer qu’une carte de taille S, L et M est acceptable
    => Opérer un découpage sur les cartes trop grosses (XL et plus).
    ==> On accepte finalement de considérer une carte dans le workflow si sa taille est On est plus dans la « dynamique » car il y a un débit de carte, le travail avance.
    => Il faut bien veiller comme indiqué dans la conclusion à ne pas s’en servir pour calculer une date atterrissage il peut y avoir dans le backlog plusieurs cartes de taille XL qui donneront naissance à une ou deux cartes supplémentaires (de tailles inférieures) sans compter les cartes imprévisibles comme les incidents. Inutile également d’essayer de découper trop tôt les cartes XL.

  2. Publié par , Il y a 6 ans

    Bonjour Sébastien,

    Merci pour tes retours.

    Effectivement, les éléments que tu décris permettent d’arriver à un débit cohérent et exploitable par la prédictibilité.

    Par la suite, une analyse plus fine du cycle time par taille de carte va permettre d’ajuster le niveau d’effort « acceptable » sur une carte, en fonction des objectifs définis et par exemple d’être amené à ne plus accepter les cartes L qui devront être découpées à leur tour.

Laisser un commentaire

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

Nous recrutons

Être un Xebian, 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.