Profession chien de berger agile — Dimitri Baeli

Après avoir travaillé pour des éditeurs logiciels principalement dans le domaine Java, en presse, banque ou assurance, Dimitri Baeli a été pendant 3 ans, responsable qualité globale chez ExoPlatform, éditeur opensource dont il accompagnait la professionnalisation des développpements pour 100 développeurs répartis sur 5 pays : processus, organisation des équipes et amélioration de la qualité. Il accompagne désormais l’équipe R&D de LesFurets.com. Il est aussi organisateur de la conférence Lean & Kanban France et de l’Agile Tour Rouen et intervient régulièrement en tant qu’orateur.

  • Bonjour Dimitri, avant de nous parler de LesFurets.com, peux-tu revenir sur ce que tu faisais chez ExoPlatform ?

Chez ExoPlatform, c’était le pari assez fou d’arriver à organiser depuis chez moi, les processus et le développement de l’agilité dans une startup qui faisait 75 personnes à l’époque, principalement au Vietnam et en Ukraine. J’étais le premier ingénieur à ne pas faire partie directement d’une des équipes de développement. Ca a été un accompagnement sur 3 ans, complexe avec la distance et la structure multi-sites : organiser les équipes à distance, organiser la communication, être sur de la qualité de l’organisation des équipes. Maintenant il y a 40 personnes techniques transverses au développement. La production de code est faite par sensiblement le même nombre de personnes, mais avec beaucoup plus d’éléments transverses : support, documentation et finalisation du logiciel.

  • C’était à la fois distant et multi-site, comment tu faisais concrètement ?

Les outils permettent de bien communiquer : plutôt des chats skype ou des groupes de discussion que par mail, à la fois pour des communautés transverses ou par sujet. On était capable de regrouper toute l’entreprise sur des releases pour concentrer la communication et les décisions. Mais surtout de la communication et des déplacements pour être humainement connecté aux relais locaux et aux équipes. J’étais quasiment le seul à avoir vu l’ensemble des employés.

  • Tu organisais et tu coordonnais tout ça ?
J’ai pris le parti de ne pas décider tout seul, mais d’être vraiment une boîte à idées pour les gens qui avaient des décisions à prendre.

Je donnais des idées, des pratiques, des exemples. En fait j’essayait de donner de la dynamique plus que des ordres. J’ai pris le parti de ne pas décider tout seul, mais d’être vraiment une boîte à idées pour les gens qui avaient des décisions à prendre. Et ça apportait beaucoup de cohérence sur les décisions puisque je faisais la navette entre plein de personnes. Chacun pouvait se concentrer sur son sujet. La plupart du temps, c’était intéressant qu’ils prennent leurs décisions. J’étais une sorte de conseiller interne de l’entreprise. L’important c’était de donner de la cohérence aux méthodes et aux processus techniques, de façon à ce que les gens n’aient pas besoin d’y penser.

Quand je suis arrivé les équipes étaient les unes à côté des autres avec un besoin de cohérence mais il fallait que ça soit une personne d’une équipe qui impose son idée aux autres. Je suis arrivé dans un fauteuil : j’étais celui qui pouvait les accompagner à se coordonner. C’était un poste de catalyse et je pense que c’est une bonne pratique dans une entreprise. Ce n’est pas le responsable process et méthode qui réfléchit dans son coin et qui envoie des normes ou des recommandations mais quelqu’un qui va sur le terrain, qui donne des idées et qui laisse les gens prendre les décisions. Et s’il travaille bien l’ensemble des décisions est cohérent. Je ne voulais vraiment pas me retrouver à donner des grandes directions de principes, de méthode à appliquer en leur disant “vous vous débrouillez”. Etre capable de mettre les mains dans le cambouis, je pense que c’était indispensable pour ce poste là.

  • Tu as rencontré des difficultés dans cette posture de catalyseur ?

Je ne me suis pas focalisé sur les difficultés. C’est vrai qu’il y a de grosses différences culturelles entre le Vietnam, l’Ukraine, la Tunisie, la France et les Etats-Unis, mais je pense qu’au contraire les gens sont intéressés à se synchroniser, surtout s’ils sont en position de prendre leurs décisions locales. C’est une douce recette entre la décentralisation et un système central qui n’est pas trop décisionnaire non plus.

Par abandon successifs de solutions, il ne reste que des choses qui sont possibles… et si elles sont toutes bonnes, peu importe si on ne prend pas exactement la meilleure.

Etre là quand il y a besoin et laisser les gens se développer, quitte à ce qu’ils fassent leurs erreurs plutôt que de tout contrôler et décider à leur place. Ca peut poser des difficultés lorsqu’il y a des décisions difficiles à prendre, qui peuvent ne jamais être prises. Il y a des moments où je n’ai pas voulu passer le pas d’imposer des décisions. Je pariais sur le fait que les idées pouvaient se mettre en place à force de partage, de recoupements ou vraiment d’avis : “ça, ça ne peut pas marcher, il faut vraiment l’abandonner”. Et au final, par abandon successifs de solutions, il ne reste que des choses qui sont possibles… Parmi celles qui restent, si elles sont toutes bonnes, peu importe si on ne prend pas exactement la meilleure.

  • Tu es maintenant chez LesFurets : peux-tu nous en présenter le contexte ?

Avec LesFurets.com, j’ai découvert l’univers du web, très différent de celui des éditeurs logiciels. L’ équipe de développement de 12 personnes est très proche de ses utilisateurs finaux. C’est une grosse équipe de dev pour un site web, mais plus réduit que ce que j’ai pu connaître auparavant. Au total, avec l’équipe marketing et commerciale cela représente une entreprise de 25 personnes. Il y a un lien direct entre le marketing et la production : sur une ou deux semaines on a un vrai retour d’expérience. On attend pas comme un éditeur que le client mette lui-même le produit en place, avec une couche de configuration et un délai supplémentaire. Là on met en production et 1h après, on a des retours, positifs ou négatifs de ce qu’on a fait. On vit au rythme du site.

  • Et quel est ton poste ? Toujours un rôle de catalyseur ?

Mon travail c’est d’améliorer la performance de l’équipe pour pouvoir livrer quasi en continu. Je suis avec une équipe déjà assez mature, mais on vise encore plus haut et il y a toujours à faire. Je ne suis pas manager directement, mais une sorte de super Scrum Master, en charge d’accompagner l’architecte, le responsable qualité et le manager qui sont demandeurs, et l’équipe sur tout les plans.

Améliorer les conditions de travail des développeurs et leur efficacité, en essayant de dégager tout les freins qui peuvent arriver en amont ou en aval

C’est un poste très polyvalent, et technique et organisationnel. J’aide les personnes à se concentrer sur leur tâche en travaillant sur les processus, les outils, les pratiques et leur environnement, quitte à me mettre à côté d’eux pour les aider à améliorer leur outil de travail ou leur code. L’idée, c’est d’améliorer les conditions de travail des développeurs et leur efficacité, en essayant de dégager tout les freins qui peuvent arriver en amont ou en aval.

  • Tu peux me donner un exemple ?

Je peux passer 3 mois à mettre en place des tests de performance avant un lancement de pub télé en déployant des nouvelles techniques ou des nouvelles stratégies de test et en développant les modules nécessaires, par exemple pour injecter des milliers de pages rapidement, automatisés avec Jenkins et Amazon EC2. J’ai travaillé sur de l’outillage de gestion de configuration ou sur de la génération de code. C’est de l’outillage très technique mais je travaille dessus directement parce que ça ajoute des compétences et des capacités à l’équipe. Ce n’est plus l’architecte directement qui fait ça ou le meilleur développeur qui prend du temps là-dessus. C’est moi qui les aide à mettre ça en place.

Non, c’est vraiment une symbiose. Ils ont des besoins. Soit ils le font eux-même et je leur confirme qu’ils sont sur la bonne voie, soit ils demandent que ça soit fait pour eux parce que ça les aide et là je peux faire. C’est donner confiance dans toutes les décisions dans et en-dehors du produit. Il y a un architecte pour tout ce qui est dans le produit, un responsable qualité pour tout ce qui est fonctionnel/métier, un manager pour tout ce qui est organisation des personnes. Et moi je suis là pour que les gens arrivent à travailler avec les bons outils, les bonnes stratégies, les bons processus. Et je pense que ces 4 casquettes là se marient bien. Et c’est beaucoup plus dur à l’intérieur d’une seule tête quand il y a un DSI qui essaie de tout faire d’un coup.

Quand on passe son temps à enlever des problèmes, les gens oublient les problèmes qu’ils avaient avant et peuvent croire qu’il ne se passe rien

Après, j’apprends à mesurer un peu plus le résultat et mieux apprécier la qualité de ce travail-là. Quand on passe son temps à enlever des problèmes, les gens oublient ceux qu’ils avaient avant et peuvent croire qu’il ne s’est rien passé (rires). On enlève des douleurs mais comme il en reste, on peut avoir l’impression de ne pas avancer. Donc il faut aussi parler des succès et de ce qui avance et recontextualiser régulièrement la progression. Ce n’est pas parce qu’on a toujours mal que ça n’avance pas.

  • Sur le plan humain, ça doit être un sacré changement : moins de monde mais un contact beaucoup plus direct !

J’ai 4 bureaux, je suis le seul à bouger un peu à toutes les places et ça perturbe surement un peu les gens. Mais la dynamique intellectuelle est un peu la même et en fait je suis globalement en contact avec le même nombre de personnes, une quinzaine. Je fais les mêmes tests de performance ou de suivi de fabrication de binaire. C’est très différent mais finalement, il y a autant de complexité à gérer et pas mal de dynamique. Mon activité ne change pas beaucoup. Je l’ai défini comme “chien de berger agile” : le mec qui courre partout, on se demande un peu ou il va, mais au final le troupeau atteint sa destination. Ce n’est pas moi qu’il faut suivre mais le résultat.

  • Qu’est-ce qui est complexe pour toi ?

La complexité, c’est de donner une logique à tout un enchaînement de pratiques très très différentes : le développement logiciel, la fabrication de binaires, le déploiement, la planification, l’organisation des tâches, l’organisation du poste de développeur, la qualité du build. La complexité c’est d’organiser toute l’information nécessaire à une équipe de développement. L’architecte est concentré sur l’architecture du produit. Moi, je suis sur le mélange entre la technique et l’humain, plus le politique : les priorités, les impacts de changements de planning… La complexité, c’est la diversité des sujets.

  • J’ai l’impression qu’il y a une espèce de grand écart entre les aspects très tech et les aspects méthodologiques et organisationnels.

En fait ce n’est pas un grand-écart ! On a besoin d’en faire un métier : mélanger la stratégie et la technique. Tout métier mélange des aspects stratégiques, organisationnels, humains. On monte un peu dans la maturité et on ne regarde pas que le code produit, mais aussi l’intention, le résultat, la valeur.

On ne regarde pas que le code produit, mais aussi l’intention, le résultat, la valeur

Ce que j’apprends en ce moment, c’est la différence entre le temps concret de développement et le délai entre demande et livraison, le temps d’attente du client. C’est une énorme différence que l’on oublie trop rapidement quand on planifie en jour/homme, en effort, où on perd toute notion du délai. Hors c’est ce que l’on me demande : raccourcir les délais de mise en production. Pourquoi remplir un planning peut le rendre impossible à réaliser ? Je comprends très bien que vider un planning n’est pas quelque chose de facile à faire.

  • Quel bilan tu tires de tout ça après 9 mois ?

La dynamique est lancée. Le travail que l’on a fait paye énormément : on a fait un lancement de pub télé et multiplié le trafic par 10 ou 20 et on a peu d’incidents de production. On a continué au même rythme, voire accéléré puisqu’on livre 1 fois par semaine, sachant qu’on a beaucoup plus de traffic. On rend invisible une masse de travail supplémentaire qu’on était pas capable de faire avant : on a développé les capacités de l’équipe, même si c’est difficile à mesurer. L’objectif c’est qu’on entende pas parler de l’IT. LesFurets, c’est une boîte qui met en relation des internautes et des assureurs, on passe par un site web certes, mais ce n’est qu’un moyen qui ne doit pas ralentir la mise en relation.

  • Tu travailles avec 3 autres personnes : comment ça se passe ce travail en équipe avec d’autres managers qui ont des rôles complémentaires ?

C’est une vraie équipe pluridisciplinaire. On échange beaucoup. L’intitulé de mon poste c’est “R&D Team Mentor”, mentor de chaque personne et mentor de l’équipe. J’essaie de donner une cohérence, sachant que chacun à son sujet de prédilection et du lien entre tout le monde. C’est un équilibre : des échanges et de la confiance. C’est une vision assez moderne, puisque c’est assez à plat : il n’y a pas de responsable, sous-responsable…

  • Comment tu vois la suite ?

J’apporte déjà une force de frappe, une organisation, mais reste à donner de la valeur à ce poste sur le long-terme. Au départ, j’ai un peu eu l’impression que ce poste là ne pouvait pas durer sur le long-terme : j’arrive à organiser et après on en a moins besoin quand on arrive à une certaine maturité. Est-ce qu’on a toujours besoin d’aller plus haut ? Est-ce qu’on a forcément besoin d’aller au maximum du potentiel de l’équipe ? Avoir un rythme soutenable est aussi important, nous sommes des marathoniens.

Est-ce qu’on a forcément besoin d’aller au maximum du potentiel de l’équipe ?

Pour l’instant mes projets, c’est de synthétiser, prendre du recul ou écrire sur les sujets. J’ai fait beaucoup de conférences mais très peu d’écrit. Organiser des conférences m’intéresse : je prends beaucoup de plaisir à voir des gens échanger, se rencontrer ou prendre des claques à des présentations. Donc à la fois une phase d’action dans l’équipe et d’observation à l’extérieur. On va voir comment Kanban va être digérer, comme Scrum l’a été, par des managers.

  • D’accord tu développes les capacités de l’équipe, mais comment tu développes tes capacités , comment tu fais pour être crédible ?

Mon travail se développe en fait beaucoup à partir des travaux que je fais à l’extérieur. Finalement, je ne peux être crédible dans mon poste, dans l’équipe, que si je le suis à l’extérieur. Je me développe par l’organisation de conférences, en m’exposant à l’extérieur et en me mettant en danger sur différents sujets. Je passe beaucoup de temps à développer mes capacités pour pouvoir aider l’équipe à développer les siennes. Il y a trop de gens qui se reposent sur leurs acquis. Dans ma position, c’est impossible. Je ne pourrais tenir justement qu’un certain temps parce que j’aurais épuisé mes capacités.

Ca serait présomptueux de dire que je réussirais si mon poste avait disparu. Mon poste disparaitrait si j’avais épuisé mes capacités, ce dont je refuse l’idée. Et donc j’ai besoin de les développer, notamment parce que l’équipe grossit et me rattrape. Mon but c’est que l’équipe me rattrape et que j’ai avancé entretemps.

Mon but c’est que l’équipe me rattrape et que j’ai avancé entretemps.

Un autre aspect qui me parait important, c’est l’apprentissage par les jeux avec les “serious games”. J’ai participé à Agile Games France l’an dernier en prenant énormément de plaisir et en apprenant beaucoup de choses. J’ai organisé pas mal de Kanban Games avec Guillaume Lours et Laurent Morisseau en France et c’est très intéressant de voir des gens découvrir des sujets uniquement par la pratique. Ca m’intéresse de creuser l’utilisation des jeux en entreprise pour aider les gens à développer leurs capacités. Comment le temps d’entrainement ou de jeu, qui n’est pas du temps productif, apporte quelque chose à la capacité de production ?

  • Pour finir, un livre à recommander ?

Je viens de finir le livre de Reinertsen : The Principles of Product Development Flow, et je recommande en fait de ne pas le lire si vous n’avez pas un an pour vous en remettre. C’est le genre de livre pour lequel on est pas le même après l’avoir lu.

Et sinon How Google Tests Software, qui apprend beaucoup de choses sur le profil de testeur, sur l’approche ultra technique — qui ressemble à ce que je fais — qui consiste à développer des outils de tests pour les développeurs plutôt que de responsabiliser les testeurs. L’objectif est de ne pas avoir de testeurs.

  • Un livre que tu recommandes et un livre que tu ne recommandes pas ! Merci Dimitri !

Originally published at www.lesmanagersit.com.