La 1ère pratique du CTO: aller sur le gemba ! (1/2)

Le CTO seul dans sa tour

Durant mes premières années de CTO, j’ai pu observer à quel point il était facile de se déconnecter de la réalité du terrain. Tout concourt en ce sens. On prend du grade, on s’éloigne progressivement du développement, on travaille sur du reporting, des KPI, des OKR… On adopte une stature de dirigeant pour travailler sur des sujets stratégiques.

Pourtant cette perte de connexion avec le terrain n’est pas sans conséquences. Elle éloigne le CTO des vrais problèmes rencontrés par les collaborateurs et l’isole dans ses prises de décisions. De plus, le CTO se retrouve également plus loin des difficultés rencontrés par les clients et les utilisateurs finaux.

Comment faire pour rester connecter à l’opérationnel et prendre des décisions éclairées ? Comment faire pour que les collaborateurs puissent apprendre et améliorer leurs pratiques auprès de leaders compétent ?

Il existe une pratique précieuse qui nous vient du Lean: le gemba. Ce mot japonais signifie “le terrain, là où la valeur se crée”.

Le gemba dans le monde du software engineering

Bien qu’initialement inventé dans le milieu industriel, le gemba est universel et s’applique à tous les métiers. Je le pratique dans le software engineering autour des équipes IT: des développeurs, testeurs, architectes, Ops, DevOps, …

Le principe peut paraitre simple: il s’agit d’aller sur le terrain à la rencontre d’un collaborateur et de l’observer en conditions réelles, en évitant les “ingérences” susceptibles de brouiller l’observation. Ce n’est pas un “vis ma vie” car il ne s’agit pas de faire le travail du collaborateur, mais bien de garder du recul pour observer. Dans un premier temps, je le pratique sans les middle-managers tout en les informant de ma démarche et en les invitant s’ils le souhaitent. Il est néanmoins indispensable de former les managers directs au gemba sur le long terme. En effet, ce sont eux qui vont assurer cette connexion au terrain en prenant conscience des difficultés rencontrées par les collaborateurs en les coachant à résoudre les problèmes rencontrés.

Le déroulé d’un gemba suit un protocole assez strict.

❶ Libérer du temps – Première difficulté dans l’agendas saturé du CTO ! Personnellement, mon rythme est de 2 gembas par semaine lors de la prise de poste puis 1 gemba par semaine.

➋ Identifier le collaborateur – Lors de ma prise de poste, je privilégie les personnes qui se sentent en confiance, plus ouvertes à l’expérimentation. En effet, cette pratique sera forcement racontée, discutée, challengée entre collègues. Autant commencer par un succès avec des personnes plus curieuses, enclines au partage, à la transparence. L’actualité est aussi un bon critère: un projet qui démarre, un retard sur une livraison, des problèmes de qualité ou d’instabilité…

➌ Annoncer clairement la démarche – En général, je passe voir la personne personnellement (au début) ou j’envoie un message Slack à J-3 en expliquant la démarche en quelque lignes.

➍ Le gemba lui-même – Le jour J, je déroule le gemba en trois parties (total env. 1h15)

• 5 min – ice breaker
• 55 min – observation
• 15 min – debrief et remerciements

Ice breaker : on est en sécurité

La pratique du gemba est peu répandue dans la tech, il faut donner du sens à cette pratique. Mais surtout, cela peut être impressionnant ou déstabilisant pour un collaborateur d’avoir son n+2 ou n+3 à côté de soi pendant 1 heure. Il faut donc rassurer la personne et poser un cadre de confiance et de sécurité. Le gemba est aussi une façon pour le manager de montrer au collaborateur un véritable intérêt pour son travail, c’est une forme de respect.

Je prends donc quelques minutes pour redonner le contexte et rappeler le sens de ma démarche, c’est l’ice breaker:

C’est super important pour moi car cela m’aide à prendre des décisions éclairées, sortir de ma tour d’ivoire.

Ça m’intéresse de mieux comprendre ce que tu fais et les obstacles que tu rencontres au quotidien.

C’est un moment précieux pour échanger, prendre du recul, et pour améliorer nos pratiques.

Je te remercie de ta confiance, je suis incapable de faire ce que tu fais… / Je serais bien embeté si j’avais à le faire moi même.

Observation : les 5 sens en éveil

Une fois le cadre rassurant posé, on entre dans la phase principale: l’observation. Pour autant, il faut donner un cadre pour que l’observation soit utile. En général, je lui demande simplement de travailler sur la tâche ou l’activité qu’il aurait réalisé si je n’avais pas été là:

• une feature en cours de développement,
• un bug à corriger,
• un cas de test à écrire,
• une architecture à poser….

Par analogie avec le monde l’industrie, on appelle ce travail à réaliser “la pièce”, comme une pièce (une feature) en cours de fabrication.

Mon rôle est alors d’observer comment cette pièce arrive dans les mains du collaborateur (materials = ticket, spécification, user story…), comment il la transforme (code…) et comment il la livre au collaborateur suivant.

Je commence donc par regarder les materials, ce qu’il a reçu en entrée:

Sur quoi travailles tu ? Peux tu me montrer le ticket Jira, la spécification, le dossier d’architecture… qu’on t’a fourni ?

Puis j’enchaine sur un peu de contexte et pourquoi il travaille sur cette “pièce” précisemment:

Qui est le demandeur ou le client ?

A quoi ça va servir ou pourquoi c’est important de passer du temps là dessus ?

Est ce que tu as toutes les infos nécessaires pour travailler ?

Ces quelques questions me permettent de comprendre rapidement si le collaborateur va exécuter une mission dont il comprend l’importance et les enjeux pour le client.

Je lui propose de travailler “normalement”, “comme si je n’étais pas là”. J’essaye de ne pas trop interrompre, mais quand je ne comprends pas ce qui se passe, je pose une ou deux questions ouvertes. Mon objectif est de mieux comprendre à quel moment le collaborateur crée de la valeur (quand il code, quand il teste …) et quand il fait face à un gaspillage (quand il est bloqué, quand il recommence la même opération, quand il hésite ou ne comprend pas…).

Quand les obstacles apparaissent, la tentation est grande de vouloir tout de suite apporter une solution au collaborateur. Ce n’est pas une bonne idée ! Dans ce cas, je préfère essayer de mesurer l’impact:

Pas simple comme situation, et ça arrive combien de fois par jour ? Pourquoi ?

Pourquoi cela est-il gênant pour ta mission?

Le Dieu du gemba est avec toi !

Au bout de quelques minutes d’observation, la magie opère. Les obstacles se révèlent sous nos yeux et mettent en lumière les vrais problèmes rencontrés par le collaborateurs, y compris tous ceux qu’il ne voit plus:

• Les spécifications sont incomplètes,
• On ne sait pas comment s’y prendre pour déployer,
• Le collaborateur ne. sait pas comment modifier le code existant car il n’a pas été formé sur cette partie,
• Le collaborateur est bloqué mais n’ose pas demander de l’aide

Ces moments sont particulièrement intéressants et c’est pour cela qu’on va sur le terrain !

Ce qu’on cherche avec le gemba, c’est comprendre les blocages réels, rencontrés là maintenant par les collaborateurs, ceux qu’il faut résoudre immédiatement et qui empêchent la livraison de l’évolution tant attendue…

Très souvent à cette étape, mes idées préconçues volent en éclat.

Débrief à chaud

Une fois l’observation terminée, il est important d’avoir un moment d’échange au calme avec la personne pour plusieurs raisons: tout d’abord la rassurer (tout s’est bien passé !) et la remercier de sa confiance, et ensuite échanger sur les enseignements issus de cette observation (call to action).

En effet, cette pratique du gemba doit s’inscrire sur la durée pour aider les collaborateurs à :

• identifier les bons problèmes, ceux qui sont importants et qui ont un impact dans leur quotidien
• leur donner la légitimité de les résoudre par eux-mêmes.

En général, j’ouvre le débrief avec un grand sourire et quelques questions ouvertes :

Alors, ça n’a pas été trop horrible 🙂 ? Comment ça s’est passé ?

Ensuite je demande ce qu’ils ont vu comme obstacles ou difficultés (les gaspillages) ?

Qu’est ce qui t’a embêté ? Où est ce que tu as perdu du temps ? Qu’est ce qui était difficile ?

Est ce qu’on pourrait essayer de changer certaines choses ?

Comment est-ce que je pourrais t’aider ?

Je prends ensuite la parole pour partager mes observations. Tout en valorisant les moments de création de valeur, je reviens aussi sur les gaspillages observés (reformulés en “perte de temps”, “blocages”….). Sur ces derniers, j’essaye de creuser sur les causes: pourquoi est on dans cette situation ? Et j’en profite pour demander à la personne si elle aurait des idées de contre-mesures à tester pour éviter que cela ne se reproduise. Mon objectif est bien entendu de l’encourager à essayer une amélioration avec ou sans mon aide.

Enfin, je termine toujours le gemba par un remerciement pour la confiance accordée :

Je te remercie vraiment de ta confiance, c’était super intéressant pour moi de comprendre plus finement ce que tu fais et les obstacles que tu rencontres

Ainsi qu’un remerciement à froid le lendemain:

Les semaines suivantes seront pour moi l’occasion de faire le “check”:
Est ce que la personne va mener l’amélioration jusqu’au bout ? A-t-elle besoin d’être soutenu ?
Comment pourra-t-elle partager cette expérimentation avec ses collègues ?

Les pièges à éviter

Vous l’avez compris, la bienveillance est de rigueur lors d’un gemba car c’est une expérience éprouvante pour le collaborateur. Quelques comportements peuvent être particulièrement contre-productifs:

• Venir “inspecter” au lieu d’observer
• Faire des reproches aux collaborateurs ou montrer de l’agacement / impatience
• Proposer / imposer sa solution immédiatement

En dépit de l’envie du leader de faire bouger les choses rapidement, il est bien plus important de chercher à développer l’expertise des personnes par ce type de coaching.

Dans le prochain article sur la pratique du gemba par le CTO, j’illustrerai avec quelques exemples tirés de mon expérience personnelle pour mettre en évidence les apprentissages et l’impact des actions d’améliorations.

Et vous comment vous connectez- vous à vos équipes et prenez-vous conscience des problèmes réels rencontrés sur le terrain chaque jour ?

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