Comment s'organiser en Squad ?

0:15 Bonjour tout le monde, je suis ici en tant qu'animateur de ce meet-up. Pour la petite histoire, ce meet-up est parti d'une simple question qui était que je cherchais à avoir du REX, du retour d'expérience sur les organisations en squad dans différentes entreprises, puisque c'est quelque chose que j'aimerais mettre en place chez Pandacraft également. Et suite à cette question, j'ai pu rencontrer Ronan et Eric, qui sont respectivement CTO de Pitchy et CTO de Google Big Connection, qui vont venir donner un réex sur leur expérience sur comment s'organiser en squad. Je vais laisser la main dans un premier temps à Eric, qui puisse se présenter et qui nous présente. Tout son organisation, son retour d'expérience. Bonjour à tous, Eric Tinoco, CIO chez LittleBig Connection.

1:16 J'ai une vingtaine d'années d'expérience dans l'IT en général avec plusieurs postes et plusieurs types de métiers, développeurs, chefs de projet, etc. Et aujourd'hui, Dans cette discussion, je vais vous présenter une des solutions possibles, ou en tout cas une des visions de la squad qu'on a chez Little Big Connection. Alors, petit disclaimer, ça ne sera pas la solution, et je ne présente pas ça comme la solution à tous les problèmes, ou en tout cas qu'il faudra répliquer. Par contre, ça vient d'une longue réflexion et je vais vous présenter quelques slides pour ça. Pour que vous puissiez aussi avoir un peu de contenu et comprendre la logique et pourquoi est-ce qu'aujourd'hui on en est arrivé à une organisation en squad comme on l'applique. Parce que je pense que le débat ou les discussions permettront de mettre ça en avant. Souvent, ce qui se compte, c'est aussi le chemin de décision qui permet de faire les bons choix et de s'assurer qu'on aura la bonne organisation derrière.

2:22 Du coup, je passe la main à Ronan pour qu'il se présente. Et puis après, je reprendrai la main pour présenter les slides. Ok, merci. Bonjour à toutes et à tous. Je m'appelle Ronan et je suis à la fois CTO et CPO chez Pitchy. Pitchy, je vais juste rapidement dire ce qu'on fait, parce que ça peut être intéressant, je pense, pour la suite de la discussion. On est un éditeur logiciel avec une solution de SaaS pour faire du montage vidéo en ligne. Donc, si vous voulez créer des vidéos facilement, on a un logiciel de montage en ligne pour faire ça. Et je pense que ça peut être intéressant parce que nous, notre activité principale, c'est qu'on est un éditeur logiciel. Et je pense que comme pas mal d'entre vous aujourd'hui, on s'est posé des questions de comment faire grossir nos équipes et comment trouver la meilleure organisation possible. Et c'est pour ça qu'on en est arrivé aujourd'hui à avoir une forme d'organisation en squad dont on parlera ensuite. Merci pour vos présentations.

3:27 Peut-être, Thomas, qu'est-ce qui t'a poussé justement à... Où est-ce que tu en es, toi, et pourquoi tu t'es posé cette question-là? Et à quel moment tu en es, je ne sais pas, dans un craft, dans votre évolution? Dans notre évolution, nous, on en est un peu au début. C'est-à-dire que l'équipe technique, pour le moment, elle est uniquement 4 personnes sur 30 effectifs. Et le but de ce qu'est vraiment de récolter des règles, c'était justement, sur l'objectif d'ici à 2023, de faire ce qu'elle est cette équipe par rapport à des besoins internes, des besoins métiers, et donc du coup de voir quelle organisation. Adopté dans l'augmentation de cette équipe, on va dire de 10 à 15 personnes, de façon à ce que ça tourne bien et que ça fasse sens à la fois pour l'entreprise et pour les équipes, et que le flot soit fluide à la fois pour tous les déliveries, introductions, le manque de temps de la sorte. C'est dans ce contexte-là que... J'avais posé ma question, mais il y en a une. Je crois que les slides arrivent. Sinon, il y a un petit coup de main.

4:28 Bon, c'est pas grave, sinon... C'est un petit cas. Voilà. Alors, pour rebondir, l'idée n'est pas d'avoir une longue présentation, encore une fois, d'évangéliser les choses, mais juste de présenter un peu la démarche qu'on a appliquée chez LittleBig et qui nous amène à l'organisation telle qu'on la voit. La première chose, on est parti d'un mode très classique. Alors, Agile, Scrum, avec des sprints, organisés plutôt en mode silo ou par compétition. avec un silo produit qui avait pour responsabilité les spécifications, la priorisation, l'assignation et le design avec le côté UTSI, qui derrière passait la main au développement, qui était responsable de l'architecture, des estimations, des développements bien sûr, et puis du testing dans une certaine mesure. Ensuite, on enchaînait sur la phase de test avec responsabilité sur l'analyse, les contrôles et les vérifications, avec tous ces tests de régration, et on enchaînait sur la partie deployment, livraison avec le go live et les feedbacks des utilisateurs ou autres.

5:35 Donc ça, c'était le premier schéma qu'on avait qui fonctionnait bien, on va dire, sur une certaine taille d'équipe. Puis les équipes ont commencé à grandir. On a commencé aussi à avoir des problématiques de distance, de ne plus pouvoir tout partager de manière orale et visuelle. Et on en est arrivé à un constat. Le constat, c'est finalement les équipes grandissantes. Pour info, aujourd'hui, on a environ 80 personnes chez LittleBig. Et l'année dernière, on va dire, début janvier, on devait être une petite trentaine. Donc, c'est aussi cette partie-là ou particularité-là qui nous a amené à nous poser la question de finalement, est-ce qu'on avait la bonne organisation? Est-ce qu'on était efficace tel qu'on l'était? Donc, on en a relevé pas mal de points. La première chose, c'est finalement, Qu'est-ce que, finalement, vers quoi... qui je dois me tourner pour savoir ce que je dois faire ou trouver l'information. Effectivement, on avait des modes silos, on avait plusieurs product owners, plusieurs team leads, etc.

6:39 Et donc, on avait un peu cette particularité de ne pas trop savoir vers qui se tourner, même si on avait les cérémonies classiques, on avait toujours un moment où il y avait un espèce de trou dans la raquette. Le deuxième constat, c'est finalement cette excuse de« Ah oui, mais moi, je n'ai pas pu avancer parce que je n'ai pas eu ma réponse. » Ou« Voir, je ne l'ai pas du tout, je n'ai même pas demandé une réponse. » La finalité de tout ça, c'est que tout le monde se plaignait de ne pas avoir du temps de pouvoir finalement faire le job ou de pouvoir partager les infos qu'il nous fallait. À ce moment-là, on s'est posé la question, on s'est dit, OK, mais comment est-ce qu'on peut corriger ce problème-là? Est-ce que finalement, on s'organise et on trouve des solutions telles qu'on l'est ou est-ce que c'est l'organisation qui n'est pas adaptée? Donc, on a enchaîné sur une phase de benchmark. Et là, il y a eu deux personnes de mon côté que je salue au passage, Romain et Yacine. Qui ont fait un gros boulot de finalement aller benchmarker d'autres organisations, de se poser des questions, de discuter avec d'autres personnes. Un peu le travail que Thomas a commencé à faire, de regarder un peu ce qui se passe autour et de se dire que finalement, il y a peut-être déjà une solution ou quelque chose de tout près à notre problématique.

7:50 Autre point important, on a aussi beaucoup discuté en interne, on a impliqué le COMEX et les équipes au global pour finalement nous… être capable d'avoir une espèce de vision 360 et de pouvoir vraiment avoir toutes les dimensions du problème et d'embarquer tout le monde. C'est un point aussi que je voudrais souligner dans ce passage en squad. Il est important à un moment de ne pas travailler en silo, de se dire que je vais réorganiser mon équipe et que ça va marcher. Il faut être capable de voir ça vraiment au niveau entreprise. Alors forcément, si on parle de 20 000 personnes, ça va être compliqué. Mais dans des structures qui sont plutôt à taille humaine ou à taille raisonnable, il ne faut pas hésiter. On va vraiment embarquer les gens pour qu'on puisse avoir une espèce de retour en live. Et que derrière, on puisse proposer la meilleure solution et surtout qu'on ne débarque pas comme ça avec« voilà comment on va faire, prenez-le et on avance». Il faut aussi bien penser à ce côté communication, à ce côté équipe. Et la communication aujourd'hui, elle doit partir vraiment, elle doit être dans les deux sens, top-down et down-to-top.

8:57 Donc ça, c'était le constat et finalement la première démarche. Et on en arrive à la solution qui nous semble être la plus carrée pour nous. Um On a décidé de passer en ce qu'on appelle une cross-functional teams. L'idée étant effectivement de garder ce qu'on a aujourd'hui dans le Scrum, qui nous semble vraiment bien. À savoir les cérémonies, tout simplement. Donc, on a les délits, les backlogs, les planning poker, les rétrospectives. Rétrospective très importante comme cérémonie, puisque c'est aussi celle qui nous a permis de récupérer pas mal de feedback et de pouvoir poser la nouvelle organe. Donc, on en arrive à cette fameuse cross-functional team où finalement, on va mixer un peu tous les corps de métier. Et c'est ce qui est sur la partie de droite, la composition, avec un team lead, aujourd'hui qui est responsable de la communication et du reporting de l'équipe, donc qui permet de remonter ça avec les autres leads. Le tech lead, qui lui est responsable de la partie technique et qui fait partie du comité tech lead.

10:01 et qui permet du coup de bien partager cette compétence et surtout qui s'occupe des onboarding et du coin de réunion par exemple. Ensuite, on a mis aussi la QA, l'idée étant de pouvoir tester au plus proche des devs, donc de pouvoir remonter les régressions le plus rapidement possible. Alors bien sûr, ça n'empêche pas d'avoir une usine logicielle derrière qui automatise les choses et qui réplique ça ou qui applique ça derrière, mais on avait vraiment ce sentiment de proximité et c'est vraiment ça qu'on a voulu créer en passant sur ce schéma de squad. Pour vraiment avoir les gens qui se parlent et ne pas avoir ces espèces de silos qui peuvent créer de la latence ou un moment de disperser les gens. Ensuite, on a défini une taille de dev raisonnable entre 5 et 7 devs avec un max de newcomers, les newcomers étant les gens qu'on souhaite onboarder. L'idée étant de ne pas trop pénaliser les équipes avec trop de newcomers et qui derrière se retrouvent un peu largués eux-mêmes. Et ensuite, on part sur les profils un peu mutualisés, notamment l'intégrateur web, l'UX, et la partie PO, très importante, qui aujourd'hui travaille avec les équipes et qui crée cette proximité sur les sujets.

11:11 Et qui permet de construire vraiment une équipe orientée feature. Après, on peut débattre sur ce qu'est une feature. Aujourd'hui, c'est vrai que la feature, on la voit souvent comme plutôt un univers ou quelque chose de très large. C'est un des points qui reste à clarifier chez nous. Il faut aussi voir que l'organisation n'est pas finalisée. au sens où on a toujours ce processus d'amélioration continue, on se pose toujours les questions. Et encore une fois, je reviens sur les rétrospectives qui sont très importantes pour nous, sur lesquelles on récupère les feedbacks et sur lesquelles on peut donner les derniers coups de tournevis dans cet organe et nous assurer que finalement, elle compte bien tous les besoins. Et sur les profils mutualisés, il y a une question de finalement, est-ce que ce n'est pas mieux d'en avoir un qui soit dédié? Alors, c'est typiquement le genre de choses qu'on est en train d'essayer de cadrer actuellement. On regarde ce que ça donne, parce qu'aujourd'hui, ça marche ou pas. Si ça ne marche pas, on continuera à faire évoluer cette organisation pour avoir du dédié et non plus du mutualisé. Ce qu'il faut retenir de ça, c'est qu'en fait, on est passé de quelque chose qui était très skills-oriented à quelque chose qui est très future-oriented.

12:16 Point important, c'est aussi quelque chose qui est adapté à la taille et au nombre de personnes qu'il y a dans l'équipe. Basculer sur ce genre de choses-là quand finalement vous avez des petites équipes, ce n'est peut-être pas le bon mode. Et je pense que c'est là où Thomas et Roland pourront apporter un peu leur paire à l'édifice. Et ça pourra du coup alimenter un peu le débat. Et pour finir, parce qu'il y a une autre particularité à ce changement, le premier point, je ne l'ai pas encore mentionné, mais on a beau être des équipes futures, on a quand même ce moment de réconciliation qui est la démonstration où aujourd'hui, tout le monde passe, on présente le travail de tout le monde. à toute la société. Le point important qu'on avait déjà en place et qu'on n'a pas du tout remis en cause, c'est de dire aujourd'hui, on présente un front sprint à tout le monde, on enregistre les démos et on partage ça pour qu'il y ait une vraie capacité à tous les niveaux, sur tous les services, d'anticiper ce qui va arriver et de pouvoir poser les questions et de pouvoir aussi relever les points qui auraient été loupés.

13:23 Donc encore une fois, c'est ce processus d'amélioration continue ou de partage qui est très important pour nous. Et du coup, si j'en reviens sur la dernière partie, qui est un peu la particularité qu'on a gardée, on n'est pas si certes en feature team, mais on garde quand même ce côté très vertical, très silo pour la partie compétences. Aujourd'hui, c'est un peu compliqué de dire qu'on a des équipes très orientées feature, et de ne pas garder ce lien entre Product Owner, par exemple, ce lien entre Tech Lead, je parlais tout à l'heure du comité Tech Lead, qui est un point important de partage, et l'idée, c'est de pouvoir garder les moments de partage avec les personnes qui partagent un domaine ou des compétences pour qu'on puisse faire grandir les gens. C'est un point qui m'est beaucoup à cœur aussi. De ne pas perdre ce côté compétence, être capable de partager et capable de travailler ensemble. Alors, vous voyez à l'écran, il y a le chapter, les guildes. Malheureusement, je n'irai pas dans les détails parce que mon expert n'est pas autour de la table et je pense que je m'orienterai vers des choses où je dirai des bêtises.

14:29 Mais ce qu'il faut retenir, Concrètement, c'est qu'aujourd'hui, on a une organisation à deux dimensions. La première dimension, c'est le côté vertical chapter où on partage les compétences. Les PO se réunissent, ils travaillent ensemble, ils progressent, ils améliorent leur côté user story, vraiment tout leur corps de métier. Pareil pour les tech leads, pareil pour les team leads. On a vraiment cette capacité, cette volonté à se dire qu'on travaille sur les compétences. Mais on a aussi cette capacité à s'orienter sur la productivité avec ce côté feature, ce côté plus horizontal où on met tout le monde autour de la table. pour créer des circuits de discussion très courts qui permettent du coup aussi de pouvoir tacler les problèmes très rapidement. Voilà la solution LittleBig, qui, je répète, n'est pas la solution que je pousserai pour tout le monde, encore une fois, c'est celle qui est adaptée à notre façon de faire et qui, aujourd'hui, nous permet d'atteindre une productivité qui est proche de la cible. Merci pour la présentation. Il y a quelques questions qui sont arrivées, notamment une de Ronan qui demande quel profil a le team lead?

15:38 Est-ce que c'est un profil technique, produit ou autre? Alors, le team lead aujourd'hui, si j'essaye de le caricaturer, c'est un scrum master qui dev, pour permettre à tout le monde de comprendre ce qu'il est. Donc, c'est quelqu'un qui aujourd'hui a plutôt une compétence technique, parce qu'il doit pouvoir faire du dev, faire du code review, mais c'est quelqu'un aussi qui a une forte appétence produit et qui est souvent à une capacité à extrapoler et à pouvoir appliquer les bonnes méthodes scrum et à pouvoir avoir une vraie discussion avec le PO. Alors, par contre, point important, L'avantage aussi de basculer en feature team, c'est que finalement, la compétence produit ou les discussions produites deviennent partagées avec tout le monde. Donc, on n'a plus de profil très technique. On a aussi une volonté à faire des profils dev, des gens qui sont capables de réfléchir et de proposer des choses niveau produit. C'est un des points que je mettrais aussi en avant par rapport à cet organe. c'est que finalement, on n'a plus le code ou un dev, et puis il va juste produire la user story qu'on lui a demandé.

16:41 Il va être aussi capable de discuter avec le produit, avec le PO, de challenger la user story, et finalement, encore une fois, de pouvoir éviter des problématiques de perte. Voilà, on a oublié tel cas, on a oublié telle règle de métier, etc. Et pouvoir ajuster très rapidement les choses. Ok. Donc, s'il y avait d'autres questions sur le sujet, dont une de Laetitia, qui demandait si le team lead, c'est vraiment un rôle à part par rapport au PO ou au tech lead. Je crois que tu as un petit peu répondu. C'est un poste à part entière. Aujourd'hui, les équipes, on ne se passe pas d'un team lead, on ne se passe pas d'un tech lead, on ne se passe pas d'un PO. Aujourd'hui, on n'essaie pas de mutualiser, on n'essaie pas de… C'est pour ça que j'avais mis les responsabilités de chacun. Parce qu'il n'y a pas de… Alors certes, ils se complètent et c'est comme ça qu'on arrive à avoir quelque chose d'homogène. Et ça permet vraiment d'avoir quelque chose sans trop de couture ou sans trop de gap. Mais aujourd'hui, il n'y a pas de volonté de faire du team lead, un espèce de PO ou tech lead.

17:42 C'est quelqu'un aujourd'hui qui a un poste à part entière dans l'ORGA, qui a son propre carrière pass, parce qu'il ne faut pas oublier qu'aujourd'hui, cet ORGA, elle est aussi liée à notre parcours RH, où aujourd'hui, on peut évoluer de team lead à… On peut changer de métier, tout simplement, si on veut. On peut aussi évoluer dans l'organigramme. Mais c'est vraiment un poste. qui est identifié et qui fait partie de la job desk qu'on a chez l'économie. Ok, top. Il y avait également une question qui était que, vu que le team lead, c'est un scrum master qui dev, quelle est la différence en fait avec le tech lead? C'est une question de Mathieu. Alors, on a des ABAC, on calcule la vélocité et un team lead aujourd'hui, on lui donne un pourcentage de développement à hauteur de, je crois que c'est 25 ou 30%. Le tech lead, lui, il a un pourcentage à hauteur de 25-30%. Le dev, lui, il est beaucoup plus. Je crois qu'il est à 75 ou 80%, puisqu'on tient compte de toute la partie réunion, des leads, etc. La différence entre le team lead et le tech lead, c'est que le tech lead, lui, il va être très orienté architecture.

18:48 Donc, c'est quelqu'un qui va participer au choix technique de la plateforme. C'est quelqu'un qui va, du coup, être capable de construire des dossiers techniques. C'est quelqu'un qui va être capable de driver les gens techniquement, d'expliquer aux gens, finalement, ton code, il n'est pas bien fait parce qu'il y a des problèmes de performance, parce qu'il y a des problèmes de sécurité, parce que tu n'as pas utilisé les bons DTO, etc. Donc, c'est quelqu'un qui va être beaucoup dans le mentoring technique et qui, en plus, va avoir un vrai rôle, encore une fois, sur la construction de la plateforme et sur sa capacité à être déployée en production. Là où le team lead, il est plutôt orienté métier, processus et suivi de l'équipe. On va dire que c'est un peu le pendant RH d'un... du tech lead. Le tech lead, il n'a pas du tout de sujet de gestion d'équipe, de RH. Là où le team lead va être beaucoup plus en capacité de suivre la personne, de discuter avec elle sur des sujets qui vont au-delà du technique. Ok, top, merci. Une petite question de Marie qui demande qui est responsable des mises en production?

19:51 Alors là, on garde quand même un schéma très classique. C'est qu'effectivement, pendant le circuit dev, on a cette feature team. Après, on continue à garder un processus de QA. où la QA valide, fait les tests de non-régression avec un peu le côté end-to-end. Finalement, on met toutes les briques qu'on a pu construire pendant le sprint dans le même sac. Et puis, la QL est là pour valider qu'on peut partir en prod avec. Ça reste aujourd'hui, il y a toujours un point de go-no-go suite à cette partie TNR. Qui est lui dédié au... Pardon, pas dédié, mais qui est aujourd'hui assuré par moi et Romain, qui est le profil un peu... Alors, c'est un PM un peu hybride, ou un PO hybride. C'est quelqu'un qui, aujourd'hui, est un peu transverse sur la partie produit. Et aujourd'hui, c'est nous qui, en fonction des retours de la QA, donnons le go ou no go pour la release. Il y a pas mal de questions, je fais attention aussi au compte qui file. Alors, je n'ai pas bien compris la question, mais je vais quand même la poser. Qui fait les one-to-one?

20:55 Will, peut-être si tu veux préciser. Je ne sais pas si c'est clair pour toi la question. Oui, alors je vais essayer de répondre. On va dire qu'on va laisser Will me rebondir si je dis une bêtise. Alors les one-to-one aujourd'hui, c'est les team leads qui vont les assurer quand on parle de sujets très orientés sprint et productivité. Après, les managers, parce que là-dessus aujourd'hui, il y a quand même quelque chose, c'est que niveau de la structure de l'Itabig, on a quand même des managers et des gens qui sont responsables hiérarchiquement d'une personne. Et je n'en ai pas du tout parlé. Vous voyez qu'aujourd'hui, je n'ai pas parlé d'RH. Je n'ai pas parlé de l'OTMID. Aujourd'hui, ce n'est pas. Ce n'est potentiellement pas le manager de son équipe, il est responsable de l'équipe sur un plan produit et productivité, mais le côté RH, ça reste le manager qui est responsable et c'est le manager qui doit organiser les one-to-one avec ses managers. Donc, on fait bien la différence entre les deux. Moi, j'avais une petite question. Peut-être Thomas. Oui, oui, Ronan, c'est bon?

21:55 Je vais, ouais, non, c'est pas, peut-être que, parce que je pense qu'il y a plein de questions, il y a peut-être des trucs que je vais couvrir rapidement dans ma presse, sans vouloir, je ne veux pas du tout tirer la couverture à moi, ce n'est pas l'idée, mais si vous voulez que je vous montre vite fait, moi, j'ai juste trois slides à montrer et raconter un tout petit peu notre histoire, et je pense qu'il y aura peut-être certaines réponses ou qu'on pourra ensuite enchaîner sur la totalité des questions. Il y a plein de trucs hyper intéressants, ou alors on fait les questions et on n'est pas obligé. Il n'y a pas de souci, je surveille le temps pour essayer de faire moitié-moitié et à 30. On peut enclencher tout de suite si tu veux et si les choses se recoupent. On répondra juste après. Donc, vas-y. Ok, alors je vais essayer de partager mon écran, à moins que... Ou est-ce qu'on fait comme... C'est Jérémy qui avait partagé tes slides, Eric? Oui. Alors, on peut dire éventuellement, peut-être que c'est de mon côté qu'il y a un problème technique. Non, mais dans ce cas-là, si Jérémy peut partager mes slides, et puis dans ce cas-là, on peut prendre une question en attendant que les slides arrivent, une autre question intéressante.

22:59 Moi, il y a... Il y a un truc, il y avait une question. Je pense que dans le modèle que tu as présenté, Eric, effectivement, et notamment dans ta dernière slide, cette slide s'est tirée souvent du modèle de Spotify. Je pense qu'il y a sans doute pas mal de personnes avec nous qui connaissent ce truc-là. Nous, il y a aussi un autre modèle qui est intéressant. Je pense qu'on ne va peut-être pas rentrer dans ce modèle-là et dans la critique de ce modèle en particulier, mais moi, je pourrais dire ce qui me paraît poser des problèmes de mon côté. Il y a aussi un autre modèle qui s'appelle le SAFE. Et quand tu parles des démos, Eric, de votre démo commune, ça fait partie peut-être justement de certains événements du SAFE. Dans le SAFE, il y a un concept de programme incrément et tout ça. Donc ça, c'est pour tous ceux qui sont dans la conférence et qui veulent avoir des informations là-dessus, je leur conseille de regarder ces deux trucs-là, le modèle Spotify et puis ce que c'est que le SAFe. Et ils auront déjà plein de pistes intéressantes d'organisation. Je vais raconter rapidement un petit peu notre histoire chez Pitchy.

24:03 Donc là, dans la slide que vous voyez, nous, on a commencé, on était une équipe de dev, il y a à peu près un peu plus de deux ans, on était une équipe de dev, on faisait du Scrum. Je vais reprendre plein de choses qu'a dit Eric. Avec des livraisons, donc on faisait du Scrum classique, vraiment la base, avec des sprints de deux semaines. Enfin, je ne sais pas si c'est la base, mais ça m'a l'air d'être un consensus, souvent d'avoir des sprints de deux semaines. Alors nous, comme on est un éditeur de logiciels et qu'on maîtrise notre plateforme, c'est nous qui faisons l'hébergement de notre logiciel, c'est du SaaS, c'est nous. qui maîtrisons nos mises en prod. Normalement, on était censé faire des mises en prod toutes les deux semaines. Et j'ai mis la partie en vert, c'est l'équipe produit, parce que l'équipe produit, elle travaille en parallèle. Et comme l'a dit Eric, son travail, c'est quoi? C'est d'identifier les stories, de faire la priorisation avec les stakeholders. Alors, les stakeholders, ça dépend dans les organisations. Qui y sont. Nous, ça va être nos fondateurs, ça va être les équipes sales, les équipes marketing, les équipes qui accompagnent ce qu'on appelle nos customer success, donc ceux qui... Ils font l'accompagnement de nos clients, etc. Donc, on essaie de recueillir l'ensemble de ces besoins.

25:06 Et ça travaillait un petit peu en parallèle comme ça. Et alors ce problème, ce modèle-là déjà, il nous posait des soucis. Souvent, ce qui se passe, c'est que la phase, quand on prépare la roadmap, et Eric, on n'a pas forcément parlé, mais je pense que c'est un point intéressant aussi, dans l'organisation en squad, il y a aussi comment ça fonctionne avec le produit et comment on construit les roadmaps et comment on livre le logiciel. Ce qui se passait, c'est qu'en général, en fin de trimestre, là, on se réveillait, on était dans l'urgence en mode« aïe, aïe, aïe, il faut qu'on prépare la roadmap du prochain trimestre, comment on va faire? » Alors, les PO, ils avaient préparé à peu près des stories, mais il fallait qu'on les size. Mais comme on avait des deliveries qui arrivaient, qui étaient déjà en retard, on faisait des sizing, on peut rester sur la première size, on faisait les sizing tout à la fin du trimestre. Souvent, ils n'étaient pas précis. Et la conséquence de ça, c'est qu'au trimestre d'après, en général, nos sizing n'étaient pas respectés. Et en fait, on n'arrivait jamais à tenir notre roadmap. Donc ça, déjà, c'est un problème que je voyais avec ce modèle-là. Ensuite, on est passé à deux équipes. Alors, ça n'a pas arrangé les choses. L'équipe, elle a grossi. On a voulu passer à deux équipes.

26:06 Donc, c'est la slide d'après. Et on a fait un système où on synchronisait les sprints entre les deux équipes. Alors, nous, on n'a jamais divisé les équipes en mode, tiens, on fait une équipe de front-end et une équipe de back-end parce qu'on pensait de toute façon déjà naturellement que ça allait poser trop de problèmes de dépendance entre les équipes. Donc, on avait plutôt une équipe orientée plutôt inter, enfin, fonctionnalités qui sont vues par les utilisateurs, donc ce qu'on va appeler feature, et une équipe... qui était plus engine, donc le moteur qu'on utilise pour rendre les vidéos. Et donc, on se disait comme ça, on aura un petit peu moins de dépendance. Mais au final, ce qui se passe, c'est qu'on en avait quand même. Et il y a un autre point qui n'a pas été abordé, mais il y a aussi la manière dont on organise le code et la manière dont est livré le logiciel. Donc, nous, on travaillait sur, en gros, tout le monde travaillait sur la même branche. Et ce qui pouvait se passer, c'est qu'il y a une des deux équipes qui commençait à livrer une feature. Finalement, cette feature, elle avait des problèmes, elle n'était pas prête d'un point de vue qualité. Et l'autre équipe était bloquée, les mises en prod étaient bloquées parce qu'en fait, on avait livré une feature d'une autre équipe et qui bloquait la deuxième équipe. Et encore une fois, on avait encore les mêmes problèmes en fin de trimestre, on était dans le rush, souvent on ratait nos objectifs de roadmap, on était en retard, et en plus il fallait faire des sizing rapides pour la roadmap d'après, et donc en fait c'était

27:21 un cercle vicieux qui continuait tout le temps. Du coup, c'est pour ça qu'on est passé en squad, nous, parce qu'en fait, moi, dans les discussions qu'on a eues avec l'équipe et avec toutes les parties prenantes, et là, on peut passer à la slide d'après, si tu le veux bien, Jérémy. Il y avait un... Alors, je vais juste commenter cette slide. En gros, moi, j'avais l'impression que ce système de Scrum synchronisé, où on synchronise les temporalités des équipes, en fait, ça crée des dépendances de la manière dont on livre le logiciel. Et finalement, on plafonnait et on aurait pu rajouter plein, plein de ressources. On n'aurait pas franchement gagné en produit. Et le modèle de squad, moi, ce qui m'intéressait, c'était de me dire, en fait, dans ce modèle de squad, je pense qu'on peut vraiment avoir une sorte de productivité linéaire par rapport au nombre de ressources et de gens qu'on va mettre dans les équipes. Et c'est aussi un truc sur lequel moi, j'étais challengé en tant que CTO par mes fondateurs qui me disaient, ouais, mais enfin... On est d'accord pour embaucher, mais il faut que vous y alliez plus vite.

28:22 Si vous embauchez 10 personnes et que vous n'allez que 10% plus vite, le rapport sur investissement n'est peut-être pas bon, il y a un problème d'organisation. Et ce qui m'intéressait dans le système de squad, c'est d'avoir cette isolation, d'essayer d'avoir des squads qui sont isolés. Et là, je pense que ça reprend exactement ce que disait Eric, c'est d'avoir ce qu'il a appelé des équipes, tu disais cross-functional, c'est ça? Cross-functional, c'est ça. Donc, des équipes un peu pluridisciplinaires qui sont autonomes. Et donc ça, moi, c'est un concept que je trouve vraiment très intéressant. Et c'est ce qu'on a voulu mettre en place aussi chez nous, chez Pitchy. C'est de dire en fait maintenant, et là on peut peut-être passer juste à ma dernière slide, Jérémy si tu le veux bien, c'est de dire en fait maintenant on a des streams, Donc, on a des streams et dans ces streams, on met des features. Et donc, pour développer une feature, on va constituer une team. Cette team, elle va créer la feature et elle va être autonome sur le développement de cette feature.

29:25 Et quand cette feature est prête, on la livre en production tout de suite. Le but de ça, c'est... Et donc, si on a des équipes qui sont bien autonomes, ça nous permet, alors je n'aime pas trop utiliser des termes anglais, mais ça nous permet de réduire notre, on peut livrer les features dès qu'elles sont prêtes. Donc, le time to market, en fait, il est réduit. Dès que la feature est prête, il n'y a pas de dépendance, elle n'est pas bloquée par quelque chose d'autre, on va pouvoir la mettre tout de suite pour les clients. Et dans un monde, nous, on est dans un milieu qui est très compétitif, on a plein de compétitions, et c'est important d'aller vite. livrer des nouvelles fonctionnalités, d'améliorer le produit très rapidement. Et donc ça, c'était un truc qui nous paraissait important et intéressant. Ce qui fait que nos cycles de livraison, maintenant, ils ne sont pas tellement liés à des cycles Scrum de deux semaines. Ils sont en fait liés au fait que la feature est terminée ou pas. Donc, dès qu'on a une feature qui est prête, en fait, on va essayer de la pousser en production et de la mettre en production. Et donc, il peut y avoir plusieurs mises en production qui sont proches les unes des autres parce que sur les streams, sur différents streams, finalement, c'est assez proche au niveau des dates de livraison, tout ça.

30:32 Comme il peut y avoir des moments où en fait il y a un creux parce que finalement c'est des features qui sont plus longues et tout ça. Et après au niveau de nous, de l'organisation des équipes, je ne sais pas Eric, comment vous faites? Est-ce que vos équipes elles sont pérennes dans le temps? Combien de temps elles restent? Peut-être ça, peut-être tu pourrais nous dire. Nous, en fait, on peut les... On ne s'empêche pas de les restructurer pour chaque feature. Alors, ça demande du coup de synchroniser à un moment donné parce qu'il faut bien qu'elle s'arrête en même temps pour pouvoir rebalayer les cartes et changer les gens des équipes. Et c'est pour ça qu'on a des creux, en fait, des fois, on a des espèces de moments entre les moments où on fait les features. Et ces moments-là, ils vont nous permettre, ces moments de pause, ils vont nous permettre justement de faire les sizing, de préparer les roadmaps des trimestres suivants, donc d'anticiper en fait la création des roadmaps et de se dire, ce temps-là, pour les développeurs, vous avez un temps qui est réservé, il va nous permettre éventuellement de faire du refactoring technique, il va nous permettre de faire des discussions d'architecture, des trucs que, en fait, sinon, on a rarement le temps d'avoir au quotidien. Ou alors il faut... Il faut avoir ce système de chapter et avoir des discussions par semaine.

31:33 Mais moi, ce que je n'aime pas trop dans ce système, c'est que j'ai l'impression qu'on a tout le temps des meetings. Et moi, les développeurs, ils ne veulent pas avoir tout le temps des meetings. Mes développeurs, ils veulent pouvoir bosser sur un sujet et ne pas avoir quatre sujets en tête en même temps et être vraiment concentré. Donc, en fait, nous, l'approche, c'est de dire qu'on se concentre sur une feature pendant un moment, on ne fait rien d'autre. Et après, on peut avoir des temps de pause dans lesquels on va peut-être avoir des réflexions architecturales, des discussions. Et là, les chapitres peuvent être intéressants. On va regrouper des gens qui sont experts de front, des gens qui sont experts de back, etc. Voilà, je pense dans les grandes lignes. Ah ouais, et puis aussi la gestion des bugs, on n'en parle pas, mais je pense que c'est un sujet qui est intéressant aussi. Avant, dans notre système précédent, les bugs, on les intégrait à l'intérieur des sprints et ça ne marchait jamais parce qu'en fait, les bugs, souvent, ils sont... Moins prioritaire que les nouvelles features d'un point de vue business. Et nous, on avait nos fondateurs ou nos équipes sales qui nous disaient, d'un point de vue business, il faut que tu dises telle et telle feature, c'est vraiment important. Et du coup, les bugs, ils passaient toujours un peu à la trappe.

32:33 Et donc maintenant, on a mis un stream de bugs avec des gens qui, nous, on a un système tournant, mais on a toujours des ressources assignées aux bugs, comme ça, on est sûr de faire avancer aussi cette partie-là. Et la partie debug, c'est hyper important pour la satisfaction client. Je pense que tous les gens qui sont aujourd'hui dans ce meetup doivent le savoir. Et pour éviter le churn, quand on a des systèmes, nous, on fait du SaaS. Donc, on a des systèmes avec des gens. abonne et puis ils peuvent renouveler ou pas leur abonnement, il faut qu'ils soient satisfaits, sinon ils s'en vont. C'est aussi le problème des modèles SaaS. Donc, il faut faire avancer les bugs. Et ça, nous, du coup, on le sépare de la partie feature. Tu ne nous en as pas parlé d'ailleurs, Eric. C'est une question intéressante dans votre système. Comment vous gérez la partie bug? Est-ce que c'est vos squads? Tu touches beaucoup de sujets que je n'ai pas évoqués. En fait, je me suis très axé sur le côté production et produits et features. Mais il y a beaucoup de choses qui vont autour et qui finalement étaient déjà en place et qu'on n'a pas changé. Par rapport au bug, on utilise un peu le concept de, je ne sais pas si vous connaissez le concept d'interrupt.

33:37 Alors, c'est un bouquin de Google, SRE Interrupt, je crois. Il y a un gros bouquin là-dessus qui est une mine d'informations, comme souvent. Nos amis les Américains sont en avance et proposent beaucoup de choses. Et il y a vraiment beaucoup de choses à retenir, notamment ce concept d'interrupt qui est un peu comme tu dis, d'allouer de la bande passante à certains sujets, et notamment en l'occurrence les bugs, pour permettre de sécuriser les choses à côté. Et finalement, on a dans les équipes, dans les feature teams, On a une équipe qui est dédiée aux bugs, tous les sprints. Et en fait, on est en release à la semaine. C'est-à-dire que c'est assez bizarre à dire, mais aujourd'hui, on a des cycles de trois semaines de développement. Donc, en gros, on pourrait release ce qu'on appelle une version majeure toutes les trois semaines, mais on release toutes les semaines. Et on release aussi des petites features. Donc, on a vraiment aujourd'hui quelque chose qui est capable d'adresser beaucoup de problématiques. Mais surtout, comme tu le disais, concentrer les développeurs sur des tâches. Et effectivement, je pense que c'est un des points de départ qui nous a amenés à changer de chose. C'est qu'à un moment, on nous disait, mais on en a marre de switcher.

34:40 Un coup, il faut faire ça, un coup, il faut faire ça. Et puis, la priorité, elle est là. Donc, en fait, on a tout accès par rapport à ça. Et tu parles d'aujourd'hui faire des roadmaps après les features. Alors nous, on s'organise différemment. On fait les roadmaps deux fois par an. C'est-à-dire qu'aujourd'hui, on a un gros chantier là-dessus où on va cadrer un peu les besoins en avance de phase. On fait un peu le tour des... de nos clients, de beaucoup de personnes. Et l'idée, c'est d'arriver à en tirer les gros sujets, les grosses features qu'on va ensuite découper et de pouvoir basculer ça et d'allouer ça à des équipes. Et donc, en fait, avec le côté équipe support, on a ce fameux temps où on peut un peu changer d'air. Et faire du tech, du refactoring, et surtout du backfixing, parce que c'est ça qu'il faut avoir en tête, tout en ayant cette capacité à produire et à s'engager et à tenir nos engagements. Alors, c'est un point que je n'ai pas mentionné, mais c'est important, on va dire, dans les valeurs qu'on avait, qu'on voulait garder, c'était absolument tenir nos engagements. On voulait, par rapport à cet orga, être capable de dire, nous, on sort telle feature à telle date et d'y être.

35:45 Et cette organisation aujourd'hui nous permet vraiment d'assurer cette partie-là, puisqu'en fait, l'équipe est dédiée. Il y a des gens finalement qui travaillent ensemble, qui créent des circuits de discussion très courts, des circuits d'agilité et d'itération très courts. Et derrière, on arrive à tenir nos délais. Et s'il y a, entre guillemets, une charge de bug ou autre chose plus importante, on arrive à allouer ça à l'équipe qui se charge de ça et qui permet de déstresser les autres. C'est un point important, je pense que c'est vrai que moi, je n'en ai pas beaucoup parlé, mais tu parlais de productivité, de livrer les futurs au fur et à mesure, il y a un point qu'il ne faut pas négliger, et ça rejoint un peu ce que je disais au début, c'est que finalement, la solution aujourd'hui, elle n'est pas unique. Elle va s'adapter à un contexte. Le contexte aujourd'hui, ça va être l'infrastructure, Est-ce que tu es capable de déployer juste après avoir ta feature ? C'est aussi important. Est-ce que c'est le fameux débat monolithe versus microservice ou multirépo? Alors, je pense que ça ferait un sujet meet-up à lui tout seul, donc on ne va pas commencer à entrer dans ces débats. Mais il y a un vrai… Il faut vraiment, dans ce changement-là, il faut vraiment tenir compte de l'environnement qui est spécifique à ta boîte.

36:52 Qui va te permettre finalement de pouvoir prendre en compte toutes les problématiques et de pouvoir y répondre. Et il n'y a pas une solution. La solution aujourd'hui, c'est celle que tu vas mettre en place avec, je voyais dans les questions du Spotify, du topologie. En fait, finalement, Spotify, c'est décrié pourquoi? Parce qu'on n'a pas les équipes de Spotify, parce qu'on n'a pas le budget de Spotify, parce qu'en fait, on n'a pas l'infra de Spotify. Mais aujourd'hui, tu prends une boîte qui a les mêmes, ça va marcher. Pourquoi ça ne marche pas? Parce qu'en fait, tu n'as pas les mêmes capacités à faire, tu n'as pas les mêmes ressources. Et finalement, ce qu'il faut faire, c'est essayer de benchmarker, de pouvoir trouver des choses et potentiellement d'aller chercher trois infos dans ta slide, deux dans la mienne, trois dans ce que va dire derrière Thomas et de pouvoir construire le modèle qui est adapté à ta boîte. Tu as dit un truc intéressant et ce n'est peut-être pas vrai dans tous les contextes de boîte, mais ne serait-ce que la manière d'organiser le code. assez important sur l'organisation des équipes. Nous, on est passé d'avoir un système où on avait des guides séparés pour chaque projet, ou chaque composant, à tout remettre dans un monoprojet avec tous les composants dedans.

37:59 Et l'idée, c'était aussi de pouvoir isoler plus facilement les features quand on les développe. Avoir tout ça dans un seul projet, ça permet plus facilement de créer une branche qui touche à plusieurs composants. Et on crée toute cette feature en isolation. On peut la tester en isolation, donc il faut aussi avoir la capacité de créer un environnement qui soit isolé. Et donc, ça a des impacts aussi sur l'aspect DevOps. Et nous, c'est un travail aussi qui est fait avec notre équipe DevOps, qui, elle, est un peu transverse, d'ailleurs. Elle n'est pas vraiment nos DevOps qui ne sont pas intégrés dans les feature teams. Mais il travaille justement sur des outils pour pouvoir facilement créer un environnement basé sur une branche, sur une feature en cours, pour pouvoir la tester et être serein aussi sur la livraison de cette feature, de dire qu'on peut ensuite la réintégrer sur Master et la livrer en production, etc. Donc la partie pour ceux qui sont vraiment très orientés code, c'est important aussi. Je rejoins pas mal sur le fait que pouvoir appliquer ce type de sensus, toutes les règles d'une méthode d'eau, ce n'est pas forcément la bonne solution, mais plutôt prendre les règles qui font sens, les retours d'expérience et les best practices qui font sens pour l'entreprise et

39:11 là où elle en est. Des entreprises de plus de taille. Et des fois, certaines entreprises ont juste besoin d'une partie d'une méthode pour que ça fasse plus sens et que ça marche mieux chez eux. Donc, il faut toujours rester alerte sur... Sur ce qu'il faut prendre et ce qu'il ne faut pas forcément appliquer. Et puis en plus, les choses bougent beaucoup. Donc entre une vision qu'on pourrait avoir à tenter de comment on peut s'organiser et face à la réalité, ça évolue. C'est toujours mouvant, donc il faut bien s'adapter. On a quelques questions, dont une de Perrine. Qui demande quelle légitimité du manager si ce n'est pas impliqué dans le quotidien des devs, notamment l'évaluation technique. Très bonne question. Au départ, quand je suis arrivé chez Pitchy, on était relativement petit, on était en train de grossir et donc je m'occupais des évaluations.

40:12 Et j'étais les mains dans le code et donc c'était assez facile de voir ce qui se passait et de voir les gens. Quand tu te détaches ou si ton manager n'est pas au quotidien, ça devient plus compliqué, mais c'est là que tu peux mettre en place d'autres systèmes d'évaluation par les pairs. Ça peut être un système où les uns et les autres mettent des évaluations. Après, je pense que la question aussi, c'est à quoi servent les évaluations? En fait, quel est le but de l'évaluation? Et quelles sont les trajectoires RH? Eric, il avait l'air d'avoir des bonnes réflexions sur les trajectoires RH à l'intérieur de la société. Et ça, c'est important aussi pour ne pas faire de bullshit comme c'est une des valeurs a priori de Tech.Rocks. Dans les boîtes, finalement, c'est quoi les possibilités d'évolution d'un développeur? C'est de devenir meilleur techniquement et d'aller vers de l'expertise technique, ou pour certains, d'aller vers du management. Mais ça ne va pas être... Ce n'est pas non plus des trucs incroyables. Ils ne vont pas devenir... C'est compliqué, il n'y a pas beaucoup de place.

41:14 Si c'est devenir CTO, par exemple, il n'y a quand même pas beaucoup de place. Souvent, quand on est dans une organisation, il y a un CTO. Donc, finalement, les évolutions... À quoi servent les évaluations? Est-ce que ça sert aux augmentations d'un développeur? Et dans ce cas-là, comment tu évalues ça ? En France, il faut définir à quoi servent les évaluations. Et pour savoir si vraiment le manager ou pas il est approprié ou pas est-ce que tu veux juste faire une évaluation technique mais est-ce qu'il n'y a que l'aspect technique est-ce qu'il y a l'aspect aujourd'hui il y a quand même un aspect aussi savoir vivre dans l'entreprise mentoring esprit d'équipe il y a d'autres dimensions que juste l'expertise technique qui font qu'un manager peut être pertinent pour je pense pour évaluer des gens suivant un peu la grille que vous pouvez avoir dans votre société pour évaluer en fait Pour rebondir un peu sur ce que tu viens de dire, Aujourd'hui, on n'est plus sur le côté très simpliste où l'évolution, c'était tu passes manager, puis après, tu grimpes, tu gravis les échelons.

42:19 Aujourd'hui, on a affaire à beaucoup de personnes qui, finalement, focalisent sur l'expertise, en fait, qui veulent évoluer dans l'expertise plutôt que dans le management. Donc, en gros, sur cette partie horizontale versus verticale que je mentionne beaucoup, Et nous, aujourd'hui, côté RH, on a des cas à passe qui permettent de monter sur les deux axes, voire d'avoir quelque chose plutôt en escalier. Je vais être expert et puis après, peut-être que je vais commencer à faire un peu de management, etc. Il faut aussi que, et c'est un gros boulot des RH chez nous, de pouvoir travailler sur le bien-être du collaborateur et de pouvoir lui proposer des choses sur lesquelles il peut se projeter. Là, on en revient sur des choses de culture d'entreprise, etc. Mais je pense qu'on pourrait très rapidement dévier. Et si on revient au point de départ sur la partie squad et le rôle du manager aujourd'hui, le manager, il n'est pas exclu de... De l'organisation. Quand je disais le team lead n'est pas forcément un manager, dans certaines équipes, le team lead peut être le manager.

43:21 À côté de ça, il y a toujours le côté, les one-to-one dont on a parlé tout à l'heure. Le manager, à un moment, il a le rôle aussi de se tenir au courant de ce qui se passe dans ses équipes. De pouvoir s'appuyer sur des KPI. On parlait du côté technique. Finalement, aujourd'hui, on a des guides. merge request, etc., on est capable de sortir des KPI. On est capable, avec l'usine logicielle et des softs type SonarCube, on est capable de contrôler si finalement la personne évolue dans le bon sens ou pas. Et ça, pour moi, c'est le process d'unboarding. Là, en tant qu'ancien développeur, j'imagine qu'il y a des cheveux qui se hérissent dans l'assistance avec des gens qui disent« Quoi? Vous regardez le nombre de merge requests des développeurs pour évaluer s'ils sont bons ou pas? C'est n'importe quoi. » Non, non, non. Je n'ai pas dit qu'on regardait le nombre de merge requests. Par contre, on va regarder effectivement s'il y a beaucoup de commentaires. Et encore une fois l'idée c'est pas de fliquer c'est hyper intéressant comme point sur l'évaluation j'ai pas du tout une volonté de fliquer à un moment ce qu'il faut aussi c'est qu'à un moment on puisse aider les gens à progresser et si on n'est pas capable d'avoir un suivi

44:23 c'est compliqué de dire à quelqu'un au bout de 6 mois bon bah toi t'es pas bon quoi bah ok mais tu te bases sur quoi c'est quoi les faits et c'est souvent là dessus que le manager va être bon c'est en étant capable de s'appuyer sur des faits et de montrer que finalement il y a un moment il y a des choses il y a des axes de progression et de pouvoir les partager avec le développeur. Ou pas que le développeur, c'est le cas d'un peu tout le monde. Et c'est un point important aussi de l'organisation et du fait que finalement, le manager, il doit faire partie de l'organisation, mais ce n'est pas pour autant que ça doit être un élément important. Il doit avoir son rôle. Son rôle de manager, c'est effectivement, on parlait de faire grandir les gens, de pouvoir les projeter dans l'entreprise. il faut que le manager soit capable de mettre en place les actions qui, pour moi, sont parallèles à cet organe, finalement, ou qui peuvent être intégrées. Mais c'est un autre poste, un autre rôle, et c'est un autre débat pour moi. Comment vous faites, Thomas? On ne t'a pas beaucoup entendu. Comment tu fais pour évaluer tes... Comment ça se passe? La première question que je me pose, c'est qu'est-ce que j'attends de telle ou telle personne?

45:24 Parce que là, on parle surtout d'évaluation technique. Mais ça dépend du poste et de la personne qu'on cherche. Donc, cette question, parce que si on vient chercher quelqu'un qui a une expertise technique très forte sur un sujet en particulier, c'est sûr qu'on va plutôt avoir tendance à évaluer. Quel est son niveau de vélocité, est-ce qu'il est bon, sur la compétence, des conseils, etc. Sur ce niveau-là, mais moi, c'est mon cas, on peut chercher aussi des personnes qui ne sont pas forcément experts dans un domaine très petit, qui vont être un peu agnostiques sur certains langages et qui vont avoir aussi de l'appétence produit. C'est pour moi important parce qu'une personne dont tu vas chercher ça peut t'aider sur d'autres aspects que les aspects techniques. Pour un développeur, avoir une appétence produit va aussi lui permettre de venir t'aider et faciliter les flots, les interactions entre les gens, du travail avec un PO ou d'autres personnes, la fluidité des échanges. Est-ce que seule l'évaluation technique fait sens?

46:25 Pour moi, ça dépend vraiment de ce qui est attendu sur le poste. rapport à la personne. Il y a aussi l'aspect humain, ce genre de choses. Donc moi, cette évaluation technique, elle est faite, alors ça peut m'arriver de la faire, mais je la fais de manière assez objective à travers d'autres outils comme CodeClimate, c'est-à-dire suivi du niveau de test code range, suivre au niveau des techniques et maintenabilité du code qui a été produit, etc. Via certains outils externes. Après, comme je n'ai pas une énorme équipe, les échanges sont quand même assez de proximité entre vous et moi, donc je me rends compte bien, soit à travers des revues de code, soit à travers, je ne sais pas, leur demande de spécifier techniquement des choses à produire. Voir quel niveau ils atteignent de qualité et ce qu'ils apportent. Donc, pour moi, il ne faut pas se focus. C'est juste mon expérience. Se focus uniquement sur un pan, mais vraiment rechercher ce qu'on demande à la personne, ce qu'on attend d'elle, et sur ces différents pans, voir où se situe la personne et est-ce qu'elle évolue.

47:32 Aussi dans le temps, parce qu'il y a ça qui est important, et qu'est-ce que nous aussi on fait en tant que manager pour accompagner cette personne dans la... Dans l'amélioration. On peut en comprendre. Est-ce que tu veux qu'on reprenne des questions? Oui, on a une question, je prends par ordre du pote. Une question de Mickaël. Quel est l'autre couple des chapitres? Ont-ils leur propre roadmap? Planning s'organise-t-il sans péter les plannings des feature teams? Et d'ailleurs, peut-être qu'on peut faire venir les gens sur scène, Thomas, s'ils veulent poser leurs questions derrière. Avec plaisir, je cherche juste comment on fait ça. Je crois qu'il faut qu'il lève la main. Si par exemple, si Mickaël, je crois qu'il faut qu'il lève la main et ensuite on peut les accueillir sur scène, donc n'hésitez pas. Mickaël qui a levé la main à l'instant. Jérémy, si tu m'entends, tu vas commenter ça. Salut. Excellent. Bonjour, Mickaël. Bonjour.

48:35 Ouais, du coup, nous, ça fait quelques années qu'on... Donc déjà, merci pour les conférences. Très intéressant de voir d'autres perspectives. Nous, ça fait quelques années qu'on utilise l'espoir de chez Gatorade Europe. C'est 5 ans à peu près et on a itéré plein de fois sur les process et sur la façon de s'organiser. Et notamment, nous, clairement, les chapters, c'est un sujet. On en a, on a des roadmaps back-end, des roadmaps front-end et d'autres choses. Et c'est vrai qu'on n'arrive pas encore à trouver complètement l'équilibre sur comment faire avancer ces roadmaps-là. Donc, les roadmaps des chapters, ça va être... Vous l'avez dit, des refactoring, mais aussi des roadmaps techniques, comme extraire certaines parties du code, ou ça peut être tester, faire un peu de R&D, tester des nouvelles technologies pour éventuellement régler certains problèmes, anticiper certains sujets qui peuvent venir dans le futur. Ça peut être plein de choses. Des fois, ça rentre bien dans le cadre des feature squads, des fois, pas vraiment. Et la limite entre qui le fait, entre les feature squads et les chapters, elle n'est pas évidente.

49:38 Et c'est là que, en fait, malgré le travail des estimations, je pense qu'on sait tous que les estimations, c'est un peu, c'est de la science, c'est disons que c'est... On essaye de faire au mieux, mais souvent, on peut se tromper. Et donc, des fois, les feature squads peuvent prendre du retard. On a des buffers pour essayer de fixer ces retards. Mais par contre, les... En général, les roadmaps des capteurs, c'est souvent elles qui vont avoir un impact. Donc, c'est là que je suis intéressé par voir un petit peu vos perspectives. Moi, j'ai une question pour toi, Mickaël. Est-ce que vos équipes, elles sont stables? Vos feature teams, elles sont stables dans le temps ou est-ce qu'elles bougent? Quelle souplesse vous avez dans le fait de la réorganiser? Alors, elles ne bougent pas souvent. Je dirais qu'elles bougent tous les 12 à 18 mois, peut-être même 24, c'est arrivé dans le passé, mais je dirais à peu près 18 mois. Tous les 1 an et demi, ça bouge un peu. Nous, nos feature squads, elles sont organisées autour de sujets produits très précis ou sujets techniques très précis.

50:41 Ça permet aux équipes de vraiment acquérir une expertise sur certains sujets et de venir avec des idées, de vraiment owner les sujets. Je parle beaucoup anglais aussi, désolé. Et du coup, non, elle ne bouge pas beaucoup. Pourquoi je pose cette question? Je me demande, parce qu'en fait, effectivement, si tu as un chapter et qu'il y a une feature qui ne rentre pas dans aucun des domaines, enfin, qu'il y a un sujet qui ne rentre pas dans aucun des domaines des feature teams, je conçois que c'est peut-être là qu'il y a un truc à régler, parce qu'en fait, ça ne s'intègre pas dans la roadmap, parce qu'il n'y a aucune feature team qui va pouvoir prendre cette tâche-là. Je te donne un exemple. Peut-être, par exemple, disons que tu utilises un framework de développement. Nous, par exemple, on utilise Ruby on Rails. On est sur la version 5, il y a la version 6 qui sort, qui est sortie d'ailleurs. On a testé dans le passé d'avoir une équipe qui est dédiée vraiment à ce genre de choses, la core squad.

51:42 On a une core squad, mais c'est un peu différent aujourd'hui. Et on pense que c'est vraiment… Là, récemment, on a plutôt testé de mettre ça dans la responsabilité des chapters, qu'ils aient leur roadmap. Et c'est vrai que c'est un peu dur de maintenir la roadmap sans beaucoup de synchronisation, beaucoup de meetings et tout ça. Et ça, en effet, ça ne rentre pas dans les équipes futures. Aujourd'hui, en tout cas. Eric, Thomas, vous voulez rebondir sur cette question? Difficile, très difficile. Oui, très difficile parce que... La réponse, en vrai, c'est plus pour amener une perspective. Je pense que déjà, c'est bien, c'est de se dire qu'aujourd'hui, il n'y aura pas la réponse. Il y aura peut-être des bris de réflexion. La façon dont je vois les choses, ou en tout cas de la façon dont on les applique chez nous aujourd'hui, c'est la roadmap, elle est produite. On essaye d'appeler un chat un chat, c'est sur le produit qu'on a une roadmap. Et on essaie de tout construire autour de ça.

52:43 À savoir que tu parlais de monter des versions du framework, on a un peu les problématiques chez nous, on a une équipe qui est un peu transverse et qui du coup construit une roadmap technique en parallèle de ça. C'est-à-dire que par rapport aux futures produits qu'on veut sortir, On prévoit ces choses-là et on les met en parallèle sur la roadmap ou en série. Enfin bref, on s'organise autour de ça. Et ça permet finalement de construire des roadmaps qui ont un sens et qu'on arrive à dérouler les unes à la suite des autres. Et finalement, la zone de friction, elle est très petite, voire inexistante, et on arrive à bien avoir quelque chose de fluide. Maintenant, ça nous arrive d'avoir des problèmes et de dire, oups, là, on n'y a pas pensé à ce truc-là. Et la meilleure réponse que je peux apporter à ça, c'est la réactivité et finalement le côté agile. Il faut se dire que comment est-ce qu'on fait rentrer les choses? Parce qu'aujourd'hui, c'est quelque chose d'urgent et donc on doit déprioriser autre chose. Donc, on repasse sur la notion de priorisation, la priorisation. C'est comme ça qu'on arrive à traiter ces aléas. C'est de se dire que finalement, on arrive avec et on planifie ça plus tard. Ou au contraire, c'est quelque chose qu'on a absolument besoin d'avoir maintenant.

53:46 Et on regarde dans la roadmap comment est-ce qu'on bouge les choses. Finalement, on réunit tout le monde, tous les sachants, entre guillemets, et on trouve une solution en groupe. Et derrière, on déroule ça et on communique beaucoup aussi, parce que c'est important. Une fois qu'on a un commitment, l'important, c'est aussi d'être capable, si on ne le tient pas, de communiquer, de pouvoir partager les infos. Et donc, on est sur ce côté où on itère, on est agile et on communique derrière. Je pense, Thomas, qu'on approche de la fin du meet-up. C'est la question que je me posais. Je ne sais pas. Il y a encore pas mal de questions. C'était, je pense, Thomas, Ronan qui disait, comment l'exec considère les temps de pause qu'il y a entre la délivrabilité de feature qui est plus accordée? Bonne question. Moi, mes fondateurs, ce qui les intéresse, et je pense qu'Eric a dit la même chose, c'est comment avance le produit. Et donc, moi, mon rôle, c'est d'organiser le plus performant possible.

54:51 Et tu peux très bien mettre en place des métriques pour dire, sur ce trimestre, on a livré 5 features, 6 features, 7 features. Je pense qu'il faut que tu sois... capable de démontrer aux execs et au top management, au fondateur, finalement, que tu es plus productif avec cette méthodologie-là qu'avec une autre. Si c'est le cas, il n'y aura pas de problème pour justifier des pauses et des moments de refactoring. Il faut peut-être leur demander un peu de temps. C'est-à-dire, il faut peut-être leur demander, il y a peut-être besoin d'avoir 6 mois ou même 12 mois d'implémentation pour avant de tirer des conclusions. Mais moi, je pense qu'au final, on est beaucoup plus productif parce qu'on se concentre sur des features, on les livre plus tôt, on n'a plus de dépendance. Et donc, même si on a des moments de pause, en fait, au final, on est plus productif, beaucoup plus productif le reste du temps. Et donc, au final, on livre plus. Voilà ce que je dirais. De toute façon, l'idée, c'est d'avoir des métriques. Les métriques, c'est la seule manière de pouvoir communiquer avec ton top management ou même avec tes équipes et d'avoir une vision et de partager une vision sur ce qui se passe, est-ce qu'on est dans la bonne direction ou pas. Et d'avoir des bons KPI.

55:53 C'est un sujet intéressant et un sujet à part entière, mais de trouver les bons KPI pour savoir si ça va dans la bonne direction. On a parlé des KPI au niveau de l'évaluation des développeurs, mais il y a aussi des KPI globalement de comment avance le produit, etc. Oui, juste pour compléter rapidement ce que vient de dire, c'est aussi l'importance d'impliquer les execs dans ce changement-là ou dans l'organisation. C'est la meilleure façon qu'ils puissent comprendre et finalement adhérer à ces temps de pause et de ne pas les vivre comme étant des« bah ouais, mais là, les mecs, en fait, ils se sont mis les pieds sur le sol». C'est vraiment important. Et ça permet, entre guillemets, d'éviter les débats trop tard ou sur le tas du« Ah ouais, mais là, ce n'est pas possible, on n'est pas capable parce qu'on a besoin de telle feature. Je vais appeler Noémie pour la conclusion. Il y en a là.