Benoit Meunier, Mathieu Gandin
Transcription
Et on va vous présenter un retour d'expérience de transformation, de fusion d'équipes agiles dans un contexte de continuous delivery assez important.
Et à l'issue de ce talk, voici à peu près avec quoi vous allez repartir. Un retour d'expérience sur un changement organisationnel dans un contexte de continuous delivery. Les leçons tirées de ce changement et nos ressentis mutuels, Benoît en tant que Product Owner et moi en tant que Technical Leader de l'équipe sur laquelle le changement organisationnel a eu lieu.
Alors avant de démarrer, on va vous faire un petit peu de contexte.
C'est important parce que c'est les bases de quoi on part vers ces changements organisationnels qui ont été mis en place.
Donc lesfurets.com, ce site peut-être un peu corporate, on va aller vite, c'est un site de comparaison d'assurance. On a 5 produits d'assurance, auto, moto, santé, habitation, emprunteur, sur lequel chaque année on a environ 3 millions de devis. Et chaque tunnel de comparaison varie entre 40 et 200 questions à remplir. Donc c'est beaucoup de matière, d'éléments qu'on modifie au fil de l'eau. Justement pour pouvoir faire varier notre business et avoir le plus de... Ça marche le mieux possible.
On est organisé, notre delivery, on est organisé autour de 7 experts métiers, de 20-25 développeurs. Avec trois future teams. Une pour tout ce qui est acquisition de trafic, une pour convertir tout ce trafic en lead chez nous, C'est sur cette équipe-là qu'on va vous faire un retour d'expérience. Et une plutôt orientée infrastructure, donc gestion de la data et gestion de tout ce qui est DevOps, outillage DevOps. On travaille tous en tant que développeurs sur une seule base de code qui fait à peu près 500 000 lignes de code. Et on a du continuous ybri, on met en production le site des furets tous les jours, sauf le vendredi. Et donc du coup, on a de 1 à parfois 3 releases par jour. Et tout ça, c'est en feature branching. Donc tous les développeurs sont en train de cloner des branches et on se retrouve avec 20-30 branches en parallèle tous les jours en cours de développement.
Je termine. Tout ça n'est pas venu, Rome ne s'est pas fait en un seul jour.
On est parti d'une première base agile en 2012 qui était un Scrum mensuel avec une release de l'incrément à la fin du mois. Puis on est passé en 2013 à un Scrum Hebdo avec release une fois par semaine. Et enfin, Benoît et moi qui sommes arrivés entre 2014 et 2016, on a eu la chance de connaître les livraisons quotidiennes en flux tiré en camban qui nous amènent à environ 210-220 relis par an. Et on a des réflexions pour fluidifier, simplifier encore ces choses-là pour les prochaines années.
Voilà à peu près le cadre posé et on va vous expliquer un peu plus en détail ce qui s'est passé.
Ce qui nous intéresse vraiment aujourd'hui, c'est vraiment de vous faire part d'un retour de terrain. Je pense que sur une conférence comme celle qui se passe ici, Il y a souvent beaucoup de théories. Pour le coup, vous n'allez pas en avoir beaucoup avec nous. Ce qu'on vous propose, c'est plutôt de l'application, ce qu'on a fait, ce qu'on a vu, ce qu'on a pu appliquer, des théories qu'on a étudiées et qu'on a reçues également ici.
Et ça, c'est le point de départ. C'est ce qui s'est passé chez les Furets. On est parti de trois équipes. Alors, il y a d'autres équipes chez les Furets, mais on est parti de ces trois équipes-là. Vous avez une légende, je ne sais pas si les couleurs sont très visibles, mais vous avez en orange les business analysts, un par équipe. En bleu, des développeurs. Donc on est sur des petites équipes agiles. On a simplifié ici, mais c'est rarement plus que ça. Et vous avez en vert, alors il n'est pas très visible, mais il est sur la partie du milieu, le technical leader, en l'occurrence Mathieu, qui était sur l'une des équipes, alors que moi j'étais business analyst de cette équipe-là. Trois équipes. Qui fonctionnent toutes avec une culture, qui est une culture d'entreprise du Kanban. On a tous la théorie du Kanban, plus ou moins maîtrisée, mais globalement plutôt mûre sur le sujet, adoptée, comprise. Chaque équipe partage cette culture-là, mais a adopté son Kanban. Au fur et à mesure de ses propres... propres rétrospectives et de ses expériences, donc des méthodes un peu spécifiques à chaque équipe. Et puis chaque équipe a une thématique particulière, traite d'un sujet en particulier, la gestion de nos partenaires, donc des assureurs, des mutualistes, la manière dont on communique avec eux, dont on leur transmet les informations, toute la partie tunnel. Qui est les formulaires. Les formulaires, chez nous, c'est des formulaires de comparaison d'assurance. C'est souvent un peu long et il y a beaucoup de métiers derrière. Et puis, une troisième thématique est la souscription en ligne. Je ne vais pas rentrer plus que ça dans le détail. Qu'est-ce qui se passe à ce moment-là au niveau de l'ambiance des équipes? Chacun vit sa vie, tout le monde est content. On a trois équipes qui tournent et, a priori, pas besoin de changer. Sauf qu'arrive une demande, et ça c'est le point de départ de ce qu'on va vous présenter aujourd'hui, c'est que notre management nous dit que ces trois équipes-là traitent de différentes facettes d'un même sujet qui est la conversion, conversion au sens e-commerce, même si on n'est pas réellement un site de e-commerce. Donc on va fusionner ces équipes-là et ça va être beaucoup mieux.
Alors on l'a fait.
On a mis une équipe, mais on a continué de fonctionner avec les trois implémentations différentes du Camban.
Donc, on avait une équipe, l'équipe par exemple qui s'occupait des tunnels, on avait quoi? On avait un board sur Gira et un board physique sur lequel on faisait notre... stand-up.
On fait un peu de remote chez les Furets et du coup ceux qui étaient en remote c'était plutôt, je travaille sur cette feature là sur Slack et puis s'il y a besoin de problème vous me contactez sur Slack. On avait après notre propre type de rétrospective. Une autre équipe, par exemple celle qui est plutôt partenaire, on fait par exemple tout sur le board qui est sur Jira. Les stand-up surgira et ceux qui sont en remote, ils se mettent avec une webcam et ils participent virtuellement, enfin, remotely au stand-up. Et en plus, comme la partie des partenaires nécessite une interaction avec les partenaires, c'est tous les assureurs qu'on intègre sur notre site, nécessite donc une interaction avec des commerciaux et des chefs de projet chez les assureurs qu'on intègre, c'était pas mal de mettre les commerciaux en présence de stand-up pour qu'ils puissent se synchroniser correctement.
L'équipe de souscription en ligne avait aussi son propre mode de fonctionnement. Et donc, quand on a commencé à mélanger tout ça, ça ne marchait pas du tout. Du coup, très vite, c'était bof.
Et dans un premier temps, un grand coup d'étonnement qui est pourquoi faire ça? Finalement, ça marchait bien avant. Pourquoi ce changement organisationnel qui est aussi forcé? Et donc, résistance du changement, finalement, chacun s'est dit, en résistance du changement, puisque ça marchait, Et bien avant, autant continuer sur le même mode de fonctionnement qu'avant. Donc chaque spécificité de chaque équipe est restée finalement dans sa spécialisation. Donc moi qui étais du côté des équipes plutôt tunnel et donc avec des spécificités front, on s'est dit, on ne va pas toucher à ces vilains codes de back-end, ce n'est pas beau à voir.
De l'autre côté, ceux qui faisaient du back-end,« Oh là là, non, le front, c'est compliqué, je n'ai pas envie d'y aller, et puis le code est moche dedans. » Et puis, au final, il y avait quand même la perception de notre management qui avait voulu cette fusion d'équipes pour gérer toute la conversion. Qu'est-ce qui se passe? Ça n'avance pas assez vite.
Alors on a progressé, on a joué le jeu.
Donc on est passé à l'étape d'après. L'étape d'après, c'était de stopper un peu l'hypocrisie et de dire qu'on était une seule équipe, alors qu'on était en fait toujours trois équipes regroupées sous un seul nom, mais ça n'avait dans les faits pas changé grand-chose. Donc on a laissé la frustration, on va dire, à continuer à monter un peu de la part du management et puis de la part de l'équipe sur des incompréhensions jusqu'à un moment où c'était plus vraiment tenable. Et donc le déclic, ça a été de dire, bon, arrêtons ça et fusionnons nos rituels. On a commencé à se dire, il nous faut un seul stand-up. Donc il nous faut un seul board, donc il a fallu faire des choix aussi. Est-ce qu'on garde un board physique, un board gira pour permettre à ceux qui sont à distance de le consulter? C'était plus facilement des questions très terre-à-terre, pour le coup, très logistiques dans la gestion de l'équipe au quotidien. En tout cas, on a réussi à faire ça et on s'est retrouvés à faire des stand-up. Alors j'imagine que dans la salle, il y a des gens parmi vous qui en font, des stand-up agiles. En général, c'est agréable quand on est en petit comité, quand c'est rapide, quand c'est un peu discipliné, quand on commence à être 12, des fois 14, c'est un peu compliqué. Donc on a eu des stand-up qui n'étaient pas hyper efficaces. Le ressenti de l'équipe, bof, bof. Un camban énorme, des tonnes de tickets, des priorités floues, parce que trop de tickets, donc on ne sait plus lesquels faire. Finalement, par défaut, on revient sur ces comportements de base, à savoir que je vais prendre... Le sujet qui était mon sujet de prédilection avant. Donc on a fusionné nos rituels, mais on continue à fonctionner un peu pareil. On a une équipe qui est trop grande à ce stade-là, ça se sent, et on a des priorités qui sont difficiles à arbitrer au quotidien. Quel est le prochain ticket que je vais prendre? Et à côté de ça, on a une illusion au niveau de notre management qui dit« Ah, ça y est, ils ont enfin réussi à fusionner. Maintenant qu'on a une grande équipe, ça va aller beaucoup plus vite. » Sauf qu'en réalité, on n'a pas plus de monde qu'avant. Ils sont juste regroupés au même endroit. Et donc, il y a cette espèce d'incompréhension aussi où nous, on est toujours les pieds dans la boue et le management s'impatiente de plus en plus en ayant l'impression que parce qu'on est... Tous debout devant un board le matin, ça y est, ça fonctionne. Ce n'est pas le cas.
Alors, on a continué de réfléchir sur comment s'améliorer et finalement, on est arrivé à ce mode de fonctionnement qui est le mode de fonctionnement actuel.
Donc un des premiers éléments qui a été assez transformant dans l'équipe, ça a été la prise de conscience sur les différents rôles et responsabilités de l'équipe. Donc un des premiers, ça a été déjà que Benoît se positionne en tant que product owner de toute l'équipe conversion, alors qu'il était product owner d'une des sous-équipes. Et ça a l'air tout bête comme ça, mais ce n'était pas forcément très clair initialement. Et le fait de le clarifier a permis de fluidifier beaucoup plus, notamment les choix des priorités. Vu que nous sommes sur trois équipes qui sont maintenant rassemblées sur une seule, mais qui ont quand même trois grandes thématiques assez fortes, ces thématiques-là, on n'est pas arrivé à dire j'arrête une temporairement pour booster un peu plus une autre. Donc on continue d'avancer de front sur les trois thèmes. Donc l'intégration de nouveaux partenaires, modification des expériences front pour rendre les tunnels beaucoup plus simples à utiliser et optimiser les étapes finales de la souscription en ligne dans nos tunnels.
Et donc on s'est dit, en tant que développeur, nous, c'est bien de pouvoir se positionner sur n'importe quel des sujets. On a commencé à sortir... à se déspécialiser, en quelque sorte. Mais on s'est dit qu'on ne pouvait pas non plus l'imposer à tout le monde, parce qu'il y a des développeurs qui voulaient dire« Non, non, non, moi je veux rester sur mon sujet de prédilection, parce que, notamment sur l'intégration de partenaires, on a un développeur qui est là depuis 10 ans, qui connaît ça par cœur, et c'est son choix, il ne veut pas en changer. » Donc très bien, on ne va pas te mettre un pistolet sur la tempe, tu restes sur ton sujet de prédilection, et tu vas devenir l'expert, le référent des partenaires. Donc on va, d'une quelque sorte, donner beaucoup plus de responsabilités. Et tu vas travailler en binôme avec un business analyst qui travaille justement sur l'intégration des partenaires. Et tous les deux, vous allez aider l'équipe à... À fluidifier tout le flux de demandes qui nous arrive. Et c'est à vous de trouver des... Et les autres développeurs sont là pour t'aider, en fait, sur ces problématiques-là. On a fait pareil avec toutes les problématiques liées au tunnel.
Et aux problématiques liées à la souscription en ligne. Donc on a à chaque fois un binôme référent développeur, leader, tech sur la thématique avec un business analyst. Et les autres développeurs, moi en l'occurrence par exemple, j'en fais partie, on est dans un pool où on se réarrange en fonction des demandes sur chacune des trois sous-domaines.
Et donc on a lancé ça, et du coup ça va beaucoup mieux en fait. On est revenu à un état où l'équipe est glou. globalement contente.
Et globalement contente, pourquoi? Parce que ça fait finalement plus de sens. On a réussi au quotidien, vu qu'on était dans une phase assez compliquée, à quand même réfléchir sur comment on s'améliore et à trouver du sens dans toute cette affaire. Donc l'équipe s'est améliorée, elle a trouvé du sens et on a trouvé une organisation plus fit pour gérer l'ensemble de ces problématiques-là. Et du coup, on a commencé à dire à notre management, c'est bien, ça y est, on a stabilisé l'équipe, n'y touchez plus. Et du coup, maintenant, la perception du management, c'est bon, ça marche, on n'y touche plus maintenant.
Alors, voilà de manière assez factuelle ce qui s'est passé pendant un an chez nous, chez les Furets. On va un peu plus détailler ce qui s'est passé au sein de l'équipe.
Alors déjà, dans un premier temps, comment ça s'est passé pour l'équipe? On a eu peur du changement. Mais en même temps, à peu près tout le monde s'est dit« Ok, ça fait peur ce qui va se passer, mais on a quand même des choses à y gagner si on le fait. » Donc même si au début il y a eu une forme de réaction pour ne pas y aller, on s'est dit« Si on joue le jeu, on va apprendre des choses. » On va découvrir des nouveaux sujets, on va les apprendre. Et en plus, si jamais ça recommence... En tout cas, c'est une des choses que j'ai bien aimées avec tout. cette histoire-là, c'est que si jamais ça recommence, j'ai des billes, j'ai des choses, j'ai des idées pour le refaire d'une autre manière les autres fois. C'est au sein de l'équipe.
Alors déjà, dans un premier temps, comment ça s'est passé pour l'équipe? On a eu peur du changement. Mais en même temps, à peu près tout le monde s'est dit« Ok, ça fait peur ce qui va se passer, mais on a quand même des choses à y gagner si on le fait. » Donc même si au début, il y a eu une forme de réaction pour ne pas y aller,
on s'est dit, si on joue le jeu, on va apprendre des choses. On va découvrir des nouveaux sujets, on va les apprendre, et en plus, si jamais ça recommence, en tout cas, c'est une des choses que j'ai bien aimées avec toute cette histoire-là, c'est que si jamais ça recommence, j'ai des billes, j'ai des choses, j'ai des idées pour... Pour le refaire d'une autre manière les autres fois. Et une des premières leçons qui est à retenir, c'est, vu que c'est quand même à la base un changement organisationnel qui est poussé, forcé par nos managers,
il va y avoir de la résistance au changement. Et donc les changements, alors là j'ai remis un slide que je présentais déjà, il y a des anneaux en conférence agile, que j'avais repiqué un bouquin de Gérald Weinberg qui a été écrit il y a 30 ans, donc il n'y a rien de nouveau. Mais c'est important de s'en rappeler, c'est que quand on lance un changement, on ne passe pas d'un ancien statu quo à un nouveau statu quo directement. On est d'abord dans une phase qui est très chaotique, sur laquelle on va essayer... plein de choses qui marchent et qui ne marchent pas, jusqu'à trouver une idée transformatrice avant de lancer une étape d'apprentissage progressive qui va nous amener vers le nouvel état de changement. Et donc, en partant du postulat que ça va arriver quasiment tout le temps, que ce soit la façon dont vous allez changer l'ordre où vous rangez vos chaussettes et les gros changements organisationnels que vous pouvez faire dans votre grande entreprise, Soyez bien conscient du problème que vous voulez solutionner. Si vous êtes bien conscient de... Vous voulez changer pour solutionner un problème, que les managers, que les personnes de l'équipe en ont bien conscience, alors cette étape-là, qui peut, dans tous les cas, et c'est normal, soit un peu douloureuse, se passera mieux.
Et donc, on en a quand même tiré des bénéfices.
On en a tiré des bénéfices, et en réalité, c'est même les bénéfices que, je pense, le management avait projeté au moment de l'expression de cette demande de fusion d'équipe. C'est-à-dire qu'on a un sujet d'ensemble, qui est cette conversion sur un service full web, qui est adressé par une seule équipe, qui maîtrise toutes les facettes de cette problématique-là, et donc le sujet est bien mieux maîtrisé avec un objectif commun. Donc ça, c'est vraiment beaucoup mieux. Et puis, une visibilité accrue aussi sur le séquençement, la roadmap, et à la fois un niveau... Moyen terme ou long terme, et puis sur une base très quotidienne de comment on va séquencer les... Et pourquoi on fait ça plutôt que telle autre chose ? Ça, on y a vraiment gagné. Et puis, par ailleurs, une forme de résilience à la panne, c'est aussi la problématique des petites équipes qu'on avait avant. Quand on est une équipe où il y a un business analyst et trois personnes, il y en a un qui se casse une jambe ou plus un départ en congé, et l'équipe est assez vite en panne. Aujourd'hui, le fonctionnement de cette grande équipe avec ce pool de développeurs qui va venir finalement dynamiquement s'allouer sur différents sujets et donc qui s'infuse de ces différents sujets, au final, on est beaucoup plus résilient à la panne et on fonctionne beaucoup mieux et on peut lisser notre charge de travail de manière beaucoup plus efficace. Avec ce partage de connaissances.
Ce qui a bien marché lors de cette fusion d'équipes, et pour moi c'est un des points les plus importants, c'est que assez rapidement on s'est rendu compte que ça ne servait à rien d'aller forcer des solutions. Il valait mieux laisser les choses se faire, laisser les problèmes mûrir,
et les accueillir d'une certaine manière. Et c'est là où la clé, et c'est probablement la chose, en tout cas à titre personnel, je sais que Mathieu partage ce point de vue, la chose fondamentale, qu'on n'invente pas, Les rétrospectives en agilité, c'est quelque chose d'extrêmement difficile à faire, même si c'est simple sur le principe. Les maintenir et les rendre efficaces, c'est quelque chose de difficile, et je pense qu'on a réussi à faire ça. C'est-à-dire qu'on a tiré des rétrospectives et de l'engagement qu'on a réussi à mettre de la part de l'équipe dans cette rétrospective, la capacité... À recueillir les problèmes et à y porter des solutions, et donc à mettre en place progressivement, pas des solutions parachutées ou identifiées par un tel ou un tel, mais des solutions d'équipe par rapport à des problèmes identifiés par l'équipe, et donc à se placer dans une réelle dynamique d'amélioration continue. Et ça, c'est bon pour le moral, c'est bon pour le fonctionnement de l'équipe, mais c'est bon pour son moral aussi. Et c'est vraiment très agréable, au quotidien également, de sentir que chaque jour, les choses vont mieux qu'hier. Donc encore une fois, c'est... Presque une évidence, quoique en cambant, la rétrospective n'est pas forcément si évidente que ça. On va tout à l'heure zoomer un peu dessus.
Oui, pardon, j'oublie un point. C'était en partie le sujet du talk précédent. Mathieu et moi avons volontairement, mais assez naturellement également, adopté une position de servante leader, c'est-à-dire que
nous ne détenons aucune vérité, nous nous mettons juste au service de l'équipe pour soutenir, encourager les initiatives, dynamiser un peu les choses lorsqu'il y en a besoin, mais en tout cas, ce n'est pas nous qui avons porté des solutions aux problèmes. Au contraire, on s'est vraiment positionnés en tant que... manager, support sur un rôle vraiment de support de l'équipe.
Justement, la rétrospective, c'est une photo prise à l'issue d'une de nos rétrospectives. Ça ne va pas vous apprendre grand-chose, si ce n'est qu'elles n'ont rien de fantastique. C'est triste, vous venez peut-être ici pour voir des choses fantastiques, mais nos rétrospectives, elles ne le sont pas. Elles sont au contraire centrées sur l'essentiel.
On a une équipe nombreuse. On fait une rétrospective tous les 15 jours d'une durée d'une heure. Une heure à 12, encore une fois, on est entre 12 et 14 en fonction des moments. Une heure à 14 personnes, c'est compliqué de faire des jeux ou de varier un peu les rétrospectives, comme c'est souvent l'habitude, notamment en scrum. Nous, ce qu'on a fait, c'est qu'on a préservé ce rituel plutôt issu de Scrum sur le Kanban, et on l'a gardé dans sa forme la plus simple. Qu'est-ce qu'on doit continuer à faire? Qu'est-ce qu'on doit commencer à faire? Qu'est-ce qu'on doit arrêter de faire? Et quelles sont les idées qui ressortent? On commence par... Classiquement passer en revue les actions de la rétrospective précédente, puisque sinon ça ne sert à rien de prendre des actions si on ne s'assure pas qu'elles sont faites, et ensuite commence la vraie rétro. En quoi? 10 secondes, 30 secondes, on prend la température de l'équipe, vote à main levée, 5 je suis hyper content, 1 je suis à deux doigts de poser mes dèmes, Et ensuite, on fait un tour de table et on pose la question aux gens. Quand je dis« on», en fait, c'est l'animateur et l'animateur tourne, c'est jamais le même. Ce n'est ni Mathieu ni moi, c'est quelqu'un de l'équipe sur la base du volontariat. Qui va poser la question« Aujourd'hui, tu as mis 3, pourquoi tu as mis 3? Qu'est-ce qui s'est bien passé? Qu'est-ce qui s'est mal passé? » Et on se garde deux minutes de temps de parole chacun, ininterrompu. Personne ne rebondit sur personne pour avoir le temps de s'épanouir sur ce temps de parole-là. Et l'animateur note, c'est ce que vous avez vu sur la slide d'avant, note au fur et à mesure les points saillants de ce que va dire cette personne pendant deux minutes. Le tour de table se termine, il nous reste encore du temps, et ça ne manque pas, à chaque fois qu'on fait cette rétrospective, il y a des nébuleuses qui apparaissent de sujets récurrents. On va avoir trois ou quatre personnes qui cristallisent sur le même sujet. Et donc on va avoir deux ou trois problèmes principaux qui vont naturellement, le mot est important, remonter à la surface. Et donc on va faire le choix, sur le temps restant de la rétrospective, d'adresser ces deux ou trois sujets-là. En groupe, débat libre, il n'y a pas de cadrage particulier. On est aussi sur une équipe qui est assez... Les gens se connaissent bien, l'équipe est assez mature. Donc c'est à la fois discipliné et bienveillant. Donc ça, ça se passe très bien. Et donc on va chercher des solutions. On va surtout chercher à identifier le problème.
Et ensuite, une fois qu'on en a fait le tour, ou qu'on est à court de temps, puisque des fois le temps manque aussi, on va prendre des actions au sens... Pour ceux qui ont lu le livre Getting Things Done, c'est vraiment des actions... actionnable. C'est-à-dire, quelle est la plus petite chose, la moins engageante, la moins coûteuse qui va mettre l'équipe sur la voie de la résolution de ce problème? Et ça peut être tout simplement faire un mail comme c'est déjà arrivé, on constate tel problème, on n'a pas la capacité, nous, à le résoudre, on va faire un mail d'équipe signé du nom de l'équipe, adressé à notre management. Nous, équipe conversion, constatons tel problème.
Voyons que ça pose tel et tel souci de manière opérationnelle, proposons telle et telle solution, signé l'équipe conversion.
Et ensuite, on prend des actions, et la résultante, elle est celle que je disais tout à l'heure, c'est que,
c'est quasiment de l'ordre de la psychologie, ne serait-ce que la verbalisation et la capacité d'avoir un temps et un espace pour déverser ces frustrations, les exprimer, ou alors au contraire célébrer les choses qui se sont bien passées, Tout le monde en ressort plus léger avec le sentiment qu'on a la main sur notre destin, au moins en partie, ou en tout cas on peut remettre les responsabilités là où elles sont.
Je ne saurais mieux dire. Une chose importante, on a essayé de revenir au cœur même, ce qui est de...
Elles sont effectivement, comme a dit Benoît, pas très funky, mais elles sont au cœur même de ce que nous pensons être l'amélioration continue. Donc réfléchir ensemble, échanger, réfléchir ensemble et s'améliorer. Alors il y a des choses qui n'ont pas marché aussi. Normal. Une des premières choses a été de plaquer des solutions, effectivement, sans bien réfléchir aux problèmes. C'est ce qui s'est passé notamment au démarrage de l'équipe.
Je sais qu'avec, par exemple, une des PMO qui travaille chez les Furets, on a essayé de formaliser au début des ateliers pour définir un objectif d'équipe.
J'y croyais à moitié et finalement ça n'a pas bien marché parce que ça sert surtout à mettre les gens dans une pièce et effectivement ils vont prendre conscience qu'ils vont travailler ensemble. Mais au final, l'objectif qui va en sortir, il ne sert un peu à rien. Ce qui va vraiment construire un objectif d'équipe et qui va faire du sens dans l'équipe, ça va se faire de manière incrémentale au quotidien avec tout le monde. Et c'est tous les échanges qu'on a pu sortir, des rétrospectives, où là vraiment il y a eu une... Un sens commun, un sens de toute l'équipe qui s'est construite.
Une chose qui ne marche pas très bien, c'est que l'équipe, au final, est devenue très grande. On n'est plus dans une pizza team. On avait trois pizza teams au début, maintenant on a une grande équipe. Donc ça nécessite beaucoup plus de coordination en interne dans l'équipe.
Quand une personne n'est pas là, il faut essayer de reprendre son travail, ou quand elle va partir et qu'il faut passer le relais, ça nécessite un peu de coordination, et aussi une coordination avec les autres équipes. La résultante, c'est qu'on a fusionné. On a trois équipes et donc potentiellement, on a beaucoup plus de demandeurs de features qui arrivent. Donc ça nécessite, hors de... Aux frontières de l'équipe de s'organiser en termes de coordination. Donc ça demande beaucoup plus de temps que si on avait une petite équipe à 3-4 personnes sur un sujet particulier. Un des points qui est assez technique, mais on a la particularité chez les Furet d'avoir un front-end beaucoup plus complexe que les back-end. Et donc du coup, moi qui étais sur le front, si vous voulez les détails techniques, je passerai après sur les questions. Mais du coup, j'ai pu faire l'effort d'aller sur le bac après coup en me disant, tiens, ça va être intéressant, je vais apprendre des choses.
Et je me suis planté peut-être deux ou trois fois au début sur certains sujets, mais c'est normal dans une phase d'apprentissage. Mais après, ça allait globalement. Par contre, faire venir des personnes qui, ça faisait quelques années, qui étaient vraiment sur du bac, les faire revenir sur les sujets front, qui est assez complexe,
on n'y est pas arrivé. Là, c'est un exemple qui est lié à notre contexte, mais sachez que quand vous mélangez des équipes, il peut y avoir des sujets techniques beaucoup plus complexes que d'autres et qu'à partir du moment où on veut déspécialiser tous ces sujets, c'est compliqué. Et comme on est sur un delivery qui est assez tendu, je vous l'ai présenté au début, on est dans un continu delivery, on livre tous les jours, on a trois problématiques métiers fortes sur lesquelles ça rapporte quand même. C'est le cœur du business du site lesfurets.com. C'est compliqué d'organiser du temps d'apprentissage aussi fluide pour notamment embrasser toutes les complexités techniques qu'on peut avoir. Donc on n'y est pas bien arrivé. Et la tension entre le delivery et les formations partage de connaissances a par moments pesé sur notre équipe. Et alors qu'on avait des indicateurs, une pression qui nous demandait d'un peu de ramer avec des mains dans une barque, Benoît et moi, on était là à dire, attention, il y a des choses peut-être certes moins urgentes, mais tout aussi importantes, comme par exemple une rame et d'avancer.
Quelques exemples, notamment... Un exemple tout simple, technique, c'est qu'on a certains éléments dans notre base de code qui sont très manuels. Et on a réfléchi, pas complètement, mais en tout cas, il y en a quelques-uns qui ont été faits pour rendre ça le plus automatique possible.
Par exemple, quand vous recherchez une voiture sur le site desfurets.com, avant, c'était une tâche manuelle pour mettre à jour les voitures. Du coup, on a automatisé ça parce qu'on avait marre d'avoir un ticket qui arrive toutes les semaines. Un autre exemple, beaucoup plus organisationnel, on a eu un moment où un des commerciaux est arrivé avec 10, 15, 20 nouveaux partenaires. D'un coup, il me les faut pour dans un mois, puisque vous êtes capable d'intégrer un assureur dans un mois. Vous êtes à peu près 10, c'est bon, c'est plié. En plus, j'ai vendu tout ça à mes clients. What? Du coup, cette situation-là, qui est une situation complexe, a permis de prendre conscience, et il nous manquait un process un peu plus clair de priorisation des partenaires qui nous arrivent dessus. Et donc, comme on avait l'habitude de les traiter environ de 1 à 2 par mois de manière assez confortable, ça nous a poussé à nous remettre en question et à trouver un mode de priorisation plus adapté avec des phases où plein de nouveaux partenaires vont arriver chez nous. Donc on a un système de priorisation beaucoup plus clair. Donc c'est venu d'une rétrospective où on a commencé à dire de manière assez ouverte, ça ne va pas, ça ne va plus, il faut qu'on exprime. De mémoire, ça s'est fait avec un mail déjà de prise de conscience à tout management, des ateliers, beaucoup de discussions, jusqu'à arriver, Benoît et Damien, le business analyst, qui travaillent sur ces sujets-là, ont trouvé un système de priorisation beaucoup plus clair et explicite pour tout le monde. à deux par mois de manière assez confortable, ça nous a poussé à nous remettre en question et à trouver un mode de priorisation plus adapté avec des phases où plein de nouveaux partenaires vont arriver chez nous. Donc on a un système de priorisation beaucoup plus clair. Donc c'est venu d'une rétrospective où on a commencé à dire de manière assez ouverte, ça ne va pas, ça ne va plus, il faut qu'on exprime. De mémoire, ça s'est fait avec un mail déjà de prise de conscience à tout management, des ateliers, beaucoup de discussions, jusqu'à arriver, Benoît et Damien, le business analyst qui travaille sur ces sujets-là, ont trouvé un système de priorisation beaucoup plus clair. Et explicite pour tout le monde.
Qu'est-ce qui aurait pu être fait différemment ? C'est un peu délicat comme sujet. Cette liste-là, elle est issue d'entretiens que Mathieu a eus avec les personnes de l'équipe. C'est difficile de se dire si on avait fait de telle ou telle manière, ça aurait été mieux. En réalité, on n'en sait rien. Maintenant, ce qu'on se dit... c'est que les choses se sont probablement précipitées un peu et que vraisemblablement on y aurait gagné à observer un peu plus, à l'époque où on était trois équipes distinctes, comment chacune d'entre elles fonctionnait et pourquoi avec le temps elle avait abouti à tel ou tel fonctionnement. En général c'est soutenu par des raisons, ça ne se fait pas tout à fait par hasard. Et donc ce temps d'analyse-là, il n'a pas existé, clairement. Et je pense que ça, ça nous a freinés, en tout cas ça ne nous a pas aidés.
Du point de vue managérial, la communication en réalité a été effectuée principalement sur Mathieu et moi. Sans que nous-mêmes en comprenions exactement toute la profondeur de ce qu'ils attendaient de cette fusion-là. Et du coup, on pense qu'une communication plus claire et plus précise sur le pourquoi du comment, sur la genèse de cette fusion, aurait probablement aidé. Et les deux derniers points, c'est qu'on se dit, soit il aurait fallu limiter la taille de l'équipe, puisqu'on... qu'on est quand même au bord de l'exercice, ou alors se réorganiser plus dynamiquement autour de projets plus petits. Mais encore une fois, c'est difficile à évaluer.
D'un autre côté, ce qu'on se dit, c'est qu'on est peut-être en train de faire un pas vers quelque chose qui se murmure dans les couloirs chez les furets depuis longtemps. C'est la volonté de certains. On n'y est pas encore parvenu, mais finalement, ce qu'on a fait sur cette fusion de trois équipes, c'est déjà un premier pas, c'est de se dire qu'on abolit les équipes, on abolit les feature teams, on considère que tous les ingénieurs et tous les business analystes travaillent pour la même compagnie et font partie du même pool de gens qui travaillent sur des sujets d'évolution du service web. Et finalement, la recette qu'on a trouvée là d'avoir des référents à la fois fonctionnels et techniques, sur chaque sujet clairement identifié. Et après, tout le reste qui constitue une espèce de réserve de gens qui vont travailler sur tel ou tel sujet, on se pose la question, est-ce que ce n'est pas la prochaine étape, finalement, de retirer aussi les autres équipes qui sont chez les Furets, au niveau de l'acquisition du trafic ou au niveau de la data, et puis d'élargir ce qu'on a commencé au niveau de l'équipe conversion à toute la société. On en parle, on n'a pas commencé à le faire, mais on en parle.
un ressenti peut-être plus personnel maintenant sur la manière dont on a vu les choses et dont on se positionne maintenant en tant que respectivement technical leader pour Product Owner pour moi. Aujourd'hui, j'ai deux rôles. Je suis toujours business analyst sur la partie gestion des tunnels et de la comparaison en tant que telle. Donc ça, c'est une première chose. Mais là, c'est vraiment mon point de vue de Product Owner, c'est-à-dire sur l'ensemble de l'équipe conversion pour le coup.
Mes priorités vont clairement à permettre à l'équipe d'avancer. Donc c'est maintenir la roadmap à la fois moyen terme et à court terme, déterminer, aider à la priorisation à court terme. Ça veut dire aussi faire des arbitrages à la volée sur des sujets du quotidien, les petits blocages, si vous travaillez sur des services qui soient... Quel qu'il soit en fait, vous devez bien voir de quoi je parle, des petits arbitrages au quotidien, des petits obstacles sur la route de telle ou telle fonctionnalité ou telle ou telle conceptualisation, il y en a tout le temps. Donc ça c'est avant tout ce sur quoi je vais porter mon attention. Et puis d'un autre côté,
Ce n'est pas parce que j'ai un rôle fonctionnel que je dois être étanche. Il y a une quinzaine d'années, j'ai développé moi-même, donc j'ai aussi une certaine porosité aux problématiques techniques. Mais je me fais un devoir aussi d'entendre
les problématiques techniques remontées par l'équipe d'ingénieurs, pour les valoriser et les remonter, pour qu'elles fassent aussi partie intégrante de la vision produit. Je ne crois pas tellement à une roadmap produit d'un côté et une roadmap technique de l'autre. La meilleure manière qu'on ait trouvé aujourd'hui de fonctionner, c'est aussi d'arriver à mélanger les deux et d'aligner certaines features avec des blocs d'endettement technique ou d'outillage qu'il faut faire avancer par ailleurs. Je prends ça très à cœur. Et d'un autre côté, ce n'est pas parce qu'on est ingénieur ou développeur et qu'on fait principalement du code qu'on est insensible au produit. Donc il y a aussi des tas d'idées qui sont dans la tête des ingénieurs et dont on parle en rétrospective, de manière informelle en pause café ou de manière plus formelle sur des réunions d'équipe. Que je prends et que là aussi je vais utiliser pour nourrir la roadmap. Le dernier point, et qui n'est pas des moindres, on est dans un contexte, quelque part je pense que c'est une société qui s'est habituée à ce niveau d'agilité, à pouvoir aller vite. Quelque part, agilité par moment, ça donne l'impression que c'est devenu synonyme d'un peu n'importe quoi. C'est-à-dire que comme on peut tout faire très vite, On peut changer d'avis tout le temps. Et donc ça crée beaucoup de bruit. Et donc Mathieu, comme moi, on essaye de filtrer une partie de ce bruit-là pour faire en sorte que l'équipe travaille de la manière la plus sereine possible.
Voilà, effectivement. En tant que mon ressenti, en tant que technical leader, effectivement, l'idée, je vais me retrouver avec des tâches, on va dire, des tâches techniques et des tâches de management, de leadership. Je vais rebondir plus sur le leadership par rapport à la presse précédente. Et l'idée, c'est aussi effectivement... d'avoir un certain niveau de protection, pas complète non plus, mais au moins protégée de bruits qui seraient liés à des changements très radicaux de décision, pour laisser les ingénieurs travailler de manière la plus concentrée possible.
Ça fait deux ans que je suis dans la boîte, donc il y a des gens dans mon équipe qui ont beaucoup plus d'expérience sur le code existant. Et j'ai même des gens plus jeunes que moi qui sont sûrement plus brillants que moi techniquement. Donc je ne vais pas chercher à me mettre en expert technique systématiquement. Et je vais plutôt être là pour les écouter et leur proposer de l'aide. Et des fois, en leur posant quelques questions, ça peut aider à débloquer techniquement des choses, même si je n'ai pas apporté d'expertise. Et quand ça se passe, je suis assez content.
À travers ça, je suis technical leader, donc je n'en suis pas moins développeur. Et je fais la balance systématiquement entre ces tâches-là et des tâches qui sont des tâches de développement pur où j'ai besoin d'être concentré. Donc je vis au quotidien. Ce mouvement de balancier qui n'est pas forcément simple à gérer, mais je suis quelqu'un d'assez expérimenté, donc il faut aller vers ça, c'est intéressant. Et je considère même que si un technical leader ne prend pas le temps d'écrire du code, il doit revoir sa copie.
Et pour ça, je me réserve du temps. Donc mon agenda est bloqué par endroit. Les gens ne peuvent pas, dans la mesure du possible, me mettre de réunions ou de choses qui vont être interrompues, sur lesquelles je reste concentré sur des tâches de développement. Alors, je l'ai dit, j'essaie de mettre plus dans une posture de développeur senior, à peu près au même niveau que les autres développeurs. D'ailleurs, du coup, je ne me suis pas mis sur un pôle d'expertise métier dans les référents de l'équipe, mais plus dans le pool, avec pour objectif d'aller un peu partout dans le code. Et du coup, c'est très compliqué de prendre un sujet technique, de tacler des gros, gros sujets techniques de refactoring de fond où il faudrait tout casser. J'en ai fait quelques-uns, avec certains plus ou moins de succès que d'autres. Et je ne peux pas en attaquer plus d'un de front. Parce que sinon, je n'arriverais pas à les finir.
D'une certaine manière, le tech lead, ce n'est pas le plus mauvais développeur, mais c'est un développeur qui a de l'expérience et il n'y a pas besoin de se mettre à un niveau d'expertise, de se mettre la pression pour atteindre un niveau d'expertise. J'ai essayé, mais ce n'était pas une bonne idée. Et finalement, laisser les autres dans l'équipe, qu'ils soient plus ou moins jeunes, les prendre, c'est bien parce que, un, moi, ça me soulage, et deux, ça va leur donner en plus du... Powerment, pour sortir un mot un peu conférence agile.
Un petit wrap-up.
Du coup, nous, c'est les trois points avec lesquels on vous conseille de bien garder à l'idée. Bien identifier et communiquer les problèmes que vous voulez solutionner. C'est important. Si vous voulez lancer un grand changement organisationnel, nous, c'était fusionner des équipes, mais si vous voulez faire autre chose, casser une grosse équipe ou lancer des aspects un peu plus forts dans votre organisation,
Quel problème vous voulez corriger? Réfléchissez bien à ça et communiquez bien avec tous vos équipes, si vous êtes manager, vers l'équipe plus délivrée et vice-versa. La rétrospective, c'est primordial. Ça a été popularisé avec Scrum, ça existait bien avant Scrum, ou Extreme Programming. Kanban a fait péter l'esprit, fait péter une partie de la planification, mais on considère nous que c'est bien de garder toutes les deux semaines un rythme de rétrospective, même si on est dans un flux Kanban tiré avec du continuous delivery qui nous amène à livrer en production tous les jours. Et garder bien du temps pour de l'apprentissage. C'est-à-dire que vous allez délivrer, on va vous demander de continuer de délivrer comme avant, de changer complètement votre organisation. Donc peut-être que vous pouvez négocier ce qu'on aurait pu faire nous plus. On va un peu moins délivrer, encore un peu moins que quand on... Que peu qu'avant, et se garder plus de temps pour l'apprentissage, que ce soit auprès des experts métiers, parce qu'il y a des sujets à apprendre, que les développeurs.