Méthodologie Shape-up

0:00 On inaugure ce nouveau format, si j'ai bien compris, chez Tech.Rocks. J'ai fait un petit support, je vais vous partager ça. On a collecté à peu près cinq questions. Alors, je n'ai pas forcément les noms des personnes, donc si à un moment vous estimez que c'est vous qui avez posé la question, n'hésitez pas à vous signaler si vous le souhaitez. Voilà, hop, je vous partage mon écran en même temps. Et du coup, on va enchaîner rapidement. Juste, je voulais rappeler deux, trois petites choses rapidement. Chez Tech.Rocks, on a à peu près trois initiatives en cours. On a le groupe ShapeUp, pour ceux qui veulent rejoindre, où on a des discussions sur un chat. Ça démarre depuis fin d'année dernière. Et on fait des coffees régulièrement pour échanger autour de ShapeUp. On travaille aussi sur un bout du livre blanc dans lequel il y aura un retour d'expérience et puis deux interviews de l'e-tech. Qui seront exprimés sur ShapeUp, dont Marc qui est là ce matin.

1:05 Merci Marc pour ta participation. Et puis, il y aura une petite presse autour de ShapeUp sur la petite scène, je ne sais pas comment on l'appelle, de Tech.Rocks, en lien avec le thème de la résilience de cette année. Du coup, je voulais me présenter rapidement pour ceux qui ne me connaissent pas. Je suis Engineering Manager Hands-Off chez Welcome to the Jungle. J'ai un parcours avec une passion autour de tout ce qui est process. Je suis parti du Lean, je suis passé par le Scrum, Kanban, etc. J'ai ouvert ShapeUp il y a un petit moment maintenant et j'ai eu l'occasion de tester la méthode sous différentes approches, notamment chez Welcome. J'ai toujours été assez impliqué dans les parties refinement, estimation et avec à la base une... J'ai beaucoup travaillé sur la partie estimation et chez E-Pop, on en parlera un peu après.

2:06 Il y a un peu un changement de paradigme autour de ce sujet-là. Dernière chose avant de commencer, les éléments de réponse que je vous donne, les limites, c'est juste que ça vient de mon expérience, mes lectures, les échanges que j'ai pu avoir avec d'autres personnes, mais bon, je n'ai pas vocation à avoir parole d'évangile sur le sujet. Donc, n'hésitez pas, si à un moment, il y a des choses qui vous heurtent, qui vous font réagir, à soit les noter pour les échanges de fin, soit les mettre dans le chat. En tout cas, ça n'est que mon approche et mon expérience. Je suis content de pouvoir la partager avec vous et échanger avec vous pour continuer aussi à m'enrichir sur le sujet. Je ne sais pas quelles sont les connaissances des uns et des autres sur ShapeUp. La slide est un peu lourde, mais je vais rapidement passer. En gros, il y a trois principes clés, plus le système de cycle qui est un peu spécifique à H. ShapeUp. Première chose, c'est quelque chose qui n'est pas figé. Ryan Singer, qui a co-écrit le livre sur ShapeUp, le dit d'ailleurs dans une interview, le système de cycle de six semaines plus deux semaines de cooldown, ce n'est pas quelque chose de figé, c'est un principe.

3:15 Et puis ça, c'est des choses qui sont adaptées sur votre fonctionnement. Et d'ailleurs, certaines boîtes l'adaptent ou ont même des tailles de cycle variable suivant les périodes de l'année parce que des fois, avoir un cycle de cinq semaines, ça permet de coller au quarter. Donc voilà, un des premiers principes, en tout cas, c'est cette alternance cycle de build shape et après cool down de deux semaines. On est sur une méthode où il n'y a pas d'estimation. Et on parle d'appétit, on en reparlera tout à l'heure dans les questions, je ne vais pas plus m'étendre là-dessus tout de suite. On a un système de dual track sur la version pareil by the book de ShapeUp avec un shape et un build en parallèle. Et il y a une attention particulière qui est portée sur l'autonomie des équipes. Mais en fait, ça devrait être le cas à partir du moment où on travaille en agile, puisque ça fait partie des principes aussi agiles de pousser à l'autonomie des équipes pour maximiser le résultat.

4:18 On va enchaîner avec la première question, question autour de la gestion de la dette, qui est donc comment on peut adresser efficacement la dette technique ou financière. fonctionnel durant les cooldowns. Donc, pour rappel, les cooldowns, c'est une phase qui se fait après un cycle de développement de manière standard, donc un cycle de développement de six semaines. Et on fait une phase de cooldown où les équipes vont être dans une phase de traitement de support, d'amélioration, etc. Il y a beaucoup de choses qui peuvent se faire pendant le cooldown, mais on ne traite plus un pitch et les équipes sont... On relâche un peu la pression ou au moins la charge mentale. Au maximum. Alors, sur cette histoire de dette technique ou fonctionnelle, nous, l'approche qu'on a, et moi l'approche que j'en ai en tout cas, c'est de le faire par rapport à la taille un peu de ce qu'on souhaite, ou à l'effort qu'on souhaite mettre sur le traitement de la dette, ou sur un sujet précis de dette technique.

5:24 C'est quelques heures, la question ne se pose pas, en vrai, est-ce que... Ou c'est quelques jours, en effet, le cool-down, ça peut être un bon moment pour s'en occuper. Dans certaines boîtes, ça se fait en deuxième semaine de cool-down, par exemple. On se met... Des certains sujets, on voit quelles équipes ou quelles personnes sont intéressées pour le traiter. Et souvent d'ailleurs, on peut se permettre par exemple de casser aussi les équipes et de monter des équipes un peu à d'autres pour traiter des sujets et de voir aussi un peu l'attraction qu'il peut y avoir côté dev, côté des équipes pour savoir si... Si les équipes seront, si ça motive vraiment des personnes dans l'équipe. Au-delà d'une semaine de taf, du coup on parle d'appétit, donc si on se dit qu'on veut mettre plus d'une semaine de budget,

6:27 Là, on rentre typiquement dans quelque chose qui doit sortir. à mon sens, du coup d'armes, et qui peut rentrer dans un cycle. Dans Shai Pop, ce n'est pas fortement abordé. On parle beaucoup, beaucoup de produits ou de tech pour le produit, mais pas vraiment de sujet tech pour tech. Et donc sur ces sujets-là, il y a différentes approches. Il y a certaines boîtes qui font des cycles un peu sanctuarisés une fois, deux fois par an sur des sujets tech pour traiter efficacement de la dette technique. Et là, même des fois, c'est toutes les équipes en même temps qui sont sur des sujets de dette. Mais bien sûr, ça dépend un peu des particularités de chaque entreprise, de la taille de la dette, de l'impact, de la... De la contrainte que peuvent générer certains éléments de la dette. Donc là, l'exemple que j'ai très, très concret, je gère une équipe qui travaille sur un produit qui est en phase bêta.

7:31 On a des retours des bêta testeurs. On va faire de l'itération fonctionnelle. Cette itération fonctionnelle, on en a fait un cycle. Donc, on a fait le choix à un moment de repousser certaines features pour faire de l'amélioration. Donc là, on ne parle pas purement de dette, mais ça peut être l'approche. Voilà. Nous, on a fait ce... Dans les discussions, ce qui était ressorti, qui nous a... Et beaucoup plus, c'était l'approche de découper le coup de l'art en deux parties. Une première semaine qui était vraiment consacrée à accompagner un peu la mise en production finale du cycle en se disant, si on met en prod, on a potentiellement parfois un peu du suivi, un peu de retour sur l'observabilité, des choses comme ça. Parfois, on a du support aussi, on en parlera tout à l'heure, à traiter. On fait toute la partie rétro, toute la partie betting, donc projection sur le cycle d'après.

8:36 Et après, la deuxième semaine, on donne une semaine aux ingés pour qu'ils fassent en gros ce qu'ils veulent. Alors, ce qu'ils veulent, c'est des sujets qui peuvent être suggérés par la plateforme, c'est des sujets qui peuvent être suggérés par les SRE, par n'importe qui en fait. Là, on est même en train d'essayer d'intégrer les sales pour qu'eux-mêmes puissent suggérer certains sujets à impact et voir si ça génère pareil, s'il y a de l'attractivité auprès des équipes. Là, il y a vraiment une phase de grande autonomie et de constitution des équipes. Et chacun va un peu pitcher, vendre son sujet. Voilà une approche d'organisation de cool-down. Je vous propose, c'est la deuxième question qui a été posée autour de tout ce qui était urgent. et j'ai rajouté les focus parce qu'on rentre sur un sujet qui est comment l'équipe gère-t-elle les bugs urgents de production.

9:39 Un principe qui est très fort en ShapeUp, c'est d'essayer de protéger au maximum l'équipe sur son cycle de six semaines, sur la phase de six semaines, donc sur le build. De la même manière, dans les discussions que j'ai pu avoir jusqu'à présent, un des éléments qui peut pousser fortement à aller vers ShapeUp, c'est se dire On n'arrive plus à avoir d'impact, on n'arrive pas à avoir assez d'impact. Il y a d'autres aspects de la méthode qui intéressent, mais la notion d'impact, souvent, elle est importante. Et en fait, pour avoir de l'impact, un des leviers, c'est de protéger l'équipe et d'essayer de la garder focus le plus possible. Sur ce qu'elle doit faire sur les six semaines. Sauf que le paradoxe, c'est que quand on a une vision globale, on aimerait que l'équipe soit capable d'avoir de l'impact sur un sujet donné et en même temps que les bugs urgents ou même toutes sortes de bugs puissent être traités le plus vite possible et la priorisation.

10:42 Et pas évidente entre, on va dire, des fois, je le vois chez nous, le support technique qui a du mal à avoir cette vision globale et qui va vouloir impacter très vite sur les retours qu'il peut avoir. On est souvent séduit par l'aspect focus et protection de l'équipe et impact qu'on pourrait avoir grâce à ShapeUp, mais en même temps, on veut répondre immédiatement aux bugs. Il y a un passage intéressant dans le livre sur Shape Up où Ryan Singer met en avant le fait que En fait, il n'y aurait pas tant de bugs si urgents que ça. En tout cas, pas tant de bugs qu'ils ne peuvent pas attendre six semaines. Moi, j'ai trouvé ça assez... La lecture, c'est un des éléments qui m'a paru un peu contre-intuitif. Je posais la question, je me suis dit qu'en tout cas, au moins, ça ne s'adaptait pas à toutes les entreprises. Et je n'étais pas sûr, par exemple, chez Welcome, que ça puisse prendre de se dire, en fait, on va essayer de protéger au maximum l'équipe pendant six semaines.

11:45 Ce qui fait que si un bug rentre une première semaine de build, on va peut-être donner une réponse au bout de huit semaines, puisque un cycle plus cool down, ça fait 6 plus 2, ça fait 8. En fait, l'expérience que j'en ai aujourd'hui, c'est qu'en effet, il n'y a pas tant de bugs qui nécessitent une action urgente, mais il en existe quand même. Et on a essayé, et je pense que c'est le cas dans pas mal d'entreprises, de distinguer des cas, des solutions différentes. Il y a plusieurs approches. La première approche, il y a des entreprises qui ont des support teams qui vont jouer ce rôle-là. Et donc, on se retrouve à découper d'un côté le build et le run. S'il y en a certains qui ont déjà expérimenté ça, ça existe.

12:46 Il n'y a pas besoin de shape-up pour expérimenter ce genre de méthode, d'approche. Avec tous les aspects positifs que ça peut avoir d'avoir une équipe spécialisée, hyper réactive, etc. Mais aussi... avec toute la déconnexion que ça peut générer entre une équipe qui build et qui, au fur et à mesure, va se déconnecter en plus de problématiques de run ou de l'impact qu'elle peut avoir. Et parfois aussi une lassitude des équipes qui sont en support permanent, parce qu'il faut aussi trouver les bons profils pour construire des équipes support, il y en a, mais je pense que ce ne sont pas des postes évidents. La deuxième approche que j'ai pu voir, c'est de s'appuyer énormément sur des staffs ingénieurs, en tout cas des ingénieurs transverses, peu importe la dénomination que vous leur donnez. Pareil, ça peut générer une charge mentale, une charge de travail importante. L'approche qu'on a mis en place, c'est d'avoir un système de firefighting.

13:49 Les équipes sont elles-mêmes responsables sur un domaine, sur plusieurs mission teams, plusieurs teams. Du support, de la maintenance liée aux produits qu'elles maintiennent ou qu'elles développent, et par rotation. Ce qui fait qu'aujourd'hui, par exemple, je prends vraiment l'exemple de ce qu'on fait dans les équipes que je gère, un ingénieur, il va se faire à peu près une semaine de firefighting sur huit semaines. Ce qui répartit quand même la charge, ce qui est une semaine en général un peu chargée pour les personnes qui se retrouvent à faire du firefighting. mais qui limite énormément le défocus du message qui tombe sur Slack et qui descoppe toute l'équipe avec un bug qui peut ne pas être qualifié. Après, tout ça pour poser un peu le cadre. C'est intéressant parce que ça développe un peu la multicompétence, mais par contre, ça nécessite énormément de cadrage, de communication pour assurer une montée en compétence sur une multiplicité de sujets.

14:58 Le firefighter chez nous a le droit à... d'aller questionner n'importe quelle personne ressource qui lui sera utile pour qualifier un bug et de le transmettre en accord avec la personne qui va le recevoir à une personne qui, elle, sera potentiellement, même parfois, plus à même de le traiter suivant la criticité du bug. Pour ce qui est vraiment top priorité, je crois que c'est comme dans n'importe quelle boîte, quand on est dans une situation de crise, on a un dispositif de crise où on va là dé-scoper beaucoup plus de monde, avoir un principal, un architecte, un SRE, une personne qui va pouvoir aussi communiquer auprès des clients qui sont impactés, etc. Donc là, le dispositif est complètement différent et quelque part, on accepte là facilement, si on a un produit qui est complètement planté, de défocus une équipe complètement le temps du traitement d'une urgence. Mais on distingue bien ces cas-là de...

16:02 Suivant la criticité et après on a au-dessus de la plus élevée, on a le cas nous des situations de crise et là on a un dispositif qui est complètement différent. Il faut espérer que ce ne soit pas le cas qui revienne régulièrement parce que là il y a un autre travail de fond à faire, il me semble, qui n'est pas du tout lié à la méthode. On a une troisième question. autour de la flexibilité. Comment gérer les changements de périmètre durant un cycle sans retarder la livraison? Alors, déjà, ce qui est bien, c'est que le fait de changer, de pivoter pendant un cycle, c'est quelque chose qui est très intégré à la méthode et qui répond, pareil, à un des principes du manifeste agile, l'adaptation au changement plutôt qu'à l'exécution d'un plan. Qui est une des quatre valeurs du manifeste.

17:05 Donc en ça, ShapeUp est vraiment une méthode agile. Vous verrez, c'est une question que vous retrouvez sur le net des fois, est-ce que ShapeUp est une méthode agile? Pour mettre en place chez EPOP, je pense qu'il faut vraiment investir beaucoup sur la communication. Et si ce n'est pas un point fort dans vos équipes, il faut se poser la question de comment vous allez pallier à ça ou comment vous allez accompagner vraiment les équipes fortement sur la partie communication. C'est déjà souvent ce qui grippe une organisation de manière générale. Je pense que l'insuffisance ou la mauvaise communication peut gripper n'importe quelle forme d'organisation. Mais alors, je trouve que c'est encore plus important en shape-up parce que Il faut se dire que quand on rentre dans un build, on n'a pas de specs détaillés en théorie. on essaye d'avoir, on va dire, un périmètre, d'avoir été, d'avoir potentiellement testé une partie de l'approche qu'on souhaite avoir, d'avoir été voir quel gros bloqueur on pourrait avoir.

18:18 Alors là-dessus, pareil, il y a différentes approches. Moi, j'ai vu vraiment des choses très cadrées, beaucoup moins cadrées, suivant l'implémentation qui est faite de ShapeUp. Mais pour moi, ce qui me semble essentiel, c'est que le produit design, ça dépend comment vous êtes, comment s'organiser les équipes, soit très fortement connecté aux équipes qui produisent pendant le build. Alors, c'est là où ça peut être compliqué puisqu'on fait un shape, c'est-à-dire la préparation du build en parallèle d'un build. Donc, on prépare le cycle d'après pendant qu'on produit le cycle qui a été shapé sur le cycle d'avant. Et on a très peu de rituels, il n'y a pas de ritualisation comme ça peut être par exemple en Scrum où on a quand même des rituels qui sont très décrits, des rituels qui sont fortement ritualisés, désolé pour l'heure. Pour la formulation. En ShapeUp, il n'y a pas ce cadrage-là.

19:19 Nous, aujourd'hui, le seul rituel imposé pendant les builds, c'est un weekly. On n'a plus de daily, on ne fait plus de stand-up. Pour la bonne et simple raison, raison qu'on a fait tout un travail d'accompagnement très très fort pour que les équipes se parlent beaucoup plus, pour qu'elles collaborent beaucoup mieux, pour qu'elles soient capables s'il faut de faire 5 meetings très courts de synchro dans la journée plutôt que d'attendre le stand-up du lendemain. l'unité de la journée et pas toujours l'unité temporelle dans laquelle on a besoin de se parler. Et donc, pour pousser un maximum, un maximum à faire des trade-offs, dans un sens comme dans l'autre. C'est-à-dire, alors, Bien sûr, souvent, on réduit un peu le scope, puisqu'on a cette habitude d'essayer d'en prendre toujours un maximum. Mais petit à petit, je vois que je me retrouve avec des équipes qui sont éduquées à collaborer différemment avec le produit. Et donc à faire vraiment ces échanges. Il y a un élément qui est fort en ShipeUp aussi, qui est rarement implémenté, mais qui pourtant apporte énormément de sens et répond à cette question aussi, c'est ce que Ryan Singer appelle le circuit breaker.

20:30 Qui en fait est de se dire si j'arrive en fin de cycle et qu'on n'a pas terminé, qu'on n'est pas capable de livrer à la date prévue, on jette. Ça en général, ça fait bondir beaucoup de gens parce qu'on se dit on ne va pas jeter six semaines de travail avec des équipes de trois à six ingés, ce n'est pas acceptable. Alors ça c'est la première définition un peu simple du circuit breaker. Reintinger dans le livre il en fait une deuxième un peu plus étoffée en expliquant que l'objectif c'est avant tout de faire peur. Un petit peu avec ce circuit breaker d'avoir cette espèce d'épée de Damoclès au-dessus de soi et de se dire il faut vraiment qu'on livre à date, il n'y a pas le choix en fait, on doit livrer à date. Donc pour livrer à date, il faut que parfois on fasse des trade-off. Malgré tout, quand il réexplique le circuit breaker, il explique qu'en fait, il ne faut pas que ça devienne une normalité. chaque fois dépassé, débordé sur le cool down.

21:32 Malgré tout, si on arrive en fin de cycle et qu'on se dit qu'on n'est pas capable de livrer à date, c'est révélateur d'une situation, d'un dysfonctionnement de l'équipe, et il faut le prendre vraiment au sérieux et se dire, si mon équipe dysfonctionne, qu'est-ce que je peux faire? Et en rétro, et même en cool down, on va prendre le temps de travailler pour que ça ne se reproduise pas. Par contre, qu'est-ce qu'on fait de ce qu'on a développé? Il nous reste un ou deux jours de dev à faire, on ne va pas le jeter. Par contre, si on se rend compte qu'on n'a pas réussi à dérisquer une partie du projet, c'est sûrement qu'il faudrait peut-être repasser en shape, et qu'on a mal défini ou on a un vrai problème dans l'approche globale qu'on a eue. Et là, peut-être qu'il vaut mieux tout jeter. Mais le principe de livraison à date, ça doit être une règle sur laquelle on ne transige pas. Il vaut mieux livrer moins et livrer à date, que les équipes puissent avoir leur coup d'arme, puissent souffler, etc. Et repartir sur un cycle dans de bonnes conditions. Le problème après, c'est qu'on crame les équipes et pour retrouver une situation un peu normale, c'est difficile. Et puis, on a aussi tendance à casser la confiance avec les équipes, ce qui n'aide pas.

22:36 Il y a un outil qui est intéressant pour ça, on en parlera après, c'est le Hill Chart. Le Hill Chart, c'est un outil de suivi et nous, ça nous permet vraiment de piloter et de voir justement, de ne pas rater ces moments forts pour s'assurer qu'on dérisque bien suffisamment tôt un cycle. Mais en tout cas, il faut se rappeler qu'on n'a pas de spec. de specs détaillés et donc on prend le temps de communiquer avec les parties prenantes, produits, design, 1G et tous les markets même des fois, on essaie d'intégrer un maximum de personnes pour pouvoir prendre les bonnes décisions et les prendre le plus possible. Quand on fait des cycles avec un seul pitch sur six semaines, On a, nous, ce qu'on a créé, on appelle ça des courbes de vélocité, on a des temps forts, on sait qu'à certains moments, il faut qu'on soit apte à prendre des décisions. Et maintenant, on expérimente ça sur des pitchs de 4 semaines dans un cycle, donc on a plusieurs pitchs. Et ça nous arrive de multiplier du coup, d'augmenter les points de synchro dans la semaine pour s'assurer qu'on a bien dérisqué suffisamment tôt.

23:45 Le pitch qui est en cours. On reparlera de l'Inchart tout à l'heure, mais qui est à mon sens un support vraiment super bien pour ça. Question 4, autour de l'appétit. Alors, ça se voit peut-être à ma tête, mais comment déterminer l'appétit pour un pitch? Le sujet de l'appétit qui paraît peut-être parfois une évidence. Au début, quand on le lit, c'est vraiment un sujet qui, je pense, n'est pas simple. Et dans les interviews que j'ai faites, ça reste souvent un sujet. La notion d'appétit. Donc, c'est quelque chose qui est assez fabuleux, moi, je trouve. On renverse complètement le paradigme autour de l'estimation. On se dit, on n'estime plus et on va se définir. Mettre un appétit autour d'un pitch. Alors l'appétit, moi la définition que j'en fais, c'est que c'est un budget. Un budget qu'on peut dire un budget temps. Ça vient bien sûr en contre-pied de la partie estimation.

24:49 Je pense que vous l'avez vécu, les estimations qui sont toujours incorrectes ou difficilement précises. On décale les livraisons. Donc, c'est souvent un échec d'estimer. Moi, j'aimais beaucoup la partie estimation, mais en effet, je me suis vite rendu compte que l'intérêt surtout d'estimer, en tout cas quand je faisais du Scrum, à mon sens, c'était surtout de générer de l'engagement de l'équipe. Il se retrouve en position de discuter de ce qui rentrait dans un sprint. Et si le rituel était bien drivé, ça générait à mon sens de l'engagement et de l'alignement. Mais alors la valeur de l'estimation derrière, un peu compliquée. Donc, l'appétit, moi, je le vois comme un budget. Si je me dis, j'ai 3 000 euros pour refaire une pièce, par exemple, je vais peut-être faire des choix. Je vais peut-être acheter un meuble sympa, très sympa, à 3 000 euros.

25:53 J'ai ça dans ma pièce, je suis content, ça change ma pièce. Je vais peut-être choisir de refaire la peinture, le sol. Je vais peut-être choisir de poser un parquet. Il peut y avoir différentes approches. Mais j'ai un budget de 3 000 euros, j'ai un budget de 3 000 euros. Si je n'ai pas plus, je n'ai pas plus. Quand on gère des équipes, le temps, on s'en fixe, mais on accepte largement de dépasser, combler le budget, etc. Là, l'approche, elle est vraiment ça. On se dit la contrainte, c'est le temps qu'on souhaite mettre sur un sujet. Alors, là où ça devient un peu abstrait, c'est que c'est le temps qu'on souhaite mettre sur un sujet. Mais c'est aussi le temps. que les équipes sont prêtes à mettre sur le sujet. Alors ça, ça dépend de l'approche qu'on peut en avoir. Et puis, ce qui rend les choses encore plus abstraites, c'est qu'un cadre au forfait, sa journée, elle est variable, mais même en sortant de ça, on n'est pas une chaîne de production automatisée. Les développeurs ne sont pas des machines qui ont une capacité de production constante, permanente, et

27:00 il y a juste besoin de faire des one-one pour les entretenir et continuer à avancer avec le rythme qu'on souhaite avoir. Il y a des semaines, une journée, je peux produire deux heures, et puis d'autres, je peux produire, je ne sais pas, dix heures. Il y a des meetings, il y a des jours, je me sens plus à même de traiter certains sujets. Il y a des journées où je teste un scénario, et puis au final, le scénario, c'est un échec, et je jette l'approche que j'avais pu avoir. Donc, on a parfois peut-être tendance à avoir une plus petite vélocité en début de cycle, et puis, moi, c'est un peu mon cas, et une vélocité un peu plus importante en fin de cycle. Donc tout ça, c'est des variables à prendre en compte, des congés, il y a beaucoup de facteurs qui peuvent impacter la vélocité d'une équipe. Et donc faire un calcul, c'est souvent pas évident. Donc dans certaines... Les implémentations de ShapeUp, il y en a qui, en effet, soit calculent une capacité, soit... mettre en place des calculs mathématiques un peu autour de l'appétit.

28:04 Ce qui n'est pas forcément l'approche standard, mais qui est une approche et qui peut rassurer. Ce n'est pas évident de mettre en place le concept d'appétit. Moi, j'avoue que là, chez Welcome, je pense que si on fait une réunion en tech manager sur l'appétit, je pense qu'on n'aura pas tous la même approche sur ce qui est réellement l'appétit. Et en plus, là où ça se corse, c'est qu'on s'engage sur un scope qui est flexible, sur lequel on va faire des trade-offs. Donc, moi, je vois l'appétit plutôt comme une forme d'engagement individuel, d'une part, mais aussi d'équipe. Et quand je dis d'équipe, c'est tech, produit, stakeholders, vraiment tout le monde de se dire, quand on fait la betting table, quand on valide ce qui va rentrer en build, se dire ok, on est en phase tous ensemble pour y aller et on est prêt à faire des concessions et on est prêt à y consacrer 2, 4, 6 semaines. Alors on y reviendra après, il y a des tailles. Et ça, c'est pas... Il y a une manière de quantifier parfois un peu l'appétit et ça, les approches sont aussi différentes.

29:12 Voilà. Il y a une contrepartie, c'est construire la confiance d'une équipe, etc. Il faut que tout le monde soit engagé là-dedans et même, je pense, aussi au niveau du top management et fortement au niveau des top managers produits tech. Parce que C'est sûr que le top management va avoir vite une envie de quantifier la pétine, de se rassurer en disant qu'est-ce qu'on va pouvoir sortir, etc. À mon sens, ça peut bloquer certains aspects qu'on peut mettre en place en shape-up. Et c'est sûr qu'il y a aussi des gens qui sont un peu démissionnaires qui vont se cacher derrière l'approche abstraite. Donc, généralement, on trouve un peu... Nous, on a trouvé quelque chose d'un peu médian pour rassurer. Mais ça, je pense que c'est vraiment un sujet qu'il ne faut pas laisser de côté quand on est en place shape-up et sur lequel... il me semble qu'il faut se réinterroger régulièrement, essayer de s'aligner régulièrement sur le sujet et se laisser la place de se dire, on peut tester, on peut itérer vraiment sur le sujet, tester des approches différentes et voir ce qui satisfait tout le monde.

30:15 J'ai eu la sensation que, par exemple, dans ce qu'on en a fait chez Welcome, au début, on était persuadé d'être tous alignés sur la notion d'appétit. Et en fait, ça a nécessité, et ça nécessite encore aujourd'hui, du temps à passer. L'approche qui peut être faite parfois, c'est petit batch, big batch, small batch, ou des appétits fixes, 2, 4, 6, etc. Donc voilà, à voir selon votre approche, mais c'est vraiment un sujet important à discuter. Dernière question sur la partie suivie. Oui? Je me permets de te couper, Baptiste. Je pense qu'on a encore quelques minutes, on a encore 10 minutes, parce qu'en fait, on finit à 9h30. Je ne me suis pas rendu compte que j'avais... Non, mais ne t'inquiète pas, je suis là pour ça. Ce que je te propose, c'est peut-être de... De prendre peut-être les questions, parce qu'il y a pas mal d'interactions sur le volet discussion, il y a notamment des questions. Je ne les ai pas, excusez-moi. Non, non, mais du coup, ça peut peut-être recouper avec la dernière question, et en fait, on peut prendre le temps là de réagir sur les questions et les interactions. Je vois que Fabrice, alors Fabrice, je ne sais pas si tu es parmi nous encore, si tu veux peut-être, je vois que tu avais posé des questions, si tu veux prendre la parole, ou en tout cas, si tu avais des feedbacks.

31:23 N'hésite pas à poser à Baptiste. Oui, bonjour. Vous m'entendez? Yes. Oui. Alors, les deux questions que j'ai mises au début, il y en avait une, c'était simplement quelles adaptations vous faites? Bon, là, Baptiste, tu as déjà abordé pas mal de sujets, mais comme quoi la durée des cycles peut être différente selon les entreprises, selon les moments, etc. Il y a peut-être d'autres adaptations encore auxquelles tu pourrais penser. Et une remarque qui m'a été faite aussi, c'est que pour certaines personnes, ShapeUp était plus adapté à des grosses équipes ou à des grosses structures. Moi, je l'ai vu fonctionner dans des équipes relativement petites, pas forcément très grosses. Mais en tout cas, on m'a opposé un petit peu ça, que ce n'était pas forcément idéal pour les petites équipes. Et souvent, les gens souhaitaient revenir à du Scrum ou des choses comme ça.

32:24 Voilà en gros les deux questions que j'avais posées. Est-ce que Baptiste, tu souhaites rebondir un peu dessus ou tu souhaites compléter ? Ou pas, je ne sais pas si Baptiste était parmi nous. On ne voit plus Baptiste. Ah si, il est là. Désolé, apparemment on m'a perdu, en effet j'ai eu un souci de connexion, excusez-moi. Désolé. Juste Fabrice, du coup sur ces deux questions, je ne sais pas si tu avais pu les voir et entendre un petit peu son feedback, si tu voulais peut-être compléter rapidement sur... Ça a coupé juste avant qu'il parle, je suis désolé, je n'ai pas entendu. Si quelqu'un peut s'intéresser, on va dire. Juste pour redire, c'est quelles adaptations tu vois ou que vous avez faites sur ShapeUp? Et puis, est-ce que tu as déjà vu ShapeUp bien adapté à des petites... Quelles adaptations on a fait ?

33:29 Il faut se dire qu'on fait des adaptations, c'est vraiment un premier point important. On a parlé de l'appétit, d'ailleurs j'ai vu la remarque de Marc là-dessus, et en effet, je pense que là déjà, il y a pas mal de choses qui sont faites. Nous, on a fait un choix pour le moment de faire d'abord que des cycles de 6 semaines et après de faire des cycles, d'accepter de faire du 6 ou du 2-4 pour essayer de cadrer un peu et que les équipes comprennent la vélocité. J'avais vraiment cette question-là de se dire qu'ils sentent vraiment quand un cycle se termine parce que je ne voulais absolument pas qu'ils mangent sur le cool-down. On a changé l'organisation des cool-downs, mais surtout, on ne fait pas de betting table au sens chez E-Pop, chez Welcome par exemple. On appelle ça des prix au comité. Et on a une approche assez différente où l'équipe a un gros travail de préparation avant et où elle pitch devant les stakeholders, les staffs, par exemple. Je parlais du circuit breaker tout à l'heure.

34:30 Le circuit breaker, ça a fait vraiment trop peur initialement. Donc, on l'a amené différemment parce que ça pouvait générer beaucoup d'inquiétudes. Sur la partie petites équipes, j'avais une mission team sur le cycle d'avant. j'avais deux devs et une personne au produit et une au design. plus une problématique d'équilibre entre ce que le produit pouvait amener côté shape, où ils avaient une énergie beaucoup trop débordante pour une équipe de deux devs. Donc, on avait plus ce problème d'équilibre. Par contre, ça n'a pas posé de soucis particuliers. Au contraire, ce qui était sympa, c'est que quand on a des équipes plus grosses, nous, on a une personne qui prend un peu le lead côté dev, qu'on appelle... Un tech owner parce qu'on n'a pas d'engineering manager en zone donc bref c'est aussi lié à notre organe mais et là les devs peuvent être impliqués sur les petites équipes tous ensemble donc

35:36 il y a un côté intéressant de ce point de vue là par contre en termes de défocus c'est un peu plus compliqué parce qu'il n'y a pas une personne qui peut protéger un peu plus les uns ou les autres sur un cycle Après, pour t'aider, je crois qu'il y avait Nicolas qui avait une question. Oui, sur le firefighting. Oui, je peux te la reposer à l'oral. Merci déjà, super instructif. Pour te donner un peu le contexte, nous, on est dans une phase où on a démarré la mise en place de ShapeUp début janvier. Donc on est encore au tout début, puis on l'amène progressivement, on met des briques au fur et à mesure dans les process et la manière dont on veut instaurer ou implémenter la méthode chez Pop en interne. Il y a un point que je me posais comme question, c'est le problème de gestion des problèmes de production, que ce soit des incidents, etc. Je voulais comprendre un petit peu mieux ce que tu mentionnais tout à l'heure.

36:37 Tu as un rôle de firefighter spécifique dans chacune des équipes. C'est-à-dire que chaque semaine, tu as une personne qui est dédiée au firefighting du scope de l'équipe. Comment ça se passe dans la réalité? Alors, les équipes sont regroupées en domaines. Ça, c'est quelque chose qui n'est pas encore tout à fait stabilisé chez Welcome, mais qui est encore en test et qui devrait être adapté sur la fin de l'année un petit peu. Mais on va toujours rester avec des regroupements d'équipes. Et ça, ça a été un gros changement de dynamique parce qu'avant, il y avait des squads qui travaillaient indépendamment et qui géraient leur scope de maintenance, etc. Là, on a mutualisé des scopes de maintenance avec des gens qui n'avaient pas forcément toutes les compétences. Donc ça, c'est un point qui est, nous, important parce qu'on a un fort enjeu de transfert de compétences, de connaissances. qu'on organise, je pourrais l'expliquer rapidement. Le firefighting peut aider aussi à ça. Le firefighting, ce qu'on fait, c'est que par domaine, on a une personne par semaine plus un suppléant. Le suppléant, c'est pour les... S'il y a une charge trop importante, et puis aussi parce que chez Welcome, on a la semaine de 4 jours, et donc on en a un qui est sur le vendredi et un sur le mercredi, pour s'assurer qu'on ait les 5 jours qui soient complets.

37:43 Et en effet, on a un planning, avec un chat unique pour le domaine, et chaque début de semaine, on a une personne qui... On change un alias sur Slack pour... Enfin, il y a une automatisation, mais pour s'assurer que les firefighters changent. Et le rôle principal du firefighter chez nous, c'est de faire de l'aiguillage. Il prend, il qualifie et il assure une relation de qualité avec le support tech en leur donnant des vrais délais. Donc ça, ça rassure tout le monde. C'est intéressant parce que j'ai eu le premier bilan sur le firefighting fin de semaine dernière avec le responsable tech support chez nous. Ils sont extrêmement contents, ce qui est trop bien pour nous, mais de la relation que ça a pu créer, de la dynamique que ça a pu créer, ils ont l'habitude d'avoir vraiment un interlocuteur privilégié qui répond très rapidement et d'avoir une qualification claire avec des sortes de Celle interne qu'on a fixées, suivant la criticité du bug, à se dire soit on traite dans la journée, soit on traite dans le build, soit sur les six prochaines semaines, soit on traite dans le cooldown. Alors, c'est des règles fortes, mais en vrai, après, il y a des difficultés qui se mettent en place et il y a du challenge, de la négo, des workarounds, etc.

38:48 Mais l'objectif principal... Chez nous pour le firefighting qui va, c'est de faire se dire tout ce qui peut être repoussé, tout ce qu'on peut enlever du build, on l'enlève. Donc les devs ont cet objectif-là de trouver des workarounds, de faire en sorte qu'il reste le plus focus possible, défocusé le moins possible les autres. Et du coup, je me permets de poser une autre question qui va dans ce sens-là. C'est-à-dire que vous avez créé ou tu as créé un framework d'aide à la décision sur... Est-ce que je traite ce problème-là soit dans le cool-down parce que c'est moins prioritaire? Comment vous aidez les ingés pour faire ces choix-là aujourd'hui? On a monté un decision tree. Alors moi, j'aime beaucoup les principes itératifs, donc qui est à la base ultra, enfin qui était, la première version était ultra basique, vraiment, oui, à l'âge, c'est peut-être moins, mais il y a un qui était ultra, ultra basique

39:55 et qu'on a, et qu'on fait évoluer au fur et à mesure, donc on a fixé des criticités avec des temps de traitement et qui nous permettent de rentrer. Donc, on a le critère de l'impact. Je suis coté? Non, on t'entend, merci. Je pense qu'il y a un petit... C'est revenu, je pense, mais je pense qu'il y avait un petit décalage de ton côté, Baptiste. Ok, du coup, vous avez la réponse, c'est bon? Oui, merci beaucoup. Je ne vais pas monopoliser toutes les questions. Je vais laisser la main à quelqu'un d'autre. Merci. Est-ce que peut-être une dernière question? Je vois qu'il est l'heure, mais peut-être en une minute, si quelqu'un a une dernière question, n'hésitez pas à vous manifester. En tout cas, c'est fait pour. On a déjà abordé pas mal de questions, mais... On peut prendre encore une minute de plus. Sinon, je pense que ça semble plutôt clair.

41:00 En tout cas, je pense que... N'hésitez pas à rejoindre le groupe. Si vous avez d'autres questions qui viennent pour pouvoir échanger, on va organiser un coffee dans pas longtemps. On pourra poursuivre ces échanges-là en coffee. N'hésitez pas, s'il y a des choses qui vous ont interpellé aussi après par message ou à me contacter, très hyper ouvert pour discuter ou continuer ces discussions en dehors. En tout cas, c'est un sujet qui me passionne. Et merci aussi pour votre participation. J'espère que c'était intéressant pour tous ceux qui étaient là. Merci à toi, merci beaucoup. Merci beaucoup Baptiste. Et en effet, on vous retrouve sur le Slack pour continuer les échanges sur le groupe. N'hésitez pas à vous manifester. Et si vous n'êtes pas encore sur le Slack, n'hésitez pas à me pinger directement. Et on se retrouve pour un prochain rendez-vous. Et puis d'ici là, on vous souhaite une bonne journée. Et à très vite.