Comment mesurer la qualité de votre processus de développement?

Est-ce qu’on s’améliore? Est-ce qu’on est meilleurs que lors du dernier sprint? Est-ce qu’on devrait changer notre approche? Je me fais continuellement poser ces questions en tant que Scrum Master. Et je n’étais jamais satisfait des réponses que je donnais aux directeurs, aux gestionnaires ou même aux vice-présidents. Même si je pense qu’on progresse et qu’on s’améliore, que notre processus est plus efficace et robuste, communiquer seulement avec son instinct ne devrait pas être la norme pour mesurer notre progrès.

En tant qu'agiliste, comment m'assurer que les dirigeants voient la valeur d’adopter la méthode agile dans notre quête d'excellence dans le domaine? Le Lean Manufacturing et le programme de recherche DORA DORA m'ont inspiré un retour aux sources. Et tout commence par la mesure de votre processus! Je vous présente ci-dessous mon parcours pour obtenir quelques mesures de base sur la qualité de notre processus et mes humbles conseils pour les améliorer.

L'importance du temps de cycle

Voici ma règle d'or lorsque j'essaie une nouvelle habitude : commencer par ce qui est le plus facile. Si vous voulez commencer à mesurer votre processus de développement, commencez par les données que vous avez déjà en main. Combien de temps faut-il pour qu'une story, une tâche ou un Post-it passe de «en cours» à «terminée» ou «déployée»? En tant qu'agilistes, il faut tenter de réduire le temps de cycle dans nos processus. C'est un indicateur de l'état de la situation sur le terrain. Voici une petite expérience qui pourrait vous aider à vous lancer.

Commencez simplement :

Si vous utilisez un outil de gestion de projet comme Jira ou Azure DevOps, vous pouvez accéder directement aux données sur le temps de cycle dans vos tableaux de bord. Si ce n'est pas encore le cas, voici un moyen simple de commencer à mesurer le temps de cycle.

• Prenez un tableau blanc, des Post-its et des marqueurs.
• Divisez votre tableau blanc en quatre colonnes (à faire, en cours, en révision, terminé).
• Inscrivez chaque tâche sur un Post-it distinct.
• Ajoutez un point sur votre Post-it pour chaque jour que vous consacrez à une tâche.
• Changez la couleur que vous utilisez chaque fois que votre Post-it change de colonne.

Pour compiler les données, comptez les points de chaque couleur sur chaque Post-it. Le résultat vous servira de base pour calculer le temps de cycle moyen pour une période donnée (un sprint, une semaine, ou ce qui a du sens pour vous).

Pour passer à un autre niveau :

• Répétez l'exercice et entrez vos nouvelles données dans un graphique pour déterminer si l'indicateur de performance augmente ou diminue par rapport au cycle précédent.
• Répétez l'opération sur une période plus longue (je recommande trois mois) pour suivre toute variation ou amélioration.

Pourquoi le temps de cycle est-il important?

Le temps de cycle peut vous aider à mieux communiquer les progrès que vous réalisez avec l'équipe et les parties prenantes. C'est un excellent indicateur à haut niveau de la vélocité moyenne de votre équipe de développement et de votre processus, tous autres facteurs étant égaux. En général, la tendance du temps de cycle doit être stable ou décroissante. Ainsi, si vous observez une augmentation de votre temps de cycle, vous pouvez réagir en conséquence.

Mon temps de cycle moyen a augmenté. Que faire?

Si vous remarquez que votre temps de cycle moyen augmente au cours d’un sprint, creusez un peu plus! Voici quelques questions pour vous aider à comprendre ce qui se passe :

• Y a-t-il quelqu'un en vacances ou une nouvelle recrue dans l'équipe? Votre équipe a peut-être un problème de partage des connaissances. Pour remédier à la situation, vous pourriez organiser des activités de transfert de connaissances en jumelant différents membres de l’équipe.
• L'équipe travaille-t-elle sur une partie plus imposante du projet? La taille des tâches est-elle similaire à celles des cycles précédents? Si votre temps de cycle plus long est le symptôme d'une tâche plus complexe, vous devrez peut-être revoir le découpage de vos storys pendant la phase de raffinement.
• Quelle colonne est à l’origine de l'augmentation du temps de cycle? S'il s'agit de la révision, c’est un bon point à aborder lors d'une prochaine rétrospective.
• Y a-t-il un conflit non résolu au sein de l'équipe? Premièrement, assurez-vous que le problème ne s'aggrave pas. Puis, organisez des activités (1 à 1, discussion de groupe, remue-méninges silencieux) pour que les gens puissent exprimer leur point de vue.
• Avez-vous été affecté par un problème de production? Essayez d'analyser la réponse de votre équipe en planifiant une activité post-mortem.

TLDR :

• Commencez doucement.
• Comptez le nombre de jours où vous considérez qu'une tâche donnée est en cours d'exécution.
• Mesurez votre temps de cycle moyen pour le sprint en cours.
• Agissez si votre temps de cycle augmente sprint après sprint.

Bien sûr, le temps de cycle ne suffit pas pour évaluer la qualité de votre processus. C’est ce qui nous amène au débit!

Le rythme de l'équipe : c'est un marathon, pas un sprint

Maintenant que nous avons mesuré le temps de cycle, prenons un peu de recul et examinons le débit de l'équipe. Cette mesure dépend du contexte de votre équipe. Le débit est le nombre d'éléments terminés sur une période donnée. Il est assez simple de rassembler des données pour cette mesure. Disons que votre référence temporelle est une semaine : comptez le nombre de tâches qui sont passées de «à faire» (backlog) à «terminé». Il vous suffit de regarder la dernière colonne de votre processus.

Le débit est également un indicateur de performance que vous pouvez observer dans Jira ou Azure DevOps. Si vous n'utilisez pas ces outils, voici quelques points clés à prendre en compte pour commencer :

• Définissez la période de référence (il est courant d’utiliser la durée d'un sprint).
• Comptez le nombre d'éléments dans la colonne «terminé» à la fin de cette période.
• Suivez vos données à l'aide d'une feuille de calcul et d'un graphique linéaire.
• Donnez-vous au moins quatre itérations pour identifier les tendances.

Pourquoi le débit est-il important?

Le débit de l'équipe en lui-même n'est pas l'information la plus utile que vous puissiez recueillir. Elle doit plutôt servir d'indicateur de la productivité de l'équipe pour déterminer si vous apportez plus ou moins de valeur à vos clients sur une période donnée. De nombreuses variables peuvent influencer le débit. Après un certain temps, vous pouvez même utiliser cet indicateur de performance pour prédire la capacité de votre équipe à livrer un projet. Intéressant, non?

Mon débit a diminué. Que faire?

Ici, nous souhaitons une tendance stable ou croissante. Si votre débit pour une période donnée est inférieur à votre moyenne, il est préférable de se pencher sur la question. Voici quelques pistes pour commencer :

• Un nouvel obstacle a-t-il mis l'équipe au défi pendant le sprint? Vous pourriez chercher à savoir pourquoi ce problème n'a pas été détecté avant, pendant la planification ou le raffinement.
• Un élément non planifié est-il apparu au cours du sprint? S'il s'agit d'une tendance récurrente au sein de votre équipe, commencez à garder une trace de ces éléments inattendus. Rendez-les visibles pour l'équipe afin qu'elle agisse ou qu’elle change ses habitudes.
• Est-ce que les gens travaillaient ensemble pour atteindre l'objectif du sprint? Une équipe qui a plusieurs priorités et dont les membres travaillent en vase clos peut devenir très dysfonctionnelle. Vous pourriez introduire une limite de travail en cours (WIP), afin que les gens n'aient pas d'autre choix que de travailler ensemble de manière collaborative. .
• Une tâche du projet était-elle plus importante que prévu? En général, on découpe les story et les tâches pendant le processus de raffinement. Si votre équipe néglige cette étape, essayez d'influencer les membres de l'équipe à avoir une nouvelle définition de «prêt» pour vos story. Vous pourrez ainsi identifier à l'avance les tâches plus importantes.

TLDR :

• Commencez doucement.
• Comptez le nombre de tâches terminées.
• Utilisez un graphique linéaire pour surveiller l'évolution du débit dans le temps.
• Intervenez si votre débit tend à diminuer systématiquement.

Dernières réflexions

Le temps de cycle et le débit ne sont pas les seules mesures indiquant la qualité globale de votre processus de développement. Mais vous seriez surpris du niveau d'information qu'ils peuvent vous donner sur votre équipe. En confirmant votre intuition à l'aide de ces mesures, vous serez plus confiant lorsque vous parlerez aux directeurs, aux responsables ou aux vice-présidents. Vous verrez également l'impact que vos actions en tant que Scrum Master peuvent avoir sur votre équipe!

Comptabiliser ces indicateurs manuellement demande beaucoup d'efforts de votre part. Et soyons honnêtes, votre valeur ajoutée n'est pas d'être un spécialiste des données pour votre équipe : c'est de l'aider. C'est précisément la raison pour laquelle nous avons créé Axify : une plateforme web qui augmente la visibilité du processus de développement logiciel. Elle vous permet de suivre facilement les mesures mentionnées ci-dessus et bien d'autres encore (nous avons parlé de quelques-unes de ces mesures ici).