Kanban tour d'horizon par Laurent Morisseau au CARA Lyon

Coach et formateur Kanban, Laurent Morisseau nous a présenté mardi 6 novembre les principes de Kanban lors d'une session du CARA Lyon.  Fort de son expérience il est également l'auteur du livre  "Kanban pour l'IT"

Les slides de sa session sont disponibles ici. Comme j'ai trouvé sa présentation très intéressante, voici mes notes sur son intervention

Kanban ? 

Kanban n'est pas une méthode agile ni une méthode de gestion de projets. Ce n'est pas non plus une  méthode faite uniquement pour gérer des tâches. C'est plutôt une méthode de conduite au changement se basant sur l'amélioration des processus.

La cible d'amélioration est le lean. L'enjeu est de faire travailler tous les acteurs ensemble. Que ce soit le user, le métier, le dev, la qualité, l'exploit....

Avec les méthodes classiques on  travaille en mode push.. alors qu'ici on est en mode pull c'est le développeur qui vient chercher de nouvelles specs auprès de l'analyste par exemple une fois qu'il a terminé ses tâches.

Un système kanban et un système tiré par les éléments de travail (les kanbans, les étiquettes) qui sont en nombre limité.

Le changement doit se faire en douceur. La gestion des tâches est assez simple alors que la conduite du changement n'est pas toujours simple. Il faut respecter l'organisation déjà en place et faire du changement en douceur.

Les pratiques

• Visualiser
• Limiter le travail en cours pour passer d'un mode push a pull
• Mesurer et gérer le flux de travail
• Rendre explicite les règles de gestion DoD definition of done
• S'améliorer de manière collaborative.

Tout ça en suivant une démarche en mode pdca pour s'améliorer (conception, mettre en oeuvre, étudier, apprendre et s'améliorer)

Conception
Il faut identifier les phases qui permettent de modéliser les différentes étapes entre le client et les utilisateurs finaux. On est dans la définition des processus.

Il faut allez vers un système en mode pull.

A chaque étape on aura des étiquettes (les kanbans) qui ne pourront pas dépasser une certaine limite (pas plus de x tâche en cours en même temps). Si je suis au niveau n-1 et que j'ai fini, il faut que le niveau n libère une tâche.

Dans lean on parle d'efficience des systèmes. Temps moyen que mettent une story, un élément de travail pour parcourir le système sur le temps total. Généralement il met autour de 6%. 90%de temps à attendre. Il faut essayer de limiter ces temps d'attente pour être plus efficace (Just In Time).

Mettre en oeuvre
Au quotidien l'équipe gère son flux de travail. Contrairement à Scrum on ne fait pas le tour des personnes mais des éléments en ne s'arrêtant que sur les points de blocages. Cette organisation permet d'augmenter le nombre de participants à ces points.

Avec ce système de seuil supérieur on peut arriver à des blocages. Si l'on veut être strict une fois la limite atteinte, on s'arrête. On doit agir sur ces blocages...pour essayer de s'améliorer. Les équipes bloquées peuvent essayer d'aider les équipes autour pour les aider à avancer .

L'équipe doit suivre la capacité au quotidien ce qui va lui permettre de passer à la partie étude

Étude

Le WIP (work in progress) d'aujourd'hui est le meilleur indicateur pour définir la capacité de demain. 

Quand on commence on peut arriver a un système globalement saturé ou tout est bloqué. Si des tâches prioritaires doivent être effectuées que  faire?  On peut avoir aussi bien avoir des problèmes en entrée mais aussi à l'intérieur du système.

Il ne faut pas grand chose pour passer d'un système chargé a un embouteillage (exemple des autoroutes). Si on met trop de chose le débit va baisser. La réponse peut être trouvée dans la théorie des files d'attente. Le coach ou le manager doit détecter ces situations et essayer de donner du mou en priorisant les étiquettes, en mettant plus de personnes....

Le système peut être aussi saturé localement (présence d'un goulet d'étranglement). Que faut il faire? Doit on commencer de nouvelles taches malgré la limite ? La théorie des contraintes peut apporter des solutions. On peut mette en place par exemple des buffers (zones tampons) ou les tâches seront stockées en attendant leur traitement...

On peut également être dans le cas où le système est trop variable. Les temps de réalisation changent sans arrêt...  Pour le suivre on peut suivre chaque carte en regardant le temps qu'elle a passée dans le système et se focaliser sur les cartes qui sont en dehors des limites.

Il existe beaucoup de modèles pour essaye de s'améliorer... le lean, options réelles pour aller plus vers de la planification JIT.

Apprendre et s'améliorer
On va ajuster le système, affiner les processus, les limites, la granularité des cartes....

Il y a des modèles de conception qui émergent (couloirs, files d'attentes, buffer, tableau a deux niveaux....) et des modèles de collaboration (auto organisation, décentralisation de la prise de décision, équipe propriétaire de son processus, fusion des petites équipes pour une gestion plus souple)

Contextes de clients ayant adopté Kanban

Laurent a terminé sa session en nous donnant des cas où le Kanban s'applique particulièrement bien

• Organisation en silo d'une DSI ayant besoin de livrer plus rapidement (site web marchand)
• Logiciel en production qui évolue beaucoup pour faire converger des équipes de PMA et dev
• Équipe multi activités devant gérer plusieurs projets en même temps