Immersion dans une entreprise Lean du monde numérique – chapitre 4

Dans ce 4e volet, Catherine Chabiron découvre comment se déroulent les gemba walks dans un environnement digital, où les flux de transformation et les données sont par essence cachées dans les ordinateurs.

C’est ma quatrième incursion sur le gemba dans le groupe Theodo. Dans les trois premiers articles de cette série, nous avons pu voir comment l’entreprise a amélioré les délais de prise en charge des clients, en réfléchissant efficacement à la valeur pour le client, et en réussissant à recruter et fidéliser les talents. Si vous suivez depuis le début la progression de mon enquête, j’espère que vous ressentez comme moi le fun du gemba.

Parmi les nombreux défis que doit relever un groupe digital en croissance rapide comme Theodo, il y a la façon de parcourir « l’atelier » et de s’informer sur la conception du code et sa production, alors que toutes les informations sont cachées dans les ordinateurs. Le but de ma visite en compagnie de Marek, Directeur Technique de BAM, est de comprendre comment Theodo tente de surmonter cet écueil. BAM est une des premières filiales de Theodo (elle a été fondée en 2014), et comme la plupart de ses entreprises sœurs dans le groupe, elle a bénéficié d’une croissance à deux chiffres en 2020.

Marek me raconte pourquoi il a cofondé BAM : « Theodo était et est toujours très focalisé sur les applications Web, mais nous voulions aussi développer notre expertise sur les applications mobiles. Nous avons eu le pressentiment qu’être capable de développer aussi bien sur iOS (Apple) que sur Android nous permettrait de faire la différence. »
Marek m’explique qu’à l’époque, une application devait être développée deux fois – sous iOS et sous Android – et cela demandait des compétences en développement très différentes. Puis, Facebook a développé ReactNative, ce qui a permis de réduire considérablement la complexité de tels projets. BAM a saisi l’opportunité et a appris le métier. Ils sont dorénavant en train de faire la même chose avec Flutter, développé par Google, et améliorent également leurs propres compétences sur iOS et Android.

Dans les applications mobiles, la concurrence est rude, et l’avance que BAM avait prise sur ce marché en 2014 s’est déjà réduite. Les concurrents peuvent être des entreprises comme BAM, mais c’est surtout le talent de leurs développeurs (en CDI ou en prestation) qui fait la différence. « Nous pouvons très bien tenter de recruter les stars du domaine, au risque de les perdre plus tard pour une raison ou une autre, » explique Marek, « ou bien nous pouvons nous entraîner à apprendre le métier en continu et parfaire notre technique afin de toujours garantir la qualité et la fiabilité. C’est la voie que nous avons choisie. »

Marek m’indique un graphique sur le mur de son bureau, qui montre le nombre de jours vendus divisé par le nombre de bugs sur cette même période : l’équivalent d’une mesure de PPM ou, plutôt, le nombre de jours travaillés sans générer de bugs. Ces chiffres se sont améliorés récemment, mais c’est un combat sans fin.

---

ALLER SUR LE GEMBA DANS LE MONDE DE LA TECH

 « En tant que CTO (Chief Technical Officer), aller sur le gemba est une des contributions les plus importantes que je puisse faire » dit Marek. « Le marché bouge très rapidement et les CTOs sont confrontés à trois problématiques majeures : rester au plus proche du code et de la technologie malgré la croissance de l’entreprise ; développer et aligner l’équipe en permanence et gérer la crise permanente entre la demande et la capacité. Chaque faux pas peut mettre le business en péril. »

Vous vous demandez peut-être ce que la croissance de l’entreprise a comme effet concret dans la vie de Marek. Il y a quelques années Marek pilotait son équipe en direct, mais dorénavant, il y a entre un développeur et lui, un Team Leader, qui rapporte à un Engineering Manager, qui lui-même rapportera bientôt à un Engineering VP fraîchement recruté, qui rapportera à Marek.

En tant que CTO, Marek a développé sa propre vision des gemba walks : « C’est l’observation silencieuse d’un travail en cours, quel qu’il soit – écrire du code, concevoir de nouvelles fonctionnalités ou l’architecture sous-jacente, réaliser la maintenance, superviser les déploiements. » (Voir ci-dessous quelques exemples des notes prises lors de ses observations.)

L’observation (qui dure une vingtaine de minutes) est suivie par un échange. Marek m’explique : « Il ne s’agit pas d’un audit, mais plutôt un moyen d’évaluer le système de travail que j’ai créé en tant que CTO. C’est l’opportunité d’aider les personnes lorsque les problèmes les dépassent – méthodes, staffing, formation, et ainsi de suite. »

Marek interrompt notre discussion car c’est l’heure de son observation sur le gemba. Avec la pandémie et une partie des effectifs en télétravail, les gemba walks doivent souvent être menés à distance, comme celui-ci. « Les conditions sont loin d’être idéales. Lorsque je suis assis à côté de quelqu’un, je peux voir quand la personne est en train de chercher des données ou des informations manquantes. Je peux voir où elle va, comment elle investigue, ce qu’elle cherche. J’en apprends beaucoup sur notre 5S ou notre processus d’intégration et de formation. Dans une session à distance, je peux seulement voir ce que la personne choisit de partager. »

ALLEZ VOIR, DEMANDEZ POURQUOI, MONTREZ DU RESPECT

Le gemba walk à distance que nous commençons avec Marek se concentre sur un atelier de conception technique et fonctionnelle. Il se déroule avec un expert en architecture de BAM et un développeur sous-traitant (Vincent). Antoine, le responsable de cette équipe, participe aussi à distance.

Le sujet est la conception d’une application de commerce électronique, de click and collect pour les professionnels qui achètent des matériaux de construction. Le client souhaite fusionner les besoins et les spécificités de ses quatre marques en un seul outil commun, en partant d’une seule application existante. À ce stade, l’équipe travaille sur un produit minimum viable (MVP – Minimum Viable Product).

Nous observons en silence pendant que Guillaume et Vincent travaillent et discutent sur la conception d’une page qui décrit le point de vente, son adresse et ses horaires d’ouverture. L’application originale ayant été développée par le client, ils utilisent une plateforme collaborative, Postman, pour faire de la rétro-ingénierie de l’API (interface). En d’autres termes, ils essaient de comprendre l’application actuelle et d’en construire une nouvelle à partir de leurs observations.

Vingt minutes plus tard, Marek, qui a pris de nombreuses notes, arrête leur travail et engage une discussion avec l’équipe. Il interroge chacun d’entre eux, un par un, en leur posant ces deux questions : que pensez-vous de la situation actuelle ? Peut-elle être améliorée ?

Guillaume, l’architecte, explique ce qu’ils essaient de faire : « Il est important que nous nous mettions d’accord sur le modèle de données dès le départ pour éviter les retouches par la suite. » Mais il bute ensuite sur un problème technique : « Je n’ai pas pu accéder à la configuration que Vincent a créée dans Postman. Nous devrions les partager dès qu’elles sont créées. »

Vincent, le développeur externe, admet qu’ils ont du mal avec les conventions de nommage : « Nous avons peut-être passé trop de temps à réfléchir sur le nom et le format du champ de l’horaire d’ouverture : est-ce un string, un nombre ou un float ? Aurions-nous dû mieux préparer en amont ? Ou peut-être demander à l’expert API du client d’y participer ? »

Antoine, le responsable, intervient et commence par les « bravos » : « Je suis tout à fait d’accord sur l’importance de sécuriser les standards sur le modèle de données ». Il se demande ensuite, comme l’a fait Vincent, si l’atelier est d’une quelconque utilité en l’occurrence : « Il est utile de travailler ensemble pour résoudre un problème ou pour former quelqu’un, mais était-ce la meilleure façon de progresser ici ? ».

Marek, qui a écouté attentivement, commence par approuver l’idée d’un modèle de données défini au préalable. Mais il interpelle ensuite le groupe : « Nous travaillons sur une application d’e-commerce, un produit largement connu dans notre monde technologique. Ne pourrions-nous pas partir de quelque chose qui existe déjà plutôt que de créer ce standard à partir de zéro ? ».

Antoine et Marek ont tous deux confirmé verbalement les bons points (sécurisation d’un modèle de données) et interpellé les techniciens par des questions – deux comportements de management essentiels dans un gemba walk. Chacun sait ce que Fujio Cho, président honoraire de la Toyota Motor Corporation, avait l’habitude de dire : « Allez voir, demandez pourquoi, montrez du respect ». Il est déjà suffisamment impressionnant d’avoir un directeur assis à côté de vous (Marek est à l’heure actuelle un N+3), mais s’il donne une solution au lieu de favoriser l’apprentissage et l’expérimentation par des questions, les gens se diront probablement : « Qui suis-je pour le remettre en cause ? »

L’art des gemba walks consiste à sonder la situation actuelle – « Sommes-nous dans des conditions normales ? » « Travaillons-nous bien du premier coup ? » « Sommes-nous en ligne avec nos objectifs ? » – et à soulever des questions sur les alternatives possibles.

Guillaume et Vincent doivent quitter la réunion, et le débriefing se poursuit avec Antoine seul :

Marek : « Antoine, qu’as-tu appris en tant que responsable ? »

Antoine : « Que nous passons trop de temps sur la conception. »

Marek : « Quelle est l’idée fausse ici ? »

Antoine : « Croire que l’on n’a pas besoin d’aide pour concevoir le modèle de données ? »

Marek se permet enfin de proposer une piste possible. « Le modèle de données provient de l’API client existante. Ce qui pourrait aider ici, c’est une approche de conception pilotée par le domaine (Domain Driven Design – DDD), pour se mettre d’accord sur les objets (entités, événements, transactions), leur dénomination et leurs interactions. Une fois ces éléments clarifiés, le codage devrait se faire facilement », explique-t-il. Comme il me l’expliquera plus tard, l’équipe essayait de faire de la rétro-ingénierie sur l’API construite par le client, sans avoir une idée précise de la façon dont le modèle de données devait fonctionner. La manière la plus efficace d’aborder ce problème serait de réfléchir d’abord au modèle de données dont ils ont besoin, par une approche DDD, puis de se tourner vers l’API existante et d’en tirer les informations de données.

Antoine poursuit : « Pigé ! J’ai prévu de renforcer l’équipe avec l’ajout d’un team leader expérimenté, mais je dois aussi penser en termes de problèmes types/solutions types lorsque je fais un gemba walk. Dans le cas présent, le DDD apparaîtrait naturellement comme une solution ».

Marek lui demande également de valider la plateforme de conception qu’ils utilisent pour dessiner le modèle d’architecture. Les développeurs sont libres de choisir leur environnement de conception, mais Marek se demande si cette plateforme permet réellement de collaborer avec d’autres projets en cours, afin de bénéficier des modèles existants. La discussion entre Marek et Antoine est intéressante : ils sont très conscients que le partage du code est indispensable (en fait, Antoine a même conçu une bibliothèque de code partagé pour BAM), mais ils ne se sont pas encore interrogés sur la nécessité de partager l’environnement de conception lui-même. Ce gemba walk est une occasion idéale pour soulever ce point.

PAS DE GEMBA SANS UN CADRE DE FONCTIONNEMENT EN TÊTE

Alors que la discussion avec Antoine se termine, je demande à Marek comment il se prépare à ses gemba walks. Il me confirme qu’il ne s’agit jamais d’une visite surprise. Faire preuve de respect signifie qu’un rendez-vous officiel est pris et que des explications sont données sur le pourquoi (vérifier si les gens travaillent dans les meilleures conditions possibles) et le comment (observer et échanger). « Je planifie deux gemba walks chaque semaine. Au début de BAM, je travaillais directement avec les développeurs et quand je voyais que l’un d’entre eux restait tard au travail, je m’arrêtais et m’asseyais à côté de lui pour essayer de comprendre le problème et l’aider. J’ai vraiment commencé un programme gemba en 2020, car nous travaillions tous à distance. Un gemba walk, même à distance, est un excellent moyen d’entretenir la confiance et de resserrer les liens au sein de notre équipe technique BAM. »

En réfléchissant à ce que je viens d’observer, je dois dire que la richesse du gemba walk est vraiment incroyable. Comment détecter autrement les situations hors standard, comme le choix d’une plateforme de conception collaborative avec un sous-traitant ? De quelle autre manière pouvez-vous repérer les besoins de formation, comme l’adoption d’une approche DDD pour gagner du temps sur les modèles de données ? Comment aidez-vous les managers à développer leur propre posture de soutien ? En phase de croissance, vous devez constamment accueillir de nouveaux arrivants pour tenir le rythme. Le moins que vous puissiez faire, c’est de prendre de leurs nouvelles pour les aider à se développer le plus rapidement possible.

Marek confirme qu’il y a beaucoup à apprendre sur le gemba. « Cela alimente ma propre compréhension de notre situation en termes de personnel, de technologie et de stratégie. Cela nourrit également ma réflexion lean sur notre stratégie », explique-t-il.

Lorsque je lui demande ce qu’il recommanderait à ceux qui commencent à faire leurs propres gemba walks, il me répond qu’il est important d’avoir un cadre clair en tête, une représentation à la fois de l’entreprise et des interactions humaines en son sein, ainsi qu’une bonne compréhension des compétences techniques dont vous avez besoin. Marek est catégorique à ce sujet : “Vous ne pouvez pas regarder et observer sans un cadre auquel vous pouvez vous référer. Je suis présent sur le gemba depuis un certain temps déjà, et cela m’a permis de mieux comprendre les compétences techniques dont nous avons besoin, un aspect pour lequel je suis toujours à l’affût. Lorsque nous avons commencé à discuter des modèles de données tout à l’heure, le cadre qui m’est venu à l’esprit était le DDD. Un autre cadre que j’utilise est le TPS (Toyota Production System), bien entendu. J’ai appris de mon sensei à penser en permanence qui doit apprendre quoi afin de s’améliorer. »

Vous souvenez-vous de l’échange avec Antoine, le manager ? Marek cherchait clairement à détecter les idées fausses et les besoins d’apprentissage, à sentir comment Antoine comprenait ce qu’il avait observé, pour l’interpeller sur ce qu’il n’avait pas vu, à l’aider à développer son propre cadre de référence et encourager la résolution de problèmes.

Marek me raconte une expérience qu’il a vécue lors d’un gemba walk. Le technicien avec lequel il était assis était en train de tester une fonctionnalité d’une application mobile. Une fois le code prêt à être testé, il a assisté à 17 minutes de travail laborieux : recherche de plusieurs appareils dans le laboratoire sur lesquels tester son code, sans trouver immédiatement tous les modèles dont il avait besoin, puis téléchargement manuel de la dernière version de l’application sur chacun d’eux, échec du test et plantage de l’application. Marek a sorti ses deux questions habituelles. « Cela arrive-t-il souvent ? » « Plutôt », répond le technicien. « Qu’est-ce que tu en penses, est-ce normal ? » « Hmm, non, pas vraiment. » Marek l’a ensuite challengé pour que le build et le test de toute nouvelle fonctionnalité ne dépassent pas 10 minutes. Cela a déclenché une réflexion et deux semaines plus tard, le même technicien est revenu. Il avait trouvé un moyen de réduire le temps d’installation et de test de la fonctionnalité sur les appareils, ce qui permettait à BAM d’économiser une journée de travail par semaine.

Il est facile, lorsque l’on cumule les responsabilités et que l’on monte en grade dans l’organisation, de se détacher du terrain. La bureaucratie, les conflits entre départements et les arbitrages politiques au corporate (entre autres) ont tendance à nous aspirer. C’est pourquoi la seule façon de rester en phase avec le monde réel, d’aider les équipes à développer leurs compétences et les clients à en bénéficier, est de mettre en place un calendrier de visites très régulières sur le gemba. « Les Gemba walks sont des occasions d’aligner les équipes autour de la stratégie de BAM. Et de corriger cette stratégie si elle ne peut pas être exécutée correctement », ajoute Marek avec un sourire.

Téléchargez l’article en PDF.

Article de Catherine Chabiron, auteure Lean et membre de l’Institut Lean France.
L’article original est paru dans Planet-Lean.com
Il a été traduit par Marc-Antoine Guichard, Nicolas Villemain et François Lopez