X — Je ne vais pas y arriver : le contenu que je devais publier à la fin de semaine ne sera pas prêt.

Moi — Est-ce que tu veux qu’on regarde ensemble ? Je sens une point d’irritation derrière cet andon.

X — Tu appelles ça un « andon » ?! Je pensais que c’était plutôt pour les développeurs de l’équipe, quand ils étaient coincés dans leur code et qu’ils appuyaient sur le bouton orange de leur kanban.

Moi — Et pourtant, à chaque fois qu’on me signale un défaut ou un problème, je tente d’en changer l’étiquette dans ma tête : en utilisant « andon », cela me force à aller au bout de la réflexion. Avec un « problème », je me serais arrêté une fois trouvé un palliatif à la situation présente.

X — Ce serait déjà bien suffisant, non ?

Moi — Désormais j’essaie d’en saisir l’opportunité pour aller plus loin. Quand l’appel au secours devient « andon », je dois quitter les habits de pompier. Ça me force à regarder la situation sous un autre jour. Sans oublier de rechercher la cause racine (ce que nous ne savions pas que nous ne connaissions pas) et sans faire l’impasse sur les efforts nécessaires pour que ce problème n’arrive plus.

X — Et dans mon cas, ça donnerait quoi ?

Moi — D’abord t’écouter, probablement utiliser les 5 pourquoi au passage. Ensuite - et dans le meilleur de cas - découvrir qu’il y a un truc qu’on peut tenter pour sauver la publication de ce contenu. Et peut-être revoir le calendrier des publications qu’on a fixé il y a bientôt 6 mois.

X — Tu veux dire qu’on pourrait le mettre à la poubelle, comme ça, simplement parce que je rate une publication.

Moi — C’est peut-être l’éléphant au milieu la pièce : chercher d’abord à faire la bonne chose et au bon moment. Le planning n’est pas à suivre au pied de la lettre systématiquement, surtout si tard après sa mise au point.

X — Oulala, j’ai l’impression que je vais devoir revoir mes conceptions personnelles du kanban ou du Just-In-Time…

Moi — Donc si on estime que ce contenu n’a plus de sens désormais ou qu’on peut faire quelque chose de beaucoup mieux, de plus efficace et percutant, il ne faut pas s’en priver. Je te donne un autre exemple : le « standard », il n’existe que pour être modifié et amélioré. Rien de pire que de produire quelque chose de moins bien : la vérité du Gemba est une bien meilleure boussole que le plan et son cortège de prémisses obsolètes.

X — Tu continues à utiliser des feuilles de papier au mur !? Je pensais pourtant que dans une boîte de logiciels qui promeut la dématérialisation des procédures RH - entre autres - il y avait mieux à faire.

Moi — Je te rassure : ici chacun fait autant de télétravail qu’il le souhaite. On peut dématérialiser autant que nous le souhaitons. Nous avons ainsi deux formes de Gemba que nous faisons régulièrement en ligne et en binôme, le « Gemba code » et le « Gemba kaizen ».

X — Mais alors pourquoi ne pas mettre en ligne ces feuilles ?

Moi — Parce que ces feuilles-là sont d’abord pour moi, quand je prends un temps du recul et de réflexion avec moi-même.

X — Décidément je ne comprends pas : si tu es le seul à les utiliser, ça pourrait tout simplement être un fichier Excel sur ton ordinateur personnel. Même pas besoin de cette couche de complexité qu’on appelle Zoom, Miro, Teams et peut-être bientôt Metaverse.

Moi — Petit hic : prendre du recul derrière un écran est littéralement impossible. Tu seras toujours à 60 cm des pixels lumineux. Je préfère largement pouvoir embrasser tout le mur d’un seul regard et m’avancer au besoin pour explorer une feuille en particulier. Je vais même jusqu’à écrire à la main les résultats que je collecte dans nos différents outils numériques.

X — Dois-je comprendre que tu aimes bien perdre ton temps à utiliser tes petits feutres vert et rouge ?

Moi — Et même le Tippex ! Dans le cas présent, c’est moi qui met les points sur les courbes et qui en efface certain avec du correcteur blanc : l’effet Ikea joue aussi sa part.

X — Un peu comme un tennisman qui joue contre le mur alors : la trajectoire de la balle ne dépend que de son coup initial.

Moi — Effectivement, je n’avais pas pensé à cette métaphore : je m’y retrouve en tout cas. En fait le mur et ces feuilles sont mon espace matériel de Hansei : ce moment d’auto-réflexion pour tenter de comprendre ce qui s’est passé, l’accepter et trouver des ressources pour l’améliorer.

X — C’est marrant que tu aies besoin d’une zone bien physique pour réfléchir : j’aurais cru que tu pouvais faire ça devant ton écran. Un informaticien est plutôt équipé pour ça n’est-ce pas ?

Moi — Et bien non, mes meilleurs moments devant un écran sont plutôt quand je code en pleine concentration. On appelle ça être dans la « zone » mais c’est plutôt que le code coule de source, les doigts tapent plus vite que la pensée, le monde extérieur n’existe pas. L’auto-réflexion, c’est au contraire une bonne tranche de réelle qu’il faut examiner, évaluer et digérer. Ce serait trop facile de l’évacuer en refermant l’ordinateur.

Ressources :

• Compost industriel

X — J’ai corrigé le bug que nous avions identifié : il y avait juste une ligne à changer.

Moi — Alors c’est bon, on peut désormais ajouter ton correctif dans notre dépôt de code source…

X — Pas tout à fait, je n’ai pas encore réussi à faire le test unitaire correspondant.

Moi — Tu veux dire qu’il n’y a pas encore la barre rouge qui se transformerait en barre verte avec le correctif.

X — Oui, c’est ça. Je me disais que vue la trivialité du correctif, on pourrait peut-être s’en passer.

Moi — Mais tu sais pourtant que je vais insister, n’est-ce pas ?

X, rigolant — On ne sait jamais, sur un malentendu…

Moi — Je te propose plutôt d’explorer tout ça ensemble et en détails.

X, avec l’index pointé sur son écran — Regarde c’est là, il suffit de changer précisément ce paramètre : j’avais oublié de le modifier en faisant un copier-coller.

Moi — Et si on regardait autour de cette ligne pour bien comprendre le contexte qui déclenche l’erreur.

X — Je commence à sentir ce que tu veux me montrer : il y a cette variable - l’utilisateur authentifié - qui peut changer radicalement le contexte d’exécution de la méthode.

Moi — C’est peut-être elle qui te bloquait dans ton test unitaire. Est-ce qu’on pourrait le regarder ensemble ?

X — Ben justement, déjà que je m’emmêlais les pinceaux entre le paramètre du code, ceux des tests, celui qui doit déclencher la barre rouge et celui qui déclenchera la verte, je me sens encore plus perdu avec cette nouvelle variable dont il faudrait tenir compte. D’autant plus que je ne l’ai pas encore croisée dans mes projets « mobile ».

Moi — Effectivement entre l’application iOs à laquelle tu participes activement et l’application web que tu re-découvres via ce bug, il y a un gouffre.

X — Et c’est bien dans ce gouffre précisément que je suis actuellement. C’est rageant de s’y sentir piégé alors que - et permets-moi d’insister - le correctif est ultra-simple.

Moi — Mais on perdrait une occasion incroyable de tous progresser au passage. Le logiciel à cause d’un cas qui ne serait pas couvert par un test unitaire, toi à cause d’un défaut de connaissances sur le contexte général d’une session authentifiée dans Opentime, et moi à cause d’un point aveugle sur les gestes indispensables du développeur qui arrive chez No Parking.

X — J’étais loin d’imaginer que cela pourrait avoir un impact sur ton boulot de manager !

Moi — Si je peux faire monter en compétence un débutant plus vite, il fera du meilleur boulot plus rapidement : c’est évident. Mais si en plus je peux supprimer la difficulté qu’il y a à initialiser le contexte de tous les tests de ce type, alors c’est potentiellement tous les développeurs de la boîte qui en profiteront. Y compris les plus anciens qui ont oublié depuis longtemps que ce n’était pas si simple et qui ont appris à faire avec…

X, paniqué — Tu veux me faire modifier tous les tests avec cette « difficulté » dans tout le code d’Opentime ?

Moi — Pas forcément, on va d’abord commencer par apprendre et appliquer le standard. Regardons d’abord comment ce type d’initialisation est réalisée actuellement. Il sera toujours temps ensuite de modifier ce standard si le potentiel d’amélioration est intéressant.

X — J’ai l’impression que les praticiens Lean n’aiment pas trop les plans d’action. C’est pourtant le b-à-ba de la stratégie : d’abord définir les objectifs puis appliquer les bonnes pratiques pour y arriver.

Moi — Parce que tu crois qu’on peut « y arriver » ?

X — Si les objectifs sont clairs, heureusement qu’on peut imaginer « y arriver » ! Sinon on ne fait rien.

Moi — Les objectifs de la maison Toyota aussi sont très clairs : satisfaire chaque client à travers les prismes « sécurité, qualité, délai & coût ». Et pourtant on est bien d’accord qu’ils sont hors d’atteinte.

X — À ce niveau-là, c’est clair : on sait tous que le « zéro défaut » n’est qu’une chimère inaccessible.

Moi — On sait aussi que c’est un challenge qu’on ne peut pas ignorer : aucun client ne souhaite un produit ou un service qui se dégraderait. Il n’y a que les financiers à courte vue pour y voir un quelconque intérêt.

X — Et pourtant ne dit-on pas « move fast and break things » dans la tech ?

Moi — C’est surtout la stratégie des fonds d’investissement, prêts à sacrifier 99% des boîtes de leur portfolio pour qu’un projet cartonne et débouche sur des rendements stratosphériques, propres à effacer toutes les pertes.

X — Mais ça marche !

Moi — Au prix d’un hasard optimiste et d’un incroyable gaspillage quand même.

X — J’imagine que tu penses la même chose des « transformations » dans les grands groupes.

Moi — Tu parles de ces plans à 18 mois ou 3 ans, pour arriver à X% de salariés en moins et Y% de CA grâce à des formules dans un tableur Excel et de jolies transitions sur une présentation en format paysage ?

X — Je sens surtout poindre une caricature de quelqu’un qui ne les a pas vécu de l’intérieur : on parle de monstres organisationnelles de plusieurs milliers de personnes, compliqués à manoeuvrer et longs à la détente. Si tu n’as pas un plan précis en tête, tu vas te casser les dents.

Moi — Fondamentalement, le Lean prend le contre-pied total : il cherche à créer et à entretenir le mouvement. Pas à atteindre un état idéal, fixe et stable, encore moins par une grande transformation big-bang. Le pari fondamental qu’il fait est double. D’abord qu’on ne peut pas maitriser l’univers extérieur. Par exemple, et sauf avantage indu, il y a un prix de marché pour tous les achats, valables pour tous les concurrents : il faut faire avec. Et ensuite qu’il faut de la stabilité interne pour répondre à ces changements externes.

X — On n’est pas si loin du « moat », ce fossé infranchissable qui protégera l’entreprise des aléas et de la concurrence : ne s’agit-il pas du graal pour n’importe quel business ?

Moi — Au prix d’être totalement submergé le jour où la digue cède…

X — Mais n’est-ce pas la même contradiction quand tu évoques une quête de stabilité dans un monde volatil ?

Moi — Les plus belles boîtes Lean que j’ai eu l’occasion de visiter avaient toutes un point commun : si tu y retournes un mois plus tard, il y a déjà des choses qui ont changé. L’esprit Kaizen est visible : on cherche à améliorer le travail (à la fois les produits et les outils de production) en permanence, par petites touches réfléchies. Et je peux te garantir que c’est loin du plan d’action. Quand tu le pratiques, ça devient même assez fun : pouvoir suivre ses intuitions avec une bonne boussole, c’est assez exaltant. Et les outils du Lean te fournissent cette boussole, à la fois précise et radicale. Reste à apprendre à la lire.