« 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 ».
