Le gemba du CTO: les apprentissages du terrain (2/2)

Dans mon article précédent consacré au gemba du CTO, j’ai évoqué les raisons pour lesquelles la pratique du gemba est essentielle aux leaders tech ainsi que ma méthode en 4 étapes. Passons à la pratique afin de vous partager quelques exemples tirés de mon expérience personnelle pour illustrer cette confrontation à la réalité du terrain. Ce sera l’occasion de mettre en évidence les apprentissages pour le manager et les enseignements pour les équipes.

Qualité des spécifications: on fait avec…

Paul, travaille sur une évolution de notre application Back-office, il me montre sa spécification qui tient en 1 ligne dans un ticket Jira sous forme d’un début de User-Story: « En tant que contributeur, je veux gérer l’historique des modifications de mon document ». Aucune maquette, ni cas de tests, ni règle de gestion complémentaire…

On s’accorde sur le fait que c’est un peu court pour les 12 jours de développement prévus. Je lui demande donc comment il fait pour développer à partir de si peu d’entrants. Et là, résigné, Paul me dit qu’il a demandé à ChatGPT de lui générer une spécification plus complète car le Product Owner, auteur de la spécification, est en congés !

Astucieux, mais cela correspond-il vraiment au besoin des utilisateurs, au problème à résoudre pour eux ? 🤨

Qu’apprenons nous de cette situation ?

Une fois passé l’effet de « surprise », je comprends que le Product Owner en charge des spécifications n’a pas jugé nécessaire de fournir plus de détails sur cette feature. Sur ce point, il sera intéressant d’échanger directement avec lui et comprendre pourquoi ? Est ce que la fonctionnalité lui paraissait évidente ? A-t-il manqué de temps ? Au final, quelle serait la check-list permettant de s’assurer qu’une spécification est prête à être développée, aka Definition Of Ready ?

La 2ème prise de conscience pour moi ce jour là, est que dans mon équipe, on développe même si on n’a pas toutes les infos nécessaires, quitte à les inventer avec une IA. Et là, c’est une formidable opportunité pour moi d’affirmer notre rôle à la tech. Si certains éléments de spécifications sont flous, on se doit de valider les hypothèses avant de développer avec les vrais besoins clients. Mieux vaut bloquer la feature que de continuer à développer du code qui ne répondrait pas au besoin des utilisateurs. Le pire des gaspillage est bien de développer des fonctionnalités inutiles pour le client.

Et Paul prend conscience qu’il a le droit de dire non, et de se montrer plus exigeant vis à vis des spécifications si nécessaire. Ce déclic marque le début d’un cheminement vers plus de maturité et d’assurance avec le soutien continu du manager.

La feature flippante

Un deuxième exemple avec une développeuse, Emma, qui travaille sur une feature demandée par un de nos plus prestigieux et important clients. Emma a donc une certaine pression pour bien faire. Il s’agit de mettre en forme des informations de copyrights dans un fichier PDF respectant scrupuleusement la mise en forme sur le Web. Auparavant, le PDF était assez approximatif comparé à la page Web.

Le développement est presque terminé et je vois que, dans le ticket Jira, il est indiqué que cette fonctionnalité devra être activée en feature flipping pour ce client. Vous connaissez l’impact de ce type d’activation dans le code: un if supplémentaire qui complexifie la maintenance et une n-ième propriété à activer/documenter pour chaque client (même si cela a tendance à encourager le Separation Of Concerns !).

Je demande à Emma ce qu’elle pense de l’intérêt du feature flipping dans ce cas précis. La réponse est clairement négative:

On pourrait très bien proposer cette fonctionnalité à tous les clients. Qui pourrait refuser cette amélioration évidente ?

Mais encore une fois, qu’est ce qu’on fait ?

Emma demande au Product Owner, auteur de la spécification ce qu’il en pense. Un message Slack et 15 min plus tard, on obtient la réponse:

Ah oui, j’avais mis cette évol en feature flipping car je ne savais pas si ça pouvait intéresser d’autres clients, on verra plus tard 😉

Encore une fois, deux apprentissages très intéressants se dessinent.

Côté produit bien entendu car le Product Owner n’a manifestement pas conscience de l’impact de sa décision. Même si elle peut paraitre prudente au premier abord car on limite le risque de mécontentement en activant cette fonctionnalité uniquement pour le client demandeur, à long terme, l’impact est catastrophique pour la maintenabilité de l’application. Compte tenu du caractère transverse sur 2 équipes du sujet, je propose à Emma de le traiter personnellement à mon niveau avec l’équipe produit. Quelque semaines plus tard, cela aboutira à une démonstration à l’équipe produit de l’impact du feature flipping dans le code, un rappel des dizaines de features activées pour seulement un client (pas de process de flag clean up) et, au final, une décision commune de limiter le feature flipping à des cas exceptionnels.

Et pour Emma, elle prend conscience qu’elle peut challenger une demande qui lui parait absurde et faire une contre proposition astucieuse étant donné son expertise technique et fonctionnelle. Par la suite, cela nous a permis d’ajuster dans notre organisation les rôles et responsabilités de l’équipe produit par rapport à l’équipe ingénierie.

Déconnexions à répétition

Nous sommes ici dans grande entreprise du monde de la distribution avec Bruno, un jeune développeur sur système AS/400. Lors du gemba, Bruno est déconnecté 3 fois du VPN interne en plein coding, ce qui occasionne un certain agacement de sa part. A chaque fois, il doit se reconnecter, resynchroniser ses repositories de code, se remettre dans le contexte… Nous échangeons alors sur la récurrence de ces déconnexions et il m’explique que tous les développeurs AS/400 sont embêtés:

Ça a toujours été comme ça, en télétravail ou au bureau !
En plus de la gêne importante pour toute l’équipe de développement, je fais rapidement le calcul: environ 10 déconnexions par jour x 15 développeurs x 3 min perdues = 7.5 heures, soit 1 ETP !

Je demande alors à Bruno s’il veut qu’on essaye de comprendre pourquoi cela arrive et comment on pourrait résoudre ce problème récurrent. Il m’explique d’abord que plusieurs personnes auraient déjà essayé mais que ce serait à voir avec IBM et que c’est très compliqué… Après quelques encouragements de ma part, Bruno décide de prendre le sujet personnellement.

Après plusieurs semaines et de nombreuses fausses pistes (les time-out du VPN, le paramétrage de Git…), Bruno va finalement trouver la cause racine ainsi que le bon paramétrage au niveau AS/400 avec l’aide du support IBM. Pour tous ses collègues de la DSI, c’est un soulagement, les déconnexions ne sont plus qu’un mauvais souvenir !

Bruno, le « petit jeune », est maintenant celui qui maitrise le mieux dans l’équipe la configuration réseau de bout en bout du poste de développement au serveur. Et cerise sur le gâteau, Bruno sera interviewé sur la chaîne vidéo interne de la DSI devant 150 collègues pour expliquer sa démarche et les apprentissages qu’il en a tirés.

Plus qu’un apprentissage, c’est pour moi la confirmation qu’un jeune collaborateur mis en confiance peut avoir un impact très fort sur une équipe grâce à sa pugnacité et son envie de faire bouger le statut quo, là où parfois des personnes plus expertes ou avec plus d’ancienneté se montreront plus résignées.

Comprendre les difficultés imposées aux utilisateurs

Et enfin pour terminer, je voudrais ouvrir sur un autre type de gemba: le gemba utilisateur. Toujours le même principe et les mêmes objectifs mais cette fois l’observation se fait auprès des utilisateurs finaux.

Le problème auquel j’étais confronté était le suivant. Une équipe tech avait développé une application de configuration de portails Web pour des utilisateurs internes. Appelons ces utilisateurs les « configurateurs »: leur rôle consiste à paramétrer les portails Web pour les clients au pixel près. J’entendais régulièrement de nombreuses plaintes comme:

L’application de configuration n’est pas du tout adaptée! C’est un cauchemar….

On passe des heures à essayer de configurer des choses simples…

Vous imaginez l’impact sur:

• la satisfaction client: retard sur les livraisons de portail, problèmes divers de qualité sur les livraisons;
• l’entreprise éditeur de logiciel: c’est un manque à gagner car on passe plus de temps que prévu sur le paramétrage;
• et les équipes: certains configurateurs sont à bout, et bien entendu des tensions commencent à apparaitre entre équipes.

J’évite de lancer une série d’ateliers métier pour identifier les problèmes rencontrés, ce qui aboutirait probablement à des dizaines d’évolutions et correctifs dans une backlog produit déjà surchargée. Au lieu de cela, je demande à quelque développeurs de l’équipe:

Est ce que vous savez comment les configurateurs réalisent le paramétrage des portails Web ?

Réponse quasi unanime:

Euh, non, pas vraiment.

A ce moment, je comprends que mes équipes de développement n’ont pas vraiment de compréhension de l’usage précis du produit qu’ils développent. En forçant un peu le trait, un peu comme si un ingénieur dans l’automobile concevait un moteur sans être jamais monté dans une voiture. Et cette situation existe chez nous malgré la proximité géographique des équipes, et la bonne entente générale. Les silos sont bien présents dans notre petite entreprise (une centaine de salariés).

Mon objectif est alors de les aider à se connecter avec les clients: découvrir les usages réels des utilisateurs pour mieux les intégrer à leurs développements. Je propose alors à 3 développeurs de l’équipe de réaliser avec eux un gemba utilisateur avec un vrai utilisateur final, un configurateur. Le rendez vous est pris avec Zoé qui a prévu de paramétrer un nouveau portail sur le créneau réservé.

Et là, nous passons 2 heures passionnantes. La réalité nous saute littéralement aux yeux: les points de friction, les perte de temps… L’équipe de développeurs prend conscience des usages réels et des obstacles qui sont imposés à Zoé avec l’application actuelle.

Par exemple, à chaque fois qu’elle change de langue utilisateur, Zoé perd le point de scroll de la page (très longue!) de tous les paramétrages disponibles ce qui lui fait perdre un temps précieux… On commence à discuter de certains changements très simples qui pourraient accélérer considérablement le travail de Zoé.

Les conséquences sont rapides et très impactantes, les développeurs ont des idées pour améliorer certains défauts constatés. En quelques semaines, des échanges directs entre les configurateurs (utilisateurs finaux) et développeurs permettent de livrer une petite dizaine de nouveautés. Les configurateurs sont satisfaits et la vélocité de leur équipe repart à la hausse. Autre conséquence directe, le volume des spécifications liées à cette application de configuration diminue grâce à l’expertise croissante des développeurs.

Bien entendu, on pourra me rétorquer que c’est le rôle des équipes produit ou MOA de tout spécifier clairement et sans ambiguïté mais la réalité est qu’ils n’en ont pas le temps, il y a toujours de l’implicite! Et surtout, cela ne doit en aucun cas empêcher les équipes tech en charge du développement de comprendre la finalité et l’usage de ce qu’ils développent pour être encore plus pertinents.

Conclusion: voir l’éléphant dans la pièce !

Assez régulièrement, durant le gemba il y a ce qu’on appelle un « éléphant dans la pièce », c’est à dire un dysfonctionnement important, un problème ou un blocage. Pour autant la personne n’en a pas toujours conscience comme dans l’exemple sur les déconnexions. C’est une situation très classique et cela fait partie des apprentissages du manager et du collaborateur qui en prend tout à coup conscience. Nous sommes tous habitués à vivre avec des obstacles depuis des jours des mois ou des années imposés par un logiciel, un process, une pratique… Le gemba nous aide à allumer la lumière pour voir l’éléphant ! Bien entendu, les problèmes observés ne se résolvent pas en un clin d’oeil, et cette culture de l’amélioration continue tant recherchée doit être constamment soutenue par l’ensemble de la chaîne hiérarchique.

Comme pour nos hommes et femmes politiques auxquels on reproche souvent d’être « déconnecté du terrain », le gemba me parait être une pratique essentielle pour les managers de la tech. En effet, elle permet de développer un leadership plus proche et à l’écoute des collaborateurs et de construire une culture de l’amélioration continue avec le droit à l’erreur en impliquant directement chaque personne. Enfin, elle permet au manager de prendre des décisions plus éclairées par la réalité du terrain. Une précaution toutefois, si le gemba est riche d’enseignements, il peut aussi déstabiliser les collaborateurs d’où l’importance de créer un climat de confiance et de sécurité.

L’excellent Boulet illustre cette confrontation à la réalité à sa manière:
Lourd est le Parpaing de la Réalité sur la Tartelette aux Fraises de nos Illusions.

(c) Boulet

Et vous, qu’avez-vous découvert sur le terrain avec vos équipes, qu’en avez vous retiré comme apprentissages ?

Merci beaucoup à Thomas L, Natacha R, Philippe F pour leur aide et l'inspiration !