Chez No Parking, nous travaillons sur la base des valeurs et des outils du Lean : one-piece-flow, jidoka, kaizen, PDCA... et en particulier, les kanbans.

Un kanban c'est quoi ?

En japonais, kanban signifie « étiquette » et chez No Parking, il s'agit de suivre une tâche, une action sur toute sa durée de vie.

Alors comment gère-t-on les kanbans ?

Cette vidéo a été réalisée pour une présentation de Perrick Penet dans le cadre de l'Institut Lean France et devient l'occasion d'échanger sur notre utilisation du lean management et de la gestion des kanbans qui en découle.

Réalisation Chloé, avec la participation de Perrick, Ophélie et Valentin

Courant 2006, nous avons expérimenté au sein de l’équipe les pratiques agiles « au pied de la lettre » : les pratiques de développement hérités d’Extreme Programming déjà rodées (tests unitaires et déploiements automatisés en particulier), on a commencé à systématiser les sprints et les rétrospectives.

Les premiers ont vite disparu : en lisant le livre de Mary & Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, on découvrit une théorie et des arguments pour arrêter les lots de 5 ou 10 jours de développement à pousser en production et dès lors on plongea le cœur léger dans le flux continu. Pas la peine d’attendre la fin de la semaine pour passer en production une correction de bug ou telle nouvelle fonctionnalité, surtout avec notre déploiement automatisé et régulier.

Les rétrospectives ont vécu une mise à l’écart moins glorieuse. Les toutes premières avaient pourtant trouvé un écho pertinent : « enfin du temps pour échanger sur nos pratiques et nos sensations d’équipe ». Mais très rapidement le souffle est retombé : nous n’avions vite épuisé les choses intéressantes à nous dire ces « vendredi après-midi sur deux ». Et faute d’entrain (de clients ?), cette pratique s’est perdue dans les limbes de nos temps de cerveaux disponibles.

Quinze années plus tard, je me rends compte qu’il nous manquait peut-être un « bac rouge » : une liste de problèmes que nous aurions réussi à corriger sur le moment (la base du métier quand même) mais qui méritaient amplement qu’on s’y attarda, qu’on les décortiqua, qu’on les traita à la racine. Non pas pour mieux les corriger la fois suivante, mais pour faire en sorte qu’ils n’apparaissent plus, ni demain ni après-après-demain.

Bien sûr une équipe agile qui utilise la rétrospective pour explorer son bac rouge aura fait le moitié du chemin : un senseï viendrait et demanderait, avec cette fausse naïveté qui masque sa longue expérience de terrain et sa ribambelle d’anecdotes : pourquoi l’équipe attend-elle ce « vendredi après-midi sur deux » pour avoir cette discussion ? Et pendant que l’équipe profitera du silence qui venait de s’installer, le senseï continuera de se demander pourquoi lui, il n’avait pas suivi le conseil de Kent Beck dans le chapitre 19 sur le Toyota Production System de leur Extreme Programming Explained, Second Edition : je vous recommande de commencer par le livre « Toyota Production System » de Taiichi Ohno. Nous sommes en 2020, c'était en 2005.