Bastien Naudé, Le lean management pour livrer rapidement de la valeur aux utilisateurs

Transcription de l'épisode : "Bastien Naudé, Le lean management pour livrer rapidement de la valeur aux utilisateurs"

Terry : Salut Bastien, merci de me recevoir. Donc aujourd'hui, on va parler de deux grandes thématiques autour, on va dire, de ce qui se passe dans des boîtes de taille plus ou moins importante. Donc la première thématique, ça va être comment structurer l'apprentissage en entreprise et la deuxième, ça va être plus axé sur comment allier la vitesse à laquelle les choses se passent et les besoins du marché avec des frameworks de type agilité à l'échelle qu'on appelle SAFE ou autres. Et puis en trame de fond, on va aussi parler beaucoup de communication en entreprise. Et puis je vais te laisser commencer par te présenter, puis nous dire un peu toi ce que tu fais et pourquoi justement c'est pertinent d'échanger avec toi sur ces aspects-là.

Bastien : Ça marche. Salut Thierry, merci beaucoup pour l'invitation. C'est un plaisir de pouvoir échanger avec toi aujourd'hui. Alors moi je m'appelle Bastien Naudet, je travaille actuellement à Paris. Mon job c'est coach agile qui est reconnu, c'est le nom qu'on connaît sur le marché. Pour détailler un peu d'où je viens, moi j'ai grandi dans le sud-ouest dans une ville qui s'appelle Pau où j'ai fait toutes mes études. J'ai fait des études d'ingénieur en informatique et après je suis arrivé sur Paris pour travailler en tant que développeur. J'ai travaillé dans une startup pendant quelques années, c'est là où j'ai appris un petit peu le job, la société a grandi rapidement. Et ça a été l'occasion d'expérimenter comment travailler à 4-5 devs et comment travailler à la fin avec plus de 60 devs dans une organisation avec plusieurs départements. Et c'est là où j'ai appris et découvert toutes ces méthodologies d'animation d'équipe et que j'ai commencé à découvrir aussi l'accompagnement d'équipe, le management. Tout ça pour petit à petit faire de moins en moins de dev et faire de plus en plus d'accompagnement d'équipe et de travailler plus sur les relations humaines. Aujourd'hui, je travaille à mon compte, je suis en indépendant et j'accompagne mes clients principalement à améliorer tout ce qui est communication, collaboration dans leurs équipes, formation des managers et s'assurer d'avoir le meilleur flux de travail possible pour assurer la fluidité entre les demandes qui sont faites et les enjeux que doivent atteindre les équipes et les orgas. Je viens de l'informatique, donc mes clients, les équipes que j'accompagne, c'est principalement des équipes IT. J'ai aussi eu l'occasion de travailler avec d'autres départements, comme des départements commerciaux, juridiques, RH, pour, pareil, les accompagner dans l'amélioration de leur dynamique d'équipe, leur collaboration, leur communication. Et c'est quelque chose que j'aime bien. Ok. Je fais partie aussi d'une association qui s'appelle Flocon, qui organise une conférence chaque année à Paris, sur principalement la thématique du Lean et autour de Kanban et de toutes ces approches, on va dire, de livraison en continue de valeur. Avec quelques collègues, on a à cœur de promouvoir un petit peu cette culture du flot, des pratiques, de faire venir des personnes idéalement du monde entier, même si aujourd'hui on va plutôt se concentrer sur l'Europe, plutôt pour éviter les grands voyages. et de mettre aussi en avant ce qui se passe dans les sociétés françaises ou les sujets du moment qui nous semblent inspirants et plein d'apprentissages pour les enjeux qu'on a aujourd'hui dans les entreprises.

Terry : Hyper intéressant, donc sur cette thématique là je pense, enfin le fait aussi que tu animes cette conf, ça permet je pense de connecter ce qu'on peut avoir dans la théorie notamment des méthodos type Kanban, ce qu'on peut avoir dans ces approches très lignes de flux avec la réalité du terrain et du coup voir un peu là où les deux s'interconnectent et voir les problématiques que tu peux avoir entre ce qui est bien en théorie et ce qui est compliqué à mettre en place en pratique. Donc je pense que c'est ça aussi que je viens chercher dans cet échange et qui va être intéressant de voir avec toi notamment parce que tu as vécu en interne une croissance quand même très importante quand tu as commencé à bosser côté dev. Donc tu as vu ces problématiques émerger et comment toi tu as pu le voir de l'interne, comment ça a pu être résolu plus ou moins bien. Et aujourd'hui, comme tu disais, tu accompagnes tes clients pour les aider sur ces sujets-là. Donc pour commencer dans le sujet de la gestion de l'apprentissage en entreprise, toi, quelle serait, on va dire, une des grosses problématiques que tu as rencontré ? récemment ou moins récemment, mais auquel t'as fait face à ce niveau-là, sur la partie apprentissage en entreprise.

Bastien : Ouais, tout à fait. Un des constats que j'ai fait en me baladant un petit peu de mission en mission et en regardant différents… en ayant l'occasion de travailler avec différents types d'entreprises, que ce soit des petites ou des grosses structures, le constat que j'ai fait, c'est que je revois souvent les mêmes problèmes, les mêmes problématiques qui vont être colorées différemment en fonction des contextes dans lesquels je suis, mais la thématique de fond, ça reste la même. Ça reste souvent comment arriver à travailler ensemble à plusieurs en évitant de siloter complètement les organisations, comment arriver à avoir des flux de livraison qui soient efficaces et où tout le monde est heureux dans le tas, que ce soit les gens qui font les demandes et qui attendent un résultat ou les gens qui réalisent le job. comment arriver à développer le leadership des managers sans tomber dans du dans des extrêmes de command and control ou de je fais rien et j'attends que ça se passe mais trouver le bon équilibre et les bons mouvements là dedans et je pourrais t'en citer plein d'autres si on prend le temps de creuser et je m'interrogeais sur comment ça se fait que moi, ça fait 10 ans que je travaille, les lectures que je fais ou la veille que je suis amené à faire ou les discussions que je suis amené à avoir avec d'autres collègues qui travaillent depuis plus longtemps que moi mettent en avant aussi que ces mêmes problématiques existaient avant que moi j'arrive sur le marché du travail. Et l'interrogation que j'ai, c'est comment ça se fait qu'avec tout ce vécu qu'on a, cette expérience qu'on a, avec toutes ces ressources qu'on a aussi, parce que les gens écrivent des bouquins, des articles, viennent en parler en conférence, on se retrouve quand même souvent à retomber dans les mêmes problématiques, les mêmes problèmes à gérer encore et encore. Ça me fait poser cette question de comment s'organiser dans une entreprise pour s'assurer qu'on apprend des erreurs ou des faux pas qu'on fait et comment on s'inspire de toutes ces ressources qu'on a sur le marché pour éviter de tomber dans des problèmes ou alors s'inspirer de je vais dire entre guillemets de bonne pratique, qu'on pourrait adapter à notre contexte et nos contraintes pour améliorer la manière dont on travaille, dont on livre les choses, dont on collabore ensemble. j'ai pas trouvé de solution miracle.

Terry : Ouais, ça elle existe rarement. Je pense que, pour juste faire une pause sur ce que tu viens de dire, et c'est très intéressant, c'est, dans certains domaines, l'erreur c'est très rare qu'elle soit reproduite deux fois. Quand t'es sur des sujets très techniques par exemple, bah t'as un gros bug qui a fait planter ton app qui a besoin d'avoir un niveau de SLA du 24-7. Quand le bug arrive, t'as des gros retours d'expérience, les techs qui viennent, tout le monde qui met les choses à plat et qui dit ok bah là en fait, Ce cas là, la marge au niveau du code n'était pas bien gérée, on le fixe et maintenant ça ne se reproduira pas. Donc sur la partie technique, c'est vrai qu'on a l'habitude, avec un regard tech aussi, de se dire quand un problème s'est produit une fois, il ne se produira pas deux fois le même problème. Sur la partie plus organisationnelle, comme tu viens de le dire, c'est quelque chose qui en revanche se produit souvent, c'est-à-dire que d'année en année, de décennie en décennie, tu vas retrouver les mêmes problématiques, et je pense que c'est dû aussi à l'humain, parce que l'humain c'est pas une machine, et c'est bien normal et bien heureusement, mais du coup c'est ce qui fait aussi la beauté du job, mais la complexité de ces métiers-là, tu nommais donc, même en off, tu me disais que le titre c'est Coach Agile, mais après ça englobe beaucoup de compétences différentes, dans lesquelles il y a beaucoup d'humains, Donc ça ne me surprend pas que tu me dises qu'il n'y a pas de réponse magique, parce qu'effectivement on est sur l'humain. Mais ce qui est intéressant de voir, c'est toi déjà, quelles sont un peu les approches que tu essayes de mettre en place, ou un peu quelques retours d'expérience là-dessus, sur ce que tu as pu essayer de mettre en place, voir fonctionner, voir moins fonctionner aussi.

Bastien : Oui, tout à fait. C'est vrai que si tu as besoin d'une entreprise et qu'un gros bug te fait perdre énormément d'argent ou de clients, en général, là, vu que tu t'es pris un mur, on va s'assurer de ne pas se le reprendre une deuxième fois et ça favorise l'apprentissage aussi. Après, il y a quand même du boulot qui est fait. Les organisations, elles évoluent. Il y a des personnes qui vraiment se posent et qui réfléchissent. 20, 15, 20 dernières années, il y a quand même beaucoup de nouveaux principes ou de nouvelles méthodos qui ont émergé. Aujourd'hui, moi j'aime bien, quand j'accompagne des équipes, j'aime bien leur montrer un petit peu comment ça marche ailleurs, essayer d'ouvrir un petit peu ce spectre qu'eux ont pour ne pas regarder uniquement comment est-ce que ça marche dans le contexte ou dans l'équipe dans laquelle ils sont là. ou même des fois d'aller chercher dans leur expérience passée, est-ce qu'il y a des bonnes pratiques ou des choses qui marchaient bien et qui ne se retrouvent pas ici. Et des fois, ce n'est pas instinctif d'avoir ce raisonnement et de se dire « ah ben en fait ouais, la boîte où j'étais avant, ça marchait super bien et on faisait ça et ça et c'était cool. Et qu'est-ce qui nous empêche de le refaire aujourd'hui ? » En fait, ce n'est pas instinctif s'il n'y a pas eu ce déclic-là. Et c'est surtout sur des pratiques comme ça que j'essaye d'aller chercher en fait Je me dis, enfin j'observe surtout qu'on est beaucoup, les équipes avec qui je bosse et les gens que j'accompagne, on est beaucoup tête dans le guidon, même moi parfois ça m'arrive, on me donne une problématique à résoudre, un job à faire et je suis plein de bonne énergie et je fonce dedans, sauf qu'au bout d'un moment on va tellement vite, on est tellement plongé dedans qu'on regarde plus trop qu'est-ce qui se passe ailleurs Et on passe peut-être à côté de choses sans s'en rendre compte. Donc c'est le fait d'avoir ce temps de recul, de prendre le temps, peut-être d'aller, on va dire, à un rythme plus soutenable ou d'aller plus doucement pour être plus conscient de ce qu'on fait plutôt que de foncer tête baissée vers quelque chose. Et donc c'est le moment où on va lever la tête et regarder un petit peu ailleurs, de regarder comment font d'autres entreprises. Tiens, cette problématique que j'ai, il y a peut-être quelqu'un qui l'a déjà rencontré et qui a écrit quelque chose dessus. Donc ça va être beaucoup basé sur ça, ou même d'aller rencontrer d'autres entreprises, de prendre le temps de se dire tiens, aujourd'hui j'ai des anciens collègues qui bossent dans telle boîte avec qui j'ai gardé du lien, je vais prendre une demi-journée pour aller les rencontrer, voir comment est-ce qu'ils travaillent, et créer aussi ce lien avec d'autres entreprises pour partager des pratiques, partager des réponses à des problématiques, des choses comme ça, qui sont peut-être moins valoriser dans une roadmap. Ce n'est pas quelque chose qu'on va prévoir, on ne va pas mettre de la business value dessus, on ne va pas avoir vraiment de valeur pour nos utilisateurs ou pour l'entreprise immédiatement. Mais la valeur, elle est cachée derrière dans le fait de fournir peut-être quelque chose de meilleure qualité, avoir des rythmes de travail qui vont être plus fluides ou des choses comme ça.

Terry : Alors là si on fait une pause hyper intéressante sur ce sujet là, alors déjà ça me permet de rappeler aussi c'est vrai pour des boîtes qui ont pu passer par différentes étapes de croissance et qui viennent pas nécessairement du digital à la base mais qui s'y sont mis par obligation, par besoin du marché, on peut avoir parfois des fois des regards sur les prestats externes, les coachs qui viennent, encore un autre coach agile qui va venir nous expliquer comment faut faire les choses etc. et donc je dis volontairement ça parce que ce que tu as expliqué c'est la vraie valeur en fait c'est que ces personnes qui viennent de l'extérieur apportent aussi ce temps de dire bah attendez on pose les stylos deux secondes on regarde un peu comment on fait les choses et parfois les gens qui sont dans le quotidien qui peuvent être dans la boîte en question depuis des années voire des décennies ont pas le temps en fait de prendre ce recul et le fait d'avoir quelqu'un de l'extérieur qui vient, en plus que cette personne souvent elle a eu d'autres expériences, donc elle a aussi vu d'autres organisations, elle peut apporter en ce sens sa pierre un peu à l'édifice de dire bah chez eux ça fonctionne comme ça, chez eux ça fonctionne comme ça. elle va aussi permettre aux gens qui ont vraiment le nez dans le guidon de se dire ah oui c'est vrai on va se lever la tête deux secondes et en fait ça permet aussi aux gens des fois en interne de trouver eux-mêmes les solutions problématiques qu'ils ont. Là c'était un peu pour poser les raisons pour lesquelles ces métiers là sont aussi vachement utiles dans des organisations qui sont très malléables et qui évoluent très vite parce que les métiers d'aujourd'hui n'existait pas potentiellement il y a 20 ans et c'est aussi la raison pour laquelle ce podcast et beaucoup d'autres existent c'est pour essayer de voilà un peu tous on a le nez dedans on voit un peu comment les autres font et on essaie d'apprendre du coup de chacun comment structurer les jobs les organisations etc donc Par rapport à ce que tu disais sur le fait donc de suggérer aussi aux personnes d'une boîte dans laquelle tu vas travailler, de regarder ou de penser à boîtes passées auxquelles ils ont travaillé ou d'aller discuter avec des collègues passés, est-ce que tu as des exemples de choses comme ça qui ont débloqué des belles situations ou d'apprentissages à partager sur ça a permis de se rendre compte de ça et derrière ça a permis de fluidifier ça ou autre ? un cas un peu concret sans aller casser des ND et que tu aurais signé avec tes clients, bien sûr, mais en restant assez high level.

Bastien : Ouais, bien sûr, j'ai un exemple qui me vient en tête tout de suite, c'est quand j'ai commencé à me former, à découvrir et à me former sur Kanban, je suis rentré en contact à l'époque, c'était je pense il y a peut-être cinq ou six ans, peut-être même un peu plus longtemps, je suis rentré en contact avec Dimitri Bailly qui était à l'époque je crois CTO chez les Furets, Et dans l'écosystème français et même plus spécifique parisien, moi c'était une société que j'avais identifiée qui faisait du kanban à bon niveau. Et donc Dimitri, avec qui je travaille aujourd'hui à la conférence Flocon, à l'époque la conférence s'appelait L'In Kanban France. Et j'ai commencé à m'intéresser à tout ça, et c'est comme ça que je suis rentré en contact avec Dimitri. Et l'équipe dans laquelle je travaillais à l'époque était aussi intéressée par ces nouvelles pratiques. On en avait un petit peu marre de Scrum, on arrivait aux limites du truc, ça nous convenait pas trop, on cherchait à s'intéresser à d'autres manières de faire. Et on est allé rencontrer les équipes de l'effuret.com dans leur bureau pour qu'ils nous montrent à quoi ça ressemblait qu'en banche chez eux, autant sur comment est-ce qu'ils faisaient un daily stand-up que comment est-ce qu'ils géraient leur management visuel, quels outils ils avaient développés en interne pour suivre leurs indicateurs de livraison, leurs indicateurs qui leur indiquaient que ça roule, tout va bien, il n'y a pas de drapeau rouge aujourd'hui. et prendre le temps de discuter avec les gens aussi. Et c'était vachement bénéfique d'avoir des devs qui discutent avec des devs et que ce ne soit pas juste moi qui dise « ah en fait j'ai retrouvé une nouvelle méthode O, on va tester ça demain », et des PO qui discutent avec des PO aussi, managers pareil, et de vraiment avoir ces échanges-là. Et donc après avec cette équipe-là, on a commencé à s'intéresser à Kanban, on y est passé et on a trouvé une méthode, enfin une manière de nous organiser qui nous a bien correspondu et ça c'était plutôt cool. Et quand j'ai quitté cette société, que j'étais dans d'autres sociétés, après j'amenais les clients voir cette équipe-là dans laquelle j'étais avant. Pareil pour eux, que les gens puissent raconter leur histoire, comment ça s'est passé, le changement pour eux, qu'est-ce qu'ils ont bien aimé, qu'est-ce qu'ils ont moins bien aimé, qu'est-ce qui marche bien. Et vraiment avoir ce dialogue entre les personnes pour mieux comprendre, mieux pouvoir s'inspirer de comment les choses ont été faites et plutôt que de juste prendre un livre et puis appliquer les étapes une par une. plutôt s'approprier vraiment toute cette philosophie, ce changement, l'appliquer derrière. Ça c'est une expérience que j'ai trouvée qui était plutôt bénéfique et c'est le petit point qu'on a aussi en fil rouge de cet épisode sur la communication en entreprise, tout ce dialogue, alors là du coup ça va être entre entreprises, tout ce dialogue qui aujourd'hui est bénéfique à prendre le temps de comprendre, à faire les choses, plutôt que pareil de trop foncer, d'être dans le guidon. Il y a un moment où il faut foncer, il y a un moment aussi où il faut s'arrêter pour prendre le temps d'observer, d'analyser, pour pouvoir derrière mieux foncer.

Terry : Hyper inspirant et je trouve assez intéressant d'aller faire parler de deux équipes, de deux boîtes différentes pour aussi qu'elles le voient par eux-mêmes plutôt que d'arriver et de dire c'est comme ça qu'il faut faire. Je trouve ça très intéressant. Merci pour ce partage et par rapport, donc t'as mentionné évidemment Scrum et Kanban, pour des personnes qui seraient moins familières avec ça et aussi pour celles qui sont plus familières avec les deux cadres de travail Agile, qu'est-ce que toi t'as pu voir qui fonctionnait peut-être un petit peu mieux du passage, enfin qu'est-ce qui pouvait bloquer quand les équipes étaient en Scrum et du coup passaient à du Kanban ou quelque chose de similaire et potentiellement inversement ? Moi si je devais résumer très trivialement l'un des différences principales entre les deux c'est que sur Scrum on est en général sur des blocs de travail qui vont être donc fixés dans le temps donc il y a une période pendant laquelle on sait ce sur quoi on va travailler et ce qu'on va livrer au bout de cette période de temps versus le Kanban où on est sur une logique de flux continu. qui historiquement vient des chaînes de production de Toyota, c'est eux qui avaient été les premiers à un peu théoriser cette approche-là, avec en fait les logiques de quand ils construisaient les voitures, plutôt que d'avoir du stock, en fait c'était plutôt des logiques de piles de matériaux, de piles de choses à dépiler au fur et à mesure des... que les chaînes de production avancent et donc en fait le travail qui avance au fil de l'eau et qui n'est pas timeboxé comme dans Scrum avec une date de début, une date de fin et on repart ensuite sur un autre timebox. Donc entre ces deux approches, qu'est-ce que toi t'as pu voir qui parfois faisait passer de l'une vers l'autre et les bénéfices ou pas d'ailleurs qui en étaient retirés derrière ?

Bastien : Oui, ok, je vois. C'est vrai que c'est un peu le match du moment dans les entreprises, Scrum versus Kanban, que faire, comment s'organiser. Aujourd'hui, Scrum c'est quand même une méthode de boulot qui a été beaucoup popularisée et qui est majoritairement adoptée par les entreprises, plus ou moins bien, avec plus ou moins de bénéfices. C'est toujours un peu touchy ce genre de méthode étant donné que ça donne un cadre de travail en espérant avoir des bénéfices plus tard. C'est aussi un cadre à adapter en fonction des contraintes que chaque entreprise va avoir et dans l'histoire on a vu que le Scrum Guide qui définit un petit peu les règles de tout ça a beaucoup évolué en essayant un petit peu de se chercher pour essayer de correspondre à la majorité des contextes, ce qui n'est pas facile. Aujourd'hui moi ce que j'ai beaucoup observé c'est que malheureusement le but avec Scrum ça devenait de bien faire un sprint plutôt que de bien faire du produit derrière. Donc tout était très focalisé sur le sprint backlog, l'engagement à respecter, le fait de devoir livrer à tout prix en fin de sprint une nouvelle version du produit et les discussions étaient beaucoup trop centrées sur ou peut-être trop centré sur le fait d'arriver à haner tous les tickets dans la colonne donne plutôt que de voir si le boulot qu'on est en train de faire maintenant était le bon boulot sur lequel il fallait qu'on bosse pour atteindre nos objectifs, répondre aux enjeux de la boîte, répondre aux enjeux des utilisateurs, etc. et je trouvais ça dommage parce que du coup on utilisait plutôt... l'objectif c'était de bien faire la méthode plutôt que de bien faire notre job. Sur le côté de Kanban, la définition que tu as donnée, je suis plutôt en phase avec ça, le fait que Scrum est plutôt catégorisé comme étant des petits batchs qu'on livre, Dans Kanban, il y a plutôt cette dynamique de livrer continuellement de la valeur en équipe, sans rentrer dans trop tout l'historique, comme tu as pu le mentionner avec le Lean, le Toyota Production System. Comment est-ce que l'IT s'est inspiré de tout ça ? Aujourd'hui, on va plutôt parler de Kanban pour l'IT, qui va être différent du Kanban, du Lean, de Toyota. Il y a une société qui s'appelle Konto, je pense que la plupart des personnes qui écoutent ce podcast doivent connaître. qui appliquent beaucoup le Lean chez eux, qui documentent aussi, on a de la chance, ils documentent beaucoup ce qu'ils font et ils partagent, que ce soit en conférence ou sur leur blog à eux, ou lors de podcasts aussi, comment est-ce qu'ils fonctionnent. Et ils se sont fait aussi accompagner par des coachs Lean ou des Sensei Lean qui ont pu aussi leur permettre de créer cette culture chez eux, partagée par toutes les équipes et toutes leurs entreprises de comment faire du Lean ou comment est-ce qu'on travaille ensemble. et ils ont défini quelque chose qui s'appelle le Contoway, qui est à l'image du Toyota Way à l'époque, qui définit un petit peu comment est-ce qu'ils... toutes leurs règles de travail chez eux. Et j'ai trouvé ça super inspirant pour, pareil, dans la même optique, d'apprendre un peu de comment font les autres et de s'en inspirer. Aujourd'hui, moi je suis plutôt orienté sur du kanban parce que je trouve que ça soit une baguette magique que j'utiliserais partout. je trouve que ça permet plus facilement à une équipe de définir à elle-même comment est-ce qu'elle souhaite travailler, quelle fréquence ou quelle cadence elle veut adopter plutôt que de suivre on va dire un basique sprint de deux semaines avec un sprint planning, une démo review à la fin, etc. Même si Aujourd'hui je pense les plus grandes questions qu'on peut me poser c'est comment réussir à garder de l'engagement quand on bosse en cambans versus un sprint où on sait qu'à la fin de deux semaines on s'engage entre guillemets à livrer quelque chose.

Terry : Est-ce que là dessus, enfin juste sur une pause sur ce sujet de l'engagement quand tu bosses en cambans c'est que pour la métaphore c'est quand tu vois juste du travail, du travail qui arrive en permanence sous format pour les devs de tickets sur ton Trello, ton Jira ou autre tu te dis mais ça finit jamais, ça fait que je prends, ça passe à fait et puis ça continue, ça continue, ça continue et c'est compliqué du coup de trouver des fois des moments que tu as dans Scrum parce que t'as les démos, tu as ensuite tes rétros, tu vas avoir ces moments là où bah oui on a fini un premier badge donc on est content et on passe ensuite au suivant, là en campement c'est vrai que tu peux potentiellement ne pas avoir ces moments là. Et donc l'engagement peut être un vrai sujet, la motivation des équipes au bout d'un moment si il n'y a pas de moment où tu dis « ça y est, là on a sorti quelque chose ». Je suis curieux de savoir toi ce que tu allais dire par rapport à ça.

Bastien : Oui, tout à fait. Il n'y a rien qui nous empêche aujourd'hui en Kanban de ritualiser ces moments de célébration des nouveaux succès ou des nouvelles évolutions qui ont été faites sur un produit. C'est vrai que dès qu'on parle de Kanban, on peut avoir quelques doutes sur le fait que ça veut dire du coup on va plus faire de sprint planning ou de démo de notre produit ou même de rétrospective. Mais en fait la première question serait pourquoi ? Qu'est-ce qui nous en empêche ? Si c'est bon pour nous, gardons-le. Peut-être on va pas l'appeler sprint planning parce qu'on fait plus vraiment de sprint et qu'on essaye de garder un langage qui reste cohérent avec la manière dont on bosse. c'est quand même un terme qui est très connoté Scrum, mais si commencer la semaine par rappeler les priorités de la semaine, faire un petit peu de planification en se disant voilà comment on va séquencer notre travail, voilà comment on va s'organiser nos prochaines prio, être sûr que tout le monde est aligné dessus et on se lance. si ça nous fait du bien et que ça nous permet de bien fonctionner, gardons-le. Pareil pour le fait de se dire on sort une nouvelle version de notre produit toutes les deux semaines. Si c'est quelque chose qui est convenable pour nous, pour les gens avec qui on bosse, gardons-le aussi. Et s'il faut faire une démo de ce qui a été fait et de tout ce qui a été réalisé, et en même temps recueillir les feedbacks des personnes à qui on présente tout ça, Dans le kanban, parfois on pense juste au tableau avec plusieurs colonnes, qui est le management visuel ou le kanban board. Derrière tout ça, il y a aussi pas mal d'autres pratiques et d'autres principes. tirés du Lean, qui sont peut-être un peu moins connus. Un des principes de Kanban, une des pratiques de Kanban, c'est de mettre en place des boucles de feedback. C'est tout ce que nous dit Kanban. Après, c'est à nous d'aller chercher un peu derrière cette phrase-là, qu'est-ce que ça veut dire, et d'identifier les endroits où mettre en place ces boucles de feedback, c'est intéressant pour nous. je pense un daily stand-up, c'est pas interdit d'en faire en campement, c'est le moyen d'avoir aussi du feedback sur l'activité de l'équipe et de comment ça marche. Pareil pour une démo du produit, faire recueillir du feedback de la part d'autres départements, des utilisateurs s'ils peuvent être là, des boss de l'entreprise, etc. Et peut-être qu'il y a plein d'autres moments où on peut mettre en place ces boucles de feedback là, pour améliorer la manière dont on bosse ensemble et pour trouver ensemble ce torguet qui nous convient bien.

Terry : Très très clair, ça permet aussi de rappeler comme toujours que tous ces cadres de travail en fait sont là pour inspirer mais derrière il faut s'approprier les choses et faire ce qui fonctionne pour son organisation. Dans cette première partie de comment organiser l'apprentissage, comment mieux apprendre de nos erreurs en termes d'organisation dans les boîtes, ce que je retiens bien c'est le fait d'aller voir ce qui se fait aussi ailleurs, de ne pas hésiter à aller discuter avec d'autres entreprises et ensuite, comme tu viens de l'expliquer, de prendre ce qui a l'air de correspondre pour nous et essayer de l'appliquer et de fonctionner de manière assez itérative sur ça. Du coup avant de basculer sur le deuxième sujet qui est plus comment tu maintiens une certaine vélocité en termes de ce que tu arrives à livrer en termes de valeur pour le marché versus des organisations qui passent à l'échelle ou qui sont assez importantes en termes en termes de personnes et donc des nécessités de mettre en place malgré tout des process, des choses qui parfois peuvent limiter du coup cette vélocité, cette capacité d'adaptation pour sortir des choses qui apportent de la valeur sur le marché. Donc avant de passer sur cette deuxième partie, est-ce qu'il y a un sujet en particulier sur cette première thématique de l'apprentissage et de comment mieux structurer les boîtes que tu voudrais accentuer ou qu'on n'a pas abordé ?

Bastien : Oui, merci pour ça. Ça me fait penser à un sujet qui est aussi important pour moi. Tout ce dont on parle là, ça me semble réalisable uniquement si on va dire la culture de l'entreprise dans laquelle on est, le soutien et le support et donc de parler dans tout ça des rôles des managers aussi. le fait de rendre possible tous ces principes dont on parle. Si on est dans une société qui favorise peu l'ouverture ou qui favorise peu le fait de prendre le temps de faire les choses, ça reste des belles paroles et ça sera très difficile de les mettre en place. Pour favoriser l'apprentissage, un sujet qui me vient en tête aussi, c'est la résolution de problèmes. d'arriver à identifier quels sont les problèmes que rencontrent les entreprises ou les équipes et comment est-ce qu'on les résout, comment est-ce qu'on s'assure que la réponse qu'on y a apportée résolue bien le problème, etc. C'est lors d'une conférence, j'ai entendu la définition d'un problème, c'est un écart de performance entre ce qui s'est passé et ce qu'on aurait attendu. Et ça m'a marqué parce que le fait de dire que c'est un écart, la personne qui disait ça c'était Marie-Pier Ignaz de chez Opera & Partners, qui est une société aussi qui est reconnue pour ses compétences dans le Lean. Et elle disait, si vous ne constatez pas d'écart de performance, c'est juste que vous avez un souci, ce n'est pas un problème. Et donc pour voir si on a un écart de performance, il faut qu'on ait principalement des mesures ou des indicateurs qui vont nous permettre de l'observer cet écart-là. Et ensuite, pour la résolution du problème, le rôle des managers est important là-dedans pour permettre aux équipes déjà d'identifier quels sont les bons problèmes, comment les résoudre, et à partir d'un moment, si on voit qu'un problème se produit plusieurs fois, Peut-être qu'il y a un travail plus systémique à faire, peut-être qu'il y a besoin de changer quelque chose à plus grosse échelle que notre équipe, ou bien de former des personnes, peut-être qu'il y a un geste qui était mal fait, je sais pas, une incompréhension, ou alors on n'a jamais trop pris le temps de discuter de comment faire ce truc-là, on le faisait un petit peu par habitude. Sauf qu'on s'est rendu compte qu'on faisait pas tous la même chose ou qu'on avait pas tous la même philosophie sur comment le faire et derrière ça pouvait créer des écarts dans la manière dont on fait notre job qui amenait peut-être à une baisse de qualité de notre produit ou des délais qui étaient plus longs comparé aux attentes qui ont été faites. Et donc pour ça, ça demande que les managers soient proches de leur équipe, soient conscients de comment se passent les choses et puissent aussi apporter des réponses opérationnelles à ce qu'ils observent. Et pour aller citer une pratique de plus, quelque chose que j'aime bien, c'est toujours inspiré du Lean et de Toyota à l'époque, c'est ce que s'appelle le Gamba Walk. Pour donner une courte définition de ce que c'est, sans rentrer trop trop dans les détails non plus. Dans les usines, c'était le fait que les managers ou les personnes qui encadraient les équipes de production descendait vraiment dans les chaînes de production, dans les usines, et passait du temps à regarder comment les gens travaillaient. Sans créer non plus une culture de « je t'observe pour voir si tu fais un faux pas et te sanctionner », mais plutôt dans l'optique d'améliorer ou les conditions de travail de la personne. Peut-être que la personne n'avait pas un poste de travail qui était adapté à sa morphologie, ou faisait des gestes qui en fait lui causaient des douleurs, et donc là, les managers pouvaient apporter des solutions. Plutôt que juste dire, tiens t'as serré 10 boulons à la minute, hier t'en avais fait 20, du coup t'auras pas ta prime. C'est pas une culture qu'on essaie de favoriser. et donc d'avoir ce fait que les managers viennent observer comment les choses se passent ou même passent du temps avec les gens dans les équipes pour voir comment les gens collaborent entre eux, comment la communication, voir comment est-ce qu'ils développent, comment est-ce qu'ils... Ils répondent aux demandes qui leur sont faites, etc. Et petit à petit, grâce à cette résolution de problème, je pense que ça permet d'améliorer l'apprentissage dans l'entreprise. Et idéalement, le step d'après, ça serait d'avoir une communauté de pratique pour échanger sur tous ces problèmes qui ont été identifiés et favoriser les échanges entre plusieurs équipes. Si tu es dans une entreprise qui a un certain nombre d'équipes et qui est plutôt grosse, qui travaille sur des produits différents, c'est pas dit que tu aies beaucoup de collaborations entre différents départements qui se croisent pas tous les jours. Donc le fait d'avoir ces communautés de pratique permet aussi, pareil, d'aller présenter le boulot qu'on a réalisé, les apprentissages qu'on a eus et voir si on peut inspirer d'autres départements, même s'inspirer des histoires des autres aussi.

Terry : Très clair pour compléter, du coup merci pour ce rappel sur l'importance effectivement d'avoir le soutien de ton manager quand tu veux mettre en place, améliorer les méthodes de travail. Ce qui est aussi, parce qu'on parle beaucoup du, ce qu'on appelle dans les plus grosses boîtes, le bottom up, il faut que ça vienne d'en bas, toutes ces organisations etc. Mais il y a un moment, il faut quand même que le manager soit là aussi pour aider, pour faciliter ces choses là. pour compléter ce que tu viens de dire et arrête moi si je me trompe mais tel que je le comprends c'est quand tu parlais d'avoir le manager qui reste opérationnel c'est dans le sens où il faut que c'est pas du micromanagement loin de là c'est plutôt de se dire qu'il a quand même un pied dans l'opérationnel pour comprendre ce qui se passe et être capable si besoin de venir vraiment à une zone débloquer des situations mais surtout d'avoir une compréhension fine de ce qui se passe au quotidien pour aider à débloquer les situations et non pas pour faire comme tu le disais du micromanagement et aller contrôler et derrière être trop directif mais c'est pour quand même avoir une compréhension de ce qui se passe et pas être juste dans des strates trop trop hautes par rapport à la réalité du terrain quoi.

Bastien : Oui c'est ça, d'avoir une bonne compréhension de comment se font les choses et aussi des compétences des gens de leur équipe, de voir est-ce que les personnes sont correctement outillées, ont les bonnes compétences, est-ce qu'il y a des compétences à développer. que ce soit des compétences techniques ou des compétences plus relationnelles ou des compétences sur le métier sur lequel ils bossent. Tous ces axes là pour s'assurer le moins de problèmes possible et que tout soit fluide.

Terry : Très clair, du coup maintenant pour passer sur la deuxième partie de l'échange, sur la partie plus comment tu fais pour maintenir une vélocité, une adaptabilité dans des organisations qui grossissent et donc qui sont obligées de se structurer avec que ce soit des frameworks ou plutôt commencer à mettre en place des process, des choses plus structurée. Qu'est-ce que toi t'as pu voir sur tes expériences passées, dans tes activités de consultant, qui étaient compliquées du coup quand tu passes à l'échelle en termes de taille de personnes qui travaillent sur un même produit ou sur plusieurs produits différents, et ce que tu as pu voir aussi de situations qui fonctionnaient bien, voilà, avoir un peu... peut-être on peut rentrer par un problème que toi, qui te vient en tête à ce niveau-là.

Bastien : C'est les gros enjeux de nos sociétés aujourd'hui, de scaler, de grossir, de continuer à livrer rapidement. C'est pas un sujet simple. Je pense qu'il y a beaucoup d'entreprises qui essayent des choses. Aujourd'hui, ce que j'observe des fois, c'est que ce réflexe de croissance, de vouloir être plus, de faire plus, ça... ça peut ne pas faire du bien aux produits sur lesquels on bosse. Je pense qu'il y a des enjeux business sur lesquels il faut rester conscient, qui demandent de faire évoluer les produits, de développer des nouveaux produits, de rester innovants, etc. qui créent des gros challenges dans les organisations, de voir comment est-ce qu'on fait évoluer ces orgas pour derrière continuer à répondre aux enjeux et plus on ajoute de personnes, plus on complexifie aussi les organisations. Il y a un petit dessin que j'aime bien, c'est vous représentez chaque personne par un point et puis vous tirez un trait entre chaque point pour représenter les communications. Quand il y a deux points, c'est facile. juste une ligne. Si vous mettez 10 points ou 9 points, je crois qu'il y a plus de 91 lignes qui sont tracées et du coup le schéma ressemble plus à grand chose. Mais ça résume bien comment ça se passe dans les équipes que j'ai pu accompagner aujourd'hui. plus on va mettre d'équipes qui vont peut-être même travailler sur le même produit, plus on va créer de silos, plus il va falloir avoir cette réflexion organisationnelle de comment est-ce qu'on découpe. Alors aujourd'hui, on a pas mal d'outils et de pratiques qui émergent, je pense, au domaine des Raven Design, combinés avec des principes issus de Team Topology pour arriver à créer des organisations qui soient avec le maximum d'autonomie, d'efficacité, en réduisant au maximum les dépendances entre les équipes, et aussi en essayant de préserver la charge cognitive que chaque équipe doit gérer. C'est des outils qui sont plutôt inspirants et plutôt utiles pour nous aider dans ce travail-là, mais ça reste quand même des travaux qui demandent d'être constamment traités. Il n'y a pas de moment où on arrive en se disant ça y est notre orga fonctionne bien puisque le lendemain il suffit qu'il y ait une nouvelle équipe qui se crée, des personnes qui s'en vont, des nouveaux objectifs, des nouveaux enjeux de business qui vont demander derrière d'aller entretenir tout ça.

Terry : Donc ça, la constance de maintenir des choses qui fonctionnent, ça je pense que c'est hyper important. Encore plus du coup, ça fait sens puisque comme on le disait au début, on est quand même sur des métiers, des organisations qui évoluent en permanence, des jobs qui n'existaient pas il y a 10-20 ans, des marchés qui aussi évoluent très vite. Et donc on n'est plus dans une logique industrielle où une fois que tu avais ton usine qui est posée, tes process qui sont rodés, Il n'y a plus qu'à délivrer. Dans notre domaine, on parle bien évidemment de boîtes technologiques ou en tout cas qui ont des produits digitaux et qui font qu'il y a cette dynamique-là à en permanence ajuster les fils pour trouver quelque chose. En fait, tu es en permanence un peu sur une ligne de crête et il faut toujours y rester. Donc là-dessus, je te rejoins. Sur ces complexités, tu as cité quelques noms de méthodes ou de façons de littérature qui peuvent aider à s'inspirer pour structurer les choses. Toi, si tu parlais d'une de tes premières aventures où tu étais dev, tu as vu la boîte grossir de l'interne. si des choses marquantes qui te viennent en tête que ce soit cette aventure ou d'autres mais je suis intéressé par vraiment un retour de l'intérieur de des choses que tu te dis ah oui ça c'était vraiment compliqué et il y a eu telles et telles choses qui ont débloqué la situation ou un peu voilà avec le recul te dire ah oui effectivement ça on a réussi à le traiter comme ça ou ça on n'a pas réussi à le traiter mais du coup voici l'apprentissage qu'il y a derrière. Est-ce que tu as quelque chose qui te viendrait en tête par rapport à ces expériences passées ou même plus récentes dans des boîtes pour lesquelles tu as intervenu en tant que consultant ?

Bastien : Yes, j'ai quelques histoires qui me viennent en tête, même semblent pas super pertinentes. Je te les partage, tu me diras ce que t'en penses. La première, c'est la première société dans laquelle j'ai travaillé quand j'ai commencé en tant que dev. Quand l'orga a grossi, on a eu un découpage naturel par produit. L'entreprise développait plusieurs produits et on avait une équipe par produit. Il y avait peut-être un produit qui avait deux équipes plutôt, avec des périmètres très très autonome et assez séparé, donc je pense qu'on n'était pas outillé avec des réflexions comme le Domain Driven Design et les différents bundled contexts qu'on peut y retrouver ou des outils comme Team Topology et de voir quelles différentes topologies d'équipes on met en place pour répondre aux besoins d'organisation qu'on a. Donc c'était un petit peu du bon sens où les choses sont faites naturellement sur un découpage vraiment orienté business et produits. Dans d'autres structures avec lesquelles j'ai travaillé, je me souviens d'une grosse orga d'environ 200 personnes qui travaillaient sur un même produit avec une organisation d'agilité à l'échelle où ils utilisaient du safe. C'était franchement pas simple. Bon, déjà juste le fait de dire 200 personnes qui bossent sur un même produit, ça nous fait tous un petit peu des frissons. Mais on essayait de faire du mieux qu'on pouvait avec toutes ces contraintes-là qu'on avait. Ce qui était intéressant là-dedans, c'était qu'on voyait bien les dépendances entre chaque équipe, parce que la méthode O permettait de facilement les identifier, résoudre ces dépendances. Par contre, c'était autre chose. En fait, la plupart du temps, on vivait avec et c'était assez douloureux. Ce qui était moins pratique, par contre, dans ce contexte-là, c'est la distance qu'il peut y avoir entre les personnes qui prennent les décisions et les personnes qui font le job derrière. Je pense à des grands comités de pilotage, d'architecture, produits ou autres, où on a l'impression rapidement de rentrer dans la tour d'ivoire avec les savants fous en haut qui écrivent des manuscrits et qui regardent de loin ce qui se passe en bas et cette distance fait que pareil il y a peu de communication ou alors le dialogue est plus difficile du coup les problématiques sont pas interprétées de la même manière entre quelqu'un qui donne une solution et quelqu'un qui l'applique derrière et qui se rend compte que cette solution n'est pas la plus adaptée ou marche pas C'est ça qui me vient en tête principalement.

Terry : Déjà, moi je trouve hyper pertinent, donc merci pour ces partages. Par rapport à la partie bon sens, je trouve ça toujours cool dans beaucoup d'épisodes, ça revient, et parce que c'est important de ne pas l'oublier. C'est-à-dire que, comme je le disais tout à l'heure, quand on parle de cadres de travail type Agile et autres, on peut vite se perdre à vouloir à tout prix appliquer à l'air de certaines choses, mais quand on disait qu'il faut l'appliquer à ton organisation, ça veut aussi dire du coup ne pas perdre ce bon sens, c'est-à-dire si quelque chose fonctionne, pourquoi le changer, même si tu ne fais pas exactement ce qui est écrit sur les théories d'organisation que tu peux lire. à droite et à gauche, donc ça top. Sur ce que tu viens de dire par rapport à des orgas où tu vas avoir 200 personnes qui bossent sur le même produit, tu as du safe qui est mis en place, donc plein plein de mécanismes du coup pour déjà mettre en exergue toutes ces dépendances, donc c'est une bonne chose déjà de le savoir. Après, comme tu le disais, très compliqué à résoudre. Derrière tu disais aussi la partie dans ce type d'organisation ou peut-être même d'autres qui sont quand même assez grosses, tu vas avoir souvent effectivement des comités de pilotage, des décideurs qui, c'est pas parce qu'ils le veulent pas, souvent c'est qu'ils ont plein d'autres choses à faire et donc ils sont assez loin du terrain. Les personnes sur le terrain parfois elles comprennent pas du coup pourquoi certaines décisions sont prises et du coup elles les appliquent bon en mal en mais à contre contre volonté quoi et donc ça c'est jamais bon donc je suis curieux de savoir ce qu'on a parlé pas mal quand même en termes de communication on parle souvent de communication entre équipes donc ça en général j'ai envie de dire une fois que ça commence à rentrer on arrive à le faire communiquer par contre entre des directions beaucoup plus éloignées du terrain et les équipes ça peut être plus complexe d'un point de vue déjà hiérarchique parce que du coup il n'y a pas les mêmes niveaux au niveau de l'organisation. Donc quels seraient un peu, tu vois, tips ou en tout cas des choses que tu pourrais partager sur pour des personnes qui sont plus endzone opérationnelles, même ça peut être des managers, qu'elles puissent utiliser pour essayer de communiquer auprès des directions beaucoup plus hautes dans les orgas, pour les aider à leur donner plus de contexte aussi sur ce qui se passe sur le terrain et leur permettre à eux, au niveau très haut dans l'organisation, de prendre des décisions plus alignées avec les problématiques du terrain.

Bastien : Yes. Tout l'enjeu là-dedans, je pense pour les organisations, c'est d'arriver à simplifier au maximum ces schémas organisationnels pour réduire ces distances et idéalement éviter ce côté des personnes qui prennent des décisions sans être consciente de ce qui se passe sur le terrain. Je pense, plus facile à dire qu'à faire, surtout dans des grosses boîtes qui peuvent avoir d'autres dimensions. on va dire plus politique avec des enjeux qui sont on va dire moins flagrants que des enjeux business ou autres et un héritage aussi qui fait que tu changes pas une organisation qui est énorme en un claquement de doigts donc peut-être plus facile à dire qu'à faire là dessus. pour revenir un peu sur ce thème de la communication et du dialogue en entreprise. Et le sujet que moi j'aimerais mettre en avant, c'est un petit peu lié avec comment on a commencé l'épisode, c'est de prendre le temps de se parler, prendre le temps d'aller comprendre les problématiques que rencontrent les gens, prendre le temps de les écouter, de comprendre comment ça se passe, de se mettre à leur place idéalement aussi. On parlait souvent d'empathie dans d'avoir plus d'empathie dans nos métiers, dans nos relations avec nos collègues. Moi, ça m'est arrivé plusieurs fois de croiser ou d'essayer de faciliter la vie d'équipe où quand tu parles à une personne, tu diras de toute façon, cette personne, elle comprend rien, elle sait pas travailler, comprend pas ce qui se passe. Et quand je changeais de côté du bureau pour aller écouter comment ça se passait de l'autre côté, j'entendais le même discours. Et là, la communication, elle est presque brisée dans ces cas-là. Donc, c'est vraiment de prendre le temps de dialoguer, de communiquer. Et peut-être, ça demande aussi du boulot d'apprendre à mieux communiquer avec ses collègues ou mieux communiquer avec sa direction, ses utilisateurs ou d'autres personnes. Quand on a discuté pour préparer l'épisode, je te parlais de la communication en entreprise, cette compétence sous-cotée. C'est vrai que moi j'observe beaucoup dans les équipes tech notamment le fait de toujours travailler sur la dernière techno, les dernières versions, donc beaucoup développer ses compétences, les hard skills, ses compétences techniques, les nouveaux outils, les nouveaux patterns, les nouvelles technologies qui sortent. Et on va beaucoup faire de conférences ou de formations sur, je sais pas, une techno en particulier ou des nouveaux systèmes d'architecture, des nouveaux paradigmes d'architecture qui sortent. Et on retrouve, en tout cas moi j'observe, qu'on retrouve moins souvent au programme de formation de compétences. comment arriver à mieux travailler ensemble, notamment via la communication, le dialogue, comment est-ce qu'on aborde les conflits au travail, comment est-ce qu'on aborde les désaccords, comment est-ce qu'on arrive à prendre des décisions ensemble, surtout dans les équipes tech où on peut très vite tomber dans des grands débats pour ou contre tel truc avec des personnes qui sont très compétentes sur ces sujets-là mais qui des fois ont du mal en fait à se parler, à converger vers une décision ensemble et qui peut créer ce conflit, qui peut amener des silos, qui peut amener des dépendances entre équipes qui sont créées à cause de ces soucis-là et qui au final ne facilite pas le fait de garder une certaine vélocité, comme tu disais, pour arriver à livrer rapidement des produits, surtout quand une entreprise grandit aussi.

Terry : Sur ce sujet hyper important de la communication effectivement, si tu devais flécher un peu, sans rentrer dans tous les détails qu'il peut y avoir, mais flécher un peu des équipes très tech qui écouteraient ce podcast et qui se diraient, c'est vrai que je vais essayer sur les six prochains mois d'un peu bosser sur mes compétences en communication pour essayer de faciliter un peu, débloquer des situations que j'ai et mettre un peu de côté la montée en compétences sur le Nouveau Framework Front ou sur la nouvelle Technoba qui vient de sortir, qu'est-ce que tu pourrais donner comme flèche, comme piste de réflexion ou de travail à ces personnes qui veulent améliorer ces compétences-là ?

Bastien : Je pense déjà prendre le temps de détecter les endroits où on n'est pas d'accord avec ce qui se passe avec nos collègues, les endroits où on entend autour de nous des conflits, des désaccords pour mieux s'ouvrir à tout ce domaine-là. Pareil que tout à l'heure, j'aimerais mettre en avant aussi le rôle des managers là-dedans, d'arriver à identifier ces relations conflictuelles et à accompagner les personnes pour adoucir ces relations et retrouver de l'harmonie dans la manière dont on bosse ensemble. Parfois, c'est... Parfois, c'est... On va dire, il y a des moments, ça peut être plus simple que d'autres. Parfois, peut-être que l'issue de ce problème-là, ça sera on ne peut plus travailler ensemble, on ne peut pas travailler ensemble aujourd'hui, donc travailler dans des équipes différentes, se séparer d'une personne, c'est des décisions qui sont dures à prendre mais parfois ça demande un petit peu de courage. Je pense le fait d'avoir une personne dans son équipe, manager ou autre, avec qui pouvoir en parler sur le côté « j'ai un désaccord avec telle personne et j'aimerais en parler à quelqu'un de neutre pour déjà clarifier un peu moi aussi mes idées et à chercher des avis à droite à gauche pour ensuite aller pouvoir amener le problème qu'on rencontre plus facilement au camp opposé. Ça me fait penser à une petite technique que moi j'avais appris dans une formation de management par un collègue qui s'appelle Eric Séguier. qui m'a présenté... alors je crois que le nom en français je dirais c'est les quatre éléments du langage, ou en anglais ça doit être four parts of a speech, quelque chose comme ça, qui propose on va dire quatre étapes pour se poser des questions et structurer son discours pour arriver à parler d'un problème en entreprise. La première étape, de mémoire si je m'en souviens, c'est le fait de poser le contexte, le framing, de donner à la personne tous les éléments dont elle a besoin pour comprendre la problématique ou le désaccord qu'il y a ou le sujet dont on parle. Le deuxième, c'est le fait de faire une proposition. Voilà, je t'expose toutes les données qui me semblent utiles pour que tu comprennes le problème. Je te propose une solution derrière et après je vais illustrer pourquoi est-ce que je pense que ma solution permettrait de répondre à cette problématique qu'on a. Par exemple, je ne sais pas si je fais telle solution, alors ça me permettra de résoudre tel problème ou d'atteindre tel objectif qui permettra de résoudre tel problème, etc. Et la dernière étape, c'est d'ouvrir les perspectives à ce que moi je n'ai pas identifié mais que le reste du groupe pourrait avoir vu pour enrichir ou même proposer une autre solution ou faire une autre proposition à ce que j'ai. Donc c'est vraiment ces quatre étapes-là. Et surtout la plus importante, ça serait d'avoir cette ouverture pour aller chercher vraiment d'autres perspectives, essayer de comprendre comment ça peut se passer pour une autre personne, comment est-ce qu'elle voit la problématique de là où elle est assise autour de la table.

Terry : Hyper clair, des tips assez intéressants sur l'importance de... Alors après, pour compléter un petit peu sur les sujets de la communication, tu as tout ce qui est communication non violente aussi, qui peuvent être intéressants à explorer pour justement exposer ce qu'on ressent d'une manière assez cadrée, un peu de la même façon là qu'exposer son problème. Ce que je trouve intéressant, c'est le point d'aller en parler à quelqu'un de neutre, ça c'est assez... assez pertinent parce que justement ça permet aussi à soi-même de réfléchir à ce qui nous pose souci et juste le fait de l'exprimer des fois fait aussi un peu changer la perception qu'on a du problème qu'on avait initialement donc ça je trouve assez cool. Donc avant d'aller vers mes questions type de fin d'épisode, est-ce qu'il y a un sujet en particulier sur cette deuxième thématique qu'on n'aurait pas abordé ou que tu voudrais accentuer en particulier ?

Bastien : Oui, tu parlais de communication non violente. C'est vrai que c'est un outil qui ressort assez facilement dans les discussions. Je trouve que c'est quelque chose qui est très utile pour soi, pour essayer de mieux comprendre aussi sa manière dont on communique. Je le trouve plus difficilement utilisable en entreprise car ça demande quand même d'avoir un espace dans lequel on peut mettre en avant nos émotions, comment est-ce qu'on se sent quand quelque chose se passe. Et de mon expérience, si en face de moi j'ai quelqu'un qui s'en fout totalement de tout ça, et que j'arrive en disant là j'étais frustré, là je me suis senti pas respecté ou autre, et qu'en face de moi j'ai quelqu'un qui est très fermé à tout ça, la communication elle se simplifie pas. Après, je pense que c'est toujours un outil intéressant à avoir dans sa bibliothèque et je ne le mettrai pas totalement de côté, mais c'est vrai que je le trouve aujourd'hui un peu moins actionnable ou alors qui demande un peu plus de travail de fond avec toutes les personnes pour arriver à créer ce cadre dans lequel on peut dialoguer plus facilement.

Terry : Intéressant, merci pour le retour. C'est vrai, apprendre potentiellement, je ne dirais pas avec des pincettes, mais à considérer par rapport au contexte de l'entreprise dans laquelle tu es et la personne que tu as en face de toi, c'est vrai que c'est un point important. Merci pour ce partage. Pour aller vers mes deux questions types, la première, c'est est-ce que tu aurais une conviction forte avec laquelle, en général, quand on discute avec tes pairs, tu es en désaccord ou en tout cas qui génère discussion ?

Bastien : Je réfléchis un peu. Je n'ai pas de souvenir de convictions fortes qui génèrent des désaccords. Moi j'apprécie beaucoup travailler dans, comme je disais tout à l'heure, ces méthodos plus orienté ou inspiré de Kanban ou du boulot qui est fait sur le Lean plutôt que d'appliquer du Scrum by the book pour construire une organisation qui permet vraiment à l'équipe d'être en maîtrise sur tout ce qui se passe plutôt que de chercher à bien faire du Scrum, mais plutôt chercher à bien faire son produit ou bien travailler ensemble, etc. Je ne suis pas totalement fermé dans mes réflexions non plus. Je sais qu'il y a du bon et du moins bien un peu partout et il y a surtout besoin de s'adapter aux différentes contraintes des différents contextes.

Terry : Donc ce que tu dirais c'est toi plus une préférence de partir vers des approches type Kanban et ensuite de les adapter aux organisations plutôt que de rentrer par des approches plus timeboxées ?

Bastien : Oui, en fait la conviction que j'ai, on pourrait dire, c'est de prendre le temps, c'est de fonctionner d'une manière qui permet de livrer continuellement de la valeur en équipe, d'avoir ça en grands principes et ensuite derrière de s'ouvrir à comment fonctionnent les autres, qu'est-ce que je peux piquer un petit peu, m'inspirer chez les autres pour améliorer mon fonctionnement à moi. Aujourd'hui on a tellement de vécu dans des domaines d'expérience, dans des domaines différents entre toute la littérature qu'on peut avoir et toutes les ressources qu'on a. il y a de quoi s'inspirer. Je ne préconise pas d'aller copier totalement ce qu'ont fait les autres. On a pu voir aussi ce qui s'est passé quand Spotify a documenté son modèle à l'époque et derrière ce qui s'est passé dans les communautés avec des personnes qui ont voulu appliquer ce modèle-là chez eux, les conséquences que ça a pu avoir. Et au final, ce qu'on en retire comme leçon, c'est que ce travail d'organisationnel, il requiert constamment de l'énergie et de s'inspirer un petit peu, à droite à gauche, de comment fonctionnent les autres pour trouver nous-mêmes le fonctionnement qui nous va bien et d'aller au-delà de juste nos compétences pures, que ce soit peut-être des compétences techniques ou autres, mais aussi d'être conscient sur, pour bien faire notre job, on a peut-être besoin aussi d'acquérir quelques compétences sur comment est-ce qu'on s'organise, comment est-ce qu'on dialogue avec le métier, comment est-ce qu'on dialogue entre nous, et donc d'enrichir sa palette de compétences pour faire son job le mieux possible.

Terry : Très clair et du coup pour aller vers la deuxième question transition parfaite au niveau des ressources des recommandations que tu pourrais avoir sur et même les choses qui toi te nourrissent aussi pour ton job au quotidien qu'est ce que tu pourrais nous partager ?

Bastien : Alors aujourd'hui, quand je prends le temps de regarder les endroits où je tire le plus d'apprentissage et le plus de ressources, je dirais que c'est principalement des communautés sur l'outil Slack. On a la chance d'avoir quand même, je trouve, beaucoup de personnes qui mettent de l'énergie dans du partage, dans le fait de monter des communautés, de les faire vivre. et de favoriser ces retours d'expérience entre équipes. Les deux que j'ai en tête, c'est la communauté TechRox, qui est très active. En plus de la communauté Slack, ils ont aussi un podcast, ils ont aussi une conférence qu'ils font chaque année. Et la deuxième que j'ai en tête, c'est FrenchProduit, qui est une communauté sur Slack. qui regroupe des personnes de toute la France, donc ça permet aussi quand on est à Paris de sortir un peu du contexte vraiment très parisien et d'aller s'inspirer aussi de ce qui peut se passer dans les autres villes et dans les autres entreprises. Après, je pense les classiques. Moi, j'apprécie toujours autant aller me balader dans des conférences pour continuer de suivre comment nos métiers évoluent, comment les pratiques évoluent. Et l'autre source, ça va être... J'allais parler des livres, mais c'est vrai qu'il y en a tellement des livres sur tous les sujets qu'on peut vite tomber dans le... remplir sa bibliothèque et ne plus trop savoir où en donner de la tête et se mettre la pression pour arriver à lire les derniers bouquins. La dernière que je préconiserais, ça serait d'aller discuter avec des personnes qui font le même job que nous. dans d'autres boîtes, que ce soit des anciens collègues, des amis qui travaillent dans les mêmes domaines, et rester curieux en cherchant toujours à comprendre et à s'inspirer de ce qui serait le plus bénéfique pour soi.

Terry : Très, très, très clair, très bon, très bon conseil. Je partage totalement le fait d'aller échanger avec, avec des gens, avec ses pairs. C'est aussi un des intérêts assez égoïste, entre guillemets, de ce podcast aussi. J'adore échanger du coup avec beaucoup de monde, donc ça me permet de le faire. Et j'espère de partager ça aussi avec, avec les auditeurs. Donc, merci encore pour ton temps, Bastien. Et puis, à bientôt, soit dans une conf ou même sur Slack French Produits. Merci, Bastien.

Bastien : Avec plaisir. Merci à toi aussi.