L’indice Adadot baisse : quelles demandes de fusion revoir en rétrospective ?

Le sprint commence bien, puis une série de modifications de code attend une revue à l’approche de la fin. Le responsable du développement doit comprendre comment le travail s’est bloqué, plutôt que constater simplement une baisse de la « vitesse » de l’équipe. Adadot analyse ensemble les données d’activité de développement et de collaboration, ce qui peut fournir des pistes pour cette rétrospective. Mais pour décider quoi changer, il faut toujours revenir aux tâches concrètes et à la discussion avec l’équipe.

Cet article analyse ce scénario à partir de la documentation officielle du produit et de cas d’utilisation historiques publiés par l’éditeur. Aucun compte d’équipe n’a été connecté et les performances prédictives du modèle n’ont pas été vérifiées.

Le site d’Adadot cite parmi les usages du produit la relation entre le temps d’attente des revues et le nombre de commentaires, ainsi que les analyses de scénarios « What if ». Cela peut aider le responsable à poser une question plus précise : si les demandes de fusion avaient été examinées plus tôt, le blocage actuel aurait-il pu être atténué ? Il s’agit d’une hypothèse à tester, pas d’une cause que le modèle aurait déjà démontrée à la place de l’équipe.

La prochaine rétrospective peut prendre la forme d’une petite expérience. Définissez d’abord une même équipe, des projets de même nature et des périodes d’observation de même durée. Notez ce qui a changé, puis sélectionnez les demandes de fusion qui, dans cette période, ont traîné jusqu’à la fin du sprint. Dans l’outil de développement d’origine, consultez les heures de soumission et de revue, l’étendue des modifications, les échanges et les éventuels changements de dernière minute des exigences associées. La FAQ d’Adadot présente elle aussi le produit comme une couche d’analyse au-dessus des outils quotidiens et précise que les informations au niveau des tâches restent à consulter dans Jira ou Gitlab.

Cette démarche permet de distinguer plusieurs réponses : si le périmètre des exigences change sans cesse, accélérer les revues ne suffit pas ; si les modifications sont trop importantes pour être comprises rapidement, on peut discuter de leur découpage ; si les relecteurs ne sont sollicités qu’au dernier moment, il faut organiser la collaboration plus tôt. Cette classification est une méthode de rétrospective, pas l’affirmation qu’Adadot attribue automatiquement ces étiquettes à chaque demande.

Dans un cas consacré à sa propre équipe et publié en août 2022, Adadot explique avoir découpé le travail selon l’ampleur des modifications de chaque demande de fusion. En discutant du ralentissement des fusions en seconde partie de sprint, l’équipe a aussi constaté qu’elle traitait d’abord les tâches faciles et repoussait les problèmes difficiles susceptibles de se bloquer. Elle a ensuite commencé à traiter ces travaux difficiles plus tôt.

Ce document est le retour de l’éditeur sur sa propre équipe. Il ne permet pas de promettre les mêmes gains de débit à une autre équipe. Il fournit néanmoins un point de départ utile : les graphiques révèlent le changement, l’équipe en explique le contexte, puis le découpage ou l’ordre de traitement des tâches évolue. Il ne faut pas sauter la discussion intermédiaire pour transformer une fluctuation ponctuelle du score en conclusion sur la performance d’un salarié.

Choisissez d’abord un seul ajustement, par exemple discuter plus tôt des tâches comportant des dépendances externes. Pendant la période comparable suivante, regardez non seulement si l’attente diminue, mais aussi si les reprises augmentent ou si le travail difficile a simplement été repoussé hors de la période observée. Une hausse du nombre de tâches terminées sans diminution des problèmes de livraison ne suffit pas encore à déclarer l’amélioration réussie.

La FAQ indique que l’indice normalise les données sur une échelle de 1–10 et applique des pondérations. Il peut donc signaler où regarder, mais ne constitue pas un équivalent direct du temps de travail, de la valeur métier ou de la contribution individuelle. Des tâches réalisées dans des contextes différents ne devraient pas non plus être classées à partir d’un seul score.

La page produit affirme que les indicateurs individuels sont agrégés et anonymisés au niveau de l’équipe, et que les indicateurs d’équipe nécessitent au moins 3 membres. Elle indique également ne pas traiter ni stocker le code. Avant une connexion effective, le responsable doit néanmoins vérifier avec l’équipe les champs visibles dans le compte réel, les sources de données, les droits d’accès et le périmètre d’utilisation autorisé par l’organisation. Les déclarations du produit ne remplacent pas ce contrôle et ne signifient pas que les enregistrements individuels bruts peuvent être affichés librement en rétrospective.

Si la question se limite à savoir qui reprend une demande aujourd’hui, une coordination directe dans l’outil de gestion des tâches existant est plus adaptée. La couche d’analyse d’Adadot mérite davantage d’être essayée lorsque les blocages se répètent, concernent plusieurs tâches et que l’équipe souhaite utiliser les données pour ajuster ensemble son processus. L’essai doit aboutir à un changement de processus clairement explicable et vérifiable après coup, pas à un classement individuel plus soigné.