Interview croisée Coach Agile et Software Craftsmanship Coach
Jean-Michel Gourbeau, coach agile et Julien Devron, software craftsmanship coach chez Agaetis se sont réunis pour répondre à nos questions dans le cadre d’une interview croisée. Le sujet ? Leur rôle en tant que “coach”; que ce soit à Agaetis ou dans le cadre de leurs missions.
Quels sont les points communs et les liens entre le software craftsman et l’agilité ? Les fondamentaux sont-ils partagés entre ces deux méthodologies de travail ? Quel est l’apport de valeurs de ces deux profils pour les projets clients ? Les réponses à ces questions et bien plus encore dans notre article !
En quelques mots qu’est-ce qu’un coach Agile et surtout quel est son rôle chez Agaetis ?
Jean-Michel
Pour moi, c’est un agent du changement, au service d’un groupe ou d’une seule personne, et toujours de façon temporaire. Via sa connaissance et son expérience de l’agilité, il doit amener, proposer, des évolutions d’organisation et de fonctionnement bien sûr, mais avec ce challenge de la co-construction avec le groupe qu’il accompagne, pour créer un modèle itératif adapté aux contraintes, qu’elles soient internes ou externes. Pour quoi ? Dans notre milieu, c’est avant tout destiné à la création logicielle, mais plus largement à faciliter les intéractions au sein d’un écosystème professionnel et que la production de valeur soit efficace, sereine.
Son but, c’est la pérennité de ces changements, de ces solutions et que l’équipe soit en autonomie complète ; signifiant la fin de mission pour le coach Agile.
Chez Agaetis, ce rôle se compose de plusieurs facettes : nous essayons de capitaliser et d’ utiliser les compétences de notre trio de coachs Agile. Mes acolytes et moi-même, nous nous impliquons dans plusieurs activités chez Agaetis. La première, c’est d’être au contact et se mettre au service de notre équipe interne de réalisation de projet, en participant à la vie d’équipe, en animant quelques rituels, en écoutant, challengeant, proposant des idées, en essayant de faciliter certains points clés et en favorisant les liens entre différents profils de notre société. Généralement, nous assurons aussi un lien avec nos clients pour les missions que nous traitons en interne.
Seconde activité: la création et l‘animation d’ateliers ponctuels, au besoin, que ce soit en terme d’amélioration continue pour les projets (sans avoir à les connaître dans le détail d’ailleurs) ou lors de la prospection commerciale pour expliciter et cadrer un besoin client, par exemple. Quel que soit le domaine fonctionnel de l’entreprise, nous apportons cette conception et l’animation d’ateliers.
Un autre point, qui se développe depuis l’an passé et qui fait d’ailleurs partie de notre stratégie d’entreprise, c’est de proposer un rôle de médiation et la posture adéquate pour assurer de l’accompagnement individuel.
Jean-Michel
Pour moi, c’est un agent du changement, au service d’un groupe ou d’une seule personne, et toujours de façon temporaire. Via sa connaissance et son expérience de l’agilité, il doit amener, proposer, des évolutions d’organisation et de fonctionnement bien sûr, mais avec ce challenge de la co-construction avec le groupe qu’il accompagne, pour créer un modèle itératif adapté aux contraintes, qu’elles soient internes ou externes. Pour quoi ? Dans notre milieu, c’est avant tout destiné à la création logicielle, mais plus largement à faciliter les intéractions au sein d’un écosystème professionnel et que la production de valeur soit efficace, sereine.
Son but, c’est la pérennité de ces changements, de ces solutions et que l’équipe soit en autonomie complète ; signifiant la fin de mission pour le coach Agile.
Chez Agaetis, ce rôle se compose de plusieurs facettes : nous essayons de capitaliser et d’ utiliser les compétences de notre trio de coachs Agile. Mes acolytes et moi-même, nous nous impliquons dans plusieurs activités chez Agaetis. La première, c’est d’être au contact et se mettre au service de notre équipe interne de réalisation de projet, en participant à la vie d’équipe, en animant quelques rituels, en écoutant, challengeant, proposant des idées, en essayant de faciliter certains points clés et en favorisant les liens entre différents profils de notre société. Généralement, nous assurons aussi un lien avec nos clients pour les missions que nous traitons en interne.
Seconde activité: la création et l‘animation d’ateliers ponctuels, au besoin, que ce soit en terme d’amélioration continue pour les projets (sans avoir à les connaître dans le détail d’ailleurs) ou lors de la prospection commerciale pour expliciter et cadrer un besoin client, par exemple. Quel que soit le domaine fonctionnel de l’entreprise, nous apportons cette conception et l’animation d’ateliers.
Un autre point, qui se développe depuis l’an passé et qui fait d’ailleurs partie de notre stratégie d’entreprise, c’est de proposer un rôle de médiation et la posture adéquate pour assurer de l’accompagnement individuel.
Même question, en quelques mots qu’est-ce qu’un Software Craftsmanship coach et quel est son rôle chez Agaetis ?
Julien
Craftsmanship est un mouvement qui énonce les principes de l’artisanat logiciel. Le but est de réaliser des logiciels de la meilleure façon possible en partenariat avec le client et en allant vers l’essentiel de son besoin. Il y a de fortes valeurs agiles puisque on cherche toujours l’amélioration continue de l’équipe par l’auto-évaluation et le partage.
Mon rôle chez Agaetis est donc la mise en œuvre et la diffusion de ces pratiques. Dans ce but nous avons donc mis en place un sprint planning commun à toute l’équipe de réalisation, une épreuve d’humilité, on fait du pair programming, des katas, on met en œuvre TDD/BDD qui sont des pratiques de développements dans les produits (et pas seulement dans les Katas), on généralise la mise en place d’architectures émergentes, on libère la parole…. Et côté client, on s’efforce de ne plus parler de projet mais de produit et de ne plus avoir recours au traditionnel cycle en V mais un partenariat, sprint par sprint, avec notre client pour définir et répondre à ses besoins. Malheureusement le processus est difficile, car inverser la manière de penser ne se fait pas du jour au lendemain.
D’ailleurs mettre en place une pratique TDD/BDD est déjà pour la majorité des développeurs une inversion complète de leur façon de faire. On ne cherche pas à avoir un code couvert, mais un code documenté par les tests, qui nous prévient des régressions. Les tests c’est le code, c’est les tests qui font émerger les fonctions et leur logique. Dans la pratique la plus courante que l’on voit, on écrit la fonction, puis un test qui couvre le code, cette pratique amène à écrire des tests qui n’ont pas réellement d’utilité et qui ne préviennent de rien. Dans la pratique TDD, on écrit le test qui exprime notre intention, et ensuite on écrit le code qui valide cette intention, cela permet qu’à la moindre insertion d’un bug, le test nous alerte sur un dysfonctionnement. C’est un exemple pour démontrer dans quelle mesure l’inversion est réelle et complète, cela demande beaucoup de pratique et de méthode pour devenir quelque chose de naturel.
Quels sont les principes, les fondamentaux de l’agilité qui inspirent le Software Craftsmanship ?
Jean-Michel
Pour moi, plus qu’inspiré, l’état d’esprit est commun. Les valeurs fondamentales énoncées dans la littérature sont d’ailleurs proches. Concrètement, le craft, comme l’agilité, c’est un ensemble de pratiques parfaitement adaptées au service du client et d’une qualité maximum, dans notre milieu de la production logicielle.
Si nous focalisons sur les principes clés dont le software Craftsmanship se nourrit, on retrouve un haut niveau d’intéractions, l’excellence opérationnelle focalisée sur la création de valeur pour l’utilisateur, avec lequel l’équipe sera le plus proche possible… ce qui est Agile à 100%. On notera également la flexibilité, la réactivité, pour répondre du mieux possible à tous les changements durant un projet. Je laisse Julien entrer dans les détails, mais beaucoup de pratiques quotidiennes servent ces fondamentaux.
Julien
Ce sont ceux énoncés par le
manifeste software craftsmanship
à savoir :
- Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
- Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de valeur.
- Pas seulement les individus et leurs interactions, mais aussi une communauté professionnelle.
- Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.
Concrètement on met l’accent sur la qualité de développement par les pratiques comme le TDD, le pair programming, qui permettent également de partager la connaissance et le savoir faire, l’amélioration continue et aussi l’aspect professionnel, au sens organisationnel et collaboratif au sein de l’équipe. On cherche surtout à faire l’outil le plus adapté pour le client avec la plus grande qualité possible.
Le but c’est que l’outil que l’on réalise transforme le métier du client. Ce qui prend des heures au client, devra prendre quelques secondes grâce à l’outil réalisé par l’équipe et cela ne peut se faire que par une collaboration entre les deux et ce sans intermédiaire.
L’une des préoccupations du Craftsmanship est de mettre le plus vite possible et le plus constamment possible l’outil entre les mains des utilisateurs, récolter des feedbacks et l’améliorer encore et encore. L’idéal est de pouvoir, dès les premiers jours en production, avoir quelque chose de simple qui évolue suivant le besoin réel. On est loin de la façon où l’équipe développe pendant X mois et met en production un outil qui se révèle à l’utilisation antinomique avec le métier.
On cherchera à être bienveillant. Être bienveillant ce n’est pas être tout le temps gentil, être bienveillant c’est aussi être ferme quand on sait que l’équipe se plante sur un choix. Être bienveillant c’est aussi dire quand les choses sont mal faites ou encore se focaliser sur le résultat qu’a produit l’équipe et non sur ce qui a été fait individuellement. Dans des équipes, le tech lead est “gentil” mais il est interdit de toucher son code, pour diverses raisons: trop compliqué, risque de régressions non détectées parce que pas de pratiques TDD, soit parce qu’il a peur que l’on touche son code. Ce genre d’attitude, ce n’est pas de la bienveillance et c’est de l’égo mal placé. Si on a peur que son code soit touché c’est que quelque part on est conscient de ses faiblesses. C’est l’équipe qui produit le code, et celui-ci doit pouvoir être refactorisé ou modifié par chaque membre de l’équipe.
D’une façon plus personnelle j’aime dire que même les non développeurs, quand ils me voient coder comprennent ce que je fais, ça ne veut pas dire qu’ils sont capables de le faire ou de comprendre chaque mot clé, mais qu’ils comprennent le sens de ce que j’écris, voir même de corriger ou alerter quand l’intention dans le code elle est mal exprimée ou peu claire pour eux. C’est très important pour moi.
Jean-Michel
Les derniers mots de Julien, c’est du vécu lors d’une session de travail où nous étions connectés tous les deux. Le pair programming est un des éléments que l’on propose aux équipes que nous accompagnons, mais sans le pratiquer nous même en tant que coach Agile… Donc c’était intéressant pour moi de l’expérimenter, ne serait-ce que de suivre le code, d’en capter le sens et de questionner Julien. Finalement, je pense que dans son activité de Gemba, un manager devrait tester le pair programming avec les développeurs de l’équipe qu’il accompagne au quotidien.
En tout cas, les valeurs défendues par le Craft : une production itérative, une simplicité de mise en œuvre, la prise de feedback en continu, être en contact permanent avec l’utilisateur, la transparence et la confiance entre équipier… C’est exactement ce que nous cherchons à atteindre quand nous coachons. Quand l’équipe de réalisation est dans un tel état d’esprit, c’est un socle solide pour toute transformation agile et nous pouvons adresser en profondeur un autre volet comme le product ownership, le management, etc.
Jean-Michel
Pour moi, plus qu’inspiré, l’état d’esprit est commun. Les valeurs fondamentales énoncées dans la littérature sont d’ailleurs proches. Concrètement, le craft, comme l’agilité, c’est un ensemble de pratiques parfaitement adaptées au service du client et d’une qualité maximum, dans notre milieu de la production logicielle.
Si nous focalisons sur les principes clés dont le software Craftsmanship se nourrit, on retrouve un haut niveau d’intéractions, l’excellence opérationnelle focalisée sur la création de valeur pour l’utilisateur, avec lequel l’équipe sera le plus proche possible… ce qui est Agile à 100%. On notera également la flexibilité, la réactivité, pour répondre du mieux possible à tous les changements durant un projet. Je laisse Julien entrer dans les détails, mais beaucoup de pratiques quotidiennes servent ces fondamentaux.
Julien
Ce sont ceux énoncés par le manifeste software craftsmanship à savoir :
- Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
- Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de valeur.
- Pas seulement les individus et leurs interactions, mais aussi une communauté professionnelle.
- Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.
Concrètement on met l’accent sur la qualité de développement par les pratiques comme le TDD, le pair programming, qui permettent également de partager la connaissance et le savoir faire, l’amélioration continue et aussi l’aspect professionnel, au sens organisationnel et collaboratif au sein de l’équipe. On cherche surtout à faire l’outil le plus adapté pour le client avec la plus grande qualité possible.
Le but c’est que l’outil que l’on réalise transforme le métier du client. Ce qui prend des heures au client, devra prendre quelques secondes grâce à l’outil réalisé par l’équipe et cela ne peut se faire que par une collaboration entre les deux et ce sans intermédiaire.
L’une des préoccupations du Craftsmanship est de mettre le plus vite possible et le plus constamment possible l’outil entre les mains des utilisateurs, récolter des feedbacks et l’améliorer encore et encore. L’idéal est de pouvoir, dès les premiers jours en production, avoir quelque chose de simple qui évolue suivant le besoin réel. On est loin de la façon où l’équipe développe pendant X mois et met en production un outil qui se révèle à l’utilisation antinomique avec le métier.
On cherchera à être bienveillant. Être bienveillant ce n’est pas être tout le temps gentil, être bienveillant c’est aussi être ferme quand on sait que l’équipe se plante sur un choix. Être bienveillant c’est aussi dire quand les choses sont mal faites ou encore se focaliser sur le résultat qu’a produit l’équipe et non sur ce qui a été fait individuellement. Dans des équipes, le tech lead est “gentil” mais il est interdit de toucher son code, pour diverses raisons: trop compliqué, risque de régressions non détectées parce que pas de pratiques TDD, soit parce qu’il a peur que l’on touche son code. Ce genre d’attitude, ce n’est pas de la bienveillance et c’est de l’égo mal placé. Si on a peur que son code soit touché c’est que quelque part on est conscient de ses faiblesses. C’est l’équipe qui produit le code, et celui-ci doit pouvoir être refactorisé ou modifié par chaque membre de l’équipe.
D’une façon plus personnelle j’aime dire que même les non développeurs, quand ils me voient coder comprennent ce que je fais, ça ne veut pas dire qu’ils sont capables de le faire ou de comprendre chaque mot clé, mais qu’ils comprennent le sens de ce que j’écris, voir même de corriger ou alerter quand l’intention dans le code elle est mal exprimée ou peu claire pour eux. C’est très important pour moi.
Jean-Michel
Les derniers mots de Julien, c’est du vécu lors d’une session de travail où nous étions connectés tous les deux. Le pair programming est un des éléments que l’on propose aux équipes que nous accompagnons, mais sans le pratiquer nous même en tant que coach Agile… Donc c’était intéressant pour moi de l’expérimenter, ne serait-ce que de suivre le code, d’en capter le sens et de questionner Julien. Finalement, je pense que dans son activité de Gemba, un manager devrait tester le pair programming avec les développeurs de l’équipe qu’il accompagne au quotidien.
En tout cas, les valeurs défendues par le Craft : une production itérative, une simplicité de mise en œuvre, la prise de feedback en continu, être en contact permanent avec l’utilisateur, la transparence et la confiance entre équipier… C’est exactement ce que nous cherchons à atteindre quand nous coachons. Quand l’équipe de réalisation est dans un tel état d’esprit, c’est un socle solide pour toute transformation agile et nous pouvons adresser en profondeur un autre volet comme le product ownership, le management, etc.
Est-ce que le software craftsmanship coach remplacera le coach agile ? Pourquoi ?
Jean-Michel
Je ne le pense pas et j’espère qu’on le ressent déjà dans notre réponse précédente; les compétences du coach Craftsmanship sont spécialisées sur le volet technique du développement logiciel. Si une équipe Agile éprouve des difficultés à maîtriser la qualité de son travail, l’expertise d’un coach Craftsmanship sera plus adaptée. L’ apport sera précis, pointu avec beaucoup plus de technique pour guider l’équipe. Je crois que les deux rôles sont complémentaires, particulièrement lorsqu’une équipe Agile est jeune.
Dans d’autre cas, à l’issue d’un diagnostic, quand le coach Agile travaillera les volets organisationnel et relationnel, le coach Craftsmanship saura accompagner l’équipe dans l’amélioration de ses pratiques de production, de développement, son outillage spécifique, etc.
Julien
Pas vraiment, ils sont complémentaires, le Craftsmanship impose un état d’esprit totalement agile, même si beaucoup sont un retour vers la méthode de l’eXtrême Programming. Les outils et l’état d’esprit du coach agile sont utiles, au contraire il doit être challengé et permettre une adhésion de la solutions de tous les maillons de la chaîne à savoir, équipe réalisatrice, clients et utilisateurs.
Jean-Michel
Je ne le pense pas et j’espère qu’on le ressent déjà dans notre réponse précédente; les compétences du coach Craftsmanship sont spécialisées sur le volet technique du développement logiciel. Si une équipe Agile éprouve des difficultés à maîtriser la qualité de son travail, l’expertise d’un coach Craftsmanship sera plus adaptée. L’ apport sera précis, pointu avec beaucoup plus de technique pour guider l’équipe. Je crois que les deux rôles sont complémentaires, particulièrement lorsqu’une équipe Agile est jeune.
Dans d’autre cas, à l’issue d’un diagnostic, quand le coach Agile travaillera les volets organisationnel et relationnel, le coach Craftsmanship saura accompagner l’équipe dans l’amélioration de ses pratiques de production, de développement, son outillage spécifique, etc.
Julien
Pas vraiment, ils sont complémentaires, le Craftsmanship impose un état d’esprit totalement agile, même si beaucoup sont un retour vers la méthode de l’eXtrême Programming. Les outils et l’état d’esprit du coach agile sont utiles, au contraire il doit être challengé et permettre une adhésion de la solutions de tous les maillons de la chaîne à savoir, équipe réalisatrice, clients et utilisateurs.
Le software craftsmanship est-il issu d’autres courants que l’agilité ?
Julien
Ce sont des mouvements complémentaires l’un à l’autre. L’agilité prend en compte surtout l’aspect organisationnel de l’équipe, alors que le Craftsmanship prend aussi en compte l’aspect des choix de design techniques, et la manière de développer. Le craftsmanship est surtout une demande de remise en cause des pratiques que l’on voit depuis des décennies et qui ne fonctionnent pas ou peu dans le domaine du logiciel comme le cycle en V, avec ses specs et les chiffrages sur des années. Des choix de designs qui ne fonctionnent pas ou très mal, qui sont peu évolutifs et pourtant employés dans 99% des projets, mais aussi le manque d’entraide dans les équipes, les prises de décisions techniques par des gens qui n’ont que le niveau hiérarchique et non le savoir-faire.
Dans quelle mesure un coach agile peut-il épauler un software craftsman ?
Julien
Il peut donner des outils à essayer pour améliorer la coordination de l’équipe, que ce soit dans des cérémonies à tenter ou dans leur format. De même, aider une équipe et un client peu mature dans l’expression du besoin. Mais aussi être un atout fort dans le changement de l’état d’esprit des divers intervenants. JM et moi discutons énormément sur tous ces aspects, nos points de vues divergent rarement, nous avons souvent des constats similaires, nos savoirs sont complémentaires, nos états d’esprit sont les mêmes.
Nous sommes tous les deux bienveillants mais dans une forme différente, pour le coach agile la bienveillance, c’est l’entente de l’équipe, protéger l’équipe de ce qui peut la parasiter. La mienne va être plus dans les hard skills (la pratique du code), la sienne plus sur les softs skills.
Jean-Michel
En effet, dans le cas où les deux rôles interviennent, le coach Agile interviendra au niveau des rituels de l’équipe et les liens avec son écosystème.
Il pourra travailler sur toute la partie du product ownership ; ses processus de décision, de priorisation… tout ce qui permettra d’amener les développeurs à travailler dans les meilleures conditions possibles.
En tout cas, c’est un travail en binôme qui se met en place et je pense que pour des transformations à grande échelle, c’est un vrai avantage de bénéficier de cette spécialité Craftsmanship dans une équipe de coachs. Finalement, le duo permet d’être plus efficient, mais surtout complet, lors de la transformation d’une ou plusieurs équipes d’ailleurs.
Un coach Agile travaillera en amont pour amorcer le changement d’état d’esprit, pour former à un nouveau cadre de travail. Il va créer les conditions nécessaires sur lesquelles le coach Craftsmanship s’appuiera pour, ensemble, déployer de nouvelles pratiques, des rituels, qui serviront au succès de la démarche.
Julien
Je complèterais en précisant que la transformation, c’est surtout arriver à identifier 3 types de personne : les adopteurs, les bloqueurs, et les indécis. Le duo va s’efforcer de transformer les indécis en adopteurs, tout en diminuant les effets des bloqueurs.
Julien
Il peut donner des outils à essayer pour améliorer la coordination de l’équipe, que ce soit dans des cérémonies à tenter ou dans leur format. De même, aider une équipe et un client peu mature dans l’expression du besoin. Mais aussi être un atout fort dans le changement de l’état d’esprit des divers intervenants. JM et moi discutons énormément sur tous ces aspects, nos points de vues divergent rarement, nous avons souvent des constats similaires, nos savoirs sont complémentaires, nos états d’esprit sont les mêmes.
Nous sommes tous les deux bienveillants mais dans une forme différente, pour le coach agile la bienveillance, c’est l’entente de l’équipe, protéger l’équipe de ce qui peut la parasiter. La mienne va être plus dans les hard skills (la pratique du code), la sienne plus sur les softs skills.
Jean-Michel
En effet, dans le cas où les deux rôles interviennent, le coach Agile interviendra au niveau des rituels de l’équipe et les liens avec son écosystème.
Il pourra travailler sur toute la partie du product ownership ; ses processus de décision, de priorisation… tout ce qui permettra d’amener les développeurs à travailler dans les meilleures conditions possibles.
En tout cas, c’est un travail en binôme qui se met en place et je pense que pour des transformations à grande échelle, c’est un vrai avantage de bénéficier de cette spécialité Craftsmanship dans une équipe de coachs. Finalement, le duo permet d’être plus efficient, mais surtout complet, lors de la transformation d’une ou plusieurs équipes d’ailleurs.
Un coach Agile travaillera en amont pour amorcer le changement d’état d’esprit, pour former à un nouveau cadre de travail. Il va créer les conditions nécessaires sur lesquelles le coach Craftsmanship s’appuiera pour, ensemble, déployer de nouvelles pratiques, des rituels, qui serviront au succès de la démarche.
Julien
Je complèterais en précisant que la transformation, c’est surtout arriver à identifier 3 types de personne : les adopteurs, les bloqueurs, et les indécis. Le duo va s’efforcer de transformer les indécis en adopteurs, tout en diminuant les effets des bloqueurs.
Quels sont les apports des communautés de pratiques, que ce soit dans le craftsmanship ou l’agilité ?
Jean-Michel
Bien qu’il y ait des spécificités évidentes, l’un des fondements de l’état d’esprit que nous avons en commun, ce sont les intéractions directes.
Nos communautés de pratiques se croisent, se rejoignent. En termes d’apports communs, on retrouve le partage d’expérience, l’intelligence collective, la veille, le pairing, l’enrichissement personnel, de nouvelles pratiques/techniques/outils à tester, de la résolution de problème… et certainement d’autres.
Ensuite, bien sûr, les sujets techniques seront différents, ce qui nous nourrit dans notre métier et participe à notre ouverture d’esprit, nos prises de recul sur ce que l’on fait, ce que l’on apporte techniquement.
Julien
Les apports des communautés vont surtout permettre d’évangéliser le savoir-faire pour qu’il soit de plus en plus présent dans les pratiques des développeurs.
Jean-Michel
Bien qu’il y ait des spécificités évidentes, l’un des fondements de l’état d’esprit que nous avons en commun, ce sont les intéractions directes.
Nos communautés de pratiques se croisent, se rejoignent. En termes d’apports communs, on retrouve le partage d’expérience, l’intelligence collective, la veille, le pairing, l’enrichissement personnel, de nouvelles pratiques/techniques/outils à tester, de la résolution de problème… et certainement d’autres.
Ensuite, bien sûr, les sujets techniques seront différents, ce qui nous nourrit dans notre métier et participe à notre ouverture d’esprit, nos prises de recul sur ce que l’on fait, ce que l’on apporte techniquement.
Julien
Les apports des communautés vont surtout permettre d’évangéliser le savoir-faire pour qu’il soit de plus en plus présent dans les pratiques des développeurs.
Quels sont les sujets qui vous intéressent lorsque vous faites de la veille et pourquoi ?
Julien
Plus jeune c’était très orienté “technique”, à savoir les nouveaux langages frameworks de développement etc… Aujourd’hui c’est surtout comment améliorer ma pratique et la qualité de mes développements, par exemple comment les autres implémentent les architectures émergentes tels que clean archi ou archi hexagonale, comment ils font leur TDD etc… Je m’intéresse énormément au côté humain et à l’interaction au sein de la société, les plus gros problèmes que j’ai rencontrés pour faire de la qualité sont plus du côté humain que technique, la technique étant souvent freinée par l’humain. C’est d’ailleurs là que le coach agile est une aide pour moi, ce sont des sujets que nous pouvons partager.
Jean-Michel
Au-delà de nouveaux formats d’ateliers, des serious game, le change management m’intéresse et particulièrement le volet psychologique d’une équipe ; quelles sont ses spécificités ? Comment est-ce qu’elle gagne en maturité ? Comment gérer ces changements, trouver le/les bons rythmes ? Comment comprendre et gérer d’éventuels conflits ? …
Je pense que la veille (et le partage au sein des communautés citées auparavant) apporte de la profondeur au coaching et sans cette teinte d’intelligence émotionnelle, il est compliqué d’embarquer les équipiers sur un chemin qui va les amener à changer leurs pratiques, leurs habitudes, leur conception de leur travail.
Julien
Plus jeune c’était très orienté “technique”, à savoir les nouveaux langages frameworks de développement etc… Aujourd’hui c’est surtout comment améliorer ma pratique et la qualité de mes développements, par exemple comment les autres implémentent les architectures émergentes tels que clean archi ou archi hexagonale, comment ils font leur TDD etc… Je m’intéresse énormément au côté humain et à l’interaction au sein de la société, les plus gros problèmes que j’ai rencontrés pour faire de la qualité sont plus du côté humain que technique, la technique étant souvent freinée par l’humain. C’est d’ailleurs là que le coach agile est une aide pour moi, ce sont des sujets que nous pouvons partager.
Jean-Michel
Au-delà de nouveaux formats d’ateliers, des serious game, le change management m’intéresse et particulièrement le volet psychologique d’une équipe ; quelles sont ses spécificités ? Comment est-ce qu’elle gagne en maturité ? Comment gérer ces changements, trouver le/les bons rythmes ? Comment comprendre et gérer d’éventuels conflits ? …
Je pense que la veille (et le partage au sein des communautés citées auparavant) apporte de la profondeur au coaching et sans cette teinte d’intelligence émotionnelle, il est compliqué d’embarquer les équipiers sur un chemin qui va les amener à changer leurs pratiques, leurs habitudes, leur conception de leur travail.
Pourquoi est-il clé pour Agetis de faire travailler ensemble vos deux profils ?
Jean-Michel
Souvent les profils techniques voient le coach Agile comme un gentil animateur, jugé peu compétent sur le développement. En associant ces deux rôles, notre action gagne en crédibilité. Pour Agaetis, c’est l’opportunité de proposer un accompagnement au changement efficace. Nous sommes en mesure de construire une équipe de coachs aux spécificités, aux expertises différentes et complémentaires. Je considère que c’est un facteur de succès supplémentaire pour le déploiement de l’agilité, ou les transformations Agiles auxquelles nous participons.
Julien
Je rajouterai qu’on modifie aussi la façon de vendre la fabrication du logiciel et la collaboration avec le client pour devenir des partenaires. Sans cela il n’y a pas de Software Craftsmanship.
Jean-Michel
Souvent les profils techniques voient le coach Agile comme un gentil animateur, jugé peu compétent sur le développement. En associant ces deux rôles, notre action gagne en crédibilité. Pour Agaetis, c’est l’opportunité de proposer un accompagnement au changement efficace. Nous sommes en mesure de construire une équipe de coachs aux spécificités, aux expertises différentes et complémentaires. Je considère que c’est un facteur de succès supplémentaire pour le déploiement de l’agilité, ou les transformations Agiles auxquelles nous participons.
Julien
Je rajouterai qu’on modifie aussi la façon de vendre la fabrication du logiciel et la collaboration avec le client pour devenir des partenaires. Sans cela il n’y a pas de Software Craftsmanship.
Quel est l’apport de valeurs pour nos projets clients ?
Julien
Pour moi la valeur principale est d’avoir au final un logiciel bien conçu et adapté à son besoin. L’adoption du produit par le client est ma principale préoccupation. Je préfère faire quelque chose de simple, qui facilite la vie du client et boost son business, plutôt que quelque chose d’extrêmement complexe techniquement, mais qui le ralentit par rapport à son ancienne méthode.
Sortir de la croyance que le métier du dev c’est de rédiger des lignes de code ; notre métier est de comprendre celui du client et de le transposer sous forme d’outil. C’est pour cette raison que les sprints ne doivent pas être pré-anticipés et qu’il doit y avoir des discussions constantes entre le client et l’équipe sur ce qui à été produit et ce qui va l’être. Ce qui était imaginé au départ par le client ne ressemble jamais à ce qui est produit pour une raison simple: le client connaît son métier, mais c’est l’équipe réalisatrice qui connaît les outils de l’informatique et c’est la fusion des deux qui répond au besoin réel.
Jean-Michel
En conclusion, pour une transformation, nous serons efficients ; nous bornons efficacement les changements nécessaires pour chaque équipe via un volet organisationnel et un volet technique poussé, détaillé. Les chantiers d’amélioration pouvant être parallélisés, je pense néanmoins qu’il y a un point d’attention; nous devons servir les équipes sans les surcharger ou les étouffer.
Pour nos projets clients pris en charge chez Agaetis, notre équipe de réalisation utilise déjà ces pratiques au quotidien pour assurer la meilleure qualité possible. A nous d’entretenir et de continuer à progresser dans cette voie.
Julien
Pour moi la valeur principale est d’avoir au final un logiciel bien conçu et adapté à son besoin. L’adoption du produit par le client est ma principale préoccupation. Je préfère faire quelque chose de simple, qui facilite la vie du client et boost son business, plutôt que quelque chose d’extrêmement complexe techniquement, mais qui le ralentit par rapport à son ancienne méthode.
Sortir de la croyance que le métier du dev c’est de rédiger des lignes de code ; notre métier est de comprendre celui du client et de le transposer sous forme d’outil. C’est pour cette raison que les sprints ne doivent pas être pré-anticipés et qu’il doit y avoir des discussions constantes entre le client et l’équipe sur ce qui à été produit et ce qui va l’être. Ce qui était imaginé au départ par le client ne ressemble jamais à ce qui est produit pour une raison simple: le client connaît son métier, mais c’est l’équipe réalisatrice qui connaît les outils de l’informatique et c’est la fusion des deux qui répond au besoin réel.
Jean-Michel
En conclusion, pour une transformation, nous serons efficients ; nous bornons efficacement les changements nécessaires pour chaque équipe via un volet organisationnel et un volet technique poussé, détaillé. Les chantiers d’amélioration pouvant être parallélisés, je pense néanmoins qu’il y a un point d’attention; nous devons servir les équipes sans les surcharger ou les étouffer.
Pour nos projets clients pris en charge chez Agaetis, notre équipe de réalisation utilise déjà ces pratiques au quotidien pour assurer la meilleure qualité possible. A nous d’entretenir et de continuer à progresser dans cette voie.
Ressources Agaetis
