Bonjour, je suis un coach organisationnel et Agile Technique, j’aide les organisations à diminuer leur complexité interne en passant sur une structure simple qui soit facilement mise à l’échelle. Je travaille avec les équipes IT pour qu’elles adoptent des pratiques modernes de développement, mais également une pensée orientée sur la collaboration et la responsabilité commune.
J’ai un long parcours de plus de 25 ans d’expérience, du développeur par passion, au développeur professionnel, j’ai commencé mon apprentissage de la programmation à l’âge de 12 ans, avec le Basic, l’assembleur et le Pascal. J’ai obtenu ma première certification de programmation à l’âge de 15 ans, et depuis j’ai pratiqué différents langages, comme le Perl, Fortran, Modula 2, Java, C#, Kotlin, Python, Elixir, Elm et Typescript. J’ai été architecte, évangéliste XP (Extreme Programming), formateur, Scrum Master, Product Owner, CTO, CEO et aujourd’hui Coach Organisationnel et Coach Agile Technique (ce que l’on nommait anciennement évangéliste XP).
Le Technical Agile Coaching est la capacité de guider des équipes sur des pratiques modernes de développement, mais pas uniquement. Il faut être capable de transformer ces personnes en une équipe qui collabore avec des objectifs communs et qui soient en capacité de s’améliorer en continu. Pour ça, il ne faut pas seulement avoir une solide expérience technique, mais également un bagage de métier dans la facilitation, le coaching professionnel, le mentoring et la formation. J’aime dire qu’il ne faut pas amener les pratiques sur un plateau doré, mais il faut que ces personnes comprennent d’elles-mêmes le pourquoi et le comment. Sinon cela passera d’une oreille à une autre et quand le coach part, tout tombe.
Cela dépend de qui est votre interlocuteur, mais il y a bien souvent le même problème racine.
Si je parle avec une personne qui a un poste de direction d’entreprise, elle voudrait que ses équipes puissent produire plus vite, mais tout va de plus en plus lentement. Malgré l’adoption d’une pratique Agile, Scrum par exemple. La définition de la “Business Agility est la capacité d’une organisation à s’adapter au contexte du marché rapidement.” Néanmoins, la vitesse réelle est celle de l’unité la plus lente, et souvent on retrouve des applications avec une dette technique qui n’est plus maîtrisable.
Si je parle avec les architectes et CTO, ils ont un objectif d’amélioration de la qualité, une meilleure maitrise des applications par de bonnes pratiques. Mais voilà, même si ces personnes adhérent progressivement à des valeurs comme le “Craft” (Artisanat Logiciel), elles n’ont ni le temps ni le savoir nécessaire pour transformer leurs équipes.
Pour ces deux types d’interlocuteurs, l’objectif ultime est déjà l’amélioration des retours clients, un client content, cela rend les équipes dirigeantes et de développement heureuses, et cette satisfaction nous aide dans notre productivité.
Oui, comme j’en ai parlé ci-dessus, il est important que le ou la coach agile technique n’ait pas seulement une expérience technique, mais bien plus que ça :
Oui quasiment, j’interviens par demi-journée par équipe. Pour la plupart des équipes que je suis, la session se déroule de la façon suivante :
Il faut forcément l’appui du management, qui va accepter que son équipe fasse autre chose que seulement produire du code ou des documents. Dans mon cas, je ne demande qu’une demi-journée par semaine !
Et évidemment, il ne faut pas d’équipes composées uniquement de personnes réfractaires.
Dans le Coaching Agile Technique, comme son nom le porte, il y a du coaching seulement si les personnes concernées sont d’accord d’être coachées.
Oui bien sûr, comme je l’ai dit au dessus, je me forme actuellement au “Organisation Relation and Systemic Coaching”, et j’utilise aussi des lectures de livres comme par exemple ceux de Alain Cardon et Kathy Anderson sur le Polarity Coaching.
Après j’utilise également mes connaissances en facilitation d’événement et la méthode “Training from back of the room”.
Le mieux est que je vous donne la description que l’on trouve sur leur site:
« Le programme ORSC propose un changement de paradigme dans la façon dont nous pensons et ressentons, agissons et réagissons dans différentes circonstances et dynamiques relationnelles : en entreprise, en famille, dans les milieux éducatifs et plus généralement dans les communautés du monde entier. Elle s’appuie sur 7 méthodologies – Pensée Systémique, Process Work, Théorie du Développement Organisationnel (TDO), Thérapie Familiale, Résolution Alternative des Conflits, Physique Quantique et Coaching Co-Actif – les programmes ORSC prônent le changement au travers de l’engagement conscient et responsable des personnes et de leurs relations. »
Actuellement je privilégie le format que partagent Marco Consolaro et Alessandro di Goia d’Alcor.Academy, que j’ai rejoint en novembre 2021. Il est basé sur le format “Training from the back of the room”. L’essentiel est que les participants découvrent par la pratique les bonnes habitudes. La session est un mélange de formation, facilitation et mentoring. C’est un format que j’aime beaucoup, j’ai actuellement de bien meilleurs résultats que dans d’autres approches que j’ai pu mettre en oeuvre dans le passé.
La règle dans chaque gestion du changement, c’est de ne pas forcer les personnes tant qu’elles ne sont pas des éléments dérangeants pour les autres. On va utiliser le pouvoir des modèles de décision. Quand vous voyez que vos collègues commencent à adhérer, à en parler de façon positive aux autres, tôt ou tard, vous allez mettre votre égo dans la poche et commencer à vous intéresser. Il ne faut surtout pas perdre votre temps à essayer de changer quelqu’un qui ne veut pas changer.
Maintenant, il m’est arrivé que je donne à une personne un problème complexe à faire sans appliquer le TDD, puis je l’ai laissé réaliser à sa façon et enfin je lui montre comment je l’aurais fait avec du TDD. Il y a pas photo, je suis plus rapide.
Quand l’organisation n’est pas prête à donner un peu de temps aux équipes pour s’améliorer, on a systématiquement des développeurs et développeuses sur des incidents ou autres demandes pendant la session de coaching. Pourtant ce sont des sessions que nous avons planifié à l’avance, il y aurait la possibilité de trouver d’autres personnes pour résoudre le problème.
Directement non, mais indirectement oui, comme pour chaque mission de coaching, on travaille sur les individus et l’équipe. Cela ne peut se mesurer directement. On va plutôt mesurer le niveau de satisfaction, le nombre de features livrées sur une période moyenne, etc.
Il n’y a pas vraiment de durée type d’un accompagnement, on travaille avec des humains, pas des machines. Par exemple pour le programme TDD, l’apprentissage se fait en 3 modules de 6 demi-journées. Le module DDD que j’avais donné l’an passé a été aussi de 6 demi-journées.
Après ces modules, je propose souvent un accompagnement pour s’assurer que ce qu’ils ont appris reste et perdure dans le temps.
Donc je pense, qu’il faut entre 6 et 12 mois, sachant que je ne suis jamais à plein temps avec une équipe.
Et oui, on le sent quand une équipe peux s’envoler sans le coach, c’est pour moi très gratifiant et c’est le moment de partir.
Selon le sujet, par exemple de l’Event Storming, après 2-3 jours l’équipe est autonome. Pour du TDD, sujet beaucoup plus complexe, je dirais qu’il me faut au moins 12 demi-journées.
N’ayez pas peur de dire quand vous ne maitrisez pas un sujet, vous êtes un humain et vous travaillez avec des humains. Tôt ou tard, on va le voir si vous parlez de chose que vous ne maitrisez pas. Quand vous expliquez quelque chose, c’est votre opinion, pas un fait, sinon il faut montrer vos sources.
Très tôt dans ma carrière, j’ai toujours aimé partagé mes connaissances avec les autres en donnant des formations techniques, en étant Evangéliste XP (ancien terme du début 2000). Je suis également orateur dans les conférences internationales depuis plus de 10 ans et j’ai co-fondé plusieurs communautés Agile et de Software Crafts.
Nous observons beaucoup d’entreprises qui ont comme objectif stratégique d’embrasser le monde digital et d’être plus compétitif dans ce monde VUCA (Volatile, Incertain, Complexe et Ambigu). On promet à ces responsables d’entreprise une accélération de leur capacité a répondre rapidement à ces changements de contexte. Certes vrai sur le papier, mais en réalité, la vitesse réelle de l’organisation est celle la plus lente de son système. Imaginez un “*Aigle avec un plomb au pied*”, il a beau être un oiseau rapide, mais avec un plomb on n’avance pas plus vite. Ce plomb, c’est souvent le service Informatique et tout son historique logiciel.
Du coup vous avez d’un côté la direction qui ne comprend pas pourquoi on ne va pas aussi vite que souhaité et de l’autre un service informatique en mode burnout, qui ne sait plus quoi faire pour s’en sortir, faute de moyen. Certes l’adoption de l’agilité et/ou du DevOps aide, mais ce n’est souvent pas suffisant, car on a rarement adressé le coeur du problème. On a juste préparé l’après, mais ce qui existe reste.
Beaucoup de responsables informatique sont justement des personnes qui ont comme mission de mettre en place des pratiques modernes de développement. Mais que beaucoup d’entre elles n’ont pas le temps ou la patience de le faire. C’est dans ce moment-là que l’on fait appel à des personnes comme moi pour solliciter leur expérience.
Je commence à rencontrer des jeunes développeurs et développeuses qui connaissent les pratiques modernes de développement, ce qui était très rare encore il y a 10 ans. Il y a beaucoup plus de monde qui vient aux événements communautaires sur le même sujet.
Je ne suis pas surpris qu’on viennent avec le terme Coach Crafts, mais je le trouve déjà dépassé, depuis 2020, on parle de modernisation logiciel, c’est bien plus que seulement du Software Crafts. On parle également de Culture d’entreprise, d’équipe, de crafts, de DevOps, Agile, de compréhension du besoin. C’est par exemple la voie qu’une partie de la communauté Crafts a décidé de suivre. Quand je lis les post francophones sur le Crafts, cela se limite souvent seulement à des sujets technique.
Je pense qu’on veut limiter à une communauté et c’est déjà contraire à la philosophie derrière le Software Crafts.
On peut me suivre sur mon site https//www.socraagile.ch ou me suivre sur mon compte linkedin qui est beaucoup plus actif.
[FR] Livre Blanc : Créer une culture de la connaissance dans vos équipes de développement logiciel [EN] White paper : Create a learning culture within your software development teams |