Le manager, catalyseur de l'agilité

0:15 Merci, bonjour à tous, très heureux d'être là avec vous pour ce sujet, pour parler autour de l'agilité un peu en général et surtout de qu'est-ce que ça implique sur votre rôle, votre quotidien en tant que tech leader. Pour ça, aujourd'hui, je suis avec Emilie Esposito et Nicolas Tricot, je vais peut-être aussi moi me présenter, si vous ne me connaissez pas très rapidement, donc moi Jean-Pierre Lambert, je suis coach agile et qualité indépendant depuis une bonne année et demie. Je fais diverses choses, je partage beaucoup et en particulier, je suis le créateur de Scrum Life, qui est une chaîne YouTube qui parle de tout ce qui est agile, etc. Si vous ne connaissez pas déjà, allez sur scrumlife.tv, vous allez adorer. Je ne vous dis pas plus. Je vais laisser Emilie et Nicolas se présenter aussi. Bonjour à tous, donc moi je suis Emilie Esposito, je suis coach d'entreprise, je suis tombée dans la JT vers 2008-2009,

1:17 J'ai beaucoup travaillé sur ce domaine-là et aujourd'hui, en fait, je passe au niveau au-dessus. J'essaie plutôt que d'aider les boîtes à devenir plus agiles dans leur méthode, j'essaie de faire en sorte qu'elles soient plus agiles. Elles deviennent également performantes et épanouissantes. Et l'AJD, du coup, c'est un des outils que j'utilise dans le quotidien. Nicolas? Et moi, je m'appelle Nicolas Tricot, enchanté. Je suis Head of Engineering chez Pack Market. Et j'ai un profil de dev back-end au départ. J'ai fait pas mal de dev pendant un peu plus d'une dizaine d'années dans différentes boîtes du web français. Mythique, Viadeo, Blablacar et maintenant dans le back market. Et à un moment donné, j'ai opéré la bascule vers des rôles de management et je me suis pas mal intéressé à l'agilité pour faire en sorte que nos équipes tournent le mieux possible. Donc, c'est un sujet qui me passionne toujours autant et sur lequel j'apprends tous les jours. Donc, ravi d'en discuter. Tu es un peu celui qui va nous garder les pieds sur terre, puisque Tech.Rocks, communauté publique, nous, on est plutôt extérieur, alors que toi, tu fais vraiment partie de cette communauté-là.

2:20 Et avant de rentrer dans le dur du sujet, il faut peut-être qu'on commence par recadrer un peu le sujet, parce qu'effectivement, on parle de l'agilité. Du coup, c'est quoi les promesses de l'agilité en fait? Pourquoi maintenant il faut être agile, tout le monde fait de l'agilité, pourquoi on en parle autant? Est-ce que vous voulez répondre? C'est quoi les promesses de l'agilité? Je pense que dans la période où on est, on pourrait déjà parler du fait que ça rend les entreprises plus résilientes. C'est-à-dire que quand on a l'habitude de s'adapter aux changements plutôt que de faire des plans sur un an ou plus, on sait mieux s'adapter aux crises. Je pense aussi que le fait d'avoir... une véritable auto-organisation, c'est que quand d'un coup l'équipe doit se retrouver à distance, on a beaucoup plus confiance sur le fait que le travail va continuer, que l'équipe va prendre le temps pour s'ajuster comme elle le fait à chaque changement, mais qu'elle va trouver des solutions et demander de l'aide si elle en a besoin pour pouvoir faire son travail correctement. Donc, je pense que dans des périodes comme celle-ci, l'agilité, elle aide particulièrement bien.

3:26 Donc, ça met en plus un focus sur le fait que c'est intéressant d'être agile et peut-être que ça convaincra des entreprises plus durablement aussi à sauter le pas. On avait évoqué aussi de manière plus traditionnelle l'idée d'avoir un ROI plus rapidement, tout simplement. C'est un peu souvent pour ça qu'on vend l'agilité, traditionnellement. Je ne sais pas s'il y a besoin de rajouter quelque chose là-dessus. Il y a peut-être le fait aussi que ça permet de pivoter plus vite. Là, je reviens sur le fait qu'on est en temps de crise. En fait, quand on a une roadmap qui est déjà hyper tracée et dont on n'a pas l'habitude de s'écarter, c'est compliqué de profiter des opportunités de la crise. Là, quand on voit par exemple des usines qui ont reconverti, reconfiguré leur matériel de production pour tout de suite produire des masques, je pense que ces usines-là ont eu des avantages concurrentiels par rapport à d'autres qui avaient des processus beaucoup plus lourds.

4:28 On a les mêmes problématiques dans l'infrastructure. Si on arrive à pivoter plus rapidement, on sait s'adapter à à peu près tout ce qui peut arriver. Exactement, et je dirais que justement la situation quand on a eu les premiers confinements, le Covid, avec par exemple des zones postales qui étaient plus livrées, on doit réagir vite pour pouvoir justement pouvoir prêter aux utilisateurs, changer de moyens de transport. C'est clairement un vrai plus dans les situations comme celle-ci où on va vers de l'inconnu, on a besoin de pouvoir réagir au cœur de la situation. C'est une série. C'est un pilier sur lequel on est en mission là. Je crois qu'il y a une question un peu d'état d'esprit où finalement, quand on a un état d'esprit agile, on voit le changement et l'imprévu presque comme un ami et des opportunités plutôt que comme quelque chose qui vient foutre par terre tous les jolis plans qu'on avait tracés. Et du coup, ça devient moins une situation de crise que, OK, on fait quoi? Comment on en profite? Comment on tire le meilleur parti de tout ça?

5:29 Donc, ça marche. Il y a aussi une dernière promesse de l'agilité qui est très humaine finalement, qui est autour de l'engagement des personnes, des employés, des membres d'équipe. Parce qu'effectivement, on passe via l'auto-organisation, on donne du sens aux choses et aussi, beaucoup, on implique les personnes. Très bien. Je vous propose qu'on commence maintenant dans le dur du sujet, qu'on commence avec Nicolas. Est-ce que Nicolas, tu peux nous raconter ton aventure, notamment entre autres à Blablacar, justement tout ce parcours, ce que tu as vécu et justement comment l'agilité s'intègre dans tout ça. En ne nous épargnant bien rien, évidemment, qu'est-ce qui était bien, mais surtout, qu'est-ce que tu as raté comme un gros nul? Pardon, qu'est-ce qui s'est moins bien passé? Oui, non, bien sûr, oui, tout à fait. Oui, effectivement, parce que c'est effectivement sur l'expérience chez Bad Baccar où j'ai pu un peu faire toute la chaîne d'agilité, à commencer par, au départ,

6:30 un peu les poncifs, on se dit agilité égale Scrum égale stand-up, et donc on se dit qu'en faisant des stand-up, on est agile, et bizarrement, on voit quand même assez peu de bénéfices. On se dit, c'est sympa, il y a un peu de visibilité, mais ça ne marche pas à des masses. Et on va essayer un petit peu, petit à petit, de reprendre un peu les bases et de recommencer sur une base un peu plus saine. De se dire que Scrum ou autres, c'est des outils en fait, mais de comprendre la philosophie qu'il y a derrière. Et on a recommencé un petit peu ensuite avec une aide extérieure en fait, d'une personne, Julien Laure de Théodo, qui nous donnait des petits coups de main des demi-journées par semaine de temps en temps pour un petit peu... Monter en compétence sur ça et avoir ce point de vue extérieur qui permet d'avoir une vision plus neutre, plus objective et moins d'implication dans la vie quotidienne de l'équipe. Et là, on a commencé à...

7:33 Sur une application Scrum un peu au bout, donc assez rigoureuse, qui a permis comme ça de petit à petit de voir un peu les bénéfices, comment ça va en voir les bénéfices, c'est-à-dire l'interaction avec l'autre, comment ça pouvait s'améliorer. Ça nous a permis, ah oui, L'introduction d'indicateurs aussi pour calculer toutes les complexités, vélocité d'équipe. Alors, juste pour les petites erreurs, au départ, ce qu'on faisait dans l'équipe, c'est qu'en fait, on faisait… des vélocités individuelles, c'est-à-dire qu'on calculait la vélocité d'un développeur, ce qui était vraiment très très sain et très agréable comme situation. Bon, très vite, ça a été abandonné, mais voilà, le type d'erreur qu'on peut faire quand on ne connaît pas, voilà. Et ensuite, ça a commencé un petit peu plus à porter ses fruits. L'objectif, c'était vraiment derrière de pouvoir donner de la visibilité sur ce qui se passait dans l'équipe. Dans son travail, pour le communiquer aussi au reste de l'équipe, mais également hors des types techniques éventuellement, que n'importe qui puisse passer devant un bord, puisse savoir un peu où les choses étaient.

8:35 Et ça, ça a plutôt très bien marché. Ce qui change pas mal dans ce... c'est qu'en fait, on commence à aimer avoir des problèmes. C'est-à-dire, quand on arrive à les détecter assez tôt, les problèmes, on arrive à pouvoir les traiter tôt aussi. Et du coup, ça prend beaucoup moins d'ampleur et c'est beaucoup moins compliqué à traiter que dans un cycle en V typique où là, en général, on voit le problème très, très tard et c'est une tannée à faire. Donc, on a un petit peu avancé sur ce chemin-là. On s'est rendu compte que l'organisation en Scrum, elle se prêtait très bien à des équipes. Des équipes proches, moins à des équipes qui étaient plus soumises à des problématiques de production, où justement là, quand on est perturbé par l'urgence, on a besoin de travailler dessus, ça peut casser un petit peu le... Le rythme, alors on essayait de se brouiller un petit peu, de garder du temps parfois, et puis on a très vite commencé à... à chatouiller un peu du camp pour voir un petit peu si justement ça ne pouvait pas nous aider à mieux gérer ce backlog un peu changeant et de mieux gérer ces urgences qui étaient non prévisibles.

9:43 Et ça a plutôt bien marché aussi. Il y a des choses qu'on regrettait un petit peu, le côté un peu spring goal du Scrum qui était assez intéressant parce que chacun pouvait se projeter un petit peu dans le futur. Et à l'inverse, le fait d'avoir du campant, certains devs se sentaient un peu moins à l'aise parce qu'ils n'avaient pas forcément… l'ensemble global de leur sprint et de se dire, moi, j'aime bien organiser mon temps, savoir un peu comment je peux faire. Donc, il y avait des plus et des moins, comme dans chaque approche. Donc, on a parfois tenté un mélange un peu des deux, un scrum band un petit peu, en gardant un principe de backlog un peu dynamique, avec quand même parfois des objectifs pour, en tout cas, la tâche principale de l'équipe, pourquoi on voulait se focaliser hormis ces problèmes de production. Donc, voilà, c'est un petit peu cette approche-là qui fonctionnait pas trop trop mal. Et ensuite, on a essayé en fait de... En fait, les équipes grandissent, elles grandissent de plus en plus et on essaye de faire en sorte qu'elles soient le plus autonomes possible.

10:44 On commence à mixer des équipes pour faire des future teams, pour avoir des gens de multi-compétences, pour avoir des gens qui puissent être autonomes. Regardez un peu aussi la souplesse qu'on a fait. Et ça, en fait, ça va permettre d'autres équipes de pouvoir avoir une vision plus claire. Des objectifs, on peut faire des choses un peu différentes, mais le principe est presque le même. Et l'équipe ensuite va pouvoir s'approprier ça et essayer de... Dans son périmètre. Et ce qu'on a essayé de faire aussi, c'est de voir comment les équipes se sentaient. La santé de l'équipe, en fait, on s'est inspiré de quelque chose qu'avait fait Spotify, qui était un health check, en fait, qui était l'idée de se dire, on regarde régulièrement la santé un peu de l'équipe, de voir un petit peu quels sont les...

11:46 Est-ce qu'ils ont l'impression d'être assez focus? Est-ce qu'ils ont l'impression d'être acteurs de leur destinée? Essayer de sentir un petit peu la santé de l'équipe. Et ça, ça nous a permis de nous rendre compte, par exemple, qu'il y avait des équipes qui, globalement, avaient des scores assez négatifs sur l'ensemble des critères. Et donc là, on se dit, il y a un problème au niveau de l'équipe. Il y a peut-être un mal-être, quelque chose qui ne fonctionne pas bien. Ou plutôt à un niveau transverse, quand on a, par exemple, sur la qualité de la code base ou quoi que ce soit, là on se rend compte que toutes les équipes ont des scores assez bas là c'est un problème transverse c'est pas lié à une équipe en particulier c'est quelque chose qu'on doit traiter de manière transversale et pouvoir avancer là-dessus donc ça permet comme ça de comprendre aussi et périodiquement de voir si les choses s'améliorent ou pas d'arriver à savoir un petit peu tout ça Voilà, et ça n'arrête pas de changer. On est toujours, si je devais conclure, en fait, on essaie vraiment d'adapter un peu après une organisation d'équipe, une organisation agile à l'équipe en fonction de ce qu'elle est. Je pense que c'est important de bien comprendre la philosophie qu'il y a derrière ça pour pouvoir ensuite s'en écarter un petit peu.

12:53 Et donc, voilà, mais en tout cas, ça porte ses fruits. Dès qu'on arrive à trouver le bon tempo, ça porte bien ses fruits. Juste pour deux choses. Tout ce que tu nous as décrit, là, ça se représente sur quel timeline, quelle durée, combien de temps ça a représenté? Ça peut être... Ça peut être... Ça s'est fait, je pense, sur l'équivalent de... Oui, je pense qu'il y avait entre 4 et 5 ans en total. Il y a vraiment... Enfin, ça peut vraiment prendre du temps. Et parce qu'aussi, il y a parfois des sujets... Des friches en fait, où il y a peu d'entreprises qui le font, on tente des choses et ça prend du temps. Ça marche. Je pense que c'est un truc essentiel. Souvent, les boîtes ou les équipes qui veulent devenir agiles se mettent une pression sur le temps, ou en tout cas, on leur met une pression sur le temps, on leur dit on va faire ça en un an ou en six mois, comme si ça pouvait se décider à l'avance. Et du coup, le fait que je pense que vous ayez pris le temps, ça a largement contribué au succès de la transformation.

14:01 Oui, et juste pour une petite anecdote là-dessus, mais la toute première fois, quand on s'est dit, on pensait qu'en trois semaines, bien comme il faut, tout serait bien rodé, bien huilé. Oui, c'était très optimiste. Du coup, je vous propose qu'on rebondisse déjà sur une première question. Déjà, tu peux peut-être couper ta webcam, parce qu'on a l'impression que tu as une connexion qui n'est pas incroyable. Ça soulagera un peu le système. Une question, est-ce que je peux les mettre en avant? Je ne peux pas cliquer dessus. Je vais vous la lire. Pourquoi l'agilité est mal pratiquée dans la plupart des entreprises et comment résoudre cette problématique? Il y a peut-être un lien avec ce qu'on vient de dire sur le fait que ça prenait du temps, etc. Qu'est-ce que vous en dites? Oui, alors, pour rebondir aussi sur quelque chose qu'a dit Nicolas, par exemple, au début, on fait des pratiques, on ne sait pas trop pourquoi on les fait, on les fait, etc. J'avais fait une conférence, il y a quelques années sur le cargo culte agile, En gros, la façon dont on a souvent introduit l'agilité dans les équipes, c'est en pratiquant le chou à riz.

15:11 En gros, chou, au début, je répète les pratiques bêtement, enfin bêtement, sans réfléchir, sans adapter, jusqu'à ce que je maîtrise parfaitement le geste. Puis, là, maintenant que j'ai les bases, je commence à ajouter ma patte, mon style à moi. Et oui, je prends de la distance par rapport au maître. À la base, c'est par rapport à de l'artisanat japonais, je crois, on peut faire des sabres. Donc, oui, je prends ma distance et je suis à mon tour capable d'aller enseigner. Et en fait, en faisant ça, en commençant par imiter des pratiques de l'agilité sans forcément chercher à comprendre ce qu'il y a derrière, on perd tout le sens de la pratique pour qu'on le fait. Moi, je sais que dans une boîte où j'ai été, Il y avait une chef de projet qui disait, oui, le planning poker, on ne sait pas pourquoi on le fait, mais bon, c'est rigolo, alors on le fait. Et alors, en fait, le planning poker, ça sert à éviter les biais qui font qu'on a tendance à dire comme celui qui a le plus d'expérience ou les biais de confirmation sociale, etc.

16:22 Et donc, ça a un sens. Et en fait, quand on ne comprend pas ce qu'il y a derrière la pratique, quand on va l'adapter, on va probablement mal l'adapter. Moi, c'est un truc dont je suis revenue, ça, depuis quelques temps, depuis quelques années. Je pense qu'il vaut mieux avoir les conversations difficiles au début, de savoir pourquoi on fait cette pratique. Tiens, mais qu'est-ce que ça vient heurter comme croyance qu'on avait? Parce qu'il y a des choses qui changent. Donc, parlons-en. OK, ça va prendre plus de temps, du coup, pour mettre les choses en place. Par contre, ce sera beaucoup plus durable. Et les équipes sont beaucoup plus... Pertinentes dans leur adaptation d'une méthode prête à l'emploi à leur contexte propre. Du coup, ça revient sur la question, pourquoi est-ce que naturellement, on préfère se concentrer sur des pratiques plutôt que sur le pourquoi? Parce que c'est plus facile. Il y a une recette de cuisine. C'est une recette de cuisine. Tu peux te former en deux jours en pratique. Tu peux être formé en deux jours en pratique, puis en fait, chaque personne est formée individuellement.

17:27 Par contre, poser des questions difficiles quand tu es dans un contexte où il n'y a pas encore de sécurité psychologique, avoir des conversations difficiles, ce n'est pas simple en fait. Je veux dire, pourquoi on estime, ça sert à quoi? Au fait, il y en a qui n'estiment pas. Et quand on, par exemple, on ne fait pas vraiment de planning, Est-ce que c'est un problème? Qu'est-ce que ça vient heurter? L'auto-organisation, c'est-à-dire que le manager, il ne sert à rien. Et non, en fait, mais du coup, il faut interroger le rôle de manager, il faut parler de cadre d'autonomie, etc. Donc, c'est beaucoup plus difficile. Ça fait peur. Ça fait peur. Et je pense, par contre, que c'est hyper important de le faire. Ça demande le courage à la fois au manager et à l'équipe. Ça demande un accompagnement, du coup, pour aider ces conversations difficiles parce qu'avoir un point de vue neutre extérieur, en fait, et comme tu disais, Nicolas, ça aide, en fait, ça amène des nouvelles perspectives. Ça nous permet de prendre du recul. Et voilà, c'est hyper important.

18:31 Moi, je ne suis pas trop pour copier des pratiques. La seule que je tiens, qui pour moi doit être au début de tout dans une équipe qui s'est dédiée à l'île, c'est la rétrospective. Parce que c'est la rétrospective qui permet d'introduire toutes les autres pratiques, de les faire évoluer quand elles ont évolué et de les tuer quand on n'en a plus besoin. Et ça permet d'avoir finalement la façon de travailler la plus ligne possible au sens maigre. Voilà. Mais même celle-là, on pourrait en débattre. Enfin, on pourrait avoir le même discours de ce que tu as dit tout à l'heure. Et pourquoi on l'a fait? Et en fait, ce que tu veux, ce n'est pas la rétrospective, c'est l'amélioration continue. C'est vrai, c'est vrai. Ce n'est pas la seule manière de… Je suis d'accord, je suis d'accord. D'ailleurs, un spécialiste du Lean, je te dirais, Mais pourquoi est-ce qu'on attend la rétrospective pour s'améliorer? Ce n'est pas l'IN, justement. Par contre, là-dessus, je suis entièrement d'accord. Je pense que c'est important. d'avoir un temps dont on sait qu'on va spécifiquement penser à ça, mais bien sûr, si on voit des actions d'amélioration dans le quotidien, mais faisons-les, en fait.

19:40 Pour moi, attendre, c'est perdre du temps. Quand on voit un truc qui nous casse les pieds, allons-y, le vent tout de suite. Surtout si on a déjà des idées, ce serait quand même couillon d'attendre deux semaines. Il faut plutôt le voir comme un moment privilégié, réservé et dédié à ça. Mais clairement, il ne faut pas… attendre deux semaines avant d'amener quelque chose. C'est sûr. Je taquinais un petit peu quand je disais ça. Mais non, mais il n'y a pas de dire. C'est tout à fait bien. Du coup, tu as commencé à évoquer le rôle du manager. Tu as dit en passant, du coup, le manager, il ne sert plus à rien. Qu'est-ce qu'on en fait? On pourrait peut-être en parler. Quand j'ai entendu Nicolas parler, il y avait deux questions, enfin trois en fait, qui me brûlaient les lèvres. Et toi, comment tu t'es senti, toi en tant que manager dans tout ça? Qu'est-ce qui a été difficile pour toi? Et qu'est-ce que tu as kiffé? Parce que tu nous as beaucoup parlé de l'équipe, mais pas de toi. Oui.

20:43 Alors, je dirais que moi, j'avais un peu à un certain moment le rôle de Scrum Master dedans. Donc, ça m'a un peu mis dans la position aussi en tant que manager de me mettre au service de l'équipe, c'est-à-dire de changer, de ne plus être dans un management directif, de dire toi tu fais ça, toi tu fais ça et toi tu fais ça, mais plutôt dans un mode, OK, on organise le travail de l'équipe grâce à la méthodologie et derrière, c'est par contre tous les bloqueurs, tous les points à faire sauter. Donc ça, c'était un peu le côté Scrum Master de jouer un petit peu là-dessus. Après, je dirais que moi, j'ai trouvé ça hyper intéressant parce que je trouve que ça clarifie énormément le travail. En fait, ça clarifie énormément ce que les gens font. Et donc, c'est aussi plus facile pour moi en tant que manager de savoir ce qui marche bien chez quelqu'un, ce qui est plus difficile, de savoir comment l'aider, de voir sur quelles tâches il... la personne a plus de difficultés, c'est vraiment beaucoup plus précis et du coup, ça peut vraiment m'aider à accompagner quelqu'un à grandir, tout simplement. Après, dans les difficultés que j'ai pu avoir, mais c'était peut-être plus lié à l'organisation qu'on avait à ce moment-là, c'est le côté, est-ce que je suis manager de personnes qui peuvent être ventilées dans différentes équipes et dans ce cas-là, je ne suis pas forcément présent auprès d'eux au quotidien.

21:53 Et donc, je compte beaucoup sur le Scrum Master, le Product Owner pour avoir des feedbacks sur comment ça se passe au quotidien ou versus manager les gens avec qui je travaille au quotidien. Et dans ce cas-là, ça a aussi des inconvénients. C'est que je suis peut-être un peu trop présent, je peux être jugé parti. Il peut y avoir des inconvénients comme ça. Donc, je dirais que les deux approches ont leurs avantages. Mais c'est peut-être ça qui est un peu plus difficile à gérer. Et qu'est-ce que j'ai kiffé ? Le côté mieux voir ce qui se passe chez les gens et puis le résultat. C'est-à-dire que ça donne une cadence à l'équipe qu'on est censé pouvoir tenir sur le long terme et qu'on arrive à tenir souvent sur le long terme. Je trouve que ça rythme tout simplement le quotidien. Chaque matin, c'est rituel, c'est les repères aussi qu'on a et ça rythme le quotidien. Et puis, moi, en tant que manager, avoir la vision globale de comment ça se passe, c'est hyper facile. Avec les outils, pour le coup, je peux les avoir, alors qu'en temps normal, j'aurais peut-être dû faire un peu le tour de tout le monde et des popotes pour savoir un peu qui en est où, pourquoi, où est-ce qu'on en est.

23:00 Là, je n'ai pas besoin de solliciter les gens pour ça. Les outils sont là justement pour nous donner cette visibilité-là. Donc, ça me donne une meilleure vision. Oui, ça, c'est assez clair. Et pour le dernier point, clairement, cette approche itérative, là, pour le coup, je l'aime bien par nature, mais je pense que ça, après, c'est aussi quelque chose de personnel. Mais l'idée de pouvoir dire, on sort quelque chose, on teste, on voit les résultats et on y terre dessus pour améliorer ou pas, ou on s'arrête. Ça, c'est quand même quelque chose d'assez appréciable parce que ça m'évite moins un gros pain point en tant que manager, c'est de faire travailler des gens pendant plusieurs semaines, voire plusieurs mois sur un sujet pour à la fin se dire, en fait, ça ne marche pas, on le jette. Et là, la déception, elle est énorme, la démotivation, elle est énorme. Enfin, on n'a pas envie de vivre ça. Donc, ça, pour moi, c'est un vrai plus. Je ne sais pas s'il y a des questions. Il y a des questions, il y en a déjà plusieurs qui touchent. Il fallait sans doute sur le remote. Comment on fait pour adapter ces process agiles, ou pas agiles d'ailleurs, mais en remote?

24:01 Et comment adapter le management visuel en remote? Il va falloir qu'on en parle tôt ou tard lors de cette table ronde. Je dirais juste en introduction, une vitesse sur le sujet, mais je pense que du coup, pour tout, Emilie, tu auras sans doute beaucoup plus d'astuces. Non, pas vraiment. On va voir. En gros, c'est que quand on parle d'un board physique, forcément, le remote, là, ça ne marche plus. On ne peut plus faire bouger ses tickets. Donc, on est obligé de passer par un outil à côté qui va nous permettre de l'avoir en version électronique. Alors, ça peut être Jira ou Trello, des choses comme ça, mais d'avoir un outil à côté qui permet de rendre ça visuel et de pouvoir le suivre au moment du stand-up, de l'afficher et de pouvoir le partager. Après, au-delà de ça, le remote, il va rendre forcément encore plus important les moments où la team se réunit. Je parle, je pense, au stand-up, bien sûr, mais la rétro, tout ce qu'il y a autour, parce que c'est... C'est le moment où les gens vont aussi se voir.

25:02 D'ailleurs, petite note au passage, insister sur l'importance de mettre la caméra et d'avoir aussi un visuel, parce qu'on sait qu'il y a pas mal de choses qui passent par là. Je trouve que c'est un outil aussi important. Il faut juste avoir un bon setup avec une connexion raisonnable. J'ai cru comprendre qu'au début, ma connexion n'était pas totem, donc ce n'est pas un très bon exemple. Mais en tout cas, l'idée est là. C'est toujours un peu flou. Ça dépend. Ça va servir. Mais en fait, je pense que ce qui est aussi intéressant, là je fais écho un peu à ce que tu as dit précédemment sur comment tu manages différemment, c'est qu'il y a une différence de granularité dans le sens que traditionnellement, déjà on n'ose pas appeler ça des personnes, on les appelle des ressources. Donc on manage des ressources, on manage un ensemble de personnes individuelles. Que là maintenant la granularité elle est beaucoup plus sur l'équipe. Ça ne veut pas dire qu'on efface complètement l'individualité et les personnes, mais c'est vrai qu'en termes de pilotage et de gestion, c'est beaucoup plus tout ce qui est indicateur, etc. Ça nous aide sur des notions d'équipe.

26:03 Et donc effectivement, c'est beaucoup plus ça aussi qu'en tant que manager, Tu vas regarder. Et donc, finalement, quand tu te préoccupes de l'individu, On sait qu'on est dans un cadre différent. On est dans un cadre qui est différent. Et finalement, quand on va le faire en remote, C'est un peu ça. Ce qu'on en revient, c'est comment on renforce ce côté équipe qui était peut-être très important, mais un peu diffus avant. C'est-à-dire qu'on a fait un... Il a juste mis tout le monde dans la même salle. Il se passait un truc un peu magique. Là, il faut peut-être un peu plus le structurer, le cadrer. Et ça renforce aussi l'importance des échanges individuels parce que justement, il ne suffit pas de se balader dans l'open space et d'ouvrir les oreilles. Donc, du coup, d'avoir des entretiens individuels devient… Ce n'est pas que ça devient plus important, c'est que ça devient plus comme une évidence qu'il faut absolument le faire. Parce qu'en fait, déjà avant, un bon manager, il fait des one-on-one, il fait un soutien individuel régulier avec tout le monde régulièrement. Ce n'est pas nouveau, c'est juste qu'effectivement, on arrivait à bricoler que là, ça devient juste, oui, sinon on n'a pas l'envie d'aider ce qui se passe.

27:09 Ce n'est pas si grave que ça de ne pas savoir ce qui se passe, mais surtout, on ne peut plus agir sur le système, on ne peut plus apporter son aide et jouer son rôle de manager. En fait, quand je dis que je n'ai pas de bonne pratique pour le remote, ce n'est pas vrai. C'est juste que sur le coup, j'ai juste pensé que je n'ai encore jamais accompagné d'équipe en mode remote. Donc, du coup, je n'ai pas forcément de clé immédiate qui me vient. Mais en fait, en réfléchissant, si un peu, parce qu'il y a 50 ans, j'ai contribué à construire une équipe du ProviCuzzle, qui était une sorte de startup incubée dans une boîte plus grande. Et on est parti vraiment dans un mode très agile dès le début avec un ADN agile. Et donc, on a adapté librement. nos pratiques, on va dire, on a beaucoup navigué entre un board physique, un board à distance, on synchronisait les deux, on a fait plein d'aller-retour, on a réfléchi sur le stand-up, parce que le stand-up, en fait, c'était,

28:13 on n'avait pas tous les mêmes horaires, il y avait des gens qui étaient plus left-art que d'autres, et C'était casse-pieds, on n'arrivait pas à trouver, on a essayé plusieurs horaires, donc au final, on a fini par faire un e-stand-up meeting où chacun faisait sur un channel Slack dédié, en fait, quand ça lui allait, et ça fonctionnait bien pour l'équipe. Cette équipe, en fait, je continue de la suivre parce que mon mari est toujours dedans. Et donc là, ils sont équipés depuis un moment en full remote, avant même le confinement et le Covid, parce qu'ils ont des membres qui sont à distance. Ils ont quelqu'un qui est en Albanie, et même il y en a qui partent en vacances plusieurs mois, enfin qui partent à l'étranger plusieurs mois et donc qui travaillent de ailleurs à donner de beaux sujets horaires. Donc en fait, ils étaient déjà équipés en full remote. Et moi, ce que j'ai vu qui fonctionnait bien avec eux, c'est déjà que les managers leur font entièrement confiance sur le choix des outils pour se synchroniser. Ils sont dans le soutien, du coup, c'est quand on dit qu'on a besoin de tel outil, quand la clinique a besoin de tel outil, le manager, parce que...

29:18 De toute façon, le coût de ne pas communiquer efficacement est beaucoup plus important que le coût de l'outil. Et voilà. Ils ont... un Discord qui est ouvert en permanence pour pouvoir se parler dès qu'ils ont envie. Et donc, du coup, les personnes sont au courant quand il y a un débat qui commence à discuter, ils ont tout de suite le réflexe de dire aux autres, on est en train de parler de ce sujet-là pour que les autres puissent venir si ça les intéresse. Pendant le confinement, ils avaient mis en place un espèce de salle Zoom café pour se retrouver. Ils se faisaient situer ensemble. Voilà. Ils ont mis en place un certain nombre de pratiques. Ce n'est peut-être pas tant les outils pour suivre le travail en ligne, mais même pour ça, en fait, c'est une outil qu'on va utiliser pour du Trello ou autre. Je pense que la grande... La pratique, c'est faire confiance à l'équipe sur le fait qu'ils vont savoir choisir le bon outil.

30:21 Parce que les outils, c'est censé leur faciliter le travail et pas leur mettre des bâtons dans les roues. Et donc, du coup, si c'est quelqu'un d'autre qui choisit l'outil, il y a de grandes chances que ce soit plus embêtant que facilitant. Voilà. Ce qui nous amène, du coup, j'ai envie de nous amener sur une question. Du coup, je rappelle à l'audience qu'hésitez pas à rajouter des questions dans la section Q&A. On nous demandait, parce que là, en fait, on parle aussi un peu d'autorisation, parce qu'effectivement, ils se débrouillent, on leur apporte notre aide, etc. Et donc, l'autorisation, c'est compliqué quand ils sont trop nombreux. Donc, on nous pose la question, est-ce qu'il y a une taille critique à une équipe agile et quand est-ce qu'on décide de découper une équipe en plusieurs? C'est une question très concrète qui arrive régulièrement. Une équipe a grossi, c'est là, qu'est-ce qu'on fait? On voit que ça marchait peut-être moyen avant, que maintenant ça ne marche plus, ou on envisage peut-être la question pour plus tard. Effectivement. Quand découper, c'est comment découper aussi. Les deux vont ensemble.

31:21 C'est quand découper et comment découper. Oui. Là, du coup, tu as eu le… Oui, en fait, clairement, Quand découper, il n'y a pas de doute. Je pense qu'il faut découper quand… Alors, on parle, vous savez, de pizza team, donc la capacité de pouvoir nourrir une équipe avec une ou deux pizzas, si on n'arrive pas, c'est qu'il y a trop de personnes. Au-delà de ça, en fait, ce qui va très vite poser problème, c'est tout ce qui est rétrospectif ou stand-up qui vont commencer à prendre plus de temps parce que, notamment pour les rétros, si on veut laisser le temps à chacun de parler, ça va prendre quand même du temps. Donc, on sent que ça va apporter des lourdeurs. Inévitablement, on va se retrouver aussi avec des personnes qui vont travailler peut-être sur des scopes un petit peu différents et du coup, quand ils vont en parler, ça va un peu ennuyer les autres. Donc, globalement, je pense qu'une bonne taille d'équipe, c'est entre 5 et 8 personnes, un max. Et après, on peut être à 10 personnes dans une équipe temporairement, le temps justement peut-être de l'aspliter et ensuite de voir si on ne peut pas faire deux équipes de 5 ou de 4. Mais je pense que c'est clairement un maximum.

32:23 Après, on commence à ne plus être aussi efficace sur les cérémonies et sur l'organisation du travail. Et du coup, comment on fait? De la même façon que j'ai dit pour les outils, je pense que l'important, c'est de faire confiance à l'équipe. Par contre, le manager va avoir un rôle de poser des questions pour permettre à l'équipe de réfléchir à comment ça fonctionne à la taille à laquelle on est. Effectivement, est-ce que les rituels sont fluides? Ou est-ce qu'on s'ennuie? Ou est-ce que d'un coup, il y a moins de gens qui viennent? Parce que des fois, c'est plus toujours bien, mais il y a toujours trois personnes qui ont… À quoi prenez quoi ? Ce genre de questions-là à poser pour que l'équipe puisse après faire son propre diagnostic, se dire tiens, mais est-ce que ce ne serait pas parce qu'on est trop nombreux du coup? Est-ce qu'on n'a pas un souci? Et après, avoir une discussion avec l'équipe sur comment il faudrait qu'on partage l'équipe. Parce que, est-ce qu'on divise? Ce n'est pas toujours simple de diviser par feature, parce qu'en plus, potentiellement, le code est…

33:27 etc. Donc, il y a des challenges techniques à pouvoir faire. Ce n'est pas simplement dire, bon, maintenant, vous êtes deux équipes à part et vous avez des rituels séparés. Ça va plus loin que juste faire ça. Ça veut dire qu'on a potentiellement des outils, c'est la question. Il va peut-être falloir détricoter quelques trucs dans le code pour rendre réellement autonome et découplé ces deux équipes. Sinon, vous n'avez pas vraiment réduit l'état d'équipe. Vous avez juste rajouté de la communication entre deux équipes qui bossent sur la même chose. Et ça, ça rajoute plutôt de la complexité plutôt que ça en enlève. C'est assez intéressant ce que tu dis. Moi, j'avais vécu ça en tant que Scrum Master. Effectivement, l'équipe devenait trop grosse et ça s'est restructuré en plusieurs plus petites équipes. Il y avait plusieurs sujets. Il y avait la taille d'équipe. Il y avait aussi le fait qu'on avait plusieurs... Thème à travailler en parallèle et donc finalement ça me semblait plus pertinent que d'avoir plusieurs petites équipes avec chacune un objectif clair plutôt que d'avoir un gloubi-glouba et c'est vrai qu'il y avait moi je voyais beaucoup la dimension En fait, on est tous potes, on est super contents d'être ensemble, on n'a pas envie d'être séparés.

34:36 Et j'avais négligé quelque chose qu'eux voyaient plus, qui était, comment on va faire pour ne pas se marcher dessus, pour rester aligné techniquement aussi. Parce qu'effectivement, on faisait cette séparation, que chacun ait un alignement et un focus fort sur le produit quelque part, mais il y avait quand même un alignement tech à garder. Et ça, du coup, c'était assez intéressant. Voilà, il faut les... Il faut aussi leur faire confiance, clairement. Après, j'étais un peu sûr que je les ai quand même emmenés en séparant un peu le rituel petit à petit, un par un. Mais effectivement, si je puis me confier, c'était un grand moment de solitude quand j'avais réussi à convaincre tout le monde individuellement que c'est une super idée. Et quand je leur ai posé collectivement la question, il s'est passé un truc et ils m'ont tous dit« Non, on va rester ensemble». Bref. Parce que tu touches à de l'émotion, en fait. Tu avais convaincu leur cerveau, mais leur cœur, ils n'avaient pas envie. Il y a un moment aussi où ce genre de questions peut se poser quand on est dans une équipe produit et que l'équipe grandit.

35:39 En fait, les produits qui se créent, souvent, c'est les devs qui développent le produit qui font aussi le support sur ce produit. Et au bout d'un moment, en fait, l'équipe grandit parce que le produit grandit et il se pose la question de, Ok, on fait quoi? On fait d'un côté les devs qui développent le produit, puis les autres qui font le support et les projets clients, ou alors on split différemment? Ça aussi, c'est une question intéressante à se poser, parce que si on veut que les devs puissent garder le contact avec les utilisateurs, ce qui apporte le support et les projets clients, et donc amène de bonnes idées dans le produit, si on coupe par fonction, on perd ce truc-là. Après, je pense que ça va dépendre un peu de chaque équipe et des envies qu'il y a dans les personnes. Mais ça aussi, c'est une question intéressante à se poser parce que si on veut que les devs puissent garder le contact avec les utilisateurs, ce qui apporte le support et les projets clients, et donc amènent de bonnes idées dans le produit,

36:44 si on coupe par fonction, on perd ce truc-là. Donc, après, je pense que ça va dépendre un peu de chaque équipe et des envies qu'il y a dans les personnes. Mais c'est... C'est des choses que j'ai déjà vues dans les boîtes plutôt petites, qui ont un produit qui commence à avoir bien maturé, mais la question se pose souvent à ce moment-là. Est-ce qu'on sépare ou pas? Et ce n'est pas toujours évident. Je ne crois pas qu'il y ait de réponse universelle d'ailleurs. Il n'y a pas de réponse universelle. Par contre, j'ai envie de rebondir sur une des questions du public qui nous parle d'OCR, qui nous demande, notre CEO souhaite mettre en place des OCR d'équipe et individualiser, donc Objectives et Key Results. Est-ce que c'est compatible avec l'agilité? Pourquoi je veux faire le lien? C'est parce qu'en fait, quand on veut séparer les équipes et qu'on veut que ça se passe bien, qu'elles soient autonomes, c'est pour ça aussi qu'on les sépare, c'est pour qu'elles puissent fonctionner chacune indépendamment. Ça suppose qu'on ait une organisation globale, un pilotage organisationnel qui soit cohérent aussi avec ça. C'est-à-dire que finalement, on sépare en deux et les deux équipes sont obligées de travailler ensemble pour livrer quelque chose. On ne va pas être beaucoup avancé. Tu en avais parlé, Emilie, sur le fait qu'il y a des contraintes techniques. Mais au-delà technique, c'est aussi complètement des objectifs qu'on peut atteindre. Donc, je fais le lien avec les OCR. C'est effectivement… Je réponds un peu, en tout cas, je donne mon avis dessus.

37:47 C'est que les OCR, c'est génial à condition qu'on ait une organisation qui soit justement orientée vers des équipes produits. Là, on peut du coup décliner des objectifs business sur les équipes. Si on arrive à sortir, OK, maintenant, on a deux équipes. équipe produit au lieu d'une et chacune a ses objectifs business, ça va bien marcher. Par contre, si on a deux équipes qui font chacun la moitié du truc, on ne sera pas capable de savoir qui a contribué, à quel auteur de l'objectif business. Donc, en fait, on ne sera pas avancé et le système d'OKR risquera de faire plus de mal que de bien. Du coup, sur la partie OKR individualisée, à mon avis, ça, c'est plutôt une bonne idée puisqu'on est concrètement dans le côté… Chaque personne de l'équipe. Voilà, je vous rends la parole. Je vois juste sur ce sujet en particulier, j'avoue que c'est une très bonne question parce que je pense que l'OQIER, ça peut vraiment être un outil, comme tu l'as décrit Jean-Pierre, qui permet de donner une vision à une équipe et de laisser une marge de manœuvre et un cadre dans lequel évoluer et d'adapter ces OQIER à son propre domaine fonctionnel et ça peut marcher très bien. Comme à l'inverse, ça peut aussi être un carcan qui va pour le coup...

38:49 Figer les choses. Et là, pour le coup, on est vraiment à l'antithèse. Et il va vraiment essayer de poser une espèce de cadre beaucoup trop rigide qui va un peu tuer ce principe d'agilité un peu dans le fond. Donc, je pense qu'il faut vraiment être très prudent à la manière dont on le décline dans les équipes et la manière dont il est utilisé. Les deux effets sont possibles. Moi, je suis d'accord avec vous deux. J'ai l'impression que vous avez dit. On va continuer parce qu'il y a plein de questions. Alors effectivement, depuis le début, quand on parlait notamment des rôles des managers, on parlait beaucoup par rapport aux développeurs, en tout cas par rapport aux équipes, par rapport à ceux qui construisent. Du coup, quelles sont les relations entre le manager? Et la partie plutôt business, métier, que devient cette partie-là ? Qu'est-ce que ça veut dire concrètement? C'est une excellente question également. C'est un super public. J'adore, j'adore. Cette réponse n'est pas simple parce qu'en fait, on se retrouve souvent avec des stakeholders externes qui vont avoir des manières de fonctionner assez différentes.

39:57 Et quand je pense à ça, je pense à… Ça peut être des équipes marketing ou des équipes commerciaux, je ne sais pas, mais qui vont être beaucoup plus objectivées sur des deadlines, sur des choses assez précises, quand est-ce qu'on peut l'avoir, etc. Et en fait, ça vient vachement mettre à mal, en fait, justement, cette organisation agile. Elle est agile, elle n'est pas complètement aveugle non plus, mais elle est forcément plus malée à plus souple, parce qu'on se laisse le droit de changer le périmètre de ce sur quoi on travaille pour mieux correspondre à notre besoin. Donc en fait, on se retrouve avec deux manières de travailler qui sont assez antinomiques en fait. Ça grince un peu. Parce qu'eux vont attendre de nous des questions, des deadlines, des choses qu'on n'a pas forcément. Déjà parce qu'on sait très bien que ça ne marche pas. C'est hyper dur de faire des estimations fiables. Et puis, parce qu'en général, on se plante dessus. Donc, en fait, on est partagé entre répondre quelque chose qu'on sait que ça va être frustrant dans un sens comme dans l'autre, qu'on arrive à la tenir ou pas, ça va être un peu frustrant parce que si on arrive à la tenir, on risque d'être frustré côté tech de ne pas avoir fait certaines choses.

41:01 Si on n'arrive pas à la tenir, ça va être frustrant côté demandeur parce qu'on n'est pas dans les temps. Donc, ça, je pense que oui, en fait, ce travail d'agilité, ce principe d'agilité, il doit vraiment être aussi partagé par tous. Et je crois qu'il y avait une question, je le vois encore, qui était comment faire adhérer les équipes non tech à l'agilité. C'est pour le coup de montrer un peu l'intérêt que ça peut avoir. C'est-à-dire qu'en fait, on va vraiment beaucoup plus cibler, enfin impliquer déjà ces stakeholders dans le process de développement au fil de l'eau. Et ce n'est pas un effet tunnel où on part sur des specs, on va te le développer dans trois semaines et tu reviens dans trois semaines. C'est vraiment d'essayer de le faire beaucoup plus au fil de l'eau. Les démos, elles sont faites pour ça aussi. Et de vraiment pouvoir les impliquer. Et je pense qu'à partir du moment où ils commencent à avoir l'intérêt de pouvoir interagir au quotidien, ou quasiment au quotidien, quasiment au quotidien avec l'équipe, et de pouvoir adapter en fonction du besoin, en fait, ce prix-là, ça a tellement de valeur qu'au bout d'un moment, ça commence à convaincre, tout simplement, que c'est une bonne manière de faire et que c'est quelque chose qui peut fonctionner sur le long terme. En fait, ce que tu décris, c'est à peu près exactement pour la raison pour laquelle j'ai voulu passer au niveau de l'accompagnement d'entreprise et pas seulement des équipes.

42:13 Parce qu'il y a effectivement une sorte de plafond de verre. Souvent, on déploie de l'agilité dans les DSI et puis… Et puis, ça ne passe pas les parois. Et effectivement, on a des soucis de ce point de vue-là. Ce que tu décris, effectivement, le fait d'impliquer les stakeholders régulièrement, par exemple dans les revues, il y a effectivement cet effet où, waouh, ce que j'ai dit, ça a été pris en compte, je vois le produit qui se construit. Je suis rassurée, en fait, ils ne sont pas en train de m'enfumer, d'essayer de gagner du temps ou je ne sais pas quoi. C'est qu'ils bossent vraiment, je le vois et je peux discuter avec eux et je comprends mieux ce qu'ils font. Et je pense qu'il y a un autre point à prendre en compte, c'est d'arriver à comprendre aussi d'où viennent leurs contraintes à eux. Pour essayer de... aussi de leur donner des clés pour qu'ils puissent défendre à leur tour, parce que souvent, ils vous mettent la pression, parce qu'il y a un autre endroit où on leur met de la pression d'une façon ou d'une autre, ou ils imaginent qu'on leur met de la pression. Et je parlais tout à l'heure d'avoir des conversations difficiles, typiquement, c'est, OK, est-ce que c'est plus important de livrer tout ce qu'on avait prévu avec une qualité moisie dans les temps?

43:29 Ou alors, sur quoi tu es prêt à faire des concessions? Enfin, à un moment donné, les utilisateurs, quand ils ont une application qui sort dans les temps prévus, mais eux, ils ne savaient pas quand est-ce que c'était prévu de sortir, mais bon, ce n'est pas très grave, mais ils ont une application, mais qui est toute buguée parce qu'on s'est dépêché pour la livrer dans les temps, ils vont vite la désinstaller de leur téléphone. J'ai pensé pour StopCovid, qui a livré bien les temps, mais voilà. Et alors, quoi? Alors que finalement, quand tu prends le temps de faire des fonctionnalités une à une, que tu amènes de la valeur ajoutée pour les utilisateurs et de la qualité, même si tu as bien moins de fonctionnalités, les gens vont garder ton application et vont l'utiliser. Donc, du coup, aller chercher, par exemple, ces croyances-là et les aider à les déconstruire, ça fait partie aussi du taf pour que ça se passe bien. Il y a les deux, les impliquer avec les guides, mais aussi arriver à les aider à déconstruire leurs propres croyances, comme vous, vous l'avez fait. Pour que ça se passe bien et que la transformation, du coup, elle soit...

44:30 Plus comme un bras de fer, mais qu'elle soit vraiment durable et qu'elle passe les frontières de la DSI. Moi, j'ai un exemple, alors ce n'est pas avec des métiers, c'était avec, c'était à Pâche Jaune, maintenant c'est le solo 4 groupes, avec la prod, enfin les gens qui mettent en prod. Il faut savoir qu'à l'époque, alors ce n'est plus le cas maintenant, mais à l'époque à Pâche Jaune, enfin sur le groupe Pâche Jaune, tout le monde mettait en prod tous les trois mois, mais tout le monde en même temps. Et si tu manquais le créneau, tu mettais en prod trois mois plus tard. Alors qu'on était... Censé à tous, agile. Et donc, du coup, nous, on est arrivés avec un projet. On avait besoin de relivrer chaque semaine. Parce qu'on produisait en gros des indicateurs pour le marketing. Donc, chaque semaine, on devait livrer des nouvelles choses. Et je peux vous dire que ça ne s'est pas forcément bien passé au début avec les gens de la proie. Quand on leur a expliqué qu'on voulait mettre en proie toutes les semaines. Ils ne comprenaient pas pourquoi, personne ne l'avait jamais fait. Et donc, du coup, ils nous ont expliqué leurs contraintes. C'est qu'on leur demandait de mettre en prod le moins souvent possible, finalement.

45:32 Enfin, si on mettait tout le monde en prod, c'est pour éviter les risques. Comme ça, c'était maîtrisé, on avait bien le temps de tester, etc. Et donc, du coup, on a commencé à discuter avec eux. On s'est rendu compte que si on livrait le… On avait la possibilité de faire un choix technique qui était de mettre une certaine partie du code sous forme de fichier de paramétrage et qui était, en fait, finalement, qui était exploité par un moteur qui, lui, variait assez peu. Donc, au final, ce qu'on livrait tous les trois mois, c'était le moteur. Et par contre, on pouvait livrer chaque semaine des fichiers de paramétrage. Donc, du coup, ce qu'on a fait pour que ça se passe bien avec la prod, c'est qu'il y avait toujours un développeur qui allait faire les mises en prod avec eux. Donc, du coup, ils ont commencé à comprendre comment leur prod fonctionnait, quels étaient leurs besoins. Ils ont dit, attends, je comprends pourquoi. Nos logs, ils sont tout pourris. Attends, on va améliorer les logs du coup. Donc, du coup, ils sont venus améliorer les logs. Donc, la prod était super contente. Et en fait, au final, on était parmi leurs équipes préférées, alors qu'au début, c'était vraiment pas gagné. Parce que justement, on se comprenait, on se parlait. Il y avait un problème, on s'appelait tout de suite au téléphone, il n'y avait pas d'escalade, rien, tout était fluide.

46:34 Je pense que quand on arrive à ça, à aller s'intéresser aux problématiques de l'autre, pourquoi il nous fait ces demandes-là? Parce que c'est jamais dans le vent, ce n'est pas pour être chiant, ce n'est pas pour nous emmerder ou parce qu'ils sont, je ne sais pas. La réalité, c'est que tout le monde a envie que l'entreprise réussisse. Donc, à un moment donné, il faut aller se poser la question de pourquoi ils nous font ces demandes-là et voir comment on peut trouver une entente, quelque chose qui convienne à tout le monde finalement. Voilà. Très bien. On va continuer. Il y a encore plein de questions. Il faut qu'on se dépêche, si on veut répondre à tout le monde. Il y a eu plein de votes. Il y a une question qui vient de remonter. Avec un découpage en feature team avec des backlogs différents, comment avez-vous réglé ou pas les problèmes d'interdépendance entre les équipes? Ah, ça ne les résout pas tous. Non, en fait, en vrai, le découpage en feature team, il va clairement permettre de traiter beaucoup mieux tous les sujets qui sont vraiment clairement identifiés comme étant du scope de cette feature team.

47:44 Ça, il n'y a pas de doute. Le fait que les personnes soient, qu'on ait l'ensemble des intervenants, les décisions se prennent vite et tout, et ça, ça marche vraiment très bien. Et par contre, clairement, la difficulté de cette organisation d'après moi, c'est vraiment justement les applications, les fonctionnalités qui sont cross-team, cross-feature-team. Et dans ce cas-là, la synchronisation, elle n'est pas simple. Parce que ça veut dire, est-ce qu'il y a une équipe qui est un peu honneur du sujet ou pas? Alors, il faut souvent en désigner une. Elle va sans doute un peu galérer à faire en sorte que les autres teams soient dans le même tempo pour pouvoir travailler là-dessus. Alors, du coup, ça peut être… Parce qu'en fait, chaque équipe va avoir du coup ses sujets à traiter, plus ce macro-sujet transverse à plusieurs équipes. Et comment prioriser les uns par rapport aux autres? Je pense que c'est la difficulté, de mon point de vue, c'est la difficulté de l'un. L'organisation en feature team, c'est les projets cross-team. Donc, je n'ai pas de solution miracle, personnellement. Si je peux me permettre de répondre et d'être peut-être un petit peu pédant sur les définitions, là, ce que tu décris, ce n'est pas la feature team, c'est déjà le niveau d'après.

48:45 Parce que dans la feature team, on leur confie des features, mais entre guillemets, on ne leur confie pas forcément le travail en amont de réflexion. Donc, il y aura peut-être une équipe qui se charge de ça. C'est pour ça que d'ailleurs, quand on regarde les modèles dits de passage à l'échelle comme l'ES ou SAFE, on sépare entre guillemets l'aspect gestion de produit. En SAFE, c'est assez fort. Il y a le niveau programme et il y a les niveaux delivery, soyons un peu bruts. On s'est parlé d'eux parce qu'en fait, effectivement, tu es un peu obligé. Parce que si tu as un souci, à qui tu le demandes? Il n'y a aucune équipe qui, par définition, est honneur du sujet. Oui, d'accord. Quand on commence à avoir des équipes, justement, que j'appelle peut-être plutôt des squads par rapport à ce qu'il y avait chez Spotify, qui, au-delà d'être capable de toucher à tout et d'être autonome pour livrer des choses, sont en plus de manière pérenne sur un pan fonctionnel du produit, ça commence déjà à pouvoir démonter cette équipe produit puisqu'ils peuvent prendre en charge ça. Mais effectivement, du coup, on a quand même toujours des problèmes sur l'aspect des sujets transverses que tu as bien évoqués.

49:49 Il n'y a pas de secret. Après, il faut aller à fond sur un micro-service et compagnie. Il faut réussir à faire que les équipes soient le plus indépendantes possible. Techniquement aussi, justement, pour dire la fin. c'est qu'on arrive à aligner les deux. L'indépendance produit avec l'indépendance technique, c'est là où ça commence à être un peu merveilleux. Tu veux jeter quelque chose, Emilie, je te vois sourire. Non, je répondais sur le chat à Timothée qui me disait que pour info, je ne sais pas, Jaune, en ce moment, les MEPS, c'est tous les jours, voire plusieurs fois par jour, ils ont mis en place du déploiement continu et que la culture a bien changé. Les transformations, les DevOps ont eu de très bons résultats et continu. Donc, c'est tant mieux. Moi, effectivement, il y a un moment, c'était il y a à peu près 8 ans, Donc, c'est cool que les choses aient changé. Et voilà, tant mieux. C'est pour ça que ça me fait sourire. Je savais que ça allait, mais c'est cool si ça continue d'évoluer à ce rythme-là. C'est bien encourageant. Ça veut dire que même les boîtes qui partent sur l'agilité, on va dire,

50:53 pas tout à fait, enfin, comment dire, plus dans les pratiques que dans l'esprit, peuvent y arriver et aller vers une agilité réelle, en fait. Donc, ça, c'est chouette. C'est encourageant. C'est peut-être un... Ça fait peut-être partie des enseignements, c'est-à-dire que réussir à prendre du recul, pour ne pas voir est-ce que c'est bien ou moins ou nul, mais voir est-ce que c'est mieux. Ce n'est pas toujours évident parce que parfois on se projette en se disant, voilà, c'est genre je veux dire, les gars ils sont contents parce qu'ils font une liste tous les trois mois au lieu de tous les ans, mais tous les trois mois c'est nul. Sauf que non, c'est génial au lieu de tous les ans. Ça en fait quatre fois pour quatre ans, donc attends, c'est énorme. Je suis d'accord. C'est vrai que… Pour moi, ça rejoint un point clé dont on n'a pas du tout parlé, sur pourquoi l'agilité… Enfin, on en a parlé au début, mais pas… Je trouve que quand on va vers de l'agilité, on ne se pose pas vraiment la question de« et ça sera un succès?

51:53 » Quand, quoi, pour nous? À quel moment on peut considérer qu'on est content, qu'on est sur le bon chemin, etc. On a dit au début tout ce que ça pouvait apporter à une entreprise, mais concrètement, pour mon équipe, ça va se traduire comment? Est-ce qu'à un moment, on se fait des textes d'acceptation par rapport à notre transformation agile d'équipe? Qu'est-ce qui va nous montrer que ça se passe mieux? Et ce n'est pas des critères pour toutes les équipes, parce que l'agilité va répondre à une limite actuelle d'une équipe. Donc, du coup, les indicateurs vont être forcément à propos de ça. Si on a du mal à livrer des choses concrètement, ça peut être le temps qu'on met entre une idée et sa mise en production. Mais si c'est des problèmes de communication ou de synchronisation d'équipe, ça va être encore un autre indicateur, etc. Je pense que c'est intéressant de se poser la question au début d'une transformation d'équipe.

52:54 Le pourquoi on le fait, et du coup, qu'est-ce qu'on va mesurer pour savoir qu'on va dans le bon sens? Parce que quelque part, c'est... déjà un premier pas dans l'agilité de se dire vers où on veut aller et où est-ce qu'on en est sur le chemin en fait. Moi, je m'en serais, mais enfin, plutôt j'irais plus loin en disant, c'est exactement la même chose que le produit lui-même qui est développé. On a besoin d'une vision produit, on a besoin d'une vision de la transfo, où on veut aller. On a besoin de savoir, ça va être quoi nos indicateurs qui nous disent, est-ce que la feature, c'était la bonne ou la mauvaise, etc. Donc, qu'est-ce qu'on mesure? C'est quoi l'objectif qu'on veut atteindre, qui nous dit c'est une réussite ou c'est un échec? Quand on parlait d'amélioration continue, il n'y a pas tellement de différence conceptuellement entre l'amélioration continue de nos process de manière travaillée et d'un produit. Ce que je disais souvent, c'est que la rétrospective et la revue de sprint, c'est la même chose, sauf que l'une est sur l'équipe, l'autre est sur le produit. Exactement. À toi. Bon, dernière question. On finit à 13 heures, très rapidement.

53:56 C'est une question un peu pratique, pratico-pratique. Certaines équipes font des délits en asynchrone via Slack pour éviter les stand-up trop longues. Qu'en pensez-vous? Moi, j'ai une réponse. Vous voulez dire quoi? J'en ai une aussi. Alors, vite. J'en ai une aussi. Je la fais en 30 secondes et on est bon. Je dirais que le faire par écrit, si c'est pour résoudre un problème de longueur, ce n'est pas forcément la meilleure option. Ça peut marcher, mais ce n'est pas forcément la meilleure option. Si c'est trop long à l'oral, ce sera peut-être même trop long à l'écrit aussi. Pourquoi pas? Après, le stand-up par écrit en tant que tel, moi, je n'ai aucun souci pour. Je pense que ça peut marcher. Les équipes... qui préfèrent ça, c'est très bien. J'aurais juste, je dirais juste, dans cette période actuellement de confinement, où on peut être distant de remote équipe, j'aurais tendance à quand même vouloir le faire en présentiel via visio pour garder ce contact humain. En fait, Nicolas, il m'a soufflé à peu près tout ce que je voulais dire. Moi, je vais dire un truc un peu différent. Moi, je vais dire que pour moi, l'essence du délit, ce n'est pas de raconter sa vie, ce n'est pas de dire ce qu'on a fait, ce n'est pas de dire ce qu'on va faire. c'est de regarder l'objectif où on va et de se poser la question.

55:00 Est-ce qu'on va l'atteindre? Si la réponse est oui, potentiellement, on peut raccrocher, on n'a rien d'autre à se dire. Si la réponse est non, il faut qu'on décide du nouveau plan qui nous permettra que ce soit oui. Et donc, du coup, si on prend ce focus-là, potentiellement, les discussions sont beaucoup plus courtes. Voilà. Du coup, on va laisser la main à Noémie, qui va conclure et qui va annoncer la suite. Tech.Rocks, pas de nous. Mais voilà. Noémie, où es-tu? Je suis là. Je suis là. Tout va bien. Merci beaucoup à vous trois pour votre participation. Voilà. Merci à toutes et tous. Et on se retrouve sur les tables. Merci beaucoup.