- Plusieurs équipes Scrum estiment le reste à faire de leurs tâches de développement sous forme d’un « Sprint Burndown chart» qui est présenté comme indicateur de vélocité.
- Il permet effectivement d’avoir une opinion sur la production. Mais la réalité est que l’autonomie et la performance attendues de ces équipes, sur le développement de logiciels, tardent à venir.
- Une équipe qui apprend plutôt à observer son travail via un indicateur de productivité et utilise le PDCA comme méthode de résolution de problème, améliore sa performance plus rapidement et tend vers l’autonomie.
La vélocité
Une équipe Scrum, actualise chaque jour une estimation des tâches qu’il lui reste à faire pour finir son Sprint. Cette estimation est souvent – mais pas obligatoirement – donnée en « story points » ou simplement en « points », unité qui exprime une taille relative d’une tâche en fonction de sa complexité, d’une incertitude éventuelle et de l’effort estimé pour la realiser. C’est un nombre, qui varie de sprint en sprint et dont il faut considérer la moyenne ; c’est la vélocité. C’est elle qui, bien identifiée, permettra à une équipe de développement de logiciels par exemple, de s’engager sereinement sur une date de livraison pour des fonctions à développer.
Quelle productivité ?
La productivité dont je parle, est parfois appelée productivité du travail. C’est la quantité de biens ou de services qu’un travailleur fournit dans un intervalle de temps donné.
Une équipe de développement Scrum, traite les éléments contenus dans son « Product Backlog ». Comme il est rappelé dans le ScrumPrimer, le Product Backlog ne contient pas des « User Stories ». Il contient en fait, une variété d’éléments, que je propose d’appeler tâches de développement, qui peuvent prendre la forme de User Stories, de cas d’utilisation, ou tout autre artefact de gestion des exigences que l’équipe souhaite utiliser. De mon expérience, l’expression de ces tâches de développement, manière la plus efficace connue de l’équipe pour exprimer un besoin client, doit couvrir deux points essentiels : elle montre la création de valeur pour le client, elle reste explicite sur les critères d’acceptation du client.
Sachant qu’une équipe Scrum fait le point sur sa progression tous les jours, la productivité est le nombre de tâches qu’un développeur – de cette équipe – termine effectivement par jour. Pour la calculer, concrètement, à la fin de chaque journée de travail, pour toute l’équipe, il faut compter le nombre de tâches terminées – d’après la définition de Terminé – et la diviser par le nombre de membres de l’équipe. Pour ce dernier, l’usage est de considérer les développeurs et les testeurs, présents ou à distance, c’est à dire tous les membres d’équipe qui ont contribué à la complétion de ces tâches.
Inspecter et adapter, donc s’améliorer
L’un des axes majeurs de l’approche Scrum, c’est « inspecter et adapter ». Cette adaptation veut dire surtout qu’il faut trouver un moyen de travailler plus efficacement tout en gardant un rythme soutenable, pour garder le client qui peut toujours aller ailleurs.
Bien entendu, la déviation d’un reste à faire peut se voir à la journée, et donc pousser à réagir. Malheureusement, j’observe plutôt une tendance des équipes à surestimer les tâches. Or, voir une mauvaise productivité du jour – par rapport à la cible nécessaire pour tenir les délais – amène tout de suite à s’interroger par exemple sur la plus ou moins bonne vitesse d’exécution des tâches, et à développer une vision plus précise de la capacité d’un développeur. C’est une perspective plus incitative à l’action face à un écart de performance. Une équipe Scrum doit apprendre à lutter contre la variabilité de la productivité.
A cela, il faut rajouter la pratique du PDCA, approche structurée de résolution de problème, qui est une réponse à l’objectif « inspecter et adapter » de l’approche Scrum. En effet, elle permettra à une équipe, face à toute déviation de performance, de faire des expérimentations structurées en accord avec les causes réelles des écarts observés et non pas de dériver avec des itérations de nouvelles initiatives basées sur des hypothèses non vérifiées.
C’est ainsi qu’une équipe Scrum avance petit à petit dans une réelle démarche d’amélioration continue. Sur ce chemin, elle se pose des questions comme :
- La taille des tâches du Product Backlog est-elle la bonne ? cette question fait suite, par exemple, à l’observation d’une variabilité de la productivité. Elle amène naturellement, après plusieurs essais, à un meilleur découpage des tâches de développement, en accord avec le Product Owner.
- Comment finir encore plus de tâches pendant un sprint ? c’est l’observation d’un écart de productivité. Le client veut qu’on en fasse plus. Souvent l’équipe traite des anomalies qu’elle a généré auparavant. Elle se retrouve à en traiter la cause, et à mécaniquement – et de façon itérative – réduire la bande passante qu’elle y allouait. C’est le PDCA pour réduire le volume des anomalies. Mais j’observe aussi le cas où les développeurs n’avancent pas à la bonne vitesse à cause de problèmes de compétences ou d’environnement, par exemple.
- Comment terminer les User stories et tâches de développement dans le bon ordre ? au moment où le client en a besoin ? C’est arriver à s’adapter à la gestion des priorités du Product Owner, apprendre à livrer au bon rythme, se connecter au système de production du client. C’est aussi apprendre à mieux travailler avec lui, par la mise en place du flux tiré.
Scrum, formidable système de livraison de logiciels, souligne la nécessité de développer par étapes courtes. Ce faisant, en observant sa productivité et avec une approche éprouvée pour traiter les écarts, une équipe Scrum développe petit à petit un système stable de production de logiciels : les moments de pression pour produire une fonctionnalité ou corriger des anomalies, que l’on observe souvent, finissent par se raréfier pour disparaître.
Quels indicateurs avez vous dans vos équipes Scrum ?
—
Contactez-nous pour en savoir plus sur la performance des équipes Scrum.
Leave a Reply