L'IA va-t-elle tuer le Scrum Master ?

Bruno:
L'agilité, on la compare souvent à la randonnée, il ne s'agit pas juste d'avancer vite, mais c'est surtout d'avancer ensemble en prenant parfois le temps de lever la tête pour pouvoir revoir son itinéraire. Et voilà que l'IA s'invite sur le chemin, prête à accélérer absolument tout le monde, même ceux qui foncent droit dans le mur. De quoi bousculer les cycles, les cérémonies, voire carrément le manifeste agile lui-même. Mais alors, l'IA va-t-elle vraiment augmenter la vélocité des équipes ou juste accélérer les problèmes ? Le rôle du Scrum Master devient-il encore plus indispensable ou au contraire menacé par l'automatisation ? Et surtout, à quand une rétro avec ChatGPT qui nous explique nos échecs sous la forme d'un haïku ? Pour répondre à ces questions d'équilibre modifié, je ne reçois pas Usain Bolt, mais il s'y connaît en accélération. Salim, monjeu.

Salim:
Salut.

Bruno:
Alors Salim, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas.

Salim:
Ok. Je suis Salim Gomery, coach agile avec 23 années d'expérience. Et j'ai aussi une formation de coach professionnel d'organisation. Donc j'ai une certification qui m'a permis justement d'asseoir un peu et d'avoir plein d'outils parce qu'on a tous ce syndrome de l'imposteur. Donc à un moment, tu te dis bon, voilà, il faut une carte en plus.

Bruno:
Alors effectivement, le sujet que j'avais envie d'évoquer avec toi, c'est que, On voit bien que, bien évidemment, tous ces outils d'IA, type Cloud Code et autres, accélèrent de manière phénoménale notre capacité à produire du code, qui reste quand même une partie importante de notre métier de développeur et développeuse. Ce qui tend à, en fonction des contextes, on voit un peu tout en ce moment. Il y a des gens qui réduisent la durée des sprints, d'autres qui augmentent la quantité de choses qui sont faites dans un sprint, d'autres encore qui vont réduire le nombre de personnes dans un squad, en se disant qu'on fait à peu près autant de story points qu'avant, mais du coup avec moins de gens, enfin bref il y a plein de, remises en cause au final du manifeste agile et je pense que c'était intéressant de pouvoir creuser ça du coup aussi avec toi, je me permets un disclaimer à chaque fois qu'on parle de ces sujets d'hier à aujourd'hui on enregistre cet épisode en étant fin août il devrait être diffusé je pense, peut-être fin septembre, il y a pas mal d'épisodes qui sont déjà en stock, avec la pause estivale, et donc il se peut qu'au moment où cet épisode est diffusé qu'il y ait encore beaucoup de choses qui aient changé. Il faut le replacer dans le temps. En tout cas, le moment où on enregistre, on est fin août, donc on vous parlera peut-être de choses qui paraîtront dépassées, quand vous l'écouterez, mais j'espère pas trop. Donc déjà, dans un premier temps. Qu'est-ce que toi, tu vois sur le terrain comme adaptation déjà faite du manifeste agile ou est-ce qu'au final, dans les faits, ça ne change pas tant que ça ?

Salim:
Alors, c'est une super question. Merci de l'avoir posée. Alors, pour moi, le manifeste Agile a été écrit il y a 25 ans par plusieurs têtes pensantes, etc. Donc, il est génial. ça reste toujours la base en fait le manifeste reste par contre, il a fallu selon moi l'augmenter comme d'IA et pour la petite histoire c'est pour ça que la suite à une discussion avec un ami Yannick. On était en train de discuter un peu moi j'avais un petit souci en coachant mes équipes parce que j'ai voulu utiliser l'IA etc. Et on était quand je voulais me rattacher au Manifeste Agile donc avec ses 4 valeurs et 12 principes ça collait mais, il manque un petit quelque chose tu vois, c'est un goût de pas fini j'ai envie de dire donc c'est la raison pour laquelle en fait j'ai créé, les Agile Manifesto donc l'idée c'était de garder l'essence même de l'Agile Manifesto mais d'intégrer l'IA à l'intérieur et, voilà grosso modo c'est dire toujours en fait on laisse toujours place, à l'humain donc l'humain reste central et ça c'est vraiment important l'humain reste le centre c'est celui qui prend la décision c'est lui qui décide, du cadre dans lequel l'IA va pouvoir jouer échanger, créer etc et, voilà il a fallu à mon sens créer ce AIGile manifesto donc je suis assez étonné en fait de la, du pouvoir que ça a eu parce que moi je l'ai fait en fin avril donc je crois que je l'ai fait pour mon anniversaire le 25 avril, petite note aux éditeurs. Au 25 avril autour du 25 avril je me suis dit bon je vais me faire un petit cadeau un petit kiff et j'ai créé les Agile Manifesto qui est disponible sur eagile.lu pour info, et donc voilà on a échangé avec Yannick mon pote qui était CTO, d'une grosse banque internationale à Luxembourg et voilà et donc en échangeant et tout je me suis dit ah ouais il faut faire quelque chose quand même et voilà et donc j'ai couché sur papier ce que j'avais déjà en tête et, top effectivement oui il y a quand même une évolution mais, je dirais pas qu'il est deprecated mais il manque d'une augmentation. Il faut l'augmenter, c'est tout.

Bruno:
Alors du coup, la première question que j'aurais, c'est est-ce que... Parce qu'on ne va pas se mentir, l'arrivée de CloudCode il y a bientôt un an, a quand même mis un vrai coup de pied dans le fonctionnement de notre métier. On voit aujourd'hui qu'on fait énormément de choses. C'est complètement développé dans des proportions folles. Quand on en parlait en novembre 2025, on se disait qu'on avait plus besoin d'écrire de code qu'on passait au spec engineering mais aujourd'hui même les specs sont de plus en plus écrites elles aussi par l'IA donc il y a quand même, un changement qui peut paraître assez fondamental du métier. Donc ma première question, ce serait, est-ce que tu penses qu'il faut juste adapter le manifesto agile ou est-ce qu'au contraire, en fait, il ne faudrait pas y appliquer, la même révolution drastique et se dire, en fait, on va le mettre à la poubelle, et on va revoir complètement la manière dont les équipes, les devs, travaillent avec les équipes produits ou ce genre de choses.

Salim:
Bonne question mais pour moi en fait moi je suis plus du principe il faut transformer, pour apporter de la valeur parce qu'en fait ce qui a été fait, c'est bien mais effectivement il faut vivre avec son temps grosso modo mais, typiquement là j'ai eu donc j'ai été invité par un, un CIO de Laplace pour demander mon avis sur l'intégration de l'IA. En fait, qu'est-ce que ça a échangé concrètement, dans les équipes, dans le cycle de développement et tout ça. Et on a échangé pendant deux heures, à peu près, avec différentes, personnes head-off de la société. Et oui, effectivement, il y a forcément d'autre chose. Donc, il faut élever, j'ai envie de dire, soyons ambitieux et élevons nos ambitions. Donc, oui, il y a des choses qui vont changer. Il y a plein de choses qui vont changer. Mais, pour moi, le fondement reste.

Bruno:
Oui, parce qu'effectivement, les fondamentaux du principe agile sont quand même, des choses qu'on a éprouvées depuis un peu plus de 20 ans maintenant. Et c'est vrai qu'on a vu l'effet sur l'industrie, ça a été plutôt efficace, ça a été plutôt une bonne idée. Le premier, quand on parle avec des gens qui sont peut-être plus sur des notions de direction, de management, la première image qu'on a de l'IA, c'est que ça va permettre d'augmenter la vélocité des équipes. est-ce que c'est le, et en fait ma question ce serait aussi est-ce que t'as une de ce que toi tu vois sur le terrain, est-ce que t'as une espèce de formule mathématique où tu peux dire, en fait avant une équipe elle pouvait produire X et aujourd'hui avec l'IA elle peut produire c'est quoi c'est 2X, c'est 15X c'est 4000X, c'est quoi le c'est quoi le vrai gain de vélocité qu'a apporté l'IA ?

Salim:
Alors c'est une bonne question, j'aime beaucoup. Pour moi en fait la vélocité c'est autant quelque chose, qui va à la base elle sert à l'équipe pour produire des indicateurs etc, savoir ce que tu vas pouvoir produire c'est ton outil ça va permettre de planifier un peu ton travail donc ça va nourrir le burn up chart, Mais c'est aussi un piège, un vrai piège en fait. Et c'est la raison en fait du... J'ai un chapitre, le 5, vélocité, mythe, piège et outil. J'en parle en fait, pour moi c'est vraiment un truc d'important parce que la vélocité c'est bien et pas bien. C'est un peu comme l'effet qui se coule il y a des choses bien et moi bien parce que en fait moi j'ai un exemple qui me revient en tête c'est que, lors d'une sprint review il y a un manager il arrive, l'équipe avait bien présenté, c'est une équipe que je manageais que je coachais, ils ont fait un super travail, ils ont produit des super choses etc et le manager s'installe donc c'est quelqu'un de très charismatique il s'installe donc l'équipe commente un premier slide et elle fait un état elle présente son, enfin je sais plus je crois qu'elle est en train de présenter. Elle a présenté juste ses points de vélocité chose que j'avais dit de ne pas faire et comme tu l'as dit je pressens des choses et là il y a le manager qui arrête tout Il dit, Attends, je ne comprends pas là. Tout le monde le regarde, je dis oui, qu'est-ce qui se passe ? Votre vélocité, elle a baissé, il y a un problème. Et voilà, donc là, l'équipe a été, elle s'est effondrée, c'était tout débot de mon coaching avec eux, elle s'est effondrée, mais il y a quelque chose de mort. Et tu vois, en fait, ça a cristallisé la discussion sur ça. Alors qu'on s'en fout en fait de la vélocité, parce qu'ils avaient fait un travail de malade, ils avaient réalisé plein de choses, ils avaient surmonté plein d'obstacles, et l'équipe a vraiment vraiment fait un taf de malade ils ont super bien bossé mais cette vélocité parce que lui il a adoré les chiffres il est matheux comme moi, il aimait bien les chiffres et tout, et c'est la raison pour laquelle j'aurais dit ne parlez pas de ponts on s'en fout de vélocité on veut savoir ce que vous avez réalisé si votre sprint goal a été atteint ou pas et, Et qu'est-ce que vous avez fait ? Quels sont les obstacles que vous avez réussi à remonter ? Et lesquels restent ? Mais là, en fait, ils ont voulu présenter. Ah non, non, mais attends, quand même, parce qu'on a eu moins de points. Mais par contre, ça reste quand même un super chiffre. Ils n'avaient rien compris, en fait, de la vélocité à la base.

Bruno:
Alors, j'entends effectivement qu'il y a la définition de la vélocité au sens manifesto agile. J'aurais peut-être plutôt dû parler de productivité, enfin, tu vois, de capacité de production. Et ouais, est-ce qu'on a une... Est-ce que toi, tu vois sur le terrain une espèce de ratio où tu te dis, en fait, la capacité de production d'un développeur sans IA est de temps et avec IA, elle est de X fois temps ?

Salim:
D'accord. Alors, j'ai une bonne réponse pour toi. La réponse est non. Il n'existe pas de formule mathématique à ma connaissance. Et heureusement, parce qu'après justement, tu vois, on a un peu ce genre de dérive. Et puis après, on va dire oui, ben telle personne produit. Non, je lui dis mais c'est du grand n'importe quoi. En fait, la vélocité, ça reste une vélocité d'équipe. Donc, on parle de pommes, on parle de ce que tu veux. Mais c'est des points abstraits en fait. Il ne faut pas les transformer en story point. Comme un des managers que j'adore d'ailleurs, qui faisait toujours oui, mais ça fait combien de man days à un story point ? Non, mais tu oublies. Alors soit tu veux faire des mind days et il n'y a pas de problème, on fait des mind days soit tu fais des story points et puis tu laisses l'équipe gérer ça et on s'en fout de combien ils ont fait c'est juste de voir l'évolution, C'est ce qui est vraiment intéressant. Mais pour répondre vraiment à ta question. L'idée, c'est ce que j'aime dire, et c'est quelque chose de sous-coté, en fait, c'est d'utiliser ce qu'on appelle des spikes. Le spike, c'est ce qui va te permettre de lever... En fait, un spike, c'est quoi ? C'est une zone temporelle, donc un temps donné, où tu vas lever une incertitude. Là, typiquement, l'IA, avec l'IA, on ne sait pas combien on peut produire, par contre donc ce qu'on va faire c'est qu'on va utiliser un spike et on va essayer, de voir en un temps donné tu peux prendre un cycle normal si tu travailles sur des deux semaines on peut faire ton sprint de deux semaines ou voire même moins, l'idée c'est juste de comprendre un peu qu'est-ce qu'on peut faire, avec quoi et tout ça est-ce que ta story va être réalisée en deux minutes, une minute, trois minutes je ne sais pas moi, une journée peut-être si ta story fait une journée avec Léa pose-toi des questions, mais par contre l'idée c'est de savoir combien, c'est ce que je disais en fait enfin c'est ce que je disais ou c'est ce que je dis, on s'en fiche il faut vraiment élever nos ambitions, il faut passer il faut avoir passé on ne parle plus de story parce que tes stories maintenant elles font en quelques minutes c'est fini, donc c'est plus un enjeu. La productivité qui était incompressible avant. On ne va pas accoucher, avec neuf femmes en un mois là en l'occurrence si avec l'IA tu vas pouvoir accoucher de ta story, en quelques minutes l'idée c'est d'élever le débat et de se dire ton développeur ou le owner, de ton point en fait maintenant on va plus le mettre sur une story mais il faut l'élever sur la feature et voir en combien de temps tu réalises ta feature et si jamais ta feature tu l'as fait aussi en 30 minutes, franchement entre nous c'est qu'il y a un souci de découpage peut-être relever encore d'un cran et parler des pics mais franchement je pense que avoir après tout dépend de l'organisation En fait, la vélocité, la productivité, pour reprendre un peu tes mots, la productivité de ton équipe va dépendre de ton organisation, des outils, de la personne, de l'utilisation de l'IA, de l'IA que tu utilises, etc. Enfin voilà, il y a beaucoup trop de facteurs pour avoir une règle mathématique, qui peut s'appliquer à tout le monde.

Bruno:
Ce qui est hyper intéressant dans ce que tu évoques, c'est que la granularité de la story aujourd'hui est, trop micro pour qu'on puisse continuer à prendre ça comme référentiel, qu'il faut passer au niveau features, voire même peut-être au niveau épique. En fait, du coup, ça m'amène plein de questions. Parce que est-ce que ça veut dire qu'on doit à ce moment-là arrêter de découper nos projets en story ? Parce que le découpage en story a quand même aussi l'avantage de pouvoir bien cadrer l'IA et du coup, elle travaille de manière un peu plus séquencée sur un projet. Et du coup on peut un peu plus facilement la guider sur ces sujets là ou est-ce que ça veut dire qu'il faut que tu tu vas décréer tes features de manière un peu plus, complète sans forcément la découper en story, est-ce que ça veut dire que le concept de story point disparaît mais on intègre maintenant des concepts de feature point ou d'epic point pour garder cette notion de vélocité au même titre. Ou est-ce que du coup ça veut dire aussi que parce que ce que tu as évoqué tout à l'heure tu nous as dit, tu as eu deux morceaux de phrases que je trouve intéressantes tu nous as dit, si à l'ère de l'IA ta story prend encore une journée c'est qu'il y a un problème parce que normalement ça devrait être beaucoup plus rapide que ça, et tu nous as dit que si tu as une feature ce qui se fait en tu nous as dit quoi en 30 minutes c'est que tu as peut-être aussi un problème de découpage, ce qui m'amène du coup aussi peut-être à un autre volet, d'exploration c'est est-ce qu'à ce moment là il faut qu'on change la durée d'un sprint, c'est-à-dire plutôt que de faire des sprints de 15 jours. Enfin, tu vois, si on dit qu'on passe au niveau épique, au niveau features voire au niveau épique, ça veut dire que potentiellement, en un cycle de deux semaines, un sprint de deux semaines, en fait, tu peux mettre en production peut-être une dizaine d'épics, ce qui est colossal par rapport à ce qu'on faisait avant. Donc, est-ce que ça veut dire qu'il faut revenir à des durées plus courtes de sprint ? Ou est-ce qu'on change juste la manière dont on découpe les projets ? Enfin, tu vois, je sais que je t'ai mis beaucoup d'éléments. Je te laisse te dépatouiller avec ça. Merci. Comment est-ce qu'on gère ce nouveau rythme de production ?

Salim:
Alors, effectivement, il y a plein de questions. Essayons déjà par la première question que tout le monde se pose. C'est le cycle. Faut-il le réduire ou pas ? Alors, j'ai envie de te dire, moi, je suis quelqu'un d'assez pragmatique, pas dogmatique. Il faut tester, franchement. Mais pour moi, non. En fait, c'est un piège. C'est un des pièges que je vois, même s'il y a des bolts, etc., qui existent et tout ça. Mais pour moi, en fait, parce que l'idée, c'est quoi ton cycle ? Ton cycle, il va pouvoir te dire, tu vas planifier, tu vas exécuter et après, tu vas pouvoir présenter, entre guillemets.

Bruno:
Avant de revenir sur ces cycles-là, parce qu'on entend beaucoup parler des bolts, est-ce que tu peux nous expliquer un peu ce qu'est un bolt aujourd'hui avec l'IA ?

Salim:
Alors l'idée c'est de dire dans ton équipe qui est très réduite, tu vas pouvoir faire en 2 jours, 3 jours partir sur des micro-cycles grosso modo, c'est un peu ça pour vulgariser les bolts c'est des micro-cycles C'est un mini sprint ? Voilà, mais très mini en fait c'est sur quelques jours, Donc l'idée après à mon sens Tu vas faire des cycles vraiment très courts. Je vais juste te donner, avant de répondre, te donner mon avis, enfin, expliquer le fond de ma pensée, va-t-on dire. En fait, moi, j'ai fait de l'extrême programming avant. On avait des rythmes de une semaine. Franchement... T'es crevé t'es crevé tu te crames moi je l'ai vécu en temps de dev à la base, c'est super énergivore donc faire des cycles plus courts donc admettons tu fais des cycles de 2 jours, et ben mon gars ben là tu vas cramer tout le monde parce que ton cycle ça veut dire il faut planifier potentiellement ton niveau va planifier oui. Par contre, ce que je dis toujours, l'IA propose, l'humain décide. Gardez son tête. Il y a mon copyright là-dessus. Non, mais plus sérieusement, même si ton IA va planifier ton travail, même si ton IA va l'exécuter, derrière, mec, il faut quand même que tu vérifies. Vérifie que ce qu'elle t'a fait, en fait, c'est pas pourri, c'est pas du code pourri. Ça vérifie bien les standards de ton entreprise qu'il n'a pas fait un commit hasardeux sur une base de données et puis après tu vas te retrouver avec des régressions non il y a quand même du taf au delà de la production, simple et bête bête et méchante quand même j'ai envie de dire au delà de ça en fait t'as quand même du contrôle tu vois c'est ce qu'on disait au préalable il y a, en fait tu peux truster mais la confiance n'empêche pas le contrôle il faut Là. Tu dois encore plus contrôler parce que ce n'est pas toi qui as fait. Donc la seule façon de savoir si c'est « OK », c'est déjà de t'assurer que ton cadre est bien là. Et en plus, de vérifier quand même. Il finit un petit peu pour voir si t'as pas des effets de bord à droite ou à gauche. Parce qu'en fait, ça va très vite. Ça va vraiment très vite. Donc si ta fondation est pourrie, tu vas faire du pourri très vite. Et ça va s'amoncer. Ça va devenir de façon stratophérique. Donc au final, tu vas produire de là à quelque chose de très pourri. Et très très très vite. Et c'est ce que j'aime aussi dans l'agilité, c'est que l'agilité met rapidement, les défauts en évidence. Parce qu'en fait, tu travailles dans la transparence totale quand tu fais vraiment de l'agilité et pas du scrum-like ou de l'agile-like avec du couvert de reporting, de managers qui sont là en train de micromanager et tout. Je ne dis pas que c'est toujours le problème des managers. Au contraire, moi, j'ai eu beaucoup de managers qui étaient à fond dans l'agilité, qui avaient un super mindset, et que ton équipe si t'es pas là pour cadrer un peu ça peut partir un peu loin donc non pour moi en fait. Les cycles courts c'est pas vraiment machin en fait tu peux laisser produire pour moi franchement laisser des sprints, de deux semaines c'est bien ça veut pas dire que tu vas rien livrer entre temps attention ne, me faites pas dire ce que j'ai pas dit ou ne me faites pas dire ce que j'ai pas dit, l'important en fait dans ton sprint c'est voilà tu vas dire on s'engage même sur trois projets, parce que pendant ton smag tu t'as perçu que tu peux faire une épique en deux jours ou trois jours ou, je sais pas ou un jour potentiellement tu peux livrer deux ou trois projets rien de ton poste de déjà livré de passer en prod machin faire tes tests, et que c'est de nos règles et tout parce que bon c'est super important les tests de nos règles même si c'est automatisé voilà présenté bon ben voilà on a vu machin truc et encore que moi les tests full automatisé, c'est bien à partir du moment où tu maîtrises toute ta chaîne. Mais l'humain quand même ça reste toujours important derrière nous on a toujours eu un humain, qui validait qui vérifie tous les cas bizarres parce que des fois en fait l'automatisation c'est quoi c'est non plus ni plus ni moins que la retranscription de ton savoir, de façon automatique donc il va être rejoué donc si à partir du moment où t'as pas réussi à tout mettre, et si tu laisses tout lié à faire machin c'est bien elle a fait mes tests automatisés alors oui il y a 95% de coverage ouais mais sur ce que toi tu as donné mais euh, l'humain est faillible. Donc ton nia est très faillible, est vite faillible.

Bruno:
Donc j'entends que tu dis qu'il faut garder sur des sprints d'environ deux semaines, qui est effectivement ce qu'on voit le plus souvent. Mais tu sembles dire du coup qu'il faut peut-être aussi revoir le ratio du temps consacré, entre guillemets, à la production et du temps passé à la vérification de ce qui a été produit.

Salim:
Ah oui, oui, oui. Ça, c'est pour moi, c'est... En fait, c'est ton nia qui va tout faire, grosso modo. mais même si après on aime bien moi j'adore mettre les mains dans en Cambuis de temps en temps et tout mais l'IA elle est là, il faut l'utiliser, il faut vivre avec son temps comme j'en vais dire, je le dis souvent mais, ouais donc il y a du check recheck, check et recheck il faut, revérifier tout le temps t'as pas produit donc potentiellement, tu vois ça va vite parce que l'IA va très vite donc potentiellement elle va dire ah oui mais attends et pour peu que tu lui donnais les droits sur un peu tout, tout ton environnement sur ta base de données sur ta mise en prod etc, Ça va très vite. Et tu te dis, waouh, mince, je n'avais pas vu cette dérive. Donc, potentiellement, il faut que je fasse du rollback.

Bruno:
Après, l'avantage, c'est qu'on dit souvent dans le monde des startups qu'il faut fail fast. Là, l'avantage, c'est qu'avec l'IA, tu empiles les choses tellement rapidement, que quand un problème arrive, en général, il arrive très vite parce que ça s'accumule très vite. Il y a aussi ça comme bénéfice, on va dire.

Salim:
Exactement, exactement alors oui, le fail fast, moi j'adore il faut y aller en fait mais fail fast ne veut pas dire refail, tu vois ce que je veux dire c'est grosso modo, ok on peut failer, mais il faut pas refaire la même erreur donc fail fast, oui et c'est pour ça que c'est vachement bien l'agilité parce qu'en fait tu donnes quand même cette latitude en te disant, bon bah moi je veux effectivement, me me donner la possibilité de faire telle et telle chose, etc. Mais potentiellement, si tu t'aperçois que ça revient, ben mec, t'as un problème dans ton organisation. Et l'idée de la rétro, parce que je pense qu'on va y revenir, la rétro, en fait, elle reste là. Il faut pas la toucher. Parce qu'il y a de l'amélioration continue derrière. Donc potentiellement, c'est comment tu vas pouvoir travailler avec l'IA.

Bruno:
Avant effectivement d'évoquer la rétro, j'aimerais revenir sur... Cette notion de découpage en stories, tu disais que les stories n'ont plus forcément, d'intérêt parce que la stories, elle est réalisée en quelques minutes, voire quelques secondes par nos IA. Est-ce que ça veut dire que pour toi, dans toute la phase de planification et de préparation, on ne parle même plus de stories ? On décrit juste des épiques directement ou est-ce qu'il faut quand même encore écrire des stories, c'est juste qu'on ne compte plus les points des stories ? Comment est-ce que tu vois tout ça ?

Salim:
Moi, la story, elle reste. C'est vraiment important. En fait, tu ne vas plus driver. En fait, tu ne drives plus ton travail par rapport à la story, mais tu la drives par rapport à la feature. Par contre, ta feature est nourrie par tes stories. Donc, ça reste. Je ne suis pas là pour dire que les stories, on oublie, machin. Non, au contraire. Ton travail de découpage de ta feature en story, il reste, ça reste et il faut que ça reste parce que potentiellement tu vas dire oui ma feature en fait voilà il faut que je tape machin truc, blou blou tu fais tes user story, tes technical story etc, mais après oui c'est en fait ta feature elle est nourrie c'est elle qui apporte. De la force en fait ou de la faiblesse à ta feature donc effectivement il faut que, ça va la renforcer ou pas mais en fait ça reste la story elle reste, donc tes story points ils restent là tu vois, mais par contre en fait vu que ta story elle est faite en 2 minutes 5 minutes, il focus on value, c'est la base de l'agilité donc est-ce que ça a valeur de dire oui bah voilà j'ai réalisé 36 stories machin on s'en fout, on s'en fout ton objectif c'est sprint goal si ton sprint goal c'est de dire voilà il faut réaliser tel, je sais pas moi réaliser. En fait la contribution à ton sprint goal c'est de réaliser, X features on s'en fout que tu parles des stories, voilà sauf si potentiellement en fait ça apporte de la valeur effectivement oui peut-être que la story là elle était sous-dimensionnée et puis c'est plus une story en fait il faut la dégager en feature et tout, oui, là oui oui ça fait du sens, mais voilà il faut quand même garder cette, cette, cette jugeotte il faut garder cette jugeotte toujours garder cette façon humaine qu'est-ce qui t'apporte de la valeur et c'est pour ça que vraiment le rôle du coach ou du Scrum Master il est super important, parce que ça va tellement vite si t'as pas une personne qui reste un peu en dehors et dire et les gars, vous avez vu ce qu'on a fait pendant ce sprint là ?

Bruno:
Là du coup quand tu disais que ça sert à rien de dire j'ai fait 36 stories Je pense que tu parlais du daily stand-up.

Salim:
Oui.

Bruno:
Ça ne sert à rien de tous les matins dire, hier, j'ai fait 30 stories. Mais juste une petite question sur le stand-up. Et je pense que de manière plus globale, après, on pourra enchaîner sur tous les rituels de la méthode agile et comment est-ce qu'on les adapte. Ma question est volontairement provoquante, parce que je sais que ce n'est pas une solution, mais, au final, si je regarde, le but du daily, c'était permettre à tous les développeurs et développeuses d'une squad, d'échanger sur ce qui a été fait, mais surtout sur les problèmes rencontrés, pour que si jamais il y a une personne de l'équipe qui rencontre un problème, les autres peuvent venir l'aider, à décortiquer une solution, à trouver une solution et décortiquer un peu le problème. Et en fait en soi c'était viable parce qu'en une journée à l'époque un développeur n'était pas capable de produire tant de choses que ça, et donc en général quand il évoquait son problème le lendemain matin en fait les gens pouvaient venir l'aider parce qu'il n'y avait pas tant de choses que ça qui ont été faites, mais là aujourd'hui quand t'arrives en daily et qu'en fait ton IA elle t'a chié 100 000 lignes de code la veille si t'as un problème à partager en fait il est potentiellement il a été multiplié par 100 000, si t'as fait effectivement de la merde donc est-ce que, en fait ma question est peut-être volontairement provoquante mais est-ce que le daily a encore du sens, est-ce qu'il faudrait pas plutôt faire un hourly, en fait pour qu'on évite d'avoir en fait des problèmes, c'est ce que t'évoquais tout à l'heure si tu gères mal ta fondation en fait tu commences à empiler de la merde sur de la merde et tu te dis un peu après qu'une, gigantesque bouse de triceratops, est-ce que du coup il vaut mieux pas raccourcir les choses pour que dans cette dynamique d'échange tu ne te retrouves pas avec une pile trop importante à gérer.

Salim:
Alors tu vois quand je disais que le coach Agile est vraiment important c'est super important parce que effectivement en fait pour beaucoup le délit c'est de dire ce qui a été fait, ce qui va, ce qui va pas en fait c'est foutaise, c'est pas ça le but d'un délit, le but d'un délit c'est simplement de parler en fait c'est un moment de synchronisation de l'équipe, Si t'as des problèmes pendant ta journée à 9h du mat, t'as commencé à 7h, t'as un problème à 9h, c'est une erreur d'attendre le délit pour le dire. Alors là, tu fais fausse route, direct, je te le dis direct. Le problème, c'est que ton délit, c'est un moment de synchro. Dire, voilà, en fait, la synchronisation de ton équipe pour savoir où tu en es dans l'atteinte de ton sprint goal. Je reviens là-dessus parce que c'est vraiment important. Et t'as plein de personnes qui se disent coacher Agile et dire, bon, bah alors, on va revoir les trois questions. Non. Les trois questions, elles n'existent même plus dans le Scrum Guide, par exemple. Tu vois ? Qu'est-ce que j'ai fait ? On s'en fout. Purée, mais changer, changer. Mec, il change. Il faut se mettre à la page un petit peu. Non. Le but, en fait, de ton DI, c'est simplement de voir, te synchroniser. C'est un point de synchronisation quotidien pour dire, voilà, Est-ce que j'atteins ? Est-ce qu'on peut atteindre notre Spring Goal ? Donc chacun va échanger ? Et dire oui ou non et quels sont les points bloquants. En fait, tu vois, tu dis, moi, par exemple, et tu parles d'achievement, donc ce qui a été achevé, on s'en fout, en fait, que tu sois encore en train de... Oui, ben, hier, j'ai travaillé sur ça, j'ai une réunion... Mais on s'en fout. On s'en fout. On s'en fout. Stop. Arrête avec ça. C'est dire simplement, est-ce que tu vas atteindre... Qu'est-ce que tu as fait pour atteindre l'objectif de Spring Goal ? Et là, ça change ton game. On s'en fout que tu as passé trois heures en réunion avec Tartampion. On s'en fout que tu as fait une pause ou que tu as été fumé ou que tu étais en vacances. Tu n'étais pas là ? Très bien, ne parle pas. On s'en fout. Tu as passé tes vacances et on en discutera après le stand-up. Le moment de stand-up, en fait, c'est vraiment quelque chose de clé. Comment tu vas faire pour atteindre ton objectif de sprint goal ? Et c'est pour ça que ton sprint goal, souvent, il n'est pas fait. C'est une grosse erreur. Tu commences déjà par un biais donc après qu'est-ce que t'as fait qu'est-ce que t'as pas fait. Ouais qu'est-ce que t'as fait pour atteindre l'objectif du sprint, déjà tu te poses la question tu te dis on va reprendre on va se poser la question qu'est-ce qu'on a fait pour atteindre l'objectif du sprint, Et là, tout de suite, tu ne vas pas dire « Oui, j'ai fait une réunion, on s'en fout ». Peut-être que ta réunion, en fait, ça a du sens pour le sprint goal. C'est très bien d'échanger. Mais sinon, est-ce que tu as des obstacles pour atteindre le sprint goal ? Et donc, quand... Ça, c'est souvent une erreur que je vois, en fait, sur le terrain. Des personnes qui attendent le lendemain pour parler d'un point de blocage qu'ils ont eu le matin à 8h du mat ou à 9h du mat, mais putain mais qu'est-ce que t'as foutu jusque là quoi, t'as attendu t'es sérieux là ou.

Bruno:
Même encore pire tu rencontres un problème à 10h et du coup t'attends le délit du lendemain pour adresser le sujet.

Salim:
Mais c'est un truc de fou ça je l'ai bien vu franchement ça arrive souvent alors moi je me remis vite en place tout le monde me connait parce que j'ai un franc parlé je suis quand même assez diplomate mais quand il y a un truc qui va pas je le dénonce et il n'y a pas de problème c'est de la transparence, L'objectif, c'est de se construire, c'est de construire quelque chose de positif pour atteindre, une perfection de l'équipe, une bonne dynamique dans ton équipe.

Bruno:
Alors du coup sur les rituels justement on a parlé du daily, pour faire dans l'ordre on commence du coup par le sprint planning est-ce que le seul changement du sprint planning à l'ère de l'IA c'est que en fait ce qu'on disait tout à l'heure plutôt que de caler des stories tu vas caler directement tes features voire directement tes epics, est-ce que c'est juste aussi un réajustement des sprint goals ou est-ce qu'il y a là aussi un peu plus de travail, un travail différent de ce qui a été fait jusque là.

Salim:
Alors, oui, il y aura un travail différent parce que tout le monde sait que, tout se fait générer, en fait, par IA. Donc, ta feature, en fait, elle va être documentée par ton IA. Elle va proposer, en fait, attention, moi, je pars toujours sur des propositions faites par l'IA. Et après, c'est toujours un humain qui vient. L'IA propose, l'humain décide. Je vais répéter souvent ça. Donc l'IA va te proposer, même en fait de la documentation pour ta feature et après toi humain que ce soit la dev team, ou product owner aussi potentiellement parce qu'on peut se rendre compte qu'en fait l'IA elle a produit vraiment des choses qui sont incohérentes entre différentes features et là tu dois être là pour rectifier et dire bah non en fait c'est pas possible Il faut faire ça comme ci, comme ça, quoi. Et donc après, oui, tu peux refaire une régénération, etc., par ton IA, si t'as pas envie de mettre... T'as pas le temps ou t'as pas envie ou tu veux gagner du temps. Enfin, je sais pas. Après, il faut... Moi, je pense qu'en fait, il y a un truc qui va être super intéressant avec les années, les mois, les années qui viennent, c'est quel est le... Le potentiel rework le retravaille, des propositions de l'IA par rapport à ce que l'humain a décidé de garder ou de jeter ou de remodifier et donc ça en fait c'est une métrique qui va devenir super importante par la suite, pour l'instant on n'a pas assez de recul il faut être il n'y a même pas assez à part, le cadre AIGEL que j'ai fait il, n'y a pas grand chose sur le sujet, comment est-ce que tu intègres l'IA, machin moi j'ai pris le temps d'écrire, moi j'adore écrire j'adore observer, j'adore proposer et modifier, voilà, fait le faste, on propose et puis après voilà, c'est pas une bible c'est un élément c'est une pierre à casser potentiellement je vais m'apercevoir, je vais dire Bruno, ce qu'on a vu il y a quelques temps, c'est pas d'actualité du tout maintenant il y a eu tel et tel IA qui est venu, Ça n'a pas de sens. Après, tu peux avoir des agents qui vont contrôler ce que l'IA a fait. Tu as des agents, en plus, maintenant, c'est l'agentique. Tu vas avoir des IA qui vont produire, d'autres qui vont vérifier, d'autres qui vont tester, si, machin, et tout. Après, il faut tester, toujours tester, toujours avoir cette. Décence intellectuelle dire ok c'est bien ou non c'est pas bien, il faut modifier n'est pas hésité à critiquer je suis complètement.

Bruno:
D'accord avec toi, mais ce qui est un petit peu difficile je trouve dans le contexte dans lequel on est, c'est qu'on a un métier qui est en plein bouleversement qu'il y a un nouveau truc qui sort toutes les 4 semaines 4 à 6 semaines et qu'en fait on a l'impression, de jamais pouvoir s'arrêter en fait que la la tu commences vaguement à prendre quelques marques sur un truc et puis le jour d'après il ya un técollé qui en aura qui dit à maintenant en fait tout ça s'est dépassé maintenant faire ça je, alors je sais qu'on a déjà dit à ce micro là plusieurs fois qu'en fait il ya un moment il faut se dire ok en fait j'arrête d'essayer d'être à la pointe à jour le jour je Je me décide là, ça, je veux maîtriser ça et puis on changera quand on sera bien maîtrisé. Tu vois, on a presque l'impression qu'avant, il y avait ce côté test un maximum de choses pour expérimenter, pour trouver des solutions. Et c'est comme ça que tu vas trouver ce qui fonctionne pour toi. Parce qu'en fait, le contexte autour de toi changeait assez peu. Donc tu pouvais te permettre d'expérimenter des choses. Mais aujourd'hui, le contexte autour de nous change tellement que c'est presque une démarche inverse de dire non, tu choisis un truc, tu te poses, tu le maîtrises. Et puis quand tu l'auras maîtrisé, tu pourras aller te mettre... Tu vois ce que je veux dire ?

Salim:
Oui, tout à fait. alors oui ça reprend le fail fast donc voilà mais effectivement, quand tu fais un travail intellectuel soit tu changes à chaque fois c'est un peu comme ton iphone tu vois, soit tu dis toujours oui je veux la dernière mouture parce que machin après voilà moi c'est ce que je faisais à un moment mais après bon ça n'a plus de sens, tu dis voilà t'as un truc qui fonctionne mon téléphone appelle je reçois bien les appels c'est bien, en fait c'est la fonction basique après c'est quel est l'usage quel usage tu veux vraiment faire effectivement, moi j'ai eu ce point là avec. J'étais tout content j'avais utilisé Cloud à l'époque pour réaliser, une sorte de Cloud Design j'avais fait un truc et après Yannick m'appelle et me dit t'as vu Cloud Design ? bah non, Et puis là, j'en rire, je lui ai dit, oh putain, merde. J'y suis passé des mois et des mois à réaliser un truc. Et bon, bah, Claude, ils l'ont fait. Ils ont largué une version de Claude Design. Je lui ai dit, waouh, ouais, quand même. Bon, qu'est-ce que je fais ? Fail fast, tu vois. Tu dis, oui, bah, effectivement, j'ai beaucoup travaillé. Le travail intellectuel était là. Voilà, ça m'a nourri. J'étais content, j'étais fier, voilà. Et puis après, tu dis, bon, bah, ouais. Bon, il faut passer à autre chose. Voilà, à toute proportion gardée, ce que t'as fait, c'était bien, mais pas suffisant, comme dirait la fesse.

Bruno:
Pour revenir du coup sur les rituels, on a parlé du planning, on a parlé du daily. J'imagine que la sprint review, au final, elle, elle ne change pas tant que ça, parce que tu fais une review de ce qui a été produit, qui est majoritairement une démo, ou est-ce que là aussi, il y a du changement ? Ou est-ce que moi, j'ai une mauvaise compréhension de la review ?

Salim:
Alors, oui, mais je te rassure, tu n'es pas le seul. La review, ce n'est pas une démo. La review, en fait, c'est inspecter ton produit. D'accord ? Inspecter ton produit, ce n'est pas dire faire une démo. C'est d'échanger de façon transparente avec tes stakeholders, avec les sponsors, etc. Sur ton produit. Voilà, grosso modo, potentiellement, tu peux avoir une démo, mais ce n'est pas forcément une démo. J'ai eu des équipes qui ont plein... J'ai eu une équipe en particulier qui me vient en tête, là. Elle avait, et en plus c'était une équipe qui faisait du front, machin, et elle a eu plein de problèmes, mais des problèmes de malade, tu te dis mais il y a un chat noir dans l'équipe, c'est pas possible, et donc en fait ils m'ont dit non mais on va pas faire de sprint review et tout. Parce qu'en fait on a rien à montrer quoi. C'est une blague. Attends, ce n'est pas la carte, la sprint review. Sprint review, c'est de façon transparente. Tu vas dire ce qui a été fait, ce qui n'a pas été fait et pourquoi ça n'a pas été fait. Et si tu as des points de blocage à adresser au manager, au sponsor, à tes stakeholders. On s'en fout que tu aies fait des choses. Si tu as des démos, c'est bien. Parce que ça flatte ton égo aussi. Il faut le dire. Oui, on a réussi à réaliser ça. Super, on est content. ouais mais là en fait et en fait ça a été d'autant plus importante qu'il y a eu, des décisions managériales qui ont été prises suite à cette review donc si pour toi la review, enfin pour toi je dis pas toi si pour, le commun des mortels la review c'est faire une démo, et bah mec vous passez à côté de tout quoi, parce que là typiquement j'ai un cas concret, donc ils ont relevé des problèmes d'infra, donc ce qui a fait qu'ils n'ont pas pu déployer ce qui a fait qu'ils n'ont pas pu, donner satisfaction au client, et bien là dans l'équipe, en fait une décision managérale c'est de dire, on va changer de provider, si on n'avait pas fait ça et bien on ne va pas faire de review parce qu'on n'a pas de démo, et bien ouais mais tu.

Bruno:
Seras toujours.

Salim:
Emmerdé avec ton infra pourri.

Bruno:
L'absence de démo est aussi au final une démo en tant que temps.

Salim:
Mais bien sûr. Mais rien faire, c'est faire.

Bruno:
Au-delà de l'aspect de la définition de cette Sprint Review, est-ce que dans un contexte full et high, est-ce qu'elle change ?

Salim:
Alors, si tu gardes toujours ce principe et que tu reviens à la définition de base, donc c'est inspecter ton produit... Ça change pas des masses en fait dans le fond parce que tu vas inspecter ton produit tu vas dire bon bah voilà lors de ce, sprint on a réussi à réaliser tel projet on a mis en prod tel état projet on a déjà des remontées clients, parce que du coup en fait vu que ton cycle est raccourci à mort et bien tu vas pouvoir réaliser mettre tes trucs en prod tu vas même avoir des retours avant la fin de ton sprint, et donc en fait c'est pour ça que c'est vraiment intéressant de garder un peu cette dynamique et tu vas pas monopoliser tous tes stakeholders tes sponsors, machin, ils ont pas que ça à foutre de venir tous les deux jours.

Bruno:
Tu t'imagines ? Donc ça veut dire qu'on rentre dans une époque où on met en prod avant de faire la review, avant d'avoir présenté aux stakeholders, aux demandeurs à qui on veut, c'est ce qui a été réalisé, comme ça du coup on a de la matière effectivement de comment est-ce que les clients ont répondu à ce qui a été produit ?

Salim:
Je vais aller plus loin, mon cher. Allons-y. Alors, pour moi, la mise en prod... C'est la base. D'accord ? Il faut aller en prod le plus vite possible. C'est pas parce que t'as un sprint de deux semaines qu'il faut que t'attendes le dernier jour pour mettre en prod. Non ! Tu peux mettre en prod au bout de deux jours. Fais-le ! Et c'est très bien. Fais-le en semaine. Ne livre pas un samedi, un vendredi à 18h. Putain, combien de fois on a été emmerdés à une mise en prod les vendredis, machin, parce que... Bon, après, il y a des contraintes. je dis pas il y a certaines choses où quand t'es face à des clients tu peux pas forcément te faire faire des mises en prod, en journée mais pourquoi cette mise en prod de vendredi elle nous tient vraiment à coeur ça je sais pas pourquoi est-ce qu'on peut pas faire des mises en prod en semaine, un mardi le lundi c'est toujours compliqué parce qu'on revient à du week-end personne s'est un peu peut-être enfariné et tout ils ont pas encore ce rythme donc peut-être le mardi, mercredi, jeudi c'est parfait, Moi, j'ai poussé pour qu'on mette en pod les mardis, voire jeudi. C'est très bien. Même les mercredis, c'est très, très bien. Vendredi, c'était red flag pour moi. Non, on ne met pas en... Bon, après, moi, j'étais aussi développeur, comme toi, je pense. Donc, on sait que le vendredi...

Bruno:
On ne met pas en pod.

Salim:
Voilà. Ben oui, parce que sinon, ça te pourrait t'embiquer un dossier.

Bruno:
Et du coup, le dernier rituel, c'est la rétro, qui est quand même souvent un des rituels les plus... Tu vois, j'ai plus souvent vu, moi, la review disparaître au profit d'une rétro un peu enrichie que l'inverse. Tu parlais de l'importance de la rétro. Moi, la rétro, c'est vraiment le... Pour moi, c'est le rituel avec le daily que je vois le plus souvent comme étant, entre guillemets respecté. Alors après, est-ce que c'était vraiment une rétro, faite au sens strictes, c'est un autre débat.

Salim:
Alors, justement, tu vois, je te disais que la sprint review, moi j'aime bien revenir toujours aux fondamentaux. C'est pour ça que d'ailleurs, dans le système Salim, le livre, j'ai consacré une partie entière sur les fondamentaux parce que c'est la base. Voilà, t'as ta base et après tu construis dessus. Dans Scrum, en fait, t'as la review qui te permet d'inspecter ton produit. D'accord ? Et t'as La rétro qui te permet d'inspecter ton process. Donc, effectivement, quand tu demandes au fondateur, en fait, au créateur du Scrum Guide, quel est pour vous, si on devait garder une seule cérémonie, un seul rituel, laquelle il faut garder ? Sans hésiter, c'est la rétro. Ce n'est pas la façon qu'est-ce qu'on va produire et qu'on se met d'accord. Non, ce n'est pas la synchro de l'équipe. Ce n'est pas ce qu'on va montrer et tout ça. Ce n'est pas le refinement pour préparer. Non, c'est la rétro. et c'est normal, parce que le but c'est de s'améliorer donc, l'inspection du process va passer par l'amélioration et dire voilà qu'est-ce qui a été, qu'est-ce qui a pas été, ça c'est bullshit aussi mec c'est du bullshit combien de rétro j'ai vu ça tu m'étonnes que les personnes en ont marre des rétros tu m'étonnes, que les personnes elles aiment bien squeezer les rétros parce qu'en fait, ouais mais on a déjà dit, oui oui en fait, on peut rien faire donc oui on l'a rennoté en poids d'amélioration mais on peut rien faire mais n'importe quoi les mecs le but c'est s'améliorer dans l'équipe on s'en fout qu'il y a un problème il y a un problème avec l'infra avec le fournisseur, enfin chez le fournisseur machin tu peux changer quelque chose non, et ben n'en parle pas en rétro, en fait c'est qu'est-ce que tu peux faire pour t'améliorer ou pour améliorer l'équipe voilà qu'est-ce qu'on peut faire au sein de l'équipe dans notre process pour qu'on s'améliore et qu'on devienne une vraie équipe autonome et qu'on arrive à mieux livrer, de meilleure qualité, etc. Ben voilà, il y a plein de scopes, quoi. C'est pas...

Bruno:
Est-ce que ça veut dire qu'on peut accepter une rétro où on se dit en fait, on n'a rien à améliorer ? On est carré, donc on se... On fait une rétro de 4 minutes.

Salim:
Alors, franchement, la rétro où t'as rien à améliorer, on me l'a souvent dit. Alors, j'avais une équipe qui me dit, oui, mais attends, nous, on livre bien, Voilà, il n'y a rien à améliorer dans notre équipe. Ok, tu es d'accord que je passe une semaine avec toi ? Ou quelques jours, on va commencer, deux, trois jours comme ça. Moi, je suis en shadow. Je suis là, j'observe, c'est tout. OK. Eh bien, je crois que c'était la rétro la plus longue que j'ai faite. Quatre heures et demie. Mais ce n'était pas quatre heures et demie pour dire, oui, voilà, vous avez fait ça, c'est pas bien, vous avez fait ça. Non. Moi, j'arrive. OK. Qu'est-ce que vous pensez de votre façon des tests d'intégration ? Qu'est-ce que vous pensez, du peer review ? Qu'est-ce que vous pensez de la façon de communiquer avec les autres équipes ? Ah ouais ? Ah ouais ? Je pense que vous avez matière à... On a échangé, machin... Alors, Monsieur Parfait, Équipe Parfaite, Diva, ça n'existe pas, les Diva existent, mais par contre, les équipes qui ne peuvent pas s'améliorer, c'est foutaise. Foutaise. Je mets au défi n'importe qui ici qui me dise, notre équipe, elle fonctionne trop bien, c'est la meilleure, on n'a pas besoin de s'améliorer. Eh bien, laisse-moi venir dans ton équipe.

Bruno:
Ce que je voulais dire, c'est que dans la théorie, il peut y arriver un moment, où une équipe te dit, en fait, dans la rétro, on n'a rien à dire parce qu'on a déjà atteint le maximum de ce qu'on est capable de faire.

Salim:
Non. Non, je ne peux pas entendre ça. Parce qu'en fait, ça veut dire que potentiellement, la perfection n'existe pas. Enfin si, c'est chez moi, mais non, je rigole. Non, pour moi, tu as toujours manière à améliorer. Toujours.

Bruno:
Mais alors du coup, dans un contexte full et high, comment est-ce que la rétro, elle est impactée par l'arrivée de tous ces outils ?

Salim:
Alors là, c'est magnifique. C'est le moment encore plus important pour moi. Donc là, on n'a pas parlé du Scrum Master. Le Scrum Master, pour moi, c'est le rôle à surtout pas... Je répète, le rôle du Scrum Master, c'est à surtout pas virer. Au contraire, messieurs, dames, il faut vraiment le garder. le Scrum Master, il est là pour observer et pour faire grandir ton équipe. Observer, améliorer, etc. Relever les obstacles et pas forcément toujours résoudre les obstacles. Ce n'est pas son job. Son job, c'est de faire en sorte que ton équipe devienne autonome. Donc pour qu'elle devienne autonome, potentiellement avec l'IA, il va voir, potentiellement, il va observer, il va voir que Pierre, en fait, il a des soucis avec l'IA. Il ne trouve pas sa place parce qu'en fait, il fait tout son taf. Il est toujours comme ça, bras croisés. Après, il y a. Une baisse de motivation, une baisse d'ambition, etc. Et puis, en fait, ton équipe, ça ne devient plus une équipe. Ça devient simplement, des start and play d'IA. Donc non, tu vois. Et ton IA, en fait, elle est là, oui, mais ça va accélérer. Ça va juste accélérer tes problèmes quand t'en auras. Ça va juste accélérer tes tensions quand t'en auras. Et ça va créer aussi des situations de burn-out, des situations, de dépression de certaines personnes, certains seniors qui ont du mal, certains seniors ou débutants qui ont du mal avec l'IA parce qu'en fait, elles se sentent vraiment inutiles. Et c'est vraiment important de le signaler avec l'utilisation de l'IA parce qu'en fait, ils ne font plus la même chose. Et effectivement, ton métier va évoluer. Alors, je mets au défi quiconque pour me dire que le métier n'évolue pas. Peut-être super PDG, machin, et encore que, mais ton métier va évoluer. Et si tu sens pas que ça évolue, il faut te poser des questions.

Bruno:
Clairement. Du coup, justement, pour terminer, ce fameux rôle de Scrum Master ? Parce que dans ce podcast, on a beaucoup parlé du changement du métier de développeur et de développeuse, qui forcément est beaucoup augmenté par ces outils d'IA. Quid du Scrum Master que tu présentes comme étant le poste à ne pas supprimer dans un contexte full AI ? Pourquoi et comment est-ce que son métier change aussi avec l'IA ?

Salim:
Alors, effectivement, son métier va vraiment changer parce qu'avec l'IA, ça va aller plus vite. Donc, en observant, en fait, il va voir plus vite. Il devrait voir plus vite des choses. Mais en fait, pourquoi je dis que le Scrum Master est vraiment utile ? C'est parce que lui va pouvoir pressentir. On en parlait un peu plus tôt sentir en fait il y a des agacements des fois, des choses qui sont pas tangibles, il y a des ressentis dans l'équipe t'as des personnes qui se sentent plus impliquées, plus dans le sens pas du tout et pas plus t'as des personnes auquel cas qui s'éclatent et qui trouvent, leur valeur ajoutée là dedans tu vois en fait c'est pour ça que c'est vraiment focus on value mais si. Enfin voilà lui il est quand même censé être là pour aussi être le relais, auprès des managers tu vois et potentiellement même accompagner cette personne pour dire voilà comment tu te sens j'ai l'impression que t'es, en fait c'est le relais direct du manager dans les attention ne me faites pas dire ce que j'ai pas dit Relais direct dans le sens où c'est quand même lui, qui va pouvoir ressentir et potentiellement relever le drapeau rouge « Attention, cette personne, je sens qu'elle n'est pas bien du tout, il lui faut de l'aide ». Toute proportion gardée, attention. C'est pas lui non plus qui est censé être là pour faire le RH et tout mais il est quand même c'est un rôle clé en fait, c'est vraiment très très très important parce qu'il est là pour ressentir aussi, tu vois au delà de l'aspect du process, en fait dans l'aspect du process enfin pas au delà mais, en plus de tout ce qui est tangible il est aussi censé voir un peu les directions que prennent telle et telle personne vers où elle se dirige si elle arrive à se projeter ou pas du tout, et auquel cas peut-être que là il faut que si la personne n'a, pas le courage parce qu'en fait il y a des pressions managériales ou pas ou parce qu'en fait il se sent pas seul etc le Scrum Master, il est quand même là pour apporter cette confiance en fait si t'as pas confiance dans ton Scrum Master t'oublies, et c'est pour ça que c'est vraiment un rôle clé quand on dit oui, bah en fait lui il était chef de projet, pas Scrum Master mais mec c'est faux quoi, arrêtez c'est pas le même job ça a rien à voir, et combien de fois je regardais encore, des offres d'emploi Scrum Master, oui, connaître E.T. le machin, mais... Mais mec, t'as rien compris, quoi, au job.

Bruno:
Ça, c'est un sujet qu'on a déjà évoqué plusieurs fois à ce micro. Je pense que c'est un des défauts de la méthode agile. C'est son nom. C'est de parler d'agilité. Parce que du coup, il y a beaucoup de directions qui se disent qu'en fait, on peut faire un peu ce qu'on veut. Parce que le but, c'est de rester agile. C'est de s'adapter, c'est de machin. Et du coup, ils adaptent la méthode qui, du coup, n'est plus du tout aussi agile que ce qu'elle pourrait être. Après, c'est un autre et vaste débat. En tout cas, merci beaucoup, Salim, pour tous ces éléments sur l'agilité à l'époque de l'IA. J'aurais deux dernières questions pour toi, qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ?

Salim:
Alors, moi, il y a... En fait, c'est plus une tendance qui arrive sur LinkedIn parce que moi j'écris beaucoup, et là j'ai vu que LinkedIn prenne un virage complètement différent par rapport à l'IA c'est que maintenant tu peux taguer des postes, je ne sais plus comment il nomme ça, mais en gros, ça pue l'IA. Donc maintenant, c'est I.S.L.O.T. I.S.L.O.T. Alors que quand tu reviens quelques temps auparavant, en fait, LinkedIn avait créé un outil pour améliorer ton poste, etc. Via l'IA. Et là, en fait, il y a un virage total qui est fait. C'est incroyable donc là ils sont en train de virer tout ce qui est grosso modo tout ce qui est génération IA mais après franchement entre nous combien de postes tu lis combien, de génération tu te dis putain ça pue en fait l'IA ou pareil en fait même dans les commentaires j'en discutais avec un pote il me dit non mais moi je vais plus sur LinkedIn parce qu'en fait les discussions entre IA, ça m'énerve c'est pas l'intérêt mais c'est du grand n'importe quoi en fait.

Bruno:
Mais du coup, est-ce que toi, il y aurait un contenu ? Je ne sais pas, un film, une série, un jeu vidéo, une expo, une pièce de théâtre ? Un truc que tu veux recommander aux éditeuristes, que tu recommandes souvent autour de toi ?

Salim:
Ouais, alors, je vais raconter, je vais faire une petite anecdote. Moi, il y a un livre qui, moi, au-delà de l'aspect religieux et tout ça, qui sont décrites dans le livre, c'est un livre qui m'a mis d'accord avec un manager avec qui on ne s'entendait pas du tout, mais vraiment pas du tout. Du coup moi j'y avais un autre coach organisationnel et certifié etc qui m'a dit non mais Salim tu peux pas rester comme ça à, te couper en fait de cette personne c'est quand même personne importante dans l'organisation et tout je lui ai dit mais j'en ai rien à foutre moi le mec je m'entends pas avec lui voilà on a pas les mêmes valeurs il dit n'importe quoi, il balance des mots que j'aime pas et tout, Et du coup, il m'a dit, non, mais je te le demande. Est-ce que tu peux aller déjeuner avec lui ? Je lui ai dit, bon, d'accord, je vais déjeuner avec lui. Mais bon, moi, j'ai toujours... Enfin, tu vois, ça cogite beaucoup dans ma tête et tout. Et j'ai un livre, en fait, qui m'a aussi donné une autre perception de la vie. Pour moi, ça a été vraiment mon game changer. C'était les accords Toltec. Donc, les accords Toltec. Du coup j'avais ça en tête et tout, donc au manager en fait, on a échangé donc je suis quand même resté fermé, mais à la fin de discussion je lui ai dit écoute, je vais te faire un cadeau je lui ai dit on se reparlera quand tu auras lu ce livre je lui file les accords Toltec et. Il m'est revenu je crois le jour d'après il m'a fait Salim merci, il fait mais merci pourquoi il me dit pour le livre je comprends je comprends mieux maintenant parce qu'effectivement sa parole n'était pas impeccable du tout et il a même refait un post, en remerciant toutes les personnes qui lui avaient fait changer de perception dans sa vie et il m'a remercié il m'a dit Salim pour les accords Toltec, il avait noté il avait pris son poste c'était reprendre une photo de tous les livres qui ont marqué sa vie sa vie, donc c'est quand même fort mais moi aussi les accords Toltec pour la petite histoire, je divorçais, Et je changeais de métier en même temps. J'ai été out, mais complètement. J'étais dix mille lieux sous terre, machin, et mon meilleur ami, Angel, que je salue, m'a dit « Salim, t'inquiète pas, la vie est belle, lis ce livre. » Et voilà, ça a été un game changer pour moi. Donc, les accords Toltec.

Bruno:
On mettra bien évidemment une référence en description.

Salim:
En plus du système Salim que j'ai écrit.

Bruno:
Bien sûr, on mettra aussi le lien vers ça. Et dernière question qui est la plus importante de ce podcast, Salim, tu es plutôt espace ou tabulation ?

Salim:
Tab, parce que je suis un gros fainéant, un gros paraisant plutôt.

Bruno:
Merci beaucoup Salim.

Salim:
Merci à toi.

Bruno:
Et merci à tous d'avoir suivi cet épisode. Donc voilà, effectivement, je pense qu'il était important de voir à quel point l'IA va impacter aussi d'autres métiers, et pas uniquement celui du développeur ou de la développeuse, donc tous ces métiers qui sont quand même autour de nous. Et comment est-ce que ça change la manière dont on s'organisent au global. Donc j'espère que ça vous a donné des pistes. N'hésitez pas à aller checker le bouquin de Salim pour aller creuser un peu ces éléments-là. Et comme il vous l'a dit, c'est des choses à tester. Ce n'est pas une vérité absolue. Ce n'est pas une règle parfaite qui s'adapte à toutes les organisations. Mais c'est des pistes de réflexion que vous pouvez tester, expérimenter, peut-être adapter à votre contexte. C'est toujours un bon moyen de progresser. De mon côté, je vous remercie comme toujours de partager ce podcast autour de vous. N'hésitez pas à vous abonner que ce soit cette chaîne youtube podcast ça dépend où est ce que vous nous écoutez je vous remercie beaucoup je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là codez bien.