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 ».
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.
Résultats de l'exploration du bac rouge chez No Parking en novembre 2020
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.
Vue sur Euratechnologies depuis les bureaux de No Parking
Ma première lecture Lean fut Implementing Lean Software Development de Mary Popendick : nous étions en 2007 et je n’en avais retiré qu’une idée, celle du flux. À l’époque, l’équipe technique de No Parking se sentait à l’étroit dans les itérations « agiles » : pourquoi attendre la fin du sprint en cours, une semaine le plus souvent, avant de pousser en production une correction de bug ou une demande client ? Nous avions déjà des outils de tests unitaires et de déploiement automatisé et le rythme imposé par le sprint ressemblait trop à un carcan. Avec la bénédiction du Lean, nous avons donc mis à la poubelle les itérations. Et nous en avons profité pour appeler nos post-its des « kanbans » et notre tableau au mur un « management visuel », avant de nous auto-déclarer « praticiens Lean ».
Ce n’est que 10 ans plus tard, que j’ai décidé de m’y replonger et d’y entraîner toute l’entreprise. No Parking allait bien (la société était toujours rentable) mais j’avais l’impression qu’on ronronnait un petit peu : l’énergie des débuts me manquait alors que l’envie de franchir un cap était encore présente. Lors de ma colonie de vacances annuelle pour informaticiens, j’ai repensé à ces confrères passés par la case Lean et je suis tombé sur une vidéo de Theodo : il était plus que temps de creuser un peu plus.
Je prends donc contact avec un premier coach Lean (ce sera Régis) : sous sa houlette, je replonge dans le Gemba. Dès la première journée, je redécouvre l’importance des 5 pourquoi et du lead time. Au fur et à mesure, nous mettons en place un certain nombre de routines : certaines sont quotidiennes (comme le petit train avec 6 tickets terminés ou l’exploration d’un problème interne), d’autres hebdomadaires (tel l’objectif d’un nouveau client signé par semaine) ou annuelles (un kaizen pour chacun).
En parallèle, j’entame une grosse acculturation livresque (qui continue encore) :
Chaque lecture - ou presque - est l’occasion de comprendre un nouvel aspect du Lean et de tester des trucs dans l’équipe. Ainsi les tableaux de management visuel se sont enrichis avec l’avancement des kaizens individuels (grâce au livre de Isao Kato et Art Smalley), puis avec le takt produit (grâce à celui de Cécile Roche et Luc Delamotte) et encore avec les lignes parallèles du macro-planning d’Opentime (grâce à celui de James M. Morgan et Jeffrey K. Liker).
Dans ma manière d’apprendre, un deuxième point important est d’intégrer un « groupe de pratique ». Pour approcher cette nouvelle communauté, il y a bien sûr les évènements physiques comme le Lean Tour à Lille (en 2018 et en 2019), le Lean Summit à Lyon (en 2018), les séminaires « Lean en France » à Paris ou les visites du Cercle de l’Excellence Opérationnel des Hauts-de-France. Mais bien d’avantage, il y a les rencontres, les échanges avec d’autres praticiens qui tentent d’explorer le même chemin, parfois avec un peu d’avance ou dans un autre domaine. Avec souvent la simplicité d’entendre « ma porte t'est ouverte quand tu veux » : leur Gemba est aussi une inspiration.
Reste qu’il y a un passage obligé qu’on appelle « Senseï » dans la communauté Lean. Elle - puisque dans mon cas il s’agit de Sandrine - vient m’ouvrir les yeux sur le seul Gemba qui compte pour de vrai, le mien. Et nous repartons de ce terrain, toujours : une réclamation d’un utilisateur, une visite chez un client, un bug en production ou un retard de livraison servira de point d’entrée pour toujours améliorer la qualité, les délais, la satisfaction. On appelle « faire l’hélicoptère » ce yo-yo incessant entre le micro des expériences de terrain et le macro de la stratégie, de la vision, des valeurs et du marché. Surtout, il faut apprendre à lâcher prise, faire confiance à ses équipes et laisser la « magie » du Lean opérer. Chez nous, cette magie s’appelle désormais les 32 heures pour tout le monde.
Reste qu’il faut faire les premiers pas.
Pour le premier je conseille Le Gold Mine, un récit lean . Le roman - écrit à quatre mains par un vétéran du Lean en France (Freddy Ballé) et son fils, écrivain et initiateur de l’Institut Lean France (Michael Ballé) - vous fera découvrir les concepts de base du Lean dans une forme agréable, avec même une dose de suspense. Et attention vous risquez même d’enchaîner rapidement avec la suite, The Lean Manager !
Le deuxième pourrait être The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer : il est en anglais (pas si facile quand on est franco-français, mais personne ne vous a dit que le Lean était facile), il parle de Toyota (c’est quand même avec eux et au Japon, à 豊田市, que l’histoire à commencé) et je ne l’ai pas lu (mais avec sa structure en liste, il devrait être assez digeste pour passer à l’action).
Et le troisième sera The Lean Sensei. Il devrait vous convaincre de chercher enfin un - ou une - Senseï, de le solliciter et de lui faire confiance avant d’appuyer sur l’accélérateur.
Depuis le 1er juillet 2019, tous les salariés de No Parking en CDI depuis au moins un an peuvent poser chaque semaine un jour plus. Et donc travailler 32h tout en conservant l’intégralité de leur salaire. Pour l’instant il s’agit d’une expérimentation d’un trimestre (jusque fin septembre 2019 donc) mais c’est surtout un nouveau pas vers le grand objectif que la boîte s’est fixé en 2018 : offrir à toute l’équipe des semaines de 4 jours sans perte de salaire, et surtout à qualité de service égale pour tous les clients.
Pour y arriver, nous nous sommes appuyés sur le Lean : une démarche d’apprentissage fondée sur la satisfaction des clients et le respect des équipes. Cela passe par un produit de qualité (dans notre cas, c’est Opentime bien sûr avec ses 37342 tests unitaires), par des salariés mis en condition de réussir (aussi bien leur kaizen personnel que la production au quotidien et les objectifs de la structure) et par une formation de terrain (à commencer par celle du dirigeant sous la houlette d’une senseï). Rendez-vous dans quelques mois pour vérifier si nous avons transformé l’essai.
Pour rester en contact avec tout ce qui se dit ici, la manière la plus simple reste de s'abonner par email. Et promis, on garde la liste pour nous, et uniquement pour nous.
