Clément Rochas & Anis Chaabani - La mesure de la performance dans les équipes de dev @Scaleway

[00:00:02] Bonjour à tous. Merci d'être venu aussi nombreux. Apparemment, comme on est complet et que les portes sont fermées, on va pouvoir commencer plus tôt. Donc soit on finit plus tôt, soit vous avez plein de questions donc on en sera, on en sera ravi.
[00:00:17] Allez, tu peux lancer. Donc on est là pour vous parler aujourd'hui de mesure de la performance des équipes et puis surtout de ce qu'on a essayé de faire à partir d'un framework que vous avez peut-être entendu qui s'appelle Space et qui, je pense, vu le public d'avertis, doit être un petit peu connu mais surtout on va vous parler de la conduite du changement et de ce qu'on a pu faire pour arriver à à ce que ça ait vraiment lieu dans dans l'entreprise. Une petite fiction pour commencer, hein, c'est un ton humoristique. Euh, donc on a dans une dans une nouvelle boîte Agathe qui est CEO. Euh, elle gère une entreprise en pleine croissance. Euh les équipes ont beaucoup grossi récemment. Euh donc beaucoup d'investissement sur la masse salariale et elle aimerait bien maintenant savoir si cet investissement un ROI.
[00:01:13] Euh bon, elle connaît le dicton sur la parallélisation, les neuf femmes qui peuvent faire une femme un bébé, tout ça. Je vais pas je vais pas vous le refaire. Euh, elle est ingénieur donc bon, elle se dit que c'est pas si compliqué puis comme elle a codé un peu en général, elle se dit que ça pourrait être fait dans le weekend. C'est un biais assez connu. Euh faisons preuve d'un peu d'empathie aussi. Elle a plein plein de sujets autre que la tech dans son entreprise. Euh il y a des sujets euh bah par rapport au client, par rapport à la stratégie, elle a des actionnaires. Euh elle connaît bien la concurrence. Euh il y a des problèmes de régulation. Bref, son sa charge mentale, elle est elle est aussi peut-être plus élevée que nos petits cas de de gens de l'ingénierie très souvent. Euh, ça fait un an qu'elle demande du reporting et euh ça n'arrive pas. Elle a toujours pas la visibilité de est-ce que euh tous ces embauches, ça a apporté de la productivité. Elle en a un peu marre, bientôt c'est elle qui va compter les lignes de code et donc vous allez peut-être devoir dès lundi euh du coup euh compter combien de lignes de code vous produisez par semaine.
[00:02:25] Ensuite, on a Gordon. Gordon, il est engineering manager.
[00:02:29] Euh, lui, il est sur le terrain. Il sait que son équipe, elle travaille, il la voit travailler tous les jours et lui aussi, il mouille le maillot. Euh, il a même l'impression que ça travaille plus que de de raisonnable et que c'est pas c'est pas durable.
[00:02:46] Euh au sujet de la performance, pour lui, les blocages, c'est surtout des décisions qui sont faites en dehors de son équipe et souvent, c'est même plutôt des non-décisions qui le bloquent.
[00:03:00] Euh et puis surtout s'il a des objectifs de mesurer des choses qu'il comprend pas vraiment, il va le faire mais il donnera ce que les gens ont envie d'avoir. Ça sera pas forcément la la la réalité.
[00:03:15] Et puis on a un consultant qui vient d'arriver il y a pas longtemps, qui s'appelle Yves. Et lui, il a une mission qui vient directement de la direction. Il faut qu'il aille vite. Il aime bien réutiliser des templates ou des méthodes qu'il a déjà utilisées dans sa mission précédente.
[00:03:30] Euh, les équipes sont pas toujours disponibles le jour où lui il est disponible et il doit faire son son atelier. Donc ça crée aussi quelques quelques frictions. Et puis souvent, il a pas forcément le temps et des fois la compétence de comprendre quelles sont quel est le vrai contexte de l'équipe et pourquoi telle ou telle mesure euh ça fonctionne pas dans le dans son dans le cas de de l'équipe. Donc ça crée aussi potentiellement pas mal de frustration. Donc voilà trois personas. Ils ont tous des besoins par rapport à la mesure de la performance. Ils sont tous de bonne foi, on peut pas douter de de ça. Mais par contre, ça va être compliqué de les aligner et de faire que tout le monde ait envie de faire quelque chose qui serve du coup à la fois à eux et à l'entreprise. Et on va surtout se concentrer sur le fait que l'engineering manager et son équipe arrive à mesurer des choses qui leur permettent de s'améliorer ou de demander de l'aide de façon de façon efficace.
[00:04:30] Ça c'est une autre slide. Euh je m'appelle Clément Rochard, je suis euh chez Scaleway depuis euh 6 ans maintenant.
[00:04:40] Et voici. Et je m'appelle Anice Yabani, je suis coach agile chez Scaleway également depuis euh 2 ans à peu près. Non et je m'occupe entre autres aussi d'un programme de recrutement et d'onboarding de junior, qui est super cool. Si ça vous intéresse, on pourra en parler après la conf.
[00:05:00] Euh, un petit mot sur euh sur Scaleway. Donc Scaleway est un cloud provider français. Euh, on a nos propres data center en France avec du droit français. Euh et euh on développe une proposition de de cloud provider, donc de de d'instance et de service managé euh euh qui est faite en France et à Paris, à Lille et euh en en remote en en métropole.
[00:05:30] Juste pour rajouter euh pour le contexte de de ce qu'on va parler aujourd'hui. Euh on a à peu près une quarantaine d'équipes euh de développement chez Scaleway entre 5 et 10 personnes par équipe. Euh elles sont toutes gérées par des engineering manager donc qui sont managers de proximité euh dans ces équipes et on a grosso modo euh c'est 40 équipes qui sont découpées en tribe d'une cinquantaine de personnes qui se veut le plus autonome possible euh pour faire ses actions. Donc des méta équipes d'une cinquantaine de personnes autonome et dedans des équipes euh et une quarantaine d'équipes en tout.
[00:06:12] Et donc on va parler aujourd'hui de productivité des équipes de développement, comme vous l'avez compris. Donc on va commencer par un petit mot sur la productivité. Euh donc c'est la contribution d'un ou plusieurs facteurs de production. Donc il s'agit d'identifier ces facteurs de production. Euh la productivité, généralement quand on parle de productivité, on parle de rendement, d'efficacité, d'efficience. Euh c'est la mesure aussi de l'impact des actions euh humaines. Euh donc quand il s'agit d'un certain secteur, par exemple, fabriquer des pantalons, on peut facilement presque, en tout cas, on a les moyens de mesurer une productivité en sachant combien de pantalons par jour, par exemple, on va on va fabriquer. Euh par contre, quand il s'agit de développement de logiciel, c'est un peu plus compliqué. Donc euh on a déjà tenté des solutions dans le passé, mesurer le nombre de lignes de code euh les points de fonction pour ceux qui ont connu ça euh de ce qui est euh Commo et compagnie ont essayé de mesurer des choses. Voilà, donc ça n'a jamais été vraiment satisfaisant pour les gens qui ont vraiment essayé de faire ça. Euh donc l'idée aujourd'hui, c'est de tester autre chose, de voir d'autres alternatives à ces méthodes.
[00:07:31] Donc euh nous, quand on a commencé à s'intéresser à ce sujet-là, de façon assez logique, on s'est orienté vers Dora. Dora, donc pour ceux qui ne connaissent pas, donc ça a été évoqué la première fois dans le livre Accelerate qui parle de DevOps qui est un une recherche en fait menée par Nicole Forsgren avec d'autres chercheurs. Euh et donc Dora, c'est une façon, un framework de mesure de la performance des équipes à travers quatre métriques principales, donc sur deux axes. Donc un axe de vélocité, les deux métriques sont la fréquence des déploiements et le lead time for change ou le temps entre la première fois qu'on commence à pousser du code, donc à commis du code et le temps que ça arrive en prod. Euh pour la stabilité et le pourcentage de failure suite à un changement. Donc suite à un problème grave suite à un changement. Euh et le temps nécessaire pour recovery une fois qu'on a un problème en prod. Et donc voilà, la vélocité plus la stabilité, ça nous donne une bonne indication sur la performance des équipes. Ce qui va être intéressant, c'est que à partir de là, ils ont continué à faire ces études-là via des assessments euh avec des équipes, plusieurs équipes dans plusieurs boîtes différentes. Et ils vont publier régulièrement donc des rapports qui s'appellent les State of DevOps Reports. Le dernier en date, c'est celui de 2023. Et ils vont classer ces équipes donc euh selon le barème qui est là. Donc élite, high, médium, low. Avec pour chaque niveau, donc voilà, fréquence de déploiement pour élite, ça va être à la demande, le change lead time, ça va être inférieur à 1 jour et cetera. Et ce qui va être intéressant ici, c'est que vous aussi, vous pouvez mesurer donc ces indicateurs là et vous positionner par rapport à ces équipes là. Avec à chaque fois des mises à jour et cetera, c'est régulier.
[00:09:39] Et donc euh à partir de là, on a continué à suivre les travaux de Nicole Forsgren principalement.
[00:09:47] Et ça nous a amené au framework Space. Donc c'est quoi le framework Space ? C'est un article qui a été publié en 2021 par encore une fois des chercheurs, dont Nicole Forsgren euh et qui dit que on peut aller plus loin, en fait suite à Dora, c'est un peu la continuité des recherches qu'ils ont commencé sur sur Dora. Euh en utilisant donc euh une vision un peu plus globale, donc en voyant les choses à partir d'un scope un peu plus plus global et plus large. Donc il commence d'abord par parler de quelques mythes quand on essaie de mesurer la productivité. Le premier, c'est que la productivité dépend entièrement de l'activité des développeurs. Généralement, c'est pas le cas, c'est rarement le cas. Euh, deuxième mythe, c'est que la productivité dépend uniquement de la performance individuelle, c'est-à-dire que la performance, c'est la somme de la performance des individus dans une équipe. C'est clairement pas le cas aussi parce qu'il y a beaucoup d'autres facteurs.
[00:10:54] Euh, troisième mythe, c'est qu'une seule métrique de productivité peut tout nous dire.
[00:10:59] Genre le nombre de lignes de code.
[00:11:02] On sait bien que ça n'a pas marché dans le passé. Euh, quatrième mythe, c'est que les mesures de productivité ne sont utiles que pour les managers.
[00:11:10] Alors que les premiers concernés normalement, c'est les développeurs eux-mêmes. Et finalement que la productivité dépend uniquement des systèmes d'ingénierie, donc de de l'outillage des développeurs. Donc si on donne un meilleur outillage aux développeurs, ils seront plus productifs. C'est pas suffisant.
[00:11:30] Et donc Space c'est quoi finalement, c'est quoi la proposition de valeur ? Donc c'est un moyen pour réfléchir plus rationnellement à la productivité des des développeurs, pour choisir euh de façon un peu plus soigneuse les mesures, de façon à donc avoir leurs limites et surtout à les mettre dans un contexte et de voir quand on est dans le cas d'un contexte, il la propriété.
[00:12:02] Donc plus concrètement, euh ce que ça nous apporte ce framework là, donc ça va être trois niveaux et cinq dimensions. Les dimensions, donc ça va être de mesurer cette performance sur un axe individuel. Donc un développeur. Le deuxième axe ou niveau, ça va être le groupe ou l'équipe et le troisième, ça va être le système, c'est-à-dire plusieurs groupes qui vont travailler ensemble pour délivrer un produit de bout en bout. Les cinq dimensions, donc ça va être euh les acronymes de Space en fait. Donc le premier, c'est la satisfaction et le bien-être. Le deuxième, c'est la performance, l'activité, la communication et l'efficacité du flow.
[00:12:50] Quelques exemples de métrique, si on se concentre uniquement sur les dimensions. Euh pour la satisfaction et le bien-être, donc ça va être le par exemple, la satisfaction des développeurs via des surveilles par exemple. Ça va être le turnover ou la rétention. La satisfaction avec les code reviews, euh la satisfaction avec l'outillage, le système d'ingénierie et cetera. On peut voir aussi que euh Dora fait partie en fait de Space. Puisque c'est des métriques qu'on peut classer selon ces cinq axes.
[00:13:29] Je vous laisse voir un peu plus de métrique. Par exemple dans l'efficacité et le flow, on peut retrouver tout ce qui est interruption, le temps des interruptions, les flows, la vélocité des flows, le temps nécessaire à des code review et cetera. Donc ce qui est à retenir ici, c'est que il faut prendre des mesures sur plusieurs axes. Et non pas qu'un seul.
[00:13:56] D'ailleurs Space nous dit qu'il faut prendre des mesures sur au moins trois de ces dimensions.
[00:14:08] Donc voilà, c'est une proposition. Non c'est bon. Donc voilà, c'est une proposition qui a été faite par un article initialement. Donc maintenant, on va falloir voir comment mettre ça en pratique. Et donc on a essayé de faire ça chez Scaleway depuis maintenant un peu plus d'un an. Ça fait à peu près un an.
[00:14:31] Et donc euh quel était notre besoin en fait ? Pourquoi est-ce qu'on voulait mesurer cette productivité chez Scaleway ? Donc on avait besoin de mesurer l'impact des actions des équipes euh et aussi les actions des managers. On avait besoin d'une démarche commune parce que il y avait déjà des initiatives dans les équipes mais qui étaient isolées. Donc il fallait mettre tous ces efforts en commun. Et on avait aussi besoin d'assistance et de ressources, c'est-à-dire qu'il y a des équipes qui nous disaient ben nous on veut bien mais on sait pas comment faire et il faut nous aider.
[00:15:10] Donc les choix qu'on avait fait, on voulait absolument que ce soit une démarche euh bottom up. Donc pour inclure les équipes dans ces choix-là, non pas que ça soit quelque chose d'imposé aux équipes qui va très vite donc être critiqué et qui sera pas mise en place quoi. Euh pour ça, on a fait un choix, c'est que on prendra on a un focus donc on va être focus sur le niveau groupe, le niveau équipe. Le niveau individu, ça nous intéresse pas beaucoup parce que pour nous l'unité, c'est l'équipe.
[00:15:42] Euh et puis le niveau système, ça serait une étape suivante.
[00:15:48] Donc euh on a fait aussi le choix que cette démarche soit collaborative, c'est-à-dire qu'elle soit pas mise en place par une personne ou deux, mais plutôt par un un groupe de travail. Euh aussi que cette démarche soit utile pour les équipes avant tout et puis aussi par pour les managers.
[00:16:10] Et donc, qu'est-ce qu'on a fait ? Donc on a commencé par réunir des personnes motivées. Euh pour ça, on a utilisé une guild, une communauté de pratique chez nous, qui est la guild des Engineering Manager. Je vais laisser Clément parler un peu de cette guild.
[00:16:25] Un petit aparté pour vous expliquer ce ce système. On a deux voir trois guild euh bon, je vais redéfinir le mot après, euh qui fonctionne chez Scaleway. Donc vous vous rappelez tout à l'heure, je vous parlais de de six, six à huit tribes différentes et en particulier pour cette communauté de pratique des engineering manager qui soit dans ses équipes, qui soit éventuellement parce qu'on a quelques engineering manager à la DSI donc qui est différent de l'ingénierie et on en a même côté opération où il y a quelques équipes qui font du software. Et donc on a fait cette communauté de pratique pour que tous les engineering manager à leur niveau puissent partager sur leur métier d'engineering manager. Donc il y a que les engineering manager qui travaillent ensemble et qui parlent de leur métier ou de leur position d'engineering manager ensemble pour trouver des solutions, pour s'améliorer, pour monter des groupes de travail pour pour faire des pour tacler des sujets ou faire des propositions à la direction, des choses comme ça. Ça fait maintenant 2 ans et demi, je crois qu'on travaille et que en particulier avec cette guild des EM, c'est la première qui a vraiment euh fonctionné euh correctement. Et euh de cette guild euh alors c'est avant tout déjà un échange, on fait à peu près euh donc tous les 15 jours euh 1 heure et demie euh de session. En général, l'ordre du jour n'est pas défini ou en tout cas, on a une page qui est créée et des sujets qui pop pendant les 15 jours et ensuite, ils sont dépilés par ce groupe autonome sans avec le minimum d'animation possible en tout cas d'une seule personne. Euh et donc du coup le groupe s'auto-anime et tacle les sujets les uns après les autres. Et des fois, il décide de créer un groupe de trois quatre personnes qui va travailler sur un sujet et en faire une restitution quelques semaines après dans une autre session de la guild. Pour la la petite la petite blague le fonctionnement qu'on a qu'on utilise depuis maintenant un bon moment et qui marche bien, c'est que les 15 premières minutes, ça s'appelle le café crème. Euh et donc du coup, c'est un moment où tout le monde vient avec son café, donc c'est en remote. tout le monde vient avec son café, discute, on commence à organiser, rajouter des sujets à l'ordre du jour et euh et ensuite vers 14h15, euh on sait qu'on démarre, que les gens soient là ou pas là, on démarre et on dépile les sujets les uns après les autres. Voilà un peu la la vie d'une guild chez Scaleway.
[00:18:54] Et voilà, donc on s'est basé sur cette guild là, on leur a soumis la proposition euh à laquelle on avait réfléchi avec Clément à l'époque, qui a été bien accueillie par euh certains Oem. Donc on a demandé à ces Oem de d'être nos early adaptors, donc de commencer à tester la démarche. Euh nous faire des feedbacks et puis surtout de continuer à la faire vivre, à la faire évoluer avec nous. D'ailleurs, j'en vois en face de moi.
[00:19:21] Euh et donc ces mêmes EM sont devenus des ambassadeurs pour partager les réussites qu'ils ont eu, donc partager les feedbacks aussi qu'ils ont eu avec les autres des équipes et puis pour aussi accompagner les reste le reste des équipes pour mettre en place la démarche.
[00:19:40] Euh donc concrètement, qu'est-ce qu'on a fait pour mettre en place tout ça ? Donc on avait dit que les équipes avaient besoin d'aide mais aussi de ressources. Euh donc on a mis un certain nombre de choses. On va rentrer directement dans dans les détails. Donc d'abord, on a mis en place un portail sur notre confluence interne, donc qui va recenser toutes ces ressources, toute l'explication sur le framework et cetera.
[00:19:22] Donc c'est même The EM sont devenus des ambassadeurs pour partager les réussites qu'ils ont eu, donc partager les feedback aussi qu'ils ont eu avec les autres des équipes et puis pour aussi accompagner les restes le reste des équipes pour mettre en place la démarche.
[00:19:41] Euh, donc concrètement, qu'est-ce qu'on a fait pour mettre en place tout ça? Donc on avait dit que les équipes avaient besoin d'aide, mais aussi de ressources. Euh, donc on a mis un certain nombre de choses. On va rentrer directement dans dans les détails. Euh, d'abord, on a mis en place un portail sur notre confluence interne, donc qui va recenser toutes ces ressources, toute l'explication sur le framework et cetera. On a mis en place aussi un catalogue des métriques, une vue qui est un peu plus jolie. Donc ce catalogue de métriques recense un certain nombre de métriques qu'on a trouvé nous-même ou qu'on connaît c'est déjà ou qu'on a repris d'autres frameworks comme Dora et cetera. Euh ou encore de Devex pour ceux qui connaissent un peu. Euh, mais aussi euh les équipes pouvaient elles-mêmes proposer d'autres d'autres mesures, tout simplement.
[00:20:38] Je rajouterai aussi l'intérêt de se faire notre propre référentiel, c'est que derrière chacune de ces métriques qu'on ajoute au fur et à mesure que quelqu'un a envie de d'essayer de faire, euh, on essaie au maximum de fournir la capacité à le faire dans le contexte de l'entreprise. C'est-à-dire que on va avoir des scripts. Euh, certaines équipes vont développer des scripts pour aller chercher la métrique, et donc du coup vont partager leur scripts. Euh dans tout ce qui est euh plutôt sondage et perception.
[00:21:10] Euh, on va mettre en place, euh, on a aussi scripté la génération de petits sondages pour que chaque EM puisse générer son sondage, l'envoyer à son équipe, récupérer les informations de sur des petits sondages de trois, quatre questions. Euh et donc du coup, bah il génère, il le modifie s'il a envie de jouer un peu avec, il l'envoie, et donc du coup on facilite au maximum l'utilisation et l'application. Il suffit pas de dire de mesurer ça et ça, euh il faut aussi donner le maximum de de d'outillage pour aller chercher cette métrique dans le contexte, dans le SI, euh qui est le nôtre.
[00:21:47] C'est ça. Donc il va y avoir des mesures qui sont reprises de la littérature et d'autres qui vont être vraiment spécifiques à l'entreprise. Euh je prends pas comme exemple, on a une notion qu'on appelle le doctoring chez Scaleway. Donc c'est une personne qui s'occupe euh un peu du run euh à tour de rôle, en fait, dans les équipes qui le point d'entrée, en fait, du run. Euh du coup, par exemple, elle a eu des métriques sur ça euh pour mesurer un peu l'efficacité de ce système-là avec des mesures plus claires. Donc voilà, des choses un peu plus spécifiques. Et donc l'idée principale aussi, c'est que ce catalogue soit enrichi de façon collaborative par toute la boîte, toute toute l'ingénierie.
[00:22:27] Ensuite, on a mis en place également un atelier de bootstrap. Donc c'est un atelier qu'on propose d'animer donc nous, les ambassadeurs, aux nouvelles équipes qui voudraient s'y mettre. Euh, cet atelier permet d'avoir une première réflexion, euh, comprendre la démarche, mais aussi sortir de l'atelier avec leur premières métriques à mettre en place. Ça veut dire que les métriques sont construites de façon collaborative par les équipes. Ça veut dire aussi que il y a pas ce il y a pas les mêmes métriques pour toutes les équipes. Chaque équipe aura ses propres métriques. Donc ça c'est très important, et ça va avec notre démarche bottom-up parce que pour nous, euh les équipes n'ont pas le même contexte, n'ont pas les mêmes problématiques euh et ne devraient pas mesurer leur performance de la même façon. Ça veut dire aussi qu'on ne peut pas comparer entre les équipes en se basant sur ces métriques là. Ça veut dire beaucoup de choses. Mais en tout cas, c'est une démarche qui est acceptée, qui permet de mesurer cette cette performance, mais focus aussi sur des objectifs, ce qu'on appelle des objectifs. Donc en entrée de cet atelier, tout ce qu'on demande, c'est que l'équipe arrive avec un ou deux objectifs.
[00:23:37] C'est quoi des objectifs? C'est des axes d'amélioration. D'accord? Et donc l'atelier va se construire autour de ça pour se dire OK, pour s'améliorer sur cet axe là, quelles sont les mesures qu'on doit mettre en place pour pouvoir mesurer l'état actuel et puis l'impact des actions d'amélioration qu'on mettra en place par la suite via ces ces mesures. Euh, comment ça se déroule? Donc de façon collaborative, on leur demande de choisir des métriques soit dans le catalogue ou de proposer de nouvelles métriques et de les classer selon les cinq dimensions dans un premier temps. Par la suite, on va faire un dot voting pour choisir uniquement cinq mesures. Sinon, si on a plein à mettre en place en même temps, on n'avancera jamais. Donc on choisit cinq métriques.
[00:24:25] Et euh, très important, en fait ces cinq métriques doivent être euh réparties sur au moins trois dimensions. Pour revenir euh à la proposition de safe, de Space, qui dit que euh il faut avoir des mesures sur au moins trois des cinq dimensions pour avoir des perspectives différentes, pour voir les choses de façon euh à ce qu'on ait des points de vue différents. Euh, et donc en sortie, voilà, on a nos cinq métriques, et l'étape suivante, ça va être de mettre en place ces métriques là. De les utiliser, euh donc il faut un lapse de temps assez assez long, généralement un quarter, pour les mettre en place, les utiliser, voir leur impact et cetera. Et puis de refaire cet atelier là de façon régulière tous les quarters par exemple pour voir si les métriques ont encore du sens, si on les garde, si on les supprime et quelles sont les nouvelles métriques à rajouter. Avec notamment de nouveaux objectifs.
[00:25:27] Ensuite, reste la question de comment je vais publier le résultat de mes métriques ou qu'est-ce que je mets à disposition en dehors de de l'équipe. Et donc euh on leur propose un template de rapport. Euh donc c'est pas un dashboard, c'est vraiment un rapport rédigé. Euh c'est du texte. Et donc un template qu'ils peuvent reprendre, retravailler, adapter à leur source et cetera dans lequel ils vont expliquer justement le contexte, les métriques qui les intéressent. Expliquer pourquoi donc on a eu ces résultats là, quelles sont les actions à mettre en place pour s'améliorer et cetera. Donc vraiment euh fournir des mesures avec un contexte bien précis et non pas juste avoir des chiffres. Parce que les chiffres, ça peut être trampeur. Euh, ça peut être sujet à plusieurs points de vue différents.
[00:26:23] Et puis autour de ça, il y a plein d'autres outils plutôt techniques. Donc on va utiliser par exemple chez Scaleway on utilise beaucoup GitLab et Jira. On va avoir les API de GitLab et Jira qui sont très utilisées pour récupérer toutes sortes de données pour calculer les métriques. On a utilisé euh, on a testé en tout cas Apache DevLake. Euh, c'est un outil euh donc de Apache qui euh permet de calculer de façon assez automatique par exemple les métriques de Dora entre autres. Euh, en fait, il va pomper les données euh via plusieurs sources, par exemple GitLab, Jira et cetera. Euh, il va mettre tout ça dans une base de données euh il va fournir un Grafana, un dashboard Grafana avec lequel on peut jouer avec des métriques prédéfinies et d'autres qu'on peut rajouter, tout simplement.
[00:27:15] C'est ça a été un peu moyen, en tout cas, on pouvait pas trop pousser les choses avec. Euh, parce que c'est assez préfabriqué quoi. Il y a beaucoup de choses qui sont prédéfinies. Euh, mais selon la façon dont les équipes utilisent les les outils, les données qu'ils ont et cetera, ça peut être très compliqué de l'adapter euh à notre sauce quoi.
[00:27:37] On a eu aussi des du sujet vu le nombre d'équipes et les droits euh comme tout le monde a pas accès au code et à euh de de de toutes les équipes euh avoir une instance, alors vous pouvez monter en en euh pour votre équipe un un dev lake mais si on avait voulu avoir un dev lake manager pour tout le monde, en fait, on on bloquait sur la sur la les autorisations. Il aurait fallu qu'il ait qu'il ait tous les droits sur toute la la plateforme. Voilà, disons que ça a marché dans un contexte simple en local.
[00:28:07] Dès qu'on voulait scaler et l'utiliser plus largement, c'était un peu compliqué. Euh, du coup, il y a une personne en particulier qui avait proposé de faire ça sur Redash. Euh donc c'est un peu plus technique, il faut plus de code et cetera, mais ça ça marche plutôt bien quand on fait les efforts nécessaires. Et du coup euh il a par la suite partagé ce qu'il a fait avec les autres équipes pour que ça soit repris aussi, et ça a marché plutôt pas mal. Euh, il y a eu aussi des outils en interne qui ont commencé à voir le jour. Des gens qui ont commencé à développer des choses, voilà, des scripts, des outils et cetera. Euh, et puis bon, on en a déjà parlé, des des rapports pour les restitutions et cetera.
[00:28:49] Donc voilà, concernant le l'outillage qu'on a mis en place et les ressources. Euh, donc en mettant tout ça en place, donc on a appris un certain nombre de choses euh qui marchent quand on utilise Space. Donc c'est que la mesure de productivité est avant tout un outil d'amélioration continue pour les équipes. Si on la voit autrement, si on pense que c'est un outil d'abord pour les managers pour essayer de prendre les bonnes décisions, ce qui est tout à fait vrai. Euh, ça marche pas, en fait, parce que les équipes vont avoir tendance à vous fournir les les chiffres que vous voulez en tant que manager.
[00:29:27] Ça, vous le connaissez, c'est assez simple. Donc les indicateurs, les indicateurs pastèque et compagnie, donc c'est très simple de de vous donner comme le cas de Gordon au début de la preze, il peut tout à fait donner au manager les chiffres auxquels ils ils s'attendent. Par contre, le fait que ce soit un outil d'amélioration continue pour les équipes, euh c'est comme ça que ça va donner plutôt de de bons résultats.
[00:29:53] Deuxième chose, c'est que il faut voir les choses de façon assez large. Donc Space nous propose de d'avoir des métriques sur au moins trois des dimensions. Donc on revient à l'histoire des perspectives et ça c'est très important. Il faut surtout pas tomber dans le piège de de l'abandonné.
[00:30:15] Euh, aussi, c'est qu'il faut toujours partager avec une interprétation, avec le contexte, et non pas partager des dashboard avec des chiffres. Les dashboards avec des chiffres, ça va nous mener forcément, en tout cas ça va mener les managers à comparer entre les équipes, à demander, à demander des métriques qui seraient les mêmes pour pouvoir comparer. Alors que souvent les contextes sont pas les mêmes, les contraintes sont pas les mêmes. C'est souvent des choses qui sont pas comparables quoi.
[00:30:46] Il faut aussi bien choisir avec soin les métriques qu'on va partager en dehors de l'équipe. Ça c'est très important parce qu'on peut avoir beaucoup de métriques dans l'équipe qu'on va utiliser pour l'amélioration continue, c'est très important, mais on peut choisir en tant qu'équipe de ne pas les rendre public. En tout cas, pas toutes. Donc il faut choisir quelles sont les métriques qui ont du sens à être partagées, euh qui vont pas nous créer des problèmes inutiles ou des mauvaises compréhensions. Et donc ce travail qui est à faire en équipe, non pas par un manager, euh est très important, donc il faut bien choisir les métriques.
[00:31:21] qu'à rendre public.
[00:31:26] Il faut aussi euh les utiliser puisque c'est de l'effort à mettre en place toutes ces métriques. Donc il faut vraiment euh les utiliser à fond, euh notamment pendant les rétrospectives. Donc les rétrospectives, c'est souvent le bon moment de sortir ces métriques là pour dire OK, donc on avait pris des actions lors de la rétrospective précédente, euh voilà les mesures qu'on avait mis en place, voilà ce que où est-ce qu'on en était et où est-ce qu'on en est aujourd'hui.
[00:31:58] Voilà concernant Space et du coup pour mettre en place tout ça, euh vous savez bien, ça marche pas comme par magie. Donc il a fallu mettre en place toute une démarche de conduite de changement.
[00:32:13] Et je laisse Clément du coup vous parler de cette démarche de conduite du changement.
[00:32:21] Qui connaît les étapes de Kotter?
[00:32:26] Ah. J'aurais pensé plus. Super. Non du coup le slide est je le slide d'intro il ira parfaitement. Euh Kotter c'est quelqu'un qui a travaillé sur la conduite du changement et qui a euh Euh en gros décrit un système en huit étapes euh qui pour tout changement euh peut être appliqué. Le premier c'est de créer un sentiment d'urgence euh ça veut pas dire que enfin, il faut comprendre là-dedans, avant de commencer à enclencher un changement, il faut être sûr que tout le monde a bien conscience qu'il est important de faire ce changement maintenant. Et donc il faut créer les conditions d'avoir envie de changer. Euh, ensuite, il faut former une coalition, c'est-à-dire un petit groupe qui va travailler le sujet et qui va euh du coup avoir de l'autonomie avec des gens qui sont à la fois du terrain, du management, et donc du coup la coalition doit avoir un mandat pour euh rendre possible ce changement dans l'organisation, peu importe où vous trouvez. Ensuite, il faut avoir une vision qui est réaliste. Il faut la communiquer. Il faut inciter à l'action.
[00:33:40] Il faut générer des victoires à court terme, donc des petites étapes, ça vous rappelle peut-être des choses dans dans ce qu'on raconte quand on parle d'agilité. Il faut consolider euh ce succès euh pour plus de changement et ensuite il faut ancrer ce qu'on a le gain et du coup en faire quelque chose qui fait partie de la culture de l'entreprise. Donc ça, c'est les huit étapes, grosso modo, à respecter dans une conduite de de changement, en tout cas, selon selon Kotter. Et on s'est euh grandement euh euh on a grandement utilisé la démarche.
[00:34:15] Euh, d'abord, notre sentiment d'urgence. Euh, on sortait de deux hypercroissance dans l'entreprise. On est passé de 150 à 400, puis à 600 euh en moins de 4 ans. Euh et on est dans une nouvelle phase de stabilisation. Alors euh, on continue une croissance mais plus douce, et surtout, c'est l'heure un peu ce que je disais tout à l'heure, où après la le besoin de d'hypercroissance et de donc de croissance sous stéroïdes des fois euh pas toujours réfléchi, maintenant qu'on a la taille qu'il faut, il faut stabiliser et euh et donner un peu de de sens à à tout ce qu'on a fait.
[00:35:01] Notre sentiment, il était là parce que quand les équipes se disent, il va falloir qu'on commence à mesurer et à montrer en quoi on nos équipes sont performantes, comment elles se mesurent, c'est aussi prendre les devant et euh et participer à cette action de stabilisation intelligente.
[00:35:19] On a créé ce groupe de travail, on vous en a parlé tout à l'heure, grâce à la guild qui du coup sur le terrain euh a pris conscience de ce de ce besoin là et s'est mis à travailler en autonomie sur le le travail.
[00:35:33] Euh, on a créé du matériel. On a pris cinq équipes motivées euh qui ont commencé à éprouver les l'atelier dont Anis parlait, euh qui ont commencé à manipuler euh les différentes métriques. On a coconstruit dans ce groupe, on a on s'est partagé euh les choses et surtout ensuite on a pu montrer à à la à la guild pour commencer euh du coup les résultats de nos de nos expérimentations.
[00:36:05] Ensuite, pour la partie communication de la vision, une fois qu'on avait ce premier exercice durant un quarter où on avait cinq équipes qui avaient fait à peu près le le chemin et jusqu'à aller à un rapport de d'efficacité de performance de l'équipe. On a organisé une présentation avec les membres du comité de direction, les RH, euh les managers au-dessus donc des des Engineering manager et donc on a euh décrit tout le fonctionnement et on voulait le faire avec justement toutes ces parties prenantes euh ben pour euh ne pas qu'il y ait de désalignement avec d'autres initiatives chez les RH, avec les sujets de talent review, des choses comme ça. Euh par rapport aux deux directions produit et Engineering qui pouvaient avoir fait des choses euh des fois qui qui qui avaient besoin d'être visibles des deux côtés. Donc on a on a vraiment mis tout le monde dans cette dans cette pièce pour montrer le résultat de la de la de du des travaux. Inciter à l'action. On l'a fait par plein de petites choses. Déjà, on a produit tous les templates pour que les Engineering manager eux-mêmes puissent au moment de discuter de leurs objectifs avec leurs managers arriver avec des templates d'objectifs déjà faits. Donc là c'était les managers qui allaient voir leur supérieur en disant ben dans mes objectifs plutôt qu'en inventer un comme à chaque fois, on va essayer de on pourrait utiliser celui-là. C'est un peu l'idée, donc l'incitant l'incitation, elle était là. Certaines tribus l'ont très bien très bien fonctionné comme ça. Et d'ailleurs euh avec leur Head of, on décidé de mettre le même objectif pour tous les euh tous les Engineering Manager. Donc du coup, ils savent tous qu'ils ont le même objectif et en plus, ils peuvent le travailler ensemble et euh et co-worker sur le sur le sujet pour euh pour arriver à à à produire quelque chose de d'utile.
[00:38:09] Euh, organiser des reviews entre les managers de livrable. Euh ça c'est ce qu'on fait maintenant. Euh on essaie dès que le quarter, la fin de quarter arrive, ben du coup, on utilise, enfin les quarter report que vous avez vu là papier. Euh, on les présente et donc du coup les managers peuvent demander des relectures euh à à d'autres d'autres managers ou aux ambassadeurs du du premier groupe de travail. Euh ça permet de challenger, de réfléchir à des actions, de partager des initiatives qui auraient pu être fait dans plusieurs équipes et donc du coup de les de les paralléliser. Et euh pour consolider, euh aujourd'hui on est dans une phase, et donc là on est on commence à rentrer un peu dans le dans le futur de la de la démarche. On est dans une phase comme je vous disais, on est dans une nouvelle une réorganisation qui est en cours. Et donc euh on a tout l'outillage déjà sur le terrain qui vont nous permettre par rapport à des demandes euh de reporting, de choses qui qui sont en cours de de demande, de plutôt dire bah, en fait, on a tel outil, on va pouvoir le faire et si vous voulez, là on a on a traité le niveau équipe. Tout à l'heure, on vous parlait du niveau système. Donc à la dans la tribu, est-ce qu'on fait le même type de report, quelles sont les métriques pour plusieurs équipes? Ben ça, aujourd'hui, on va pouvoir aller plus loin dans le framework et construire cette nouvelle cette cette, enfin ce ce ce nouvel axe du framework, on va pouvoir le le mettre en place et euh et le coconstruire avec les head off et les Engineering manager.
[00:39:53] Et le dernier, en créer les nouvelles approches. Aujourd'hui, l'objectif, hein, c'est que tout nouvel EM qui arrive dans l'entreprise, euh les EM par l'intermédiaire de la guild et des ambassadeurs forment les autres EMs à utiliser cette démarche qui est maintenant bien connue dans l'entreprise et avec plein de gens qui peuvent euh être un peu les buddies de des des des nouveaux EMs qui auraient à à à à faire ce ce travail. Donc voilà un petit peu le la la démarche, les huit étapes donc de Kotter. C'est un c'est un truc que vous vous pourrez regarder euh
[00:40:28] euh par la suite si vous avez à faire un changement euh dans vos entreprises, pensez à à ce monsieur.
[00:39:52] manager. Et le dernier, on crée les nouvelles approches. Aujourd'hui, l'objectif, c'est que tout nouvel EM qui arrive dans l'entreprise, euh les EM par l'intermédiaire de la guild et des ambassadeurs forment les autres EM à utiliser euh cette démarche qui est maintenant bien connue dans l'entreprise et avec plein de gens qui peuvent euh être un peu les buddies des des des nouveaux EM qui auraient à à à à faire ce ce travail. Donc voilà un petit peu la la démarche, les huit étapes donc de Kotter, c'est un c'est un truc que vous vous pourrez regarder euh par la suite, si vous avez à à faire un changement dans vos entreprises, pensez à à ce monsieur.
[00:40:38] Alors, euh, on est censé terminer ici, euh, mais on s'est dit que si on avait le temps, on allait vous parler un peu en spoiler de ce que on a l'intention de faire par la suite. Euh, donc toujours en suivant les travaux de Nicole Forsgren, euh, en 2023, donc il y a eu un nouveau nouvel article, un peu la suite de de sous ce travail. qui s'appelle Devexx. Donc c'est encore un framework. Euh, l'idée de ce de ce framework, c'est de se dire à quoi bon mesurer la productivité. Euh, si on améliore, si on arrive à mesurer l'expérience développeur et qu'on arrive à l'améliorer, on va gagner en productivité. Ça c'est l'idée principale. Euh du coup, ils ont proposé un framework un peu similaire sur ça donc qui se base sur trois axes. Euh l'état du flow, le feedback loop euh et puis le cognitive load. euh avec toujours un peu la la même logique donc on a différents axes et puis euh là on a des quelques exemples de métriques euh donc pour ces pour ces axes là. Euh quand par exemple le temps nécessaire à l'exécution de la CI. pour le feedback loop, euh la satisfaction par rapport au temps nécessaire pour mettre en prod et cetera. Donc c'est très orienté dev expérience. Euh la nouveauté c'est que pour une fois quand on parle de dev expérience, on ne parle pas uniquement d'outillage ou de satisfaction avec l'outillage avec l'engineering system et cetera, on va vraiment plus loin. Donc on va parler de flow, on va parler de feedback loop, on va parler de cognitive load et cetera. Euh, dans cette idée d'améliorer l'expérience développeur. Euh donc nous on a vu ça de façon un peu différente, euh on pense s'inspirer de ces travaux là pour continuer sur ce qu'on est en train de faire avec Space. Donc on va essayer de d'utiliser ce framework là, de dégager les bonnes métriques euh d'expérience pour les intégrer dans notre framework interne qui se base sur sur Space. pour pouvoir mesurer cette donc euh cette expérience développeur de la bonne façon euh et puis l'utiliser aussi dans les équipes euh pour toujours pour de l'amélioration continue. Donc euh voilà, ça va être un peu la suite des travaux qu'on va mener sur ce chantier.
[00:43:08] C'est toi, c'est vraiment fini.
[00:43:13] C'était juste pour le micro.
[00:43:18] Ça des questions ? Ah, il y en a.
[00:43:22] là-bas là-bas, il y a.
[00:43:25] Chaque équipe a des des métriques différentes, mais pour une même métrique, est-ce qu'elle est mesurée de la même manière euh techniquement parlant dans les différentes équipes ?
[00:43:36] En général, il y a des vu que c'est quand même la même entreprise et le même système, il y a ça ça y ressemble, mais c'est absolument pas une une volonté pour les raisons qu'on a expliqué de de pas chercher à à comparer les équipes. On n'a pas de de préconisation spéciale là-dessus. Éviter de refaire le même travail deux fois, si c'est possible, c'est c'est plutôt bien pour le coup.
[00:44:00] Oui.
[00:44:01] Merci pour cette présentation. Euh vous avez parlé donc de 40 équipes à la base, vous avez commencé avec cinq. Aujourd'hui, vous en êtes où ?
[00:44:09] Et ça fait combien de temps ?
[00:44:11] Alors, euh, avec le, pour en toute transparence, le la la réorg qu'on a mis en place récemment a un peu mis une pause sur le le sujet. Aujourd'hui, je pense qu'on a des équipes qui ont fait les ateliers, je dirais une dizaine à peu près qui ont fait les ateliers qui ont commencé à rédiger des choses. Euh par contre dans les prochaines semaines mois l'objectif c'est d'arriver à la à à toutes les équipes et de toute façon toutes les équipes sont au courant, toutes les équipes ou en tout cas la très grande majorité ont validé ou review les travaux des autres et donc du coup, ils attendent, ils sont ils sont déjà formés. Euh, c'est plus une histoire de de temps et puis de une fois que ça devient un peu obligatoire, on s'y met, c'est c'est souvent comme ça, mais en tout cas, tous les indicateurs nous dit que ça nous disent que ça sera dans la bonne humeur.
[00:45:05] Loïc, tu peux peut-être. Il acquise.
[00:45:10] Et ça fait combien de temps ?
[00:45:14] Ça fait à peu près un an qu'on a commencé la démarche. Donc ça a pris du temps au début pour la mettre en place et entamer le la conduite du changement. Euh, donc ça a commencé à se mettre en place il y a enfin, en tout cas, ça a commencé un peu à s'accélérer il y a peut-être 6 mois. Euh, et puis ça a un peu été mis en pause, comme l'a dit Clément, suite à la réorg actuelle qui occupe les gens sur pas mal de sujets. Voilà, après deux trimestres. Donc euh, on a l'intention de de continuer maintenant que les les choses commencent un peu à à se mettre en place. En tout cas, euh on a eu beaucoup de, j'ai moi-même animé beaucoup d'ateliers bootstrap qui ont des équipes qui ont continué par la suite euh à donc à produire les rapports et cetera, d'autres qui se sont arrêtés là parce que voilà, ils sont passés à autre chose. Euh, voilà, donc il y a on est un peu dans une phase de de scale quoi, si on peut dire quoi.
[00:46:09] Ouais, merci. Euh après avoir mis en place donc ce ce framework de mesure, quels sont les bénéfices que vous avez pu observer dans les équipes euh que ce soit en terme de management ou de bien-être des collaborateurs ?
[00:46:21] Déjà, une démarche collaborative. Donc quand on donne la parole aux développeurs, généralement, ils sont plus productifs, plus contents, euh et ça marche mieux, bizarrement. Euh, voilà, on n'a pas de fausse information, on n'a pas de faux indicateurs, on n'a pas d'indicateur pastèque et cetera, déjà. Et donc euh ça fait aussi un outil pour euh certaines équipes qui nous remontent ça parce que ils souvent ils ont du temps pour faire des ateliers et tout ça se rencontrent assez régulièrement, on appelle ça les in days, scale et cetera. Donc ça leur fait aussi des ateliers à mettre en place à faire dans leur catalogue de ce qu'ils pourraient faire pendant ce temps-là qui est dédié à l'amélioration continue. Euh, et donc euh, mais aussi que euh, certaines, ces sujets de mesures étaient souvent menés par le EM, par le manager, alors qu'avec cette démarche, ça implique plus les développeurs eux-mêmes. Donc il y a un travail de groupe qui se met en place, du coup ça avance plus vite euh et plus les feedbacks sont plus intéressants. Euh, et du coup, les mesures aussi sont plus plus intéressantes.
[00:47:28] De mon côté, j'ai vu ça aussi des engineering managers qui est étaient surtout contents d'avoir un outil qui les aidait à mieux intégrer le dans la vie de l'équipe cette activité là. qui était plus solitaire avant parce qu'ils avaient pas forcément les les les les moyens et les outils pour pour partager et coconstruire. Euh maintenant ils ont des choses un peu clés en main. des ateliers, des bootcamps, de l'animation par un tiers qui fait qu'ils ont plus facilement cette ils mènent plus facilement cette activité et en plus comme les développeurs sont plutôt contents en général de le faire, ça c'est c'est hyper vertueux.
[00:48:11] Euh, je voulais savoir si vous aviez du coup des bah des métriques ou des équipes dans lesquelles les métriques se sont euh drastiquement améliorées. Euh, si vous avez des histoires à nous raconter là-dessus.
[00:48:27] Euh, on en a, je cherche quelque chose qui serait facile à à raconter. Je pense l'exemple le plus le plus précis, alors je crois pas qu'il est là aujourd'hui, mais il est il est dans la conférence. on a un de nos nos collègues qui venait de prendre une nouvelle équipe euh et qui euh en même temps que pour le coup le le passage d'une équipe dans un flux Kanban euh assez euh assez discipliné a a pu mettre en en en enfin, rédiger toute l'évolution et l'amélioration de son flux. Et donc du coup euh pour les les gens qui connaissent bien Kanban euh il a pu jouer tous les trains de son lead time, son cycle time, euh expliquer euh la le nettoyage de son backlog et l'assainissement de son backlog et il l'a fait par ce document. Donc du coup, il a vraiment un document du premier trimestre et de tout ce qu'il avait apporte son équipe avait engagé et fait. Et euh et ça un vrai rendu de de mesure de la performance qui plaît à tout le monde avec des + 80 % des trucs comme ça. Euh mais donc ça a eu un vrai vrai ça a été un vrai outil pour rédiger le les résultats et mettre en avant les résultats. Je sais pas si tu vois d'autres d'autres exemples.
[00:49:21] Euh, comme un nom, mais je regardais Loïc tout à l'heure parce que c'est l'un de nos engineering managers avec qui on avait commencé tout ça aussi. Si tu voulais partager quelque chose par rapport à ça. où le nom, ce que tu veux.
[00:49:55] Bonjour à tous. Euh, en tant qu'engineering manager, donc j'ai fait partie des des early adopters. Euh pour moi, ça a eu plein d'aspects positifs dans mon équipe. Déjà c'était permettre à l'équipe de s'approprier des choses qu'il voit généralement comme quelque chose de négatif, un élément de surveillance de la performance ou de la productivité, constitue le gros mot en général. Euh, des fois, ça permet de confirmer aussi des choses qui n'étaient pas vues, c'est-à-dire euh, bah nous, par exemple, on avait regardé euh le deployment frequency, par exemple, on s'est rendu compte euh dès la première itération qu'on était élite, en fait. Donc on s'est dit, bah, c'est cool.
[00:50:32] En plus, on a voulu mettre en place tout de suite une une refonte de notre CI/CD et on a essayé de maintenir le même niveau d'indicateurs. Donc là, pareil, ça nous a permis de faire de l'amélioration et de euh voir si avant après on était resté au même niveau euh de de performance. Il y a une autre équipe aussi, c'était euh la code review.
[00:50:50] euh ils s'interrogeaient sur euh sur leur temps de review. Et donc là, pareil, très vite, en 6 mois, je crois, ils ont vu euh une nette amélioration de leur temps de review, de l'efficacité de leur review de code, de PR. je crois que c'est dans une autre conférence, on voyait que ça pouvait coûter pas mal de temps et d'argent donc euh. Donc voilà, il y a eu plein de plein d'expériences dans chaque équipe, de manière individuelle dans chaque équipe, des indicateurs qu'on voulait surveiller et qu'on voulait améliorer. Et ce qui est bien c'est qu'après on augmente notre corpus d'indicateurs, on ne publie que certains indicateurs en extérieur comme ça l'a été dit là. Mais nous on continue à avoir un œil sur l'ensemble de nos indicateurs, mais des fois ça va être la performance de notre système d'ingénierie, la performance de nos tests. Voilà, tout un ensemble d'indicateurs que les développeurs, que l'équipe s'approprie et partage dans les rétros et cetera et cetera. Voilà, je sais pas si ça répond à la question.
[00:51:54] Oui.
[00:51:56] Euh, merci pour la présentation. Je suis là.
[00:52:01] Euh, est-ce que vous avez identifié une une corrélation entre l'évolution des performances des équipes et la valeur ou les bénéfices générés par par l'entreprise ?
[00:52:12] Euh, alors, je dirais que c'est trop tôt, je sais pas si c'est d'accord Clément. Je dirais que c'est trop tôt. Euh, vu euh, en tout cas, la la mise en place, même si on a commencé en un an, mais il y a eu des moments d'interruption, et il y a eu la conduite du changement. Donc je dirais que c'est un peu tôt pour l'instant, mais euh, ça va être très très intéressant à mesurer. euh par la suite.
[00:52:38] Bonjour. Merci pour la présentation. Euh, c'est ça va rejoindre un peu la question précédente. Euh, vous expliquez très bien que c'est des métriques qui sont pas forcément à prendre dans l'absolu, euh, que ça dépend du contexte, que chaque équipe a ses propres ses propres métriques. Comment est-ce qu'on répond du coup à Agathe, la CEO au début, bah qu'il y a peut-être encore besoin de savoir est-ce que toutes ces embauches, ça a un impact sur le ROI ? Euh, est-ce que vous avez eu peut-être des retours vous des des C level de ce point de vue-là déjà ou euh.
[00:53:06] Euh, alors on dit surtout et on l'a peut-être pas dit dit clairement. Par contre, on encourage tout le monde à mesurer les trends dans le dans le fonctionnement. Et on est on est dans une entreprise qui a 20 ans avec une hyper croissance il y a pas longtemps, mais on a des équipes qui sont très euh récentes et puis des équipes qui ont plusieurs années voir dizaine enfin, voir une dizaine d'années. Et selon les contextes, on a des des cas où on a besoin de maîtriser une rétention.
[00:53:40] euh que les gens arrêtent de s'en aller parce que euh il y a des technos plus intéressantes ailleurs et cetera. On a des équipes où il faut convaincre sur des produits qui ont pas forcément le même intérêt.
[00:53:54] euh si on ouvre pas le capot et on réfléchit pas. Et donc c'est surtout en tout cas pour le moment euh avec les Head of et les directeurs techniques qu'on arrive à à créer un argumentaire. euh parce que justement, on a des équipes qui dans leur contexte avaient des problématiques et qu'elles commencent à les régler, elles commencent à réembaucher alors qu'elles arrivaient plus à embaucher. Donc elles ont quelque chose à raconter qui fait que il y a une évolution qui est qui est nette. Et donc ça, on arrive à le le remonter, on arrive à le coconstruire une fois que bah il y a une demande un peu plus directe, on on peut relire un peu tout ça et construire une nouvelle argumentation système.
[00:54:37] Même si aujourd'hui on a pas encore le truc. Donc c'est plutôt comme ça en tout cas moi que je je vois le comment te te répondre. C'est plutôt dans ce ce type d'action.
[00:54:47] Oui, bonjour, merci. Euh, j'ai une question sur comment vous déterminez la fréquence de la mesure, et euh, est-ce que vous rejetez tous les indicateurs qui sont pas automatisables ?
[00:54:57] Euh, on ne rejette absolument pas les indicateurs qui ne sont pas automatisables, on en a beaucoup qui sont euh, c'est des surveys, en fait. Donc tout ce qui est euh euh well-being, donc tout ce qui est satisfaction et cetera, ça va être des des surveys, donc très peu automatisables en vrai. Euh, c'était quoi la première question ?
[00:55:20] La fréquence.
[00:55:21] La fréquence, oui. La fréquence, on préconise de le faire une fois par quarter. mais les équipes sont libres de le faire aussi fréquemment qu'ils le souhaitent. Donc si vous.
[00:55:31] Même.
[00:55:32] Oui, euh, mais après, la mise en place des mesures, c'est une fois par quarter, mais le suivi de l'évolution des métriques, c'est plutôt par sprint ou par semaine, oui.
[00:55:43] de rapport de.
[00:55:48] Voilà, ça va dépendre aussi beaucoup des de la mesure elle-même. En tout cas, il y a pas de directive là-dessus, c'est les équipes, c'est à la main des équipes.
[00:55:58] Bonjour, merci. Ma question est un peu liée à la précédente sur les métriques qui ne sont pas automatiques, combien de temps ça prend au développeur, quelle est la charge nécessaire pour justement remplir le template que vous nous avez montré ?
[00:56:13] Euh, c'est ça dépend encore une fois beaucoup de la mesure. Généralement, on peut, généralement, on propose des de survey qui sont très courts.
[00:56:22] Les équipes peuvent avoir les leurs aussi, ils peuvent nous les montrer, quand ils ont le leur aussi, on leur donne un avis. Généralement, si c'est trop long, on leur dit c'est trop long, ça vous prend trop de temps au développeur. L'idée, c'est que ça soit rapide et facile à remplir.
[00:56:37] J'encourage très souvent et depuis depuis très longtemps les gens à pas réfléchir forcément à automatiser tout de suite. Et je vais te donner un exemple précis.
[00:56:47] Il y a plein de cas où tu as besoin d'avoir l'information une fois par semaine et entre essayer de l'automatiser et avoir je sais pas où dans un dashboard non apisé de Jira l'information et aller la récupérer et la répercuter dans un petit tableau une fois par semaine, ça te prend du coup 5 secondes une fois par semaine et donc franchement ça ou essayer de retrouver comment elle a été produite euh et pour la la la générer, euh il y a souvent peu de peu de trop d'efforts à à faire finalement à l'automatiser.
[00:57:12] Donc on a plein de cas, le cas le plus le plus évident ou celui que j'utilise le plus souvent, c'est le calcul du
[00:57:28] du dans dans Jira du de ton flux et de ton cycle time euh ou ton lead time, ça dépend quelle colonne tu prends. Euh tu peux le récupérer très rapidement dans l'analyse de ton flux par des dashboards. Par contre, si tu dois le calculer toi-même ou le récupérer, il y a pas la API te le permet pas et si tu le recalcules tu rentres il faut réinventer le le dashboard. Donc typiquement c'est le genre de truc où tu prends du coup ta ta donnée, tu la reprends une fois par semaine et puis c'est c'est fini.
[00:58:05] Est-ce que vous aviez déjà parmi ces 40 équipes et tout tout tout le management un peu la culture de la mesure, euh qui était un peu déjà en place l'idée de bah de mesurer ce qu'on fait ? Ou est-ce que c'est des trucs que vous avez dû euh sur lequel vous avez dû appuyer pour euh que ça prenne ?
[00:58:21] Alors, euh, oui et non. Oui, enfin, non, parce que culturellement euh et et par rapport à cette hyper croissance et au fait que bah du coup c'est souvent je dis que une entreprise en hyper croissance c'est être sur un cheval au galop sans selle et puis et puis on avance. Euh donc on avait pas ça culturellement. Par contre, on a recruté beaucoup d'engineering manager plutôt senior qui arrivait avec un bagage et des capacités à le faire. Et donc on a aussi beaucoup de gens qui aujourd'hui sont pas complètement dans le modèle. mais qui avait quelque chose de très très similaire et avec qui on s'est regardé sans aucun souci en disant bon ben le jour où il faut pour une homogénéité passer là-dessus, on passera mais moi j'ai mes slides où j'ai mon fichier, j'ai mon dashboard et globalement je fais à peu près la même chose. Donc on a deux on a une grande autonomie entre les équipes et on a beaucoup d'équipes avec une une vraie expérience et des gens d'expérience qui mènent leurs équipes avec ce avec cette culture. J'ai filé le micro, mais je vais prendre la dernière.
[00:59:31] Merci. Une question un petit peu similaire à la question qui a été posée juste avant là. Euh, en fait, comment vous montrez que les équipes progressent ? Parce que les métriques sont pas les mêmes. Il y a certaines métriques qui sont cachées. Donc quand on doit montrer par exemple à des enfin au board et cetera que les équipes progressent, c'est quoi qui est euh qui est formalisé euh enfin sur la durée, c'est enfin en terme de dashboard, en terme de consolidation quoi.
[00:59:56] Alors, c'est ce qui va être fourni dans les rapports. D'accord, donc dans les rapports, on va avoir des des objectifs d'amélioration des équipes. Donc ça donne une information sur leur maturité, sur sur les sujets. Euh ça donne aussi l'information euh sur où est-ce qu'ils en sont, quelle est leur performance, si on veut actuellement. Euh, et donc les indicateurs qui vont être dans les rapports avec le bon contexte, ça va donner cette information en plus de dire, OK, donc cette équipe, elle a des lacunes ici, elle doit s'améliorer sur telle chose et cetera. Euh, sans forcément rentrer dans la facilité de comparer entre des chiffres sans avoir vraiment le contexte et les contraintes de chaque équipe.
[01:00:35] et donc qui donnerait finalement une comparaison qui est fausse déjà de base, euh mais aussi une information tout simplement qui est qui est pas la bonne parce que c'est un chiffre sans le contexte qui va avec, sans les contraintes et les explications, ça veut tout et rien dire, en vrai. Donc euh, c'est pas facile, en fait, de de donner cette cette information, tout simplement de dire est-ce que l'équipe progresse ou pas. Mais euh, en en suivant l'équipe, en avec la lecture de ses rapports de façon assez régulière, on sait d'où est-ce qu'elle part, où est-ce qu'elle est aujourd'hui, quelles sont les mesures qu'elle utilise, et cetera, et donc ça peut mener aussi les managers à prendre les bonnes décisions, et c'est ce qui est finalement utile, en fait.
[01:01:22] Et je rajouterai que ça nous a permis aussi, je sais plus qui je regarde pour la question, mais euh ça nous a permis aussi d'inverser un peu la tendance et de plutôt de dire bah, il y a un problème, il y a un doute sur une équipe, mais venez discuter avec nous. Et donc du coup, plutôt que de vouloir absolument remonter les infos, certifier et convaincre tout le monde qu'on a les infos et que s'ils veulent venir nous aider à être meilleurs, ils peuvent ils peuvent venir et on va sortir toutes les toutes les données et on va les regarder avec eux. Euh c'est c'est aussi un changement qu'on essaie de d'insuffler et qui en général est est plutôt bien pris. euh parce que ils savent que il va y avoir une vraie discussion basée sur des faits et des données.
[01:02:08] OK, merci à vous. Je suis désolé pour seconde question, mais il faut arrêter.

Transcription