Transcription de l'épisode : "Fanny Klauk, Les développeurs et les méthodes agiles dans la pratique"
Terry : Salut Fanny.
Fanny : Bonjour Terry.
Terry : Merci de prendre du temps aujourd'hui pour parler d'agilité, mais on va parler d'agilité d'un point de vue vraiment pratique et en particulier vu sous le prisme des développeurs. Sur Just A Click, j'ai déjà fait un épisode plus sur la partie théorique avec Emmanuel qui est un épisode hyper intéressant que je recommande d'ailleurs d'écouter aux personnes intéressées par ce sujet. Et aujourd'hui avec toi on va rentrer plus dans la mise en application et notamment sur l'agilité vue par les équipes de développeurs, les problématiques qu'ils peuvent rencontrer. Et puis moi je vais apporter aussi un regard et te challenger sur ces sujets là et comment on fait le lien aussi avec les pratiques Product Management. Et donc je pense que ça va être hyper intéressant. Donc avant de rentrer dans le vif du sujet, je te propose de te présenter brièvement. Et puis ensuite, on va discuter de tout ça.
Fanny : Ça marche. Je suis Fanny Clauque, je suis TechRel et accompagnatrice agile chez AppSite depuis trois ans et demi maintenant. Et c'est exactement ce dont on va parler. J'accompagne les équipes de développement au quotidien dans le passage ou dans la pérennisation de l'agilité. Donc, ce qui est très rigolo, c'est que la demande généralement vient d'un mandataire, donc quelqu'un qui demande à ce que je vienne aider généralement quand il y a des problématiques, sinon ce n'est pas intéressant. pour que je vienne du coup aider les équipes là-dedans. Et en fait, je trouve que les équipes sont elles aussi très demandeuses de s'améliorer, de s'en sortir, de trouver des solutions. Et donc, j'ai tendance à dire que j'interviens à la demande du mandataire et des équipes elles-mêmes.
Terry : Ok, très clair. Et du coup aussi pour bien comprendre d'où tu viens, on en avait échangé en off, tu avais un passé historique aussi de développeur ?
Fanny : Oui, j'ai commencé à là.
Terry : Donc je pense que c'est un point aussi important pour les devs qui peuvent nous écouter ou les tech leads. Tu arrives pas juste avec une casquette purement théorique, au contraire, tu as cette légitimité là du fait de venir aussi du monde du dev à la base et donc de peut-être mieux comprendre aussi les enjeux, les frictions qui peuvent y avoir quand on essaie de mettre en place ces pratiques.
Fanny : Alors je suis pas omnisciente mais c'est vrai que c'est quelque chose qui aide énormément quand on vient en fait du même domaine, qu'on a déjà parlé le même langage, qu'on a rencontré aussi les mêmes problématiques, qu'on a fait des tentatives, on a testé plusieurs choses. Donc on n'est pas là en fait pour apporter la solution, mais on est là pour réfléchir à quelles pourraient être les solutions possibles, lesquelles on va tester, lesquelles nous sont les plus confortables et celles qu'on garde au final. Donc en fait, c'est ça qui est très précieux. Et j'ai envie de dire, c'est la même chose aussi pour les gens qui sont en reconversion, par exemple. Je connais une personne que j'affectionne particulièrement, qui est Pierre Vosin, par exemple. qui lui a fait de l'optique avant de venir sur le domaine numérique. Et ça lui a énormément servi et nous ça nous a énormément apporté d'avoir son point de vue justement très différent. Donc en fait, dans tous les métiers, quel que soit votre passé, il y a toujours quelque chose qui est bon à apprendre pour justement que ça nous aide au quotidien.
Terry : Ok très clair oui donc effectivement tu fais bien de nuancer c'est pas juste faire de l'agilité tu peux c'est il n'y a pas une une voix unique et c'est pas parce que tu n'as pas été d'avant que tu peux pas te retrouver effectivement coach agile ensuite c'est.
Fanny : Une aide précieuse ça aide énormément mais c'est pas le fondement même je pense que d'ailleurs la chose la plus intéressante c'est d'abord de savoir se mettre à la place des gens qui vivent le projet le produit au quotidien et se mettre à leur place, avoir de l'empathie et savoir les aider à évaluer quelles pourraient être les différentes solutions.
Terry : Top, du coup si je devais te poser la question quels sont aujourd'hui les trois plus gros problèmes auxquels tu es confronté quand tu vas accompagner ou aider des équipes du coup autour de l'agilité et notamment moi ce qui m'intéresse c'est du regard de l'équipe de développement. En gros, je ne sais pas comment sont structurées les missions que tu peux éventuellement faire, je ne sais pas si tu en fais toujours, mais en tout cas, ce que j'imagine c'est que tu arrives sur un projet, tu as une équipe de dev qui est déjà en place, et en gros, quels sont les problèmes qui vont tout de suite venir te partager autour de ça ?
Fanny : Alors oui, j'ai bien toujours des missions parce que c'est ce qui aide à rester déjà au courant de ce qui se passe, à rester humble aussi, de pas se dire ben non c'est bon j'ai tout vu, je sais tout, je vais vous apporter la solution ultime. Donc je continue à travailler avec différentes équipes. Trois principaux problèmes, il y en a déjà un déjà qui me vient à l'esprit directement, c'est le fait de fonctionner en mode siloté. On aurait tendance à dire bah oui mais maintenant l'agilité ça existe depuis longtemps, il y a des pratiques DevOps aussi qui sont de plus en plus prégnantes. Eh bien bizarrement c'est toujours aussi siloté dans les équipes dans lesquelles j'interviens. Et donc c'est un jeu constant de rejets de balles entre les équipes devs, Quand quelque chose ne fonctionne pas bien, c'est forcément la faute d'une autre équipe aux alentours, que ce soit métier ou obs. A l'inverse, les métiers, c'est forcément la faute des devs, et puis les obs, c'est forcément la faute de quelqu'un d'autre aussi. Et en fait, il y a cette espèce de triangle des Bermudes qui persiste. Et c'est là où moi j'interviens et où j'aime bien intervenir. C'est le fait de juste de faire comprendre qu'en fait, des fois, juste se poser, juste discuter, repenser objectif produit. Qu'est-ce qu'on veut vraiment faire ou est-ce qu'on veut aller tous ensemble normalement ? Déjà, il faut se mettre au clair là-dessus. Mais c'est là où j'interviens et où j'aime bien apporter, moi, mon savoir-faire, c'est dé-siloter les choses et arrêter d'avoir des murs, en fait, entre les différents sachants. Les deux autres difficultés qui pourraient être...
Terry : François, si tu voulais rebondir. Garde-les en tête, ces deux autres. Au pire, je te relancerai après. Déjà, sur cette première, du coup, avec moi, ma casquette produit, j'ai envie de te dire, c'est exactement le rôle d'un product manager que de mettre ce liant entre les différentes équipes. Donc toi, quel est ton regard par rapport à l'intérêt des méthodes agiles, pour mettre ce lien aussi, comment du coup tu vois l'apport de ces méthodes-là, ou en tout cas leur adaptation, parce que souvent ces équipes qui ont ces problèmes de silos, ils vont penser faire des méthodes agiles en plus, ou en tout cas ils vont se labelliser comme faisant du scrum, mais derrière on voit bien que ça répond pas du tout au problème premier qui est ces silos. Donc toi comment avec la pratique agile tu essaies de mettre ce lien pour essayer de faire le parallèle ensuite derrière avec le produit ?
Fanny : Il y a une phrase que j'adore dans les pratiques agiles et que j'essaye de centrer toutes mes missions là-dessus, c'est il faut être auto-organisé, autonome et à savoir qu'il faut le maximum d'expertise suffisante pour que le produit ait une réelle valeur. Et en fait, on a tout résumé en disant ça. Il faut le nombre de personnes qui ait l'expertise suffisante pour le faire. Donc s'il faut savoir parler métier, il faut quelqu'un du métier. S'il faut savoir parler tech, il faut quelqu'un de la tech. S'il faut aller au-delà, parler prod, parler maintien de la prod, il faut un OPS, etc. Et ce lien là dont tu parles en fait, si on n'arrive pas à le co-construire ensemble, on met des rôles supplémentaires. Dans le framework Scrum par exemple, il y a le Scrum Master qui est vraiment dédié à ça normalement au début des équipes agiles. Tu parles de Product Manager, mais ça peut être n'importe qui en fait qui ait ce rôle plus poussée de mettre du lien, si les équipes ne le font pas déjà naturellement entre elles. Et des fois, et c'est là où j'interviens moi, c'est quand ça ne va plus. On a dépassé cette ligne. On est tous ensemble dans le même bateau, on va y aller. Et donc mon rôle, c'est vraiment de remettre cette compréhension de tous ensemble, on est plus fort. Et puis, c'est pas le monde des bisonours, encore une fois.
Terry : — Ça me va bien, mon podcast, la conclusion qui est générique, c'est l'introduction, et c'est quelque chose auquel je crois vraiment. Seul on va vite, mais ensemble on va loin. Donc pour moi, il n'y a pas de sujet là-dessus. Pour revenir un peu sur quand tu disais que ça peut être Product Manager ou autre, Moi ça me lève quand même une question. Donc sur l'auto-organisation des équipes et du coup la responsabilisation de toutes les participants de l'équipe qui construisent le produit tech, ça fait complètement sens et peu importe les méthodes utilisées il faut tendre vers ça au plus possible. Pour autant le sujet moi qui me questionne c'est à un moment, dans un navire, t'as toujours besoin d'un capitaine. Parce que si t'as pas de capitaine, il faut qu'il y ait quelqu'un qui tranche sur certaines décisions. Dans le cas, par exemple, de Scrum, le Scrum Master, c'est pas lui qui a l'autorité pour dire, là, la priorité 1, c'est d'aller ici. Et donc, autant tendre vers une auto-organisation des équipes et une responsabilisation, oui. Par contre, quand tu dis, tout le monde peut plus ou moins prendre ce rôle, product manager là dessus moi je suis plutôt en désaccord parce que j'ai tendance à vouloir dire non il faut qu'il y ait in fine une personne qui décide alors peut-être pas de comment on construit la solution mais en tout cas de quel est le problème auquel on veut répondre et là dessus je suis curieux d'avoir ton point de vue dans le cadre du coup d'équipe agile parce que on pense là souvent à l'organisation des équipes en interne donc tu parlais des points de friction par exemple entre des devs et des ops donc typiquement le classique c'est je dev quelque chose le produit marche quand je suis en environnement de test interne potentiellement en environnement de pré-prod Ensuite ça passe en prod à ceux qui doivent opérer le système et là ils reviennent toquer à la porte en disant mais votre système il est ingérable en prod, nous nos opérateurs ils n'ont aucune procédure. Les choses classiques on va dire et déjà c'est un premier problème entre des départements techniques. Et après, il y a l'autre problème qui est le business qui lui dit, moi je demande cette feature parce que j'ai un gros client dans un mois qu'il faut que j'arrive à signer et il voudra signer uniquement sur notre feature. Et en face, j'ai des devs qui me répondent, là on ne peut pas vraiment dire, ça va dépendre de notre vélocité. Et du coup, on a un deuxième problème ici qui est entre le business et la capacité derrière in fine aux équipes tech à livrer quelque chose pour répondre à des enjeux business. Et c'est là où pour moi, pour faire tout ça, tu as besoin d'une personne type product manager. Et je suis curieux d'avoir ta vision pour répondre à ces deux problématiques.
Fanny : Déjà pour préciser ma pensée, je n'ai pas dit que tout le monde pouvait être Product Manager, je disais juste que l'aspect facilitant, le liant, le fameux liant, tout le monde est capable d'en mettre un petit peu. Et quand moi j'interviens, c'est quand même ça, c'est plus possible parce qu'il y a eu un historique, il y a eu un passé, il y a eu des choses qui sont un peu dégradées et que du coup on n'est plus capable justement, chacun, d'amener ce liant-là par nous-mêmes. Et donc on a besoin de quelqu'un de neutre, idéalement, d'extérieur et qui vient apporter ça. sur ce que tu as exposé, que moi je rallierais plutôt pas forcément de prendre la décision mais de donner le cap en fait, d'embarquer tout le monde vers un cap, vers une vision. D'ailleurs c'est un petit changement dans la dernière version du Scrum Guide, c'est qu'on ne parle plus de produit de goal mais de vision produit. Et exactement, tu as raison, il faut quelqu'un qui embarque l'équipe vers quelque chose. Et donc à un moment donné, pour déterminer ce quelque chose, il faut se tatuer. Et c'est très important que ce soit qu'une seule personne justement qui fasse cette chose-là. Par contre, il le fait en considération de beaucoup, beaucoup de choses. Il va le faire en fonction de son propre avis du marché, ses propres expériences. la connaissance des experts métiers, des futurs utilisateurs, s'il a la chance en plus de connaître des utilisateurs finaux, directs, c'est juste parfait. Et puis aussi, il aura une écoute attentive sur les possibilités techniques de réaliser de son équipe et des Ops, que je considère aussi dans l'équipe, on verra par la suite. Donc sur comment gérer le travail en adéquation avec ses tripartis en fait, Je pense que c'était malheureux, en fait. Triangle des Bermudes, les pauvres. Non, on peut faire un monde meilleur avec ces trois passages.
Terry : On peut dire le triangle d'or.
Fanny : Le triangle d'or, je préfère. Et c'est assez simple. Il y a des choses. humainement logique qui se passe, quand on a besoin de quelque chose, on se lève, on lève la tête et on va poser la question à une personne et on attend le retour pour savoir quelle orientation on doit choisir. Dans une équipe, c'est exactement pareil. Si je manque de compétences, de connaissances, d'informations, de précisions pour mener à bien mon travail, je vais aller poser ma question. Ça peut être métier, ça peut être hobby, ça peut être n'importe quoi pour le récupérer. plus mon interlocuteur sera loin, plus ce sera compliqué, et plus je vais travailler en mode asynchrone en fait. Je vais attendre que la réponse vienne pour pouvoir continuer. Donc je suis en mode blocage. Pour le VC blocage, c'est très simple. Il faut réduire le temps, il faut réduire la distance. Et c'est pour ça qu'encore une fois, je vais me référer à cette phrase, mais dans l'équipe, il faut un maximum d'expertise nécessaire à l'intérieur pour pouvoir avancer. Donc si j'ai besoin d'un métier, très souvent je peux même lui proposer de venir dans l'équipe ponctuellement.
Terry : Et du coup ce métier tu le fais intervenir dans quel type de cérémonie par exemple, à quel moment ?
Fanny : Alors ça dépend, tu fais référence au framework Scrum ? D'accord parce que comme je ne travaille pas que en Scrum...
Terry : Après je parle de Scrum mais on pourrait parler sur d'autres approches qui sont plus en flux tendu type Kanban ou même d'autres approches Dans l'XP Programming, le.
Fanny : Demandeur, l'utilisateur, est là en permanence, par exemple. Pour justement rapprocher... Oui, alors voilà.
Terry : Mais c'est très bien que tu dises ça. C'est très bien que tu dises ça, parce que du coup, c'est exactement ce type de point que j'ai envie de challenger. Parce que si ton utilisateur final, qui est, on va dire, représenté... Alors, de manière réaliste, ça va être du coup sur une organisation... Sur des organisations qui sont assez silotées, ça va être ton besoin métier, effectivement. Donc... que ce soit un CSM, que ce soit un commercial, des personnes qui sont en contact direct avec les utilisateurs finaux à qui tu vends ton produit. Ces personnes, elles ont un job premier qui est de faire ce job-là de commercial de CSM, donc elles ne peuvent pas être H24 au sein de l'équipe de développement. Pour autant on a besoin de leurs inputs. Et c'est là ma question, je parlais de cérémonie donc effectivement c'était complètement biaisé sur Scrum, mais sur d'autres frameworks, d'autres approches agiles, quels seraient tes conseils pratiques pour intégrer ces personnes du métier, du besoin utilisateur ? mais de manière réaliste, c'est-à-dire je veux pas en rendre la réponse, ils sont toujours là dans l'équipe parce que concrètement c'est pas réaliste à part si effectivement...
Fanny : Non, c'était un exemple effectivement.
Terry : Volontairement je challenge ça parce que c'est quelque chose, c'est vrai que moi j'ai entendu souvent parfois du regard de développeur, c'est que en tant que dev parfois tu peux te dire je fais ça, enfin t'as des tâches très claires sur qu'est-ce qu'il faut construire, Et tu comprends pas pourquoi la personne qui te demande, elle vient pas plus souvent te clarifier effectivement ce qu'il faut construire. Mais parce que souvent cette personne qui demande, elle a aussi plein plein d'autres choses à faire.
Fanny : Alors ces personnes-là, enfin nos interlocuteurs métiers, la plupart du temps, dans certaines entreprises, ça peut même être l'équipe d'à côté. Pour d'autres, c'est un peu plus lointain. Et effectivement, elles ont déjà leur propre job, comme tu dis. Et puis elles interviennent aussi en tant que partie prenante sur plusieurs projets différents. Donc elles ne peuvent pas être dédiées à une équipe. Donc j'ai l'impression que c'est ce que tu voulais entendre.
Terry : Je veux surtout entendre toi qu'est-ce que tu recommandes ou en termes de best practice ?
Fanny : Je ne me permettrais pas de donner des recommandations. Parce que c'est tellement différent en fonction de la situation, en fonction des équipes, en fonction du produit, la taille du produit typiquement. Quand déjà même une équipe par exemple est dispatchée sur plusieurs produits, tu peux pas te permettre d'intégrer plusieurs équipes métiers dans ton équipe aussi. Donc ça dépend vraiment de beaucoup de choses. De ce que moi j'ai vu dans ma petite expérience, j'ai pas encore dépassé les 20 ans de job, ça va être le haut plus proche et le plus à l'écoute. C'est-à-dire que quand tu parles de cérémonie, tu fais sans doute référence notamment à ce qu'on appelle les backlog refinements, donc ces éléments qui nous permettent, ces petits points qui nous permettent de s'assurer du besoin de l'utilisateur. de s'assurer de la priorité de ce besoin, d'affiner ce besoin aussi pour être sûre d'être toujours alignée. Ça c'est des choses que quand on applique Scrum et quand ça vaut le coup d'appliquer Scrum parce que des fois aussi je préconise de ne pas faire d'agilité, Mais quand c'est le cas, c'est des choses qui sont à multiplier. C'est pas quelque chose qui a lieu une fois par itération, par exemple, pour ceux qui connaîtraient Scrum. C'est vraiment des choses qui sont à multiplier, quitte à se répéter. Pédagogiquement, je pars toujours du principe que quand on a une question qui reste en suspens, c'est qu'on n'a pas compris. C'est pas parce qu'on veut embêter son interlocuteur à répéter. Donc il ne faut pas hésiter à multiplier ces points-là pour être en phase. Mais j'ai envie de dire que c'est la même chose avec tout le monde. Si je n'ai pas compris quelque chose de technique, je vais aller reposer la question à mes experts pour justement qu'ils me réexpliquent et qu'on soit toujours en permanence alignés. Donc en fait, c'est la même chose avec les métiers. La difficulté avec les métiers, qu'on a à gérer en plus, c'est qu'ils sont assez globalement oubliés dans une transformation agile quand elle ne concerne, entre guillemets, qu'un seul produit de l'entreprise, quand toute l'entreprise n'est pas agile. On a tendance un petit peu à les oublier. Du coup, ils ne comprennent pas le pourquoi de l'intérêt d'être aussi à disposition de l'équipe. Ils ont l'impression aussi de, comment dire, de tirer un peu sur la corde au final, parce qu'effectivement, ils ont un vrai métier à côté, entre guillemets. Donc c'est un petit peu compliqué de les convaincre d'être aussi à disposition. Et c'est là où c'est intéressant, c'est de reprendre à zéro les principes pourquoi on a décidé de passer en agilité. De le rappeler, de leur expliquer à eux aussi, de les embarquer, de leur faire bien comprendre leur intérêt. Et très vite, ce qui se passe, en tout cas de ce que j'ai vécu, c'est qu'en plus, ils se rendent compte de l'intérêt d'être là, présent, souvent, parce qu'en fait, ça leur sert à eux d'abord. Et ça ne sert pas que l'équipe de développement. Quand tu y trouves ton intérêt, forcément tu es plus embarqué et tu donnes plus facilement d'informations, tu es là à disposition plus facilement. C'est ultra chronophage et on ne peut pas se permettre de demander à un métier d'être là en permanence. Donc effectivement, il y a des moments d'échange privilégiés et les meilleurs ce sont ceux, je trouve, qui ne sont pas formels et donc je ne te citerai pas de cérémonie particulière. La seule où ils sont obligés d'être là, c'est la revue parce que c'est eux qui vont nous dire si c'est ok ou pas ce qu'on a réalisé durant l'itération. Mais ces petits points d'échange, je les conseille nombreux, informels et surtout sur des points précis pour que ça aille très vite et que ça ne leur prenne pas trois heures, deux heures de temps tous les jours.
Terry : Intéressant. Maintenant j'aimerais bien qu'on creuse un peu plus du coup l'aspect de comment tu fais pour passer du coup d'une organisation on va dire très cyclant V où j'ai mes besoins qui sont exprimés, ma spec, mon cahier des charges, c'est poussé à la technique et ensuite on se revoit dans six mois de la manière la plus on va dire fluide et moins brusque possible. Un peu tes petits tips pratiques sans rentrer dans le spécifique d'une méthode en.
Fanny : Particulier mais Oui, en règle générale, ça m'est énormément arrivé. Déjà, c'est une bonne question. L'idée, et je vais reprendre un petit peu ce que j'ai dit tout à l'heure, c'est vraiment d'embarquer les métiers. Effectivement, quand ils viennent toquer à votre porte d'équipe de dev et qu'ils viennent vous demander X fonctionnalités, avec cette question-là, quand est-ce que vous allez pouvoir nous le donner ? Donc une date, j'allons. Là on se dit ok, il y a eu des petites bases, des principes agiles qui n'ont pas encore été expliquées ou qui n'ont pas encore été intégrées, parce que comme tout changement c'est pas inné, ça se fait pas en un claquement de doigts, donc il faut être accompagné, a minima au début. Et donc on se pose. Et le rôle d'ailleurs en Scrum, parce qu'on parlait du Scrum tout à l'heure, du Product Owner, c'est aussi de faire comprendre ça au métier. On ne va pas écrire une liste au Père Noël avec une date estimée au-delà, ça c'est fini. On va optimiser chaque moment passé sur du développement de fonctionnalités. avec des découvertes. C'est-à-dire que là, pour l'instant, vous voulez tout ça, certes. Mais si ça se trouve, dès qu'on va vous faire votre première fonctionnalité, ça va vous faire penser à une idée de génie juste après. Hop, on va devoir, du coup, intégrer cette adaptation, ce changement-là, très vite. Et en fait, vous serez les premiers contents à avoir cette nouvelle fonctionnalité que vous n'aviez pas en tête pourtant au départ. Donc en fait, c'est vraiment le but. Et moi, j'affectionne vraiment cette façon de faire. C'est leur faire se rendre compte de l'importance qu'ils ont. qu'ils sont centraux dans nos préoccupations d'équipe de développement. Il faut aussi faire comprendre ça à l'équipe de dev que le but c'est bien de fournir quelque chose qui soit utilisable et si possible agréablement. Donc c'est vraiment cette communication, cette collaboration ensemble qui est ultra importante.
Terry : Quand tu dis ils, tu parles du coup des responsables métiers.
Fanny : Mais vraiment tout ça ensemble. Comme tu disais tout à l'heure, c'est très important d'avoir un minima. En toute honnêteté, si ces points de refinement dont on parlait tout à l'heure sont nombreux, effectivement, tout le monde ne va pas y aller tout le temps. C'est le product manager aidé de son product owner aux besoins qui va y aller. Après, il faut bien transmettre l'information, la traduire, comme tu as dit tout à l'heure. Et ça, c'est très important. Il y a effectivement une étape de traduction Ça ne veut pas forcément dire qu'on ne parle pas la même langue, c'est juste que sur des mots-clés, sur des habitudes qu'on a, sur des trigrammes, tous les mots qu'on utilise là, on pense savoir de quoi on parle à chaque fois. Non, il faut les préciser. C'est vraiment des étapes d'alignement qui sont super importantes. Donc non, quand on a une liste de 150 fonctionnalités, on ne les découpe pas en 150 cartes dans notre Kanban. Non, on ne fait pas ça. On étudie vraiment, on challenge les priorités de nos demandeurs, de nos métiers, qui vont en plus se sentir écoutés, donc ça c'est très important, et revenir petit à petit là-dessus. Et c'est pour ça aussi que c'est important qu'ils soient là à la Sprint Review, parce qu'ils vont dire si oui ou pas, on repart de là où on en est arrivé pour faire la suite.
Terry : — Ok, donc très clair. Et du coup, est-ce que t'aurais des exemples de choses qui se sont bien passées ou plutôt de... Donc là, j'entends dans ce que tu dis, par exemple, le fait que quand tu permets de délivrer petit à petit des choses, parfois, ça va pouvoir faire comprendre aussi au métier... Enfin, se faire réaliser au métier. Ah bah peut-être que là, en fait, on veut aller autre part par rapport à ce qu'on avait initialement pensé. Donc ça, je le vois comme un... un gain assez rapide et quelque chose de positif du fait d'apporter ces transitions. Est-ce que tu as d'autres petits retours d'expériences positives que tu constates assez régulièrement ?
Fanny : Oui, j'appelle ça des souvenirs feel-good. Parce qu'on ne rencontre pas que des réussites, il ne faut pas se leurrer, on teste des choses et des fois on échoue. On échoue rapidement, c'est ça qui est pratique avec l'agilité. Donc on se rencontre très vite et on essaye autre chose. Mais dans ces moments-là, on aime bien se souvenir de ces souvenirs feel-good. Et je prends toujours cet exemple-là, notamment en formation, quand j'essaie de leur montrer que quand ça fonctionne, ça fonctionne vraiment du feu de Dieu. C'est quand, au bout de six mois de projet, j'ai un... Alors à l'époque, ça s'appelait business analyst, dans l'équipe pas encore business owner. Il est carrément venu dans notre bureau s'installer, pas pour travailler tout le temps à 100% avec nous, mais juste pour être là quand on avait une question, un doute, etc. Et ça a fluidifié, nous, notre travail d'équipe de dev. En plus, on a fini par bien s'entendre et de carrément l'inclure dans l'équipe au final. Mais il se passe vraiment quelque chose de très sympa quand ça fonctionne bien et qu'on montre qu'on est vraiment à l'écoute et qu'en fin de compte, le temps qu'on réclame au business owner, c'est pour eux en fin de compte. il se passe un truc assez logique, c'est qu'ils se rapprochent eux aussi. Ils se rapprochent et puis ça permet d'aligner tout le monde très très régulièrement.
Terry : Top, j'aime bien cette anecdote. Puisque in fine, c'est ça le but, c'est de réussir à remettre du lien entre tout ça et faire comprendre que tout le monde est aligné pour un même objectif. Et donc ça, c'est une bonne anecdote que tu viens de partager. Autour de l'agilité, est-ce qu'il y a un sujet là en particulier sur lequel tu aimerais partager, donner un retour qu'on n'a pas encore abordé, toucher du doigt ? C'est vrai qu'on est parti là du coup de la notion organisation plus cycle en V versus comment on va vers l'agilité. On a parlé un peu des problématiques clés que l'on peut trouver. Est-ce qu'il y a des choses là, un, deux, trois points que tu aimerais aborder que je n'ai pas mentionné ?
Fanny : Un sujet qui me tient particulièrement à cœur depuis assez longtemps, et qui je pense pourrait du coup rassurer pas mal de monde, je suis la preuve vivante qu'on peut avoir été fâché avec l'agilité, vraiment très fort, à l'époque où j'étais jeune développeuse, et de comprendre pourquoi on l'a été, et de se dire que finalement si on bénéficie d'une bonne expérience, en fait après on est picousé et on veut faire plus que ça. Donc gardez espoir, faites-vous bien accompagner, et en toute honnêteté, ça demande un petit peu d'effort de faire de l'agilité, c'est pas facile, mais par contre ça apporte énormément.
Terry : Toi, d'un point de vue personnel, tu dirais quelles sont les qualités principales pour faire ton rôle ?
Fanny : Mon rôle à moi ? Alors lequel ? Scrum Master ?
Terry : Non, je vais dire la compréhension que j'ai de ce que tu fais, donc après peut-être tu vas me dire mais c'est pas du tout ça ce que je fais. Mais bon, le rôle que pour moi je comprends de ce que tu fais c'est d'être, alors le mot on va dire, c'est pas celui qui importe, moi je vais dire coach agile, facilitatrice agile, aide à la transition vers les méthodes d'agilité, voilà un peu tout ça. Donc ce rôle pour moi principalement facilitatrice pour apporter les pratiques. C'est ça un peu que je vois dans tes missions. Je te laisse corriger s'il y a des choses en plus ou en moins. Ok super. C'est un bon point et du coup l'idée maintenant c'est de voir pour ce rôle là en particulier quelles sont pour toi les qualités en tout cas que tu considères comme étant vraiment importantes.
Fanny : Prendre le temps de comprendre, ne pas dérouler une valise magique avec tout plein d'outils dedans et surtout savoir adapter en fonction des retours. Quand on essaie de comprendre déjà la problématique, ça veut dire qu'on essaie déjà de se mettre à la place de ceux qui vivent le produit du moment, de comprendre qu'est-ce qui fonctionne. Qu'est-ce qui fonctionne et qu'on voudrait garder ? Qu'est-ce qui fonctionne et qu'on ne voudrait pas garder aussi ? Il y a des choses, typiquement, faire des heures pas possibles jusqu'à 23h tous les soirs. Oui, ça fonctionne, oui, ça permet de, comment dire, d'aller garder les jalons, mais en fin de compte, on les cible, les équipes, donc c'est pas quelque chose qu'on souhaite. Et puis à l'inverse, qu'est-ce qu'on peut améliorer ? Et dans l'amélioration, il y a tout ce qui est interaction, process, technique, tous les outils, etc. Donc c'est ultra vaste. Et je pense que quand on arrive à se mettre à la place des équipes comme ça, ensuite la solution qu'on va essayer de co-construire avec les équipes, jamais de leur imposer, en fait c'est quasiment naturel. Oui, ça va bouger les lignes. Donc oui, on va se sentir momentanément inconfortable. Ça, c'est lié à tout changement. Mais après, quand on prend l'habitude, et c'est en ça où Scrum est assez confortable, c'est une première marche vers l'agilité parce que justement, ça crée des habitudes. Et donc du coup, après, c'est de l'acquis. Et on se retourne, on a changé en fait. Donc oui voilà, si je résume c'est vraiment savoir comprendre, observer d'abord, ne pas dérouler quelque chose de tout fait mais vraiment de co-construire avec les équipes et puis par la suite après essayer de mettre la petite graine d'amélioration continue parce que c'est pas parce qu'on a changé que c'est fini. Il y a toujours des choses qu'on peut améliorer.
Terry : Super, j'aime bien les caractéristiques que tu viennes de décrire, je pense qu'elles sont hyper pertinentes aussi dans les rôles de product manager, donc je trouve que ça fait un lien parfait. Maintenant je vais aller vers les deux questions de fin d'épisode, il y en a une qui va être peut-être à l'encontre de ce que tu viens de dire, mais elle est volontaire, c'est la question de positions clivantes que tu pourrais avoir. Donc ces deux questions que je pose maintenant régulièrement, la première c'est est-ce que tu as une position assez forte ou en général tu te retrouves en désaccord avec tes pairs quand tu partages cette position ? C'est sûr que là ça va à l'encontre d'être à l'écoute mais bon c'est quand même bien d'avoir des convictions donc je pense que ça vaut toujours le coup de les partager.
Fanny : À l'encontre, je ne sais pas. Par contre, comme je l'ai un peu précisé tout à l'heure, je ne suis pas partisane de dire qu'il faut faire de l'agilité à tout prix. Et il y a des fois où je conseille à des équipes. Là, le dernier POC qu'on a fait, d'ailleurs, une des dernières missions que j'ai faites, j'ai conseillé de ne surtout pas le faire en agilité parce qu'avec le peu de temps, le peu de moyens budgétaires qu'on avait et le peu de personnes qu'on était, ça nous aurait vraiment rallongé et fatigué pour rien. On se voyait quand même tous les jours. On faisait quand même des mini rétros de temps en temps. Donc non, on n'est pas passé en mode agile, mais sachez qu'une fois qu'on a mis le pied dedans, c'est quand même très difficile de faire autrement.
Terry : Ok super. Et bah du coup maintenant pour aller sur la dernière qui est la question des ressources donc est-ce qu'il y aurait des rocos de lecture, blogs, articles, podcasts et après pas nécessairement que sur l'agilité ça peut aussi être des choses toi qui te nourrisse intellectuellement au delà purement technique et personne aussi.
Fanny : Merci de l'avoir précisé parce que dernièrement j'ai passé ma certification PSDEV, PSD1, et je la recommande à tous les agilistes parce qu'elle est complètement différente de la PSPO et PSM. J'ai adoré la préparer. Elle donne en plus des idées d'outillage, de façon de faire, de process, que hélas je manque que ça trouve... Je trouve que ça me manque dans les certifications PSPO et PSM. Donc déjà voilà, première ressource, regardez les formations liées à PSDev1. Et moi mes trois ressources, mes bibles que je conseille toujours à chaque fois que je fais une formation, c'est l'art de devenir une équipe agile de Claude Aubry. C'est pas son célèbre bouquin justement Scrum, je crois qu'on en a la version 6 de mémoire, Non, c'est celui qui est ultra accessible et qui permet de trouver des mots super simples pour convaincre même ceux qui ne sont pas dans le numérique, dans la construction de produits numériques. Celui-là, je l'aime beaucoup. Accelerate, avec notamment Jenny Kim. C'est une référence pour moi, mais c'est un retour d'expérience. Ce n'est absolument pas une méthode. Troisième ressource, et j'ai eu la chance de rencontrer une des participatrices de ce livre, c'est Software Craft. Le sous-titre, c'est pour ça que j'ai pris une photo. TDD, Clean Code et autres pratiques essentielles. Et j'ai du coup rencontré Dora Bartagis qui a participé et c'est ultra précieux. Et ça amène énormément d'outils pour les équipes de dev.
Terry : Super. Et avant de terminer, si on veut te suivre, si on veut prendre contact avec toi, quel est le meilleur lieu pour le faire ?
Fanny : Alors j'ai un handle LinkedIn, vous cherchez Fanny Cloque. Un Twitter, KLF37. Et j'ai un petit blog, mais il est trop long, je pourrais pas vous l'expliquer.
Terry : Ça marche, super. Merci Fanny.
Fanny : Merci Terry.
