Bruno:
Le changement, c'est comme une mise à jour de ton IDE. Tu sais que ça va t'apporter des nouveautés sympas, des optimisations, des bugs corrigés, mais tu sais aussi que ton extension préférée risque de ne plus marcher et que tu vas râler pendant au moins une bonne semaine. Mais alors, pourquoi changer quand ça marche ? Comment convaincre une équipe que ce nouveau process n'est pas juste une lubie managériale et surtout, comment éviter que la conduite du changement se transforme en conduite vers une sortie de route ? Pour répondre à ces questions d'évolution, je ne reçois pas Charles Darwin, mais il s'y connaît. En adaptation, Nazim, bonjour.
Nazim:
Bonjour Bruno, enchanté. Nazim, Engineering Manager chez Caros. Effectivement, je manage actuellement les équipes mobiles et web chez Caros. Effectivement, j'ai eu l'occasion dans ma carrière, avant de développeur, de subir un peu des changements et maintenant d'être un peu à l'initiative de certains changements. Et la phrase que tu as dit qui est importante c'est quand on, commence un changement dans une équipe c'est pas parce que on se fait chier en tant que manager et qu'on veut faire quelque chose c'est parce qu'on voit une problématique, et qu'on veut essayer d'améliorer surtout le quotidien des équipes parce que avant tout c'est notre rôle donc voilà.
Bruno:
C'est un très bon point que tu soulèves en tout cas on l'espère quand il y a un changement de process, d'outils. On parle ici de changements conséquents. On ne parle pas juste de petits changements qui sont menés ici et là. On parle vraiment de changements conséquents dans le travail quotidien d'une équipe. On espère qu'effectivement c'est mené parce qu'il y a un objectif réel et qu'il soit sain pour l'équipe. Mais comment est-ce que tu fais pour identifier que justement, il y a un besoin de changement ? Tu vois que la solution aller dans un changement aussi drastique et pas forcément dans juste je sais pas, d'apporter un nouvel outil ça peut être même aussi bête que peut-être changer juste les chaises de tout le monde comment tu fais pour identifier parce qu'il y a un risque fort quand même sur ce genre de changement qu'on peut faire oui.
Nazim:
En fait sur les changements bien sûr je pense que la majorité des changements qu'on fait dans les équipes c'est des choses mineures voire on va dire moyenne difficulté. Les changements drastiques, c'est vraiment quand il y a une problématique. Et il y a plusieurs choses. Première chose, c'est déjà... En tant qu'engineering manager, discuter avec les gens, voir un peu c'est quoi leur problématique, c'est quoi les pain points, et pas forcément que des devs, que des techs, voir aussi l'aspect business, qu'est-ce qui se passe côté business, est-ce que côté business ils pensent que la vélocité des équipes, en tout cas les livrables de visite de l'équipe, ne sont pas de qualité, soit ils sont à des intervalles assez longs, ou bien tout changement que demande le business est assez coûté au côté dev, toutes ces choses-là, et voir des KPI aller regarder la vélocité de l'équipe aller regarder. Comment se comportait l'outil logiciel sur un outil, est-ce qu'il est vraiment utilisé par les équipes ? Est-ce que l'outil nous permet de faire tout ce qu'on a envie de faire ? Moi je le vois je l'ai vu chez Caros, un outil qui a été choisi il y a 2-3 ans il était top à 2-3 ans mais maintenant avec la boîte qui grandit et l'équipe qui grandit, forcément ça change tout. Donc, vraiment aller comprendre les problématiques des gens et aller voir ça, appuyer ça avec vraiment des métriques essayer d'aller chercher des métriques qui correspondent à cette problématique pour voir est-ce que c'est juste du ressenti humain ou est-ce qu'il y a vraiment une problématique quelque part. Et derrière, faire comprendre aux équipes c'est quoi le problème qu'on veut résoudre, c'est très important et les faire participer à comment on va le résoudre.
Bruno:
Donc l'idée effectivement de cette discussion qu'on va avoir toi et moi pour l'ensemble des auditeurs c'est effectivement de s'intéresser à cette notion de conduite du changement et comment est-ce qu'on s'assure que ce changement se passe dans les meilleures conditions, pour essayer de s'appuyer sur quelque chose d'un peu concret et éviter les grands discours très très marketing est-ce que tu pourrais nous raconter un peu, des grands changements que t'as vécu ou que t'es en train de vivre aujourd'hui sur ton poste Ok.
Nazim:
Pour te prendre un exemple, on a une organisation d'équipe qui est un peu... On a une équipe mobile, qui comprend des dents mobiles, mais aussi des dents back-end. On a une équipe qui s'occupe un peu de nos sas, de manière générale, et on a une équipe qu'on appelle science, mais qui est plus sur l'intelligence artificielle et comment on matche de covoitureurs. Donc, carrosse, on fait du covoiturage domicile-travail au quotidien. Et des fois, on avait une problématique qui arrivait, c'est les sujets qui sont cross-équipe. Donc, on peut avoir un sujet qui est mobile, mais qui a en même temps de l'impact sur le SAS ou qui a un peu d'impact sur la science ou l'inverse. Et comment on arrive à faire ça ? Un des constats quand je suis arrivé, c'est que la majorité des projets qui sont cross-équipe sont pénibles à exécuter et sont souvent en retard ? Et du coup, la question, c'est comment on pourrait améliorer ça ? Donc, identifier la problématique, c'est très simple, parce qu'on a des sujets qu'on livre par quartier, et on voit les sujets qui sont en retard, et effectivement, les sujets qui sont croisés équipes sont souvent en retard, parce que la priorité de l'équipe A n'est pas forcément la priorité de l'équipe B.
Bruno:
Mais cette pénibilité que tu évoques, elle s'exprime comment ? C'est-à-dire que c'est que dans du retard de projet, où il y a d'autres trucs, il y a d'autres frictions qui sont générées ?
Nazim:
Les frictions, c'est une équipe A qui attend qu'une équipe B fasse quelque chose pour la débloquer. Sauf que cette équipe B, ce n'est pas du tout dans leur priorité. Donc, l'équipe A, soit elle attend, soit elle droppe son projet, soit elle change ou elle essaye de se débrouiller sans.
Bruno:
Ce qui est encore pire, c'est qu'en général, c'est fait de manière un peu cachée, un peu sale.
Nazim:
Donc voilà, ça peut être comme ça t'as des frustrations de personnes aussi qui ont des projets là et t'as aussi, des projets, c'est souvent des projets quand on arrive à des projets cross-équipe c'est souvent des projets à gros impact en termes de business etc donc ça peut aussi être des frustrations côté business parce que c'est quelque chose qui est attendu par nos clients qui est important et tout donc voilà c'est vraiment, essayer d'identifier ça et voir, si c'est un cas isolé ou est-ce que c'est quelque chose qui se répète avec les projets.
Bruno:
Donc face à une situation comme ça quel a été le changement que vous avez décidé d'opérer chez Caros ?
Nazim:
Le changement qu'on a essayé d'opérer c'est on est arrivé avec, une proposition une base de discussion avec les équipes cette base de discussion c'est de se dire ok on sait qu'on a cette problématique là cette problématique-là va de plus en plus se répéter parce qu'on aura de plus en plus de projets qui vont être cross-équipe, et de se dire, ok, est-ce qu'une des solutions, ça ne serait pas de se dire... L'autre problématique que j'avais oubliée dans les sujets cross-équipe, c'est que ton sujet, il est par exemple chez l'équipe mobile. Mais quand il y a une partie qui est chez une autre équipe, le PM de l'équipe mobile passe la main à l'autre PM. Donc, tu as un peu deux PM qui gèrent le même sujet. Donc, c'est un peu complexe parce qu'en termes d'ownership, tu n'as pas qu'une seule personne qui gère le sujet. Et donc ce qu'on a décidé de faire c'est de se dire ok on va essayer sur deux projets pilotes de créer ce qu'on appelle des squads temporaires, de dire ok on aura un seul PM qui lead le projet on va réunir tous les devs dont on a besoin, mobile, back-end, science etc. Au sein de la même équipe avec des stand-up comme une équipe normale régulier, on était parti sur des stand-up un jour sur deux et vraiment leur faire toute la partie, faciliter toute la partie synchronisation communication et avoir un seul ownership de ce produit là en termes de produit et pas je passe la main à l'autre et j'attends que l'autre fasse sa partie là, donc on a fait un pilote on est venu avec cette base, cette idée on a présenté, la problématique aux équipes, on a présenté la base de solutions qu'on voulait, l'idée c'était de récolter des feedbacks de l'équipe parce que eux ils sont quand même au quotidien dans ce sujet là et ajuster la solution avec les retours de l'équipe. Et du coup, une fois qu'on est arrivé avec un consensus qui nous semblait correct, on s'est dit, OK, on va prendre deux projets pilotes, on va tester dessus et on va faire une rétro à la fin de ces deux projets pour se dire, OK, est-ce que ça a fonctionné et du coup, on peut l'améliorer ? Est-ce que c'était vraiment la caca et du coup, on abandonne le sujet, on abandonne le truc plus tard ?
Bruno:
Pour essayer d'encore mieux comprendre le contexte dans lequel vous étiez, est-ce que tu peux nous préciser peut-être la taille des différentes équipes et ces deux équipes pilotes aussi après que du coup comment ça a été.
Nazim:
Ouais si je prends le sujet pilote c'était c'était une fonctionnalité qu'on devait faire pour certains clients donc, Caros, on fait du covoiturage domicile-travail, mais on fait du B2B 2T. Donc, il y a l'application que vous pouvez charger sur le store. Mais nous, on a des partenariats avec soit des territoires, par exemple, l'Ile-de-France ou des entreprises. Par exemple, il peut y avoir des entreprises, par exemple, Bosch en Allemagne ou autres, qui ont besoin. Ils sont un peu en extérieur. Ça les arrange d'avoir un système de covoiturage pour permettre à leurs employés de venir tous ensemble. Et donc on avait comme.
Bruno:
Ça les gens peuvent travailler aussi sur leur trajet.
Nazim:
Sur leur commute en plus entre collègues ça leur permet de faire connaissance ça leur permet d'économiser de l'argent il y a plein d'avantages pour eux et un des sujets qu'on devait faire c'était un sujet de gestion de parking, donc en gros certaines entreprises ont leur parking et les employés qui viennent, doivent réserver leur parking et comment s'assurer que la bonne personne est au bon parking, etc. Et elle est bien réservée. Et ce sujet implique deux équipes. Impliquer l'équipe qui s'occupe un peu de nos sas, donc le back-office pour les territoires ou les entreprises, parce qu'il faut définir le parking. Exactement, le configurer, combien de places, comment c'est disposé, etc. Et l'équipe mobile, parce qu'il faut bien que la personne réserve son parking. Et donc, sur ce sujet-là, on a actuellement les équipes mobiles donc l'équipe mobile il y a 4 développeurs mobiles, 2 devs back-end, 1 PM 1 designer et dans l'équipe SaaS il y a 3 développeurs back, 1 développeur front, 1 PM pareil.
Bruno:
1 designer Donc on a une quinzaine de personnes à peu près en tout sur l'équipe tech Exactement.
Nazim:
Et du coup ce qu'on a fait on a pris 1 développeur, back et front de l'équipe SaaS exactement on a pris un dev iOS un dev Android de l'équipe de l'équipe mobile plus le PM de l'équipe SaaS et on a regroupé tout ça plus le pour le coup les designers on a pris les deux parce qu'on a un designer qui est plus spécialisé sur le mobile et un qui est plus spécialisé sur le web on a regroupé tout ce monde là au sein de la même équipe pour se dire ok maintenant à partir de maintenant vous bosser ensemble jusqu'à, la livraison de ce projet et tous vos synchronisations, vos itérations, vos stand-up, etc. Vous essayez de les faire ensemble pour permettre un peu de fluidifier cette communication et fluidifier cette synchronisation. Donc, voilà. Est-ce que je te spoil sur comment ça s'est passé jusqu'au bout ?
Bruno:
En fait, avant ça, ce qui est quand même intéressant, c'est que, alors déjà, au final, ton prototype, ton test avec deux projets, en fait, du coup, ça a impacté 100% de l'équipe tech, parce que j'imagine que, par exemple les Wimfric tu nous indiques je pense que les deux squads c'était en fait l'ensemble de l'équipe mais juste organisé différemment ce qui est intéressant aussi c'est que, déjà cette période de test a impliqué tout le monde parce que ma question au début quand tu me disais on a fait deux projets pilotes moi ma question c'était qu'ouïe de ceux qui sont à côté et qui regardent leurs petits camarades, bosser avec une nouvelle méthode et qu'eux ils sont coincés dans l'ancien système c'est pas toujours agréable mais là du coup au moins eux ils étaient tous impliqués dans le champ.
Nazim:
Toutes les équipes étaient impliquées dans le pilote, mais pas tous les devs. Il y avait des devs qui n'ont pas été impliqués dans les pilotes parce que on n'avait pas besoin de telles compétences ou elles étaient comblées par exemple, si je te prends l'exemple toujours du parking, il y avait des développeurs back dans l'équipe mobile. Sauf que le projet était piloté par l'équipe SaaS et du coup les développeurs back-end qui ont fait ce projet-là étaient côté SaaS et les développeurs back-end côté mobile n'ont pas été impliqués dans ce projet-là.
Bruno:
Et aussi, en plus de tout ça, c'est que tu as un changement qui concerne un changement d'équipe, mais aussi un changement d'organisation. Et donc, j'imagine que c'est aussi un changement de process, donc de méthode de travail. Ça a dû quand même être assez lourd du jour au lendemain de passer d'une orga à une autre.
Nazim:
Hum... En tout cas, on ressentit pour les équipes, je pense que ce n'était pas facile au début. Ce qui facilitait les choses, c'est qu'on savait que c'était un changement temporaire, dans le sens que c'était pour livrer le projet. On n'était pas en train de faire un big bang de toute l'organisation pour tout le temps. Du coup, c'était vraiment pour livrer le projet et pour se dire, OK, je pense qu'on a parlé pas mal avec les équipes. Et ce qui était aussi compris par les équipes, c'est d'une, la problématique, qu'est-ce qu'on essaie de résoudre ? Et le truc, c'est de dire, OK, on sait tous que la pire des choses, c'est de rien faire. On sait que ça ne marche pas. Donc, essayons. Ça fonctionne. On va l'améliorer. Ça ne fonctionne pas. On revient en arrière. On n'aura pas perdu grand-chose. Donc, voilà.
Bruno:
Sur ce cas très particulier, je ne sais pas si ma question va s'appliquer à tous les contextes, mais sur ce cas très particulier, en fait, tu as une difficulté à faire fonctionner les équipes entre elles. Déjà il y aurait eu une solution qui aurait été de dire on va mettre en place un process pour que l'information circule mieux pour que les deadlines s'alignent tu peux dire aussi au niveau du management de s'assurer que les objectifs soient alignés quand il y a, une passation de projet d'un côté ou de l'autre mais aussi comment tu fais pour embarquer les équipes, parce que je ne dis pas que c'est le cas mais peut-être que dans les équipes il y en a certains qui disaient le problème ce n'est pas l'organisation globale Le problème c'est l'équipe B qui fait pas ce qu'on leur demande Quand on leur demande.
Nazim:
Oui En général il n'y a pas eu ce genre de remarques Mais c'est humain de dire Le problème c'est les autres et pas moi, Embarquer les équipes pour moi Il y a deux choses qui sont vraiment clés C'est faire comprendre ce qu'on est en train de résoudre Vraiment il faut que l'équipe ait conscience Parce.
Bruno:
Qu'on cherche à résoudre Parce qu'on.
Nazim:
Cherche à résoudre exactement, impliquer les gens, discuter avec les gens, les impliquer aussi dans la solution et essayer de prendre leur feedback en amont, mais aussi prendre leur feedback à la fin, leur dire ok, vous l'avez vécu, comment ça s'est passé ? Est-ce qu'il y a des choses qu'on garde ? Est-ce qu'il y a des choses qu'on enlève ? Et vraiment pour moi c'est ça. Et il y a aussi une partie qui est importante, c'est entre les deux, suivre les équipes. Être au quotidien avec eux, peut-être assister à leur stand-up pour voir comment ça fonctionne, voir un peu leurs problématiques est-ce qu'il y a quand même encore des soucis qui sont résiduels, est-ce qu'il y a des nouveaux soucis qui sortent, parce que quand on fait un changement peut-être qu'on résout des problèmes existants mais on en crée d'autres.
Bruno:
C'est même sûr.
Nazim:
C'est même sûr qu'on en crée d'autres voilà, est-ce que ce qu'on a créé est pire que ce qu'on avait résolu, ça c'est la vraie question qui fait que est-ce que ça fonctionne ou pas mais vraiment c'est pas je décide vous appliquer, c'est « Voilà ce que j'essaye de résoudre, aidez-moi à le résoudre.
Bruno:
» Et comment est-ce que tu accompagnes les équipes dans ce changement ? Parce qu'il y a eu un changement de paradigme de plus ou moins fort selon les individus, en plus, j'imagine, en tout cas, perçu comme étant plus ou moins fort par les individus. Comment tu fais pour les accompagner, pour qu'à un moment, le changement soit mené par eux-mêmes directement ? J'imagine que c'est peut-être aussi ça, l'objectif.
Nazim:
Dans tous les cas, une fois le changement mis en place, eux ils sont au quotidien c'est eux qui sont moteurs du changement donc c'est eux qui vont le vivre au quotidien et c'est eux qui vont aussi, le faire grandir entre guillemets moi ce que je fais c'est être présent au quotidien être présent lors des rituels des équipes, discuter aussi du sujet en one-on-one avec les équipes voir comment ils se sentent, est-ce qu'ils se sentent frustrés est-ce qu'ils voient des choses positives, des choses négatives comment on pourrait ajuster même en plein milieu les choses, négatives qu'ils peuvent voir Donc vraiment, montrer qu'on est là pour les aider et que s'il y a des problématiques qu'ils rencontrent autour, on est là aussi pour les débloquer et pour les aider au quotidien.
Bruno:
C'est peut-être une vision un peu naïve de ma part, mais de ma vision, quand tu passes d'une équipe back, une équipe mobile, à des équipes avec un projet précis, un objectif précis, je me dis que c'est peut-être aussi plus agréable. En tout cas, pour moi, en tant que développeur, je préfère avoir un périmètre métier, une problématique client à résoudre, plutôt que de me dire que je suis responsable du mobile. Et au final, c'est moins palpable, c'est moins concret d'une certaine manière. Donc, ça peut peut-être t'aider aussi à embarquer les gens dans ce changement-là.
Nazim:
Oui, clairement, je pense que ça peut aider parce que les équipes comprennent, ce qu'on veut, au-delà de la problématique pour laquelle on a fait le changement, elles comprennent ce qu'on veut résoudre pour le client. Ils sont impliqués dans les retours qu'on a eu des clients, ils sont impliqués dans la construction de la future, de comment on va le faire, comment on va résoudre, c'est quoi ce qui est possible de faire côté bac, côté mobile, etc. Donc, essayer vraiment aussi d'un point de vue produit, construire les choses avec eux et voilà tout ça fait que les équipes se sentent et je suis d'accord avec toi moi je préférais toujours avoir un objectif clair me dire ok, ton rôle c'est de livrer telle feature parce qu'elle est super importante que juste tu fais partie d'une grande équipe qui a plein de choses à faire.
Bruno:
Ouais est-ce qu'il y avait une ambition de passer sur ce qu'on appelle les feature team ou les impact team de donner une mission à chaque équipe et charge à eux de choisir ce qu'ils font pour mener cette mission ou il y avait quand même une vocation de se dire, il faut faire des équipes par projet et du coup pour chaque projet on fera un shuffle des équipes ?
Nazim:
Pour être honnête, l'idée nous a traversés mais je pense que c'était... Beaucoup trop de changements pour les équipes et d'une beaucoup trop de changements pour les équipes et de deux qui dit feature team dit beaucoup de personnes, l'équipe tech elle est quand même assez petite, je te prends un exemple on a deux développeurs Android si tu les sépares ils vont être un peu tout seuls chacun de leur côté pareil pour les développeurs iOS etc donc c'est vrai que dans la réflexion on s'est posé l'idée on s'est dit ok, vu la tête des équipes et vu les contraintes qu'on a je pense que la solution c'est de faire le truc intermédiaire de dire ok sur certaines features on a besoin de créer une squad pour livrer cette feature là et après tout le monde entre guillemets retourne à ses habitudes ok donc voilà.
Bruno:
Alors j'imagine qu'avant de se lancer dans ce test vous avez défini un ensemble d'indicateurs KPI on les appelle comme on veut pour vérifier comment est-ce qu'avançait le test est-ce que vous étiez défini des seuils où vous vous êtes dit si jamais on passe sous ce seuil là ou si on passe au dessus de celui là on arrête le test, tu vois freinage d'urgence et on roll back à ce que c'était avant.
Nazim:
En gros une fois que le projet est parti c'était très dur d'arrêter en plein milieu parce que t'as un PM qui est responsable du produit tu vas pas dire ok on enlève la partie mobile que t'avais et on va la remettre chez l'autre et l'autre il débarque de nulle part pour gérer cette partie là non non, on s'est pas dit freinage d'urgence mais on s'est dit qu'on acceptait de prendre le risque pour un projet qui va durer un mois et demi de dire que même, s'il y a des difficultés, à part si c'est la catastrophe mais s'il y a des difficultés on est capable de les encaisser au moins pour cette courte période.
Bruno:
Alors, comment s'est passé ce premier test ?
Nazim:
On a fait un peu un retour à des équipes. Effectivement, on a résolu des problèmes et créé d'autres. Donc, résolu des problèmes, ce qui était cool, c'est que je pense que tout le monde a été unanime que sur l'aspect communication entre les équipes et synchronisation, c'était beaucoup mieux. C'était très facile de parler avec les autres vu que tout le monde était réuni au sein de la même équipe, c'était plus facile à gérer d'avoir un seul PM qui lead le projet totalement et pas avoir deux PM par exemple ou deux trois PM qui jongle avec le contexte de chacun, ça c'était top, l'un des points négatifs c'est, on a créé des mini silos parce que si tu prends un dev Android et que tu le mets dans une équipe dans l'équipe parking par exemple, l'autre dev Android n'est pas au courant de tout ce qui se passe à part ce que lui dit entre guillemets son collègue et du coup c'est peut-être moins facile pour lui de faire de la review de code de tester la feature, de faire de la review de manière générale donc ça crée des mini silos à cet aspect là, donc on a entre guillemets cassé les silos entre les deux équipes mais on a créé des petits silos dans les équipes. Donc ça c'était un peu le point, on va dire, négatif, et de se dire est-ce qu'on est capable de résoudre cette problématique et de se dire est-ce qu'on est capable d'adapter cette solution en la gardant pour résoudre cette espèce de silo, entre components ou est-ce que, ça va être difficile ?
Bruno:
Et donc vous avez réussi à... Alors déjà on est d'accord qu'une fois que le test est terminé, donc déjà pendant la durée du test les autres équipes en fait étaient... Quasiment vidés de tous leurs constituants. D'une bonne partie des équipes, mais une fois que le projet est terminé, ils sont revenus dans leurs équipes. Et on a repris business as usual. C'est ça ? Du coup, l'idée, c'est de reproduire ça uniquement pour des projets transverses, ou en tout cas transverses aux deux équipes, où c'est maintenant de transformer ce changement-là. On a quelque chose d'un peu plus globale ?
Nazim:
Non, pour l'instant on garde ce changement-là pour les sujets transverses. On a vu qu'il y avait des choses qui fonctionnaient et maintenant on est sur, donc on a un nouveau quarter qui commence bientôt en octobre. Et donc l'idée c'est de dire, ok, comment on arrive à fluidifier cette partie-là de mon binôme, de composants, il est au courant de ce qu'il vient de faire et au moment de l'arrivée de code ou des tests ou autre il est capable de savoir pourquoi j'ai fait ça comme ça et pas pourquoi ça comme ça donc ça c'est des discussions qu'il faut avoir avec, vraiment les personnes techniques des équipes pour en discuter avec eux et voir un peu est-ce qu'eux ils ont des solutions ou des choses à proposer, malgré le fait que nous on peut venir avec des idées mais on va garder ça je pense que les tailles des équipes qu'on a ne nous permettent pas de faire ça à grand échec, Et attends.
Bruno:
Ma question m'a échappé C'était sur... Oui, est-ce que dans ce thèse, dans ce changement de manière travaillée, il y a eu des apprentissages que vous avez quand même répercuté après sur les deux équipes ? Je ne sais pas, des changements de méthode, passage de Scrum à Ducamban ou des choses comme ça, est-ce qu'il y a eu des...
Nazim:
Ce qui s'est passé, c'est, par exemple, ce qui peut se passer aussi, c'est les deux équipes ont des manières de fonctionner qui sont différentes. Par exemple, si tu prends les développeurs BAC qui sont côté SaaS, ils n'ont pas forcément l'habitude de bosser avec du mobile. Et donc, bosser avec du mobile, c'est un peu plus différent que de bosser avec du web, parce que le mobile a un peu plus de contraintes. Et du coup ce qu'on a appris c'est surtout comment arriver à à synchroniser, les équipes tech comment on arrive à créer des specs techniques qui font que les équipes s'entendent avant même que la paix soit prête comment on arrive à gérer tout ça, comment on arrive à caler des process des équipes qui sont... Parce qu'en fait ce qui était dur c'est on crée cette équipe temporaire, mais au moment où t'as tes tickets, sur le sujet du parking et que tu dois les refiner, les estimer les complexités, t'es obligé de te retourner vers ton binôme technique et ton binôme technique n'est pas dans ton équipe, et donc c'était aussi comment synchroniser des manières de fonctionner là pour le coup les deux équipes étaient en sprint donc c'était un peu moins difficile avec des dates de début qui étaient semblables sur les débuts des sprints donc c'était un peu compliqué, un peu plus facile de bosser ça. Mais il y avait des petits soucis de synchro ou de méthodologie qui étaient un peu différentes entre les deux équipes. Et donc, on se pose la question de, effectivement, est-ce que pour aider à cette organisation, est-ce qu'il ne faut pas vraiment unifier la manière dont bossent toutes les équipes pour qu'une fois qu'elles sont dans le bas ensemble, elles se reconnaissent dans cette manière de fonctionner ?
Bruno:
Et donc du coup aussi sur les fameux binôme tech encore une fois je sais que, on parle d'une équipe de 15 personnes sur plein de technos différentes quand même déjà mine de rien, c'est ce qui ne facilite pas aussi la chose, est-ce qu'il y a aussi la mise en place maintenant, de nomenclatures ou de méthodes de travail pour que les devs Android, fonctionnent de la même façon et que du coup quand ils ne sont pas côte à côte en fait il y a des réflexes qui font que ça casse le silo potentiel qui peut se créer quand il y a un changement par un nouveau projet qui arriverait ?
Nazim:
On encourage pas mal les devs à déjà, conconstruire avec leur binôme même s'il n'est pas, dans la squad conconstruire avec lui, réfléchir avec lui de comment je vais architecturer mon code comment je vais le découper, pourquoi je fais ça comme ça et pourquoi je ne fais pas ça comme ça et vraiment arriver à à la fin j'ai une spec technique qui a été validée par les deux binômes. Et se dire, OK, on est alignés tous les deux. Je peux moins aller, entre guillemets, coder ma future en étant rassuré que mon binôme comprend le contexte et il est d'accord avec ma façon de faire. Donc vraiment, améliorer cette synchronisation, je pense qu'il est important.
Bruno:
Est-ce que pour accompagner tous ces changements, il y a eu aussi des changements de techno, des changements d'outils ? À quel point vous avez tout bousculé ?
Nazim:
Changements de techno, non, il n'y en a pas eu. Changements d'outils, on en a fait un peu en amont, juste avant de faire ce changement-là. Chez Caros, avant, quand je suis arrivé, les équipes utilisaient Monday. C'est un outil de gestion de projet. Et cet outil-là ne correspondait plus aux besoins de l'équipe. Donc pareil, juste avant, on avait fait un changement d'outil. On est passé sur Jira, mais ce qui était bien dans ce changement d'outil, c'est que il a été décidé par les équipes. En gros, quand on a vu que cet outil ne correspondait plus, on s'est dit, ok, j'ai pris une personne côté produit, côté dev côté support, et je leur ai dit dans un monde idéal si demain on change d'outil, c'est quoi vos besoins, donnez-moi juste, listez-moi c'est quoi vos besoins et on a juste listé ses besoins, on a benchmarké les outils, on a créé des comptes de test, on leur a filé à tous, on leur a dit ok à la fin c'est quoi, avec quoi vous êtes le plus à l'aise et c'est comme ça qu'on a basculé sur Gira donc il y a eu un changement d'outils avant. Je pense que les équipes étaient habituées un peu. Mais il n'y a pas eu de gros big bang au-delà de l'organisation sur d'outils ou sur de la technologie.
Bruno:
Avec ces deux expériences, tu penses que qu'est-ce qui est le plus complexe ? C'est un changement d'organisation ou un changement d'outils ou de technologie ?
Nazim:
Le changement... En fait, il y a plusieurs choses. Le changement d'orga peut avoir l'impression d'être subi. C'est plus difficile, je pense, pour des devs. Et même moi, quand je l'ai vécu en tant que dev, parce que j'ai mon équipe, j'ai mon binôme, je m'entends très bien. J'ai l'impression qu'on me sort d'un truc où je suis bien vers un truc où je ne suis pas à l'aise. Et donc, je pense que c'est peut-être plus difficile à vivre. Et après, les changements de techno, Pour moi, il y a deux trucs. Des fois, les changements technos sont bienvenus. Par exemple, côté Android, j'ai connu le passage entre Java et Kotlin. Et il n'y a pas photo. On était tous heureux. Et par contre, quand je vois par exemple tout l'impact qu'il y a, c'est très dur pour beaucoup de gens. Côté dev, de se dire, mon métier, il est bouleversé vraiment. Et soit entre guillemets je l'accepte et j'embrasse, ce changement là et si je résiste est-ce que j'arriverai à résister longtemps à contre courant, donc en fait pour moi ça dépend, est-ce que le changement vraiment il est là que pour du positif mais les changements en tant que cas c'est beaucoup plus dur parce que on bouscule beaucoup les habitudes des.
Bruno:
Gens ce qui est intéressant ce que tu dis c'est que ce que j'entends aussi c'est que quand tu changes de techno l'exemple de Java à Kotlin est assez intéressant. Quand tu passes de Java à Kotlin ce que tu dis c'est que ton métier reste le même tu restes dev tu continues à le faire de la même façon, c'est juste que tu passes à une techno plus moderne, c'est comme si tu revends ta R25 pour te prendre une Mercedes, la comparaison peut-être pas idéale mais c'est l'idée c'est que tu passes un truc, c'est la même fonction tu conduis de la même façon ta voiture que ce soit une R25 ou une Mercedes c'est juste que le confort n'est pas tout à fait le même. Là où je vois qu'effectivement l'IA c'est un perturbateur pour plein de gens parce qu'en fait on ne sait pas ce que le métier va devenir on a l'impression qu'on nous, reprend notre métier en nous disant la machine le fait mieux et que du coup on ne sert plus à rien donc forcément il y a ce rejet un peu humain de dire j'accepte pas qu'on me rejette mais ce que j'entends aussi dans ce que tu évoques sur les changements d'organisation, c'est que t'as aussi une tu vois ça me fait penser un peu aussi au code review quand t'es plus jeune dans le métier de dev les premiers codes review on les vit mal parce qu'on se détache pas du code, on dit que si t'attaques mon code c'est moi que t'attaques en fait et tu vois moi j'imagine bien qu'effectivement quand tu dis, en plus toi tu es arrivé chez Caroz de ce que je comprends et tu leur dis quand vous avez un projet transverse ça marche pas, faut qu'on apprenne à bosser autrement en fait t'as des gens en sous-texte ce qu'ils peuvent comprendre, en fait il est en train de nous dire qu'on sait pas bosser correctement et qu'il va nous rapprendre à bosser donc t'as un espèce de jugement de valeur qui peut être perçu par les collaborateurs et même inconscient.
Nazim:
C'est humain t'as une nouvelle personne qui arrive dans n'importe quelle boîte et je l'ai vécue en tant que Thève, elle te dit ok ce truc là on va le changer on va l'améliorer, inconsciemment tu peux te dire mais pour qui il se prend lui et du coup oui effectivement tu peux avoir cet effet là c'est pour ça que je pense que comprendre la problématique et des fois ce qui est important, moi ça j'ai pris beaucoup de temps à le comprendre quand j'étais dev, quand j'étais dev au début pour moi là je suis en train de faire du code, je suis en train de m'éclater et tout l'aspect de je bosse pour un business au début ça m'intéressait pas beaucoup, je prenais mes tickets, je faisais mes trucs et tout. Et en fait, au final, je l'ai compris très tard. Maintenant, en tant que manager, je suis dedans. Et j'essaie de faire comprendre aux équipes. On est là pour une boîte. C'est sûr que notre métier, on l'aime et on s'éclate à le faire. Mais on est là pour aider une boîte. Donc, si ça fonctionne en interne dans l'équipe, mais que le business voit que pour lui, ça ne fonctionne pas parce qu'on ne délivre pas assez vite ou parce que tout changement coûte beaucoup, c'est que ça ne fonctionne pas, en fait. Donc voilà des fois moi j'ai pas mal de seniors dans les équipes donc ils le voient ce truc là et c'est plutôt cool mais moi perso j'ai pris beaucoup de temps avant j'étais vraiment dans ma bulle je suis développeur et je fais mes tâches.
Bruno:
Mais ça on le voit beaucoup effectivement les personnes un peu plus juniors dans ce métier là ils vont chercher à faire un bel algorithme, de faire un joli code et compagnie là où quand tu, quand tu gagnes effectivement un expérience si tu as envie de faire quelque chose qui répond à une problématique qui t'est posée, tu veux résoudre un problème pas juste faire un joli truc, parce que faire un joli truc ça ne te fait plaisir qu'à toi là où résoudre le problème de quelqu'un potentiellement tu changes l'avis de plusieurs personnes.
Nazim:
Plusieurs milliers de personnes.
Bruno:
Ou même plusieurs millions selon l'échelle de ton service.
Nazim:
Et je te prends un exemple simple et ça quand je suis arrivé chez Caros, l'équipe mobile était sur des cycles de 1 mois donc des sprints d'un mois avec une release à la fin du mois et en fonction des sprints la release était plus ou moins, on va dire tenue et ça c'était, l'équipe ça fonctionnait très bien en interne et je le comprends, l'équipe est petite et tout ça fonctionnait très bien en interne mais pour le business, livrer de la valeur chaque mois c'était pas bon du tout, donc au début on en a discuté pas mal avec l'équipe et je leur ai dit ok, là on a une problématique moi ce que je vous propose de ce que j'ai vécu de mon expérience de dev souvent c'était des cycles de deux semaines avec des releases chaque deux semaines. Quand je leur reposais, je leur dis, on peut prendre ça, on teste sur 3-4 cycles, et se dire, ok, à la fin, on fait un point, est-ce que c'est vraiment pas mal ? Pas du tout. Au début, les équipes étaient un peu en crainte, et c'est vraiment normal, parce qu'ils imaginent, tout le boulot, que c'est une réaliste côté mobile, il faut tester, il faut faire de la non-règ, il faut tester des fois sur plusieurs devices, plusieurs versions d'OS, et de se dire, ok, on doit faire tout ça chaque 15 jours, tu nous rajoutes un travail de fou. Et la seule réponse que j'avais leur donnée c'est testons, vraiment testons et se dire ok on fait un point à la fin vous me dites non on n'arrive pas à tenir le rythme pas de soucis et au final on a fait le point et l'équipe était contente, côté produit côté business c'était plus simple surtout ce qu'on a mis en place c'est dire ok, on met en place un espèce de release trade donc on a des dates de release fixes qui sont connues à l'avance par le produit et par le business, et c'est après au produit d'arriver à dire ok moi ça m'intéresse de target tel ou tel release qui sort le 15 septembre par exemple ou target tel release et on fera en sorte qu'on y arrive, et du coup si le projet n'est pas ready la release sort quand même parce qu'il y a toujours des bugs fix il y a toujours des petites améliorations, il y a toujours des choses, donc au début ça pouvait faire peur et je le conçois tout à fait moi j'aurais été dev à leur place je leur ai dit mais tu es en train de me rajouter une tonne de boulot on n'est pas beaucoup, qu'est-ce que tu es en train de faire, mais au final quand on a fait on va dire la mini discussion après une mini rétro, les équipes étaient plutôt contentes c'est sûr qu'il y a, un peu plus de charge et on est obligé de demander plus d'aide aussi à l'équipe produit pour tester etc, mais au final avoir ce rythme là c'est calé, on sait quand est-ce qu'on est en prod on sait comment c'est fait donc au final c'était c'était top.
Bruno:
On a parlé un tout petit peu d'IA et du changement que ça apporte sur le métier. Donc toi avec ces différents projets de changement que tu as déjà mis dans des équipes, comment est-ce que tu accompagnes l'ensemble des devs chez Carros pour, justement s'adapter à ce nouveau paradigme qui est en train de changer ? On ne sait pas encore dans quelle direction, il y a quel point ça va changer. Tout ce qu'on sait, c'est que c'est en train de changer. Comment tu fais pour accompagner quand justement t'as pas cette connaissance de où est-ce que tu veux aller.
Nazim:
Sauf si toi t'as.
Bruno:
La vision et tu sais où tu.
Nazim:
Veux aller je pense que personne ne sait où il y a il y a deux choses déjà une, on leur fournit les outils, avec mon sit-ion on leur dit ok vous avez besoin de tester l'outil cursor, cloud code, machin truc venez nous voir on vous donne des licences donc ça c'est vraiment fournir l'outil et pas tester parce que quand tu testes un outil en mode trial, tu n'es pas sûr que tu as toutes les features, tu n'es pas sûr que tu aies plein de capacités de vraiment tester l'outil. Fournir du temps, leur dire ok, nous, on admet en tant que manager que vous avez X de temps qu'on vous fournit pour faire des tests. Et si jamais ça impacte des projets et des projets qui sont en retard, pour cette raison-là, nous, on prend notre responsabilité.
Bruno:
Spécifiquement sur le fait de coder avec de l'IA. De prendre des tests.
Nazim:
Oui. De prendre du temps pour tester l'IA. Donc ça, c'est le premier truc. Et le deuxième truc, c'est je pense que ça, c'est important, c'est donner l'exemple. Moi, je j'ai testé du cursor je teste du cloud code, je fais mes retours à l'équipe je leur fais ok j'ai fait ça pour la génération de test ça a marché par contre quand j'ai testé pour créer une vue ça n'a pas très bien fonctionné et vraiment être aussi la première pour leur dire, moi aussi je sais pas où je vais mais je teste avec vous, je découvre avec vous je teste avec vous en tout cas n'ayez pas peur, allons-y tous ensemble, et du coup vraiment essayer de, on a entre guillemets créé un petit channel entre nous pour essayer de donner des feedbacks ok moi j'ai testé ça, dans ce contexte là ça a marché, ça m'a fait ça moi j'ai testé ça, dans ce contexte là ça a fonctionné ou bien j'ai testé, c'était la cata, et vraiment c'est ça en fait parce que c'est vraiment c'est un big bang du métier qui est un peu dur et je pense que c'est pas facile à vivre pour tout le monde, surtout. En fait, surtout, ça change ta façon de voir totalement les choses.
Bruno:
Et tu vois une adoption de ces outils-là au sein des équipes ? Est-ce que tu saurais dire, par exemple, la proportion de code aujourd'hui qui est générée, qui vous poussez en prod ?
Nazim:
Une proportion de code qui est générée ?
Bruno:
C'est tenté que tu le traques, je ne sais pas si c'est le cas.
Nazim:
Non, je ne peux pas le dire, mais je sais que, par exemple, sur des aspects, et c'est plus facile de faire adopter, l'IA sur des aspects qui sont un peu chiant pour nous les devs genre créer des tests, faire de la doc tous ces aspects là qui peuvent être un peu plus durs, on arrive à un peu plus s'adapter sur ça mais sur le coeur du métier c'est plus dur parce que j'ai l'impression que c'est la partie où les gens s'éclatent et en train de leur enlever leur plaisir et donc prendre la porte de dire ok pour les tâches qui sont un peu dures ou rébarbatifs ou chiantes une réfacto quelque chose ou utiliser l'IA ça vous fera quand même gagner du temps jusqu'à ce que les gens voient le potentiel je pense d'eux-mêmes pour se dire ok pour cette tâche là je vais utiliser l'IA mais, Pour l'instant, dire à une personne ou quelqu'un que tu codes une majorité ou une partie de ta figure en IA, c'est un peu complexe. Après, pour des tâches un peu chantes ou un peu dures, c'est plus facile de faire adopter comme ça.
Bruno:
Pour terminer, on est dans un métier où le changement est un peu inhérent à notre métier. Il y a des nouvelles technos qui sortent en permanence, il y a des nouveaux paradigmes qui sortent, des nouvelles manières de s'organiser. Effectivement l'IA générative qui bouscule encore une fois tout ça, donc le changement c'est une nécessité, on sait qu'on est dans un métier où si tu ne changes pas tu te scléroses et tu, deviens obsolète comment est-ce que toi tu fais pour que toi et tes équipes vous soyez dans un pour que ce changement devienne quelque chose de naturel, que ce soit un changement quasi perpétuel pour qu'en fait tu n'aies plus besoin de changer, parce qu'en fait tu t'adaptes en permanence et donc tu n'as pas besoin de points de rupture.
Nazim:
Il y a plusieurs trucs qui sont importants pour moi. C'est d'une part, avoir cet état d'esprit de se dire qu'on est capable de s'améliorer tout le temps. On est capable en termes de code, en termes de process, en termes de tout. On est capable de review. Quand j'ai de nouvelles personnes qui arrivent dans l'équipe, une première chose que je dis, vous arrivez avec un regard frais. Dites-nous tout. Et si vous voyez un truc qui ne fonctionne pas ou même vous vous posez la question « mais pourquoi ils font ça ? » Dis-le moi. Je veux le savoir parce que quand t'es dedans, tu vois pas forcément tout à part tes métriques que t'as, tes KPI, il y a des choses que tu vois, mais des fois il y a des choses qui peuvent paraître pas logiques, mais qu'on les fait quand même. Tu parlais à un moment de Dev Junior, première review, et pas prendre les choses personnellement. Moi, demain, je mets en place un outil, un process, et deux mois après, on me dit, ça ne fonctionne pas, on va le changer. Ça ne me dérange pas. Je ne vais pas dire non, c'est moi qui l'ai fait.
Bruno:
Oui, mais c'est aussi parce que tu as un certain âge, et tu as cette maturité de te dire, en fait, mon travail, c'est pas moi, et que si on critique mon travail, c'est pas moi qu'on attaque personnellement.
Nazim:
Mais j'essaye, en tout cas, je pense j'essaye d'être l'exemple de dire ok, sur toutes les choses qu'on a mis en place sur toutes les choses qu'on a construites ensemble il faut se remettre en question il faut se dire ok est-ce que c'est toujours le bon process est-ce que c'est toujours le bon outil est-ce que c'est toujours la bonne façon de fonctionner, et je pense que ça ça garde un esprit dans tous les cas on est dans un comme tu dis le monde de la tech bouge énormément en termes de techno en termes de tout et il faut qu'on garde cette aide à l'esprit parce que sinon on est vite perdu, moi je me rappelle je me garde toujours un souvenir quand j'ai commencé c'était peut-être une de mes premières expériences quand je suis sorti d'école et tout, je me rappelle les développeurs Flash c'était les rois du monde c'était, on cherchait tous des développeurs Flash, ils étaient super bien payés et du jour au lendemain t'as commencé il.
Bruno:
Y a longtemps alors.
Nazim:
2010-2011 il y en avait encore un peu il y avait un peu de, pas flash.
Bruno:
2007 c'est la sortie de l'iPhone.
Nazim:
Donc 2008.
Bruno:
Steve Jobs dès 2007 Steve Jobs dit qu'il n'y aura jamais de flash sur.
Nazim:
L'iPhone et donc flash a commencé à moi.
Bruno:
Je sais que flash en faisait en 2003.
Nazim:
Il y avait flash il y avait une autre techno, ah
Bruno:
Oui ils avaient essayé de sortir un truc.
Nazim:
Celle qui faisait la techno ils faisaient beaucoup sur Facebook des jeux je sais pas s'il y avait Flash il y avait un autre truc bref je me rappelle qu'il y avait je sais plus exactement, et du jour au lendemain ils sont tous devenus soit des devs mobiles soit des devs web soit des autres choses et des fois t'as des changements qui sont imposés bah l'IS c'est un peu un changement dans le même style où il est imposé on est vraiment on a pas le choix et on est obligé donc voilà le métier bouge beaucoup et du coup il faut garder cette tête d'esprit.
Bruno:
Clairement merci beaucoup Nazim pour cette discussion j'aurais deux dernières questions pour toi qui.
Nazim:
Sont les.
Bruno:
Questions rituelles du podcast la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditoristes.
Nazim:
Un contenu que j'ai envie de partager, J'ai un livre qui m'a beaucoup aidé. C'est les principes de Toltec. Je les ai lus, surtout quand j'ai commencé un peu le management, les accords de Toltec. Et ça aide, parce que dedans, il y a ce que vous me disiez, ne pas prendre les choses personnellement, par exemple. Et ça aide un peu à voir les choses un peu autrement.
Bruno:
Canon. Et dernière question qui est de loin la plus importante de ce podcast est-ce que tu es plutôt espace ou tabulation ?
Nazim:
Tabulation.
Bruno:
Merci beaucoup Nazim.
Nazim:
Merci à toi.
Bruno:
Et merci à tous d'avoir suivi cet épisode j'espère qu'on vous a donné quelques clés pour accompagner des changements, aussi structurants ou futiles soient-ils mais surtout qu'on est dans un métier qui bouge beaucoup et donc il faut rester souple sur les genoux comme on dit, il faut rester agile, il faut rester mobile parce qu'il faut s'adapter à ces différents changements. Il y a une énorme vague de transformation qui est en train de nous tomber dessus. Peut-être que ça fera un flop, peut-être que ça va être un tsunami, on ne sait pas encore. En tout cas, ça bouge beaucoup, donc il faut s'accrocher, il faut rester effectivement agile et tenir le cap. N'hésitez pas à contacter bien évidemment Nazim si vous voulez creuser un peu le sujet avec lui. Je vous remercie moi comme toujours de partager ce podcast autour de vous. N'hésitez pas à aller checker le Tipeee en description de cet épisode si vous voulez contribuer à ce podcast et l'aider à grandir. En tout cas, moi, je vous remercie beaucoup. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.
