Pilotage en kanban d’une équipe infra

C’est l’histoire d’une équipe infra,

que j’accompagne depuis un an, ainsi que le reste de la société, certaines équipes en Scrum, d’autres en Kanban. Ils font typiquement partis des contextes que j’ai décrit dans un précédent article sur Scrum et kanban. L’équipe Infra a mis rapidement en place un pilotage en Kanban (c’est d’ailleurs celle qui utilise des avatars en lego pour leur tableau Kanban). Je leur avais demandé de suivre les délais de résolution des demandes, avec des cartes de contrôles. Et récemment, je suis revenu pour analyser leurs indicateurs.

Rappel : principe des cartes de contrôles

Les cartes de contrôles permettent de suivre les temps de cycle du système kanban. A chaque nouvel élément (story, bug, incident, …) sortant du tableau, on ajoute le nombre de jours passés dans le tableau sur la carte :             Je me propose d’expliquer pas à pas cette analyse dans cet article, jusqu’à l’identification de leurs classes de service.

Les (belles) courbes de l’équipe infra

Notre équipe infra a un historique de tickets de 10 mois, soit 750 tickets. Son activité est un mélange de support, de projets infra, infra système et maintenance, et diverses autres demandes, qui justifie le choix d’un pilotage en Kanban.   Les difficultés d’analyse de la performance sont les suivantes :

1. Les débits de chaque type d’éléments sont très variables (ils varient de plusieurs de dizaines de %)
2. Les délais de résolution sont très variables, de 0 à 250 jours !

Difficile d’en déduire une performance qui ait du sens … Et pour en convenir, voici les 3 conclusions du Scrum Master quant à l’analyse de ces métriques (l’équipe a commencé sa transformation agile avec Scrum, mais ça c’était avant) :

C’est inexploitable. On s’arrête là sur les métriques. Nous n’avons vraiment aucune règle de priorité / Organisation (Méthode La R.A.C.H.E ?) Il va falloir réfléchir et faire autrement l’analyse.

Du coup, on va plutôt réfléchir et faire autrement

Ça vaut mieux que de baisser les bras maintenant que l’on a un historique. La première étape est donc naturellement :

Première étape : on ne lâche rien

Allez, ce n’est pas parce que ça à l’air un peu compliqué qu’on abandonne, on répète après moi : non, on lâche rien !

Deuxième étape : on change de perspective

Les cartes de contrôles servent à suivre la performance, et non à l’analyser. Pour cela, le graphe de distribution spectrale est plus adapté. Ça fait un peu peur mais en fait c’est assez simple. Son but est de faire apparaître des familles de délais de résolution.

Rappel : principe des graphes de distribution spectrale

C’est un graphique ayant, comme axe des abscisses, les temps de cycle et, comme axe des ordonnées, le nombre d’éléments de travail correspondant. Voici l’exemple que j’utilise dans mon livre Kanban pour l’IT : La distribution spectrale est la signature des temps de cycle (délai) d’un système kanban, de sa performance. L’approche pour analyser cette courbe peut être assez statistique, dans le livre j’utilise par exemple les écarts types. Mais ici, nous allons le faire de manière plutôt visuelle, plus simple. Avec un simple tableau croisé dynamique dans Excel, on arrive très rapidement à ce graphe :

A voir comme cela, c’est déjà un peu plus clair que la carte de contrôle, mais on peut faire encore mieux.

Troisième étape : on cherche les bosses

Le premier constat, qui ressort visuellement du graphe, est le pic de tickets qui sortent dans les 24h (0 jour), sur la gauche du graphe. Normal, l’infra gère du support, donc un flux important d’incidents à résoudre au plus vite.

Une fois identifié ce premier type de tickets, on les enlève du graphe. Cela permet de faire un zoom sur le graphe et d’y voir un peu plus clair (si si…) :

On voit sur ce graphe émerger plusieurs bosses, en commençant par la première pour les tickets de 0 à 6 jours :

Et on enlève les tickets correspondants du graphe pour continuer le zoom et identifier la prochaine bosse. Rince & Repeat.

Chaque bosse représente potentiellement une classe de service. Le graphe laisse apparaître entre 6 et 8 bosses.

Dans cette étape, nous avons essayé de faire parler les chiffres, indépendamment de leur signification pour l’équipe.

Quatrième étape : on s’arrête et on réfléchit

On analyse maintenant les chiffres pour voir si les classes de service qui émergent ont un sens pour l’équipe et les parties prenantes.

La réalité est que les limites des classes de services que l’on a identifiées étaient plus floues que cela. Nous avons figé ces limites après analyse.

Et c’est ce qui va expliquer qu’avec cette équipe, nous n’avons finalement retenu que 5 classes de services. Voici le résultat de cette analyse :

> Moins de 24h : délais ASAP

C’est ce que l’équipe a appelé les « délais ASAP » ; ce sont les tâches urgentes à faire au plus vite, généralement dans la journée (d’où le résultat…).

> De 1 à 6 jours : dans la semaine / En Cours de Sprint

Ce sont les délais des éléments réalisés « dans La semaine / en Cours de Sprint ». Il faut savoir que l’équipe a une cadence de planification calée sur deux semaines. Cette cadence représente son cadre Scrum initial et la cadence de sprint des équipes parties prenantes (les équipes « Produit » Scrum).

Rappel : les cadences font parties intégrantes de Kanban. Elles remplacent l’approche en juste à temps lorsque celle-ci n’est pas adaptée ou non encore mise en place. Mettre des cadences en place avec du Kanban n’est PAS un constat d’échec ou de régression…

Une partie de la capacité de l’équipe est non planifiée pour pouvoir prendre le travail prioritaire au fil de l’eau. Elle se réserve une bande passante. Cette classe de service « de 1 à 6 jours » représente les éléments passant effectivement par cette bande passante.

> De 7 à 17 jours : Prochaine cadence

Ce sont les tâches arrivant en cours d’un sprint mais pouvant attendre la prochaine séance de planification, et qui seront réalisés lors de la cadence suivante.

> De 18 à 37 jours : Dans deux sprints

L’analyse montre que ce sont des tâches qui seront pris dans deux sprints.

> Supérieur à 38 jours : non priorisé / non ready

Et enfin la longue traîne des autres tâches qui ne sont ni priorisées ni ready.

> Le résultat final

Le package de classes de service

Et donc voici la proposition de classes de service que l’on a proposé, très liées à la cadence de planification de l’équipe, ce qui est plutôt normal.

1. Délais « ASAP »
   • < 24 h
   • Bande passante : 22%
2. Délais « Dans La semaine / En Cours de Sprint »
   • 1 -> 6 jours
   • Bande passante : 23%
3. Délais « Prochain Sprint »
   • 7 -> 17 jours
   • Bande passante : 27%
4. Délais « Dans deux Sprints »
   • 18 -> 37 jours
   • Bande passante : 18%
5. Délais « Non priorisé / Non Ready »
   • > 38 jours
   • Bande passante : 10%

Dernière étape : on s’auto-congratule

Oui, parce que ça fait toujours plaisir, et qu’en plus on n’y a pas passé longtemps.

Et la suite ?

Les classes de service sont finalement très liées à la cadence de travail de l’équipe. Les résultats que l’on a trouvés sont donc cohérents et représentatifs de leur activité. Alors qu’initialement le ressenti en interne et en externe était que :

– C’est inexploitable. On s’arrête là sur les métriques. – Nous n’avons vraiment aucune règle de priorité / Organisation (Méthode La R.A.C.H.E ?)

(Personnellement, je ne m’en lasse pas) Et bien, en regardant de plus près, leur système kanban est en fait assez prédictif. Les classes de service sont identifiées. Pour chaque classe, la variabilité est bien moins importante. Le travail suivant consiste à identifier les règles qui permettent de qualifier les demandes dans telle ou telle classe de service. Cela va permettre de s’assurer que l’on tient cette performance, et qu’elle devienne prédictible. Puis d’en discuter avec les parties prenantes (les demandeurs, sponsors, managers) et converger vers leurs signification et utilisation.

Tout ça c’est bien, mais si je ne tiens pas mes engagements ?

Il est clair qu’annoncer qu’il existe une classe de service « ASAP » avec un engagement de 24 heures pour la résolution est un peu ambitieux. Tout d’abord, la performance est basée sur un historique, donc c’est réaliste. Puis, tenir cet engagement nécessite d’avoir identifié les bons critères qui permettent de bien qualifier les classes de service. Partons de cette hypothèse. Malgré cela, il peut arriver que l’on n’arrive pas à tenir notre engagement, que l’on mette 6 jours à débloquer un ticket qualifié ASAP. C’est toujours possible. C’est pourquoi, l’engagement de performance dans le flux ne repose pas sur chaque ticket individuellement mais c’est bien un engagement de niveau de service. Je m’explique. Il faut plutôt lire que les tickets qualifiés ASAP ont une forte probabilité d’être résolus en moins de 24 heures. La performance que l’on va afficher est du type SLA (Service level Agreement), c’est à dire :

Les tickets ASAP sont résolus dans les 24 heures, à 98 % (par exemple), si on n’en prend pas plus que 22% de notre capacité.

L’étape d’après consiste à refaire le travail précédent sur les graphes de distribution spectrale, mais cette fois en isolant chaque classe de service. Alors, on va constater que la performance que l’on a annoncée, « en moins de 24 heures », on la tient effectivement mais dans 98% des cas (toujours le même exemple). Et l’engagement portera sur cette performance : débit, délai, probabilité ; et non sur chaque ticket, car la réalité est plus fourbe que cela.

Bilan de ce retour d’expérience de pilotage en kanban d’une équipe infra

Ce qu’il faut retenir de cette histoire ? C’est une méthode scientifique et forcément très rigoureuse en 5 étapes : Plus sérieusement, on ne change rien (a priori) et ça change tout. Avant, il était difficile d’annoncer un délai, maintenant c’est possible avec un engagement à la clé.  Tout cela, sans toucher au système, mais en le comprenant mieux ! Le bonus : une relation de confiance va pouvoir se remettre en place entre les acteurs et permettent des échanges sereins.