X — Je suis tellement content qu’on puisse se voir pour notre premier gemba de l’année : j’ai déjà commencé à travailler sur mon kaizen annuel et je suis impatient de te montrer ce que j’ai déjà fait.

Moi, emballé — Super, moi aussi j’aime bien sentir l’énergie d’une nouvelle année et d’un nouveau kaizen. Alors pour qu’on soit bien aligné, quel est le problème qu’on souhaite craquer avec ton kaizen ?

X — « Comment mieux outiller les développeurs ? » Avec comme point de départ les procédures d’import : quand un nouveau client arrive sur nos systèmes, il faut ajouter toutes ses équipes, tous ses projets, etc. On doit pouvoir faire mieux qu’un script fait à la main pour chaque cas.

Moi — Et qu’est-ce que tu as fait alors ?

X — J’ai commencé par renommer le dossier « cli » en dossier « imports » : au moins c’est plus clair dans mon esprit. Et puis j’ai créé une nouvelle méthode dans notre bot qui permet de définir plus précisément le client quand on est prêt à faire l’import sur les serveurs de production. Je m’étais brulé les doigts sur cette étape précise quand j’avais eu mon premier (et dernier d’ailleurs) import à faire.

Moi — Ou la la, c’est peut-être allé un peu vite en besogne. Est-ce que tu t’es posé la question pourquoi le dossier s’appelait « cli » ?

X, désarçonné — Est-ce si important ? Je sais qu’il sert pour les imports !

Moi — Est-ce que tu sais à quoi correspond l’acronyme CLI dans le jargon informatique ?

X — « Command Line Interface » : c’est une interface en mode texte qui permet de lancer des scripts ou des programmes, souvent d’assez bas niveau, typiquement par des développeurs ou des administrateurs-systèmes.

Moi — Et alors qu’y a-t-il dans ce dossier « cli » ?

X — Tu veux qu’on aille voir maintenant ? Moi, je souhaitais juste te montrer mon dossier « imports » et surtout les évolutions que j’ai apporté à notre bot.

Moi, essayant de ne pas paraître trop cassant — Oui.

X, après avoir ouvert son ordinateur — Alors, c’est facile : des scripts, pour certains accompagnés de fichiers Excel en plus.

Moi — Et à quoi ça te fait penser ?

X — J’imagine que les scripts avec un fichier Excel correspondent aux imports. Mais pour les scripts seuls, aucune idée.

Moi — On continue à creuser alors ? On les ouvre ces fichiers ? Peut-être qu’on comprendra quelque chose.

X — Donc : des modifications en masse d’affectations à des projets, de niveaux d’accès ou de responsabilité, des archivages d’utilisateurs ou de dossiers, et même un cas de modification automatisée de la configuration. Il y a un peu de tout !

Moi — Et alors ?

X, surpris — C’est beaucoup plus vaste que les imports que j’avais en tête !

Moi — Et alors ?

X, dépité — Mon dossier « imports » ne sert à rien. Et j’imagine que pour mes évolutions sur le bot, c’est pareil.

Moi — On aurait effectivement pu commencer par explorer comment sont faits les imports actuellement, poser la question à ceux qui en ont fait dernièrement, documenter précisément l’ensemble du processus, tenter de le répliquer. On aurait alors eu un standard à améliorer par la suite.

X, surpris — Je n’avais jamais imaginé qu’un kaizen implique d’aller voir des gens spécifiquement. J’ai toujours pensé qu’il s’agissait d’un outil de développement individuel et personnel.

Moi — Ne t’inquiète pas, tu n’es pas le premier à avoir une conception erronée d’un outil Lean. Malheureusement… Mais revenons à nos moutons, est-ce que tu sais qui a fait les dix derniers imports ?

X — Ça risque d’être compliqué : déjà moi, j’ai du mal à me souvenir de ce que j’ai fait la semaine dernière. J’imagine qu’aucun membre de l’équipe ne saura me répondre précisément.

Moi — Est-ce que tu as déjà parlé aux pièces ?

X, interloqué — […]

Moi — Pardon, je m’emballe. Est-ce que tu as déjà parlé avec le dossier « cli » ? Je suis sûr qu’il aurait des choses à te dire.

X — Et comment veux-tu que je lui parle ? Il n’est pas connecté à ChatGPT à ce que je sache.

Moi — Certes, mais je crois qu’il peut répondre quand on lui pose des questions qu’il comprend. Par exemple avec un git log.

X — Ah ah, c’est sûr qu’avec une telle commande, ça devient évident. N’importe quel répertoire peut répondre puisque Git stocke toutes les modifications. C’est donc ça « parler aux pièces » ?

Moi, évasif — Entre autres, entre autres…

X — C'est curieux : tu as l'air de tenir énormément à la formation au sein de ton équipe, mais d'après ce que j'ai compris, un seul d’entre eux aurait suivi des sessions « officielles » de formation depuis presque un an.

Moi — C'est parce que l'apprentissage réel implique un vrai problème et du temps pour soi. Si le problème n’est pas réel, la formation ne servira qu’à briller en société, et pas à autre chose : tu n'apprendras rien.

X — Mais pour apprendre, il y a sûrement de la valeur dans les répétitions des tâches au quotidien : je pratique l'aïkido depuis deux ans, et je peux te garantir que nous faisons les mêmes techniques encore et encore. J’ai même l'impression de m'améliorer.

Moi — J'imagine que tu as changé de point d’attention au fil des ans : peut-être que c'était les mains et les bras au début, et peut-être les pieds ou les hanches maintenant.

X — C'est vrai : notre sensei semble toujours avoir un truc différent à montrer pour chacun d'entre nous. Pour moi, il s'agit généralement de me rapprocher du uke. C’est d’ailleurs assez incroyable : il sait vraiment repérer les petits détails dans la pratique de chacun.

Moi — Et ces étapes qu’il te suggère de travailler chaque semaine, sont-elles de plus en plus difficiles à mettre en pratique ?

X — Je vois où tu veux en venir : chacune peut effectivement être déstabilisante. Quand il met quelque chose de nouveau dans ma tête, tout devient plus difficile et j’ai souvent l’impression de régresser alors que j’essaye juste d’incorporer ce nouveau paramètre dans mon geste. C'est vraiment dur. Mais de temps en temps, il y a un déclic et le mouvement se met en place.

Moi - C'est le vrai problème auquel je voulais en venir : dans le monde du business, il y a aussi des tonnes d’étapes à franchir les unes derrières les autres. Doubler le bon et diviser par deux le mauvais est une bonne étape pour plonger dans le Lean.

X — Est-ce l'ambition que vous fixez à vos collaborateurs ?

Moi - Au fil des ans, j'ai découvert que de tels objectifs chiffrés pouvaient être très intéressants pour l'équipe technique. Et que même, « on va jusque zéro » était encore meilleur.

X — N'est-ce pas décourageant ?

Moi — C'est la raison pour laquelle nous limitons habituellement nos efforts de kaizen dans le temps chez No Parking : après un an, chacun est libre de s'attaquer à un nouveau problème épineux. Bien sûr il peut aussi reprendre le même kaizen s’il le souhaite.

X — D'accord : je commence à comprendre cette notion de « vrai problème ». Mais peut-on revenir sur la partie « temps pour soi » : je pensais que le Lean était vraiment une question de travail d'équipe.

Moi - C'est là que mon rôle de manager prend toute son importance. D'abord, je m'assure que chacun a bien le temps de travailler sur son kaizen. Je fais un gemba avec chacun d'eux toutes les trois semaines : c'est une façon de montrer que je me soucie d'eux, d'applaudir leurs derniers succès et de les inciter à aller de l'avant. Et bien sûr, ils doivent - et peuvent - prendre du temps entre chaque gemba pour travailler sur les points durs qu’ils débusquent au fur et à mesure : c’est là qu’ils apprennent. Ensuite, une partie du processus d'apprentissage consiste à réaliser tu as besoin de l'expertise des autres pour construire la vôtre. Chacun découvre qu’il peut s'appuyer sur les connaissances de quelqu'un d'autre pour faire avancer son kaizen : la confiance se met en place quand ton collègue accepte de faire un truc qui te débloque. C’est là que le travail d’équipe émerge à son tour.

X — Je suppose que c'est le concept de nains se tenant sur les épaules de géants issu de l'univers académique.

Moi — Exactement, c'est là que la magie opère : lorsque tu sais que d'autres personnes veillent sur toi pendant que tu tentes de nouvelles choses pour répondre à de bons problèmes.

X — Parce qu’il y a de bons problèmes ?

Moi — En Lean, chaque problème est un cadeau : il faut apprendre à les accueillir avec délicatesse, délectation, dessein et détermination. Ce sont mes 4D. Il y en a d’autres.

Qu'est-ce que le lead time ?

Dans l'univers Lean, le Lead Time ou délai d'exécution est « le temps qui s'écoule entre le début et la fin d'un processus » et chez No Parking, il est au coeur de toutes nos actions !

En quoi le lead time agit sur nos manières de travailler seul ou à plusieurs et que permet-il chez No Parking ?

La réponse, en vidéo !

Une vidéo réalisée par Chloé Philippot, chez No Parking, avec la participation de Laury Henneton, Perrick Penet et Chloé Philippot

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

« Mais comment vais-je faire pour ajuster les priorités ? » C’est par cette question existentielle qu’Ophélie a réagi quand nos tickets ont définitivement mutés et sont devenus des kanbans numériques.

Il faut dire que la dernière transformation avait été la plus radicale : non seulement la « date de lancement » remplacerait la « date de fin » comme tri pour ordonner les tâches de l’équipe technique mais le champ même ne serait plus modifiable une fois la date passée, quand bien même la tâche n’aurait pas été commencée, quand bien même un autre client apporterait une tâche plus urgente ou plus importante. Cette date est bien sûr cruciale : elle correspond chez nous à la date de la demande initiale pour un client externe ou, pour un client interne, à la date à laquelle on anticipe des disponibilités au sein de l’équipe technique. À cause d’une simple remarque d’un Senseï, glissant au détour d’une conversation qu’il ne comprenait pas l’ordre des tickets de chaque développeur, elle perdait la capacité de modifier en continue le planning des tâches de toute l’équipe technique, d’en décaler une ou d’en repousser une autre au gré des demandes pressantes d’un client ou des attentes débusquées chez un prospect.

Il faut dire que les transformations précédentes avaient eu moins d’impact sur elle. Il y avait d’abord eu une autre remarque lors d’un gemba walk avec notre Senseï : « pas de chaîne d’aide, pas de kanban . » Nous avions alors ajouté un bouton « déclencher l’andon » sur chaque ticket. En cliquant dessus, le développeur indique qu’il a besoin d’aide : son responsable est automatiquement affecté au ticket et un message est envoyé sur notre outil de clavardage interne. Ce bouton venait en compléter un autre, « déposer dans le bac rouge » : celui-là permet au développeur de préciser que la demande en cours de traitement est problématique. Il lui permet de matérialiser qu’il faudra revenir sur l’ouvrage afin d’explorer les causes racines du problème.

La liste des tickets passés par « le bac rouge » ou « l’ andon » était devenue une mine d’or pour les « gemba code » : en prenant le temps d’explorer en détail tel ou tel ticket, en explorant finement des lignes d’un fichier de logs ou en décortiquant du code source, les membres de l’équipe technique ont mis en lumière des erreurs de conception, des manques de formation, des écarts de sécurité, des déficits de connaissance. Autant de découvertes qui sont devenues un mur d’amélioration continue où chaque développeur et développeuse peut venir puiser - quand il ou elle passe au bureau.

Un contexte propice pour ces explorations est l’arrivée de PHP8. Cette nouvelle mouture de notre langage de programmation nous oblige à dépoussiérer un grand nombre d’acquis sédimentés. Par exemple quand on a découvert que notre serveur d’intégration continue n’affichait pas les notices, c’était que la procédure pour mettre à jour un serveur n’était plus à jour, pas simplement un fichier d’initialisation de PHP. Ou alors quand un plugin spécifique a commencé à nous transmettre des erreurs, c’était au mécanisme de garantie de comptabilité avec tous les plugins qu’il fallait répondre, pas simplement au client impacté.

Mais c’est en bloquant leur date de démarrage, en matérialisant le lanceur donc, que les kanbans ont débordés de l’équipe technique pour toucher les équipes en prise directe avec les clients et utilisateurs finaux de nos logiciels. Et d’un pilotage opérationnel avec une date de livraison plus ou moins en accordéon, on a basculé à un pilotage par une date de démarrage, gravée dans le marbre. Bien sûr cela fonctionne parce qu’à notre niveau de maturité, on sait qu’une tâche ne devrait pas prendre plus de 8h de travail effectif et que par conséquent une tâche entamée un jour J devait être « à vérifier en production » à J+1. Et désormais on s’assure qu’une tâche plus compliquée que les autres ne glissera plus imperceptiblement jusqu’à la fin du projet : on veut que les problèmes remontent vite à la surface. Et que telle autre autre, plus complexe, ne sera pas laissée au spécialiste de la technologie à mettre en place : on veut que la formation nécessaire puisse s’effectuer au plus près du terrain. En perdant le « choix » de prendre un ticket plus facile ou plus commun, les développeurs gagnent des opportunités de monter en compétence.

Car les kanbans font système : ils sont un véritable cadre transactionnel entre client et producteur, garanti par la réactivité et le soutien du reste de l’organisation. Par son pouvoir révélateur d’écarts et de problèmes en tout genre (la vertu du lead-time), ils impliquent un tissu de confiance entre les partis prenantes et offrent d’innombrables opportunités d’apprentissage.

Bien sûr cette belle mécanique peut s’interrompre à tout moment. Nous avons eu l’occasion de le vérifier quand une développeuse s’est retrouvée en arrêt maladie alors qu’un développeur était contraint de prendre des jours de congés pour s’occuper de son tout petit garçon. Les kanbans ont commencé à se figer, déclenchant des andons automatiques : Ophélie s’est retrouvé au coeur des échanges avec toutes les parties-prenantes. Non pas parce que la tâche était déjà bien en retard mais parce que la date de démarrage était dépassée, soit - du point de vue du client - au moins 24h à l’avance. Le temps de s’accorder avec les uns et les autres et de vérifier les priorités de chacun. Le temps d’exiger de meilleurs outils pour son travail au quotidien. Le temps de construire la confiance au delà de l’équipe, avec les clients et les utilisateurs. Le temps de trouver la pleine mesure de sa fonction, « Customer Success Manager ».