Chapitre 21

Les dix principales mesures de Scrum

 

Dans ce chapitre :

• Éviter les mesures traditionnelles et inefficaces
• Faire le maximum avec les données disponibles
• Optimiser la valeur de Scrum

 

Avec Scrum, les mesures sont de puissants indicateurs numériques pour la planification, l’inspection, l’adaptation et la compréhension des progrès au fil du temps. Les taux de réussite ou d’échec permettent à une équipe Scrum de déterminer si elle doit apporter des changements ou de poursuivre le travail. Ces chiffres sur le temps et les coûts mettent en évidence les avantages des projets agiles et constituent une base pour les activités financières de l’entreprise. Quant aux mesures qui évaluent la satisfaction des gens, elles permettent à l’équipe Scrum d’identifier les domaines à améliorer avec les clients et avec l’équipe elle-même.

Le travail agile en double est une mauvaise pratique de gestion consistant à réclamer des rapports de situation traditionnelle et des réunions d’avancement en plus des documents, événements et mesures Scrum. C’est l’un des principaux pièges dans les projets Scrum. La direction recherche une chose, tandis que les équipes tentent d’en faire une autre. En conséquence, les décisions sont prises sur la base d’informations erronées, les équipes se surmènent à faire le travail deux fois et les avantages de Scrum sont diminués.

 

Ce chapitre décrit dix mesures clés pour guider les équipes Scrum.

Taux de réussite de l’objectif de sprint

Le taux de réussite de sprint est un des moyens pour mesurer la performance du projet Scrum. Le sprint peut ne pas avoir besoin que toutes les exigences et les tâches dans le backlog de sprint soient réalisées pour atteindre l’objectif minimum de sprint. Cependant, la réussite de sprint devrait avoir un incrément du produit fonctionnel qui remplit l’objectif du sprint et qui correspond à la définition de « terminé » de l’équipe Scrum : développé, testé, intégré et documenté.

 

Tout au long du projet, l’équipe Scrum peut suivre à quelle fréquence elle réussit à atteindre l’objectif de sprint et utiliser les taux de réussite pour voir si l’équipe arrive à maturité ou si elle doit corriger sa trajectoire. Les équipes devraient toujours se dépasser, donc 100 % du backlog de sprint ne constitue pas forcément l’objectif. Que les exigences individuelles parviennent à 100 % de « terminé » est important. Si le taux de réussite est inférieur à 100 % du backlog de sprint, ce sera l’occasion d’apprendre et d’améliorer. Le Scrum Master doit toujours être à la recherche de moyens pour réduire le retard de l’équipe afin qu’elle puisse atteindre des objectifs de plus en plus élevés. Les taux de réussite de sprint sont le point de départ de l’inspection et de l’adaptation.

La vélocité n’est pas un objectif ; elle se mesure juste après le sprint. Une vélocité accrue et le taux d’achèvement de l’objectif du sprint sont les deux principaux indicateurs qui mesurent en continu l’amélioration de l’efficacité de l’équipe Scrum.

 

Pour en savoir plus sur la définition des objectifs de sprint, reportez-vous au Chapitre 5 et sur la revue au Chapitre 6.

Défauts

Pour être vraiment agiles, les équipes Scrum doivent mettre en œuvre des pratiques agiles comme le pilotage du codage par les tests TDD (Test Driven Development) et l’intégration continue (CI). (Reportez-vous au Chapitre 12 pour de plus amples informations sur les tests TDD et l’intégration continue.) Sans de telles pratiques de qualité, l’équipe Scrum aura du mal à livrer de la qualité plus vite que le marché l’exige, à cause de la surcharge de tests manuels avant chaque livraison, et de la quantité de défauts masqués (que l’automatisation pourrait facilement détecter).

 

Il est peu probable qu’il existe une équipe Scrum capable d’atteindre la perfection. Tout projet peut potentiellement présenter des défauts. Les techniques agiles combinées au cadre Scrum permettent à l’équipe de développement de minimiser de façon proactive ces défauts.

 

Faire le suivi des mesures des défauts permet à l’équipe de développement de savoir comment anticiper les problèmes et quand améliorer le processus. Pour faire le suivi des défauts, il suffit d’observer les chiffres suivants :

•  Défauts au cours du développement : Si l’équipe de développement utilise des tests automatisés et l’intégration continue, elle peut suivre le nombre de défauts au niveau de la construction dans chaque sprint.
  En analysant le nombre de défauts de construction, l’équipe de développement peut déterminer s’il faut ajuster les processus de développement et les facteurs environnementaux.
  
•  Défauts des tests d’acceptation de l’utilisateur (UAT) : L’équipe de développement peut suivre le nombre de défauts que le propriétaire du produit trouve lors de sa recette des exigences dans chaque sprint.
  En faisant le suivi des défauts utilisateurs, l’équipe de développement et le propriétaire du produit peuvent identifier la nécessité d’affiner les processus pour comprendre les exigences. L’équipe de développement peut également déterminer s’il faut ajuster les outils de tests automatisés.
  
•  Défauts de livraison : L’équipe de développement peut suivre le nombre de défauts qui sont passés inaperçus jusqu’à la phase de livraison du produit sur le marché.
  En faisant le suivi des défauts de livraison, l’équipe de développement et le propriétaire du produit peuvent déterminer s’il faut apporter des modifications au processus UAT, aux tests automatisés et au processus de développement. Un grand nombre de défauts au niveau de la livraison révèle souvent des problèmes plus importants au sein de l’équipe Scrum.
  

Le nombre de défauts, qu’il augmente, qu’il diminue ou qu’il se stabilise, est un bon indicateur pour susciter des discussions sur les processus de projet et sur les techniques de développement pendant les rétrospectives de sprint.

Temps de mise sur le marché

Le temps de mise sur le marché est la durée nécessaire à un projet pour incarner une valeur du point de vue des fonctionnalités utilisateurs. Les entreprises peuvent percevoir cette valeur de deux manières :

•  Quand un produit génère directement des recettes, sa valeur est l’argent qu’il fait gagner.
•  Quand un produit est à usage interne d’une entreprise, sa valeur sera la capacité des employés à utiliser le produit et contiendra des facteurs subjectifs basés sur ce que le produit peut faire.

Pour mesurer le temps de mise sur le marché, tenez compte des valeurs suivantes :

•  Comptez la durée depuis le début du projet jusqu’à la première livraison valorisable du point de vue du client.
•  Certaines équipes Scrum déploient de nouvelles fonctionnalités du produit à la fin de chaque sprint. Pour les équipes Scrum devant fournir une livraison à chaque sprint, le temps de mise sur le marché est simplement la durée de sprint, mesurée en jours.
•  D’autres équipes Scrum planifient des livraisons après plusieurs sprints et déploient des fonctionnalités du produit en groupes. Dans ce cas, le temps de mise sur le marché est le nombre de jours entre le début du développement d’une fonctionnalité et sa livraison.

Le temps de mise sur le marché permet aux entreprises de reconnaître et de quantifier la valeur des projets Scrum en continu. Cette mesure est particulièrement importante pour les entreprises ayant des produits qui génèrent des recettes, car elle aide à la budgétisation au long de l’année.

Retour sur investissement

Le retour sur investissement (ROI) correspond aux recettes générées par le produit diminué du coût du projet : recettes moins dépenses. Dans un projet Scrum, le retour sur investissement est fondamentalement différent de celui des projets traditionnels. Les projets Scrum permettent de générer des recettes dès la première livraison (soit potentiellement dès la fin du premier sprint) et d’augmenter ces recettes à chaque nouvelle livraison.

 

Imaginez deux scénarios avec les mêmes coûts de projet et la même durée de production. Je ne connais pas le coût de la documentation supplémentaire, des réunions et les autres dépenses du projet dans sa version en cascade ; je suppose que tout est identique au projet Scrum pour simplifier. Les deux scénarios commencent le 1^er janvier et ont le potentiel de générer 100 000 euros de recettes par mois, une fois que toutes les exigences seront remplies :

•  Le scénario A est le projet en cascade et présente la livraison une fois toutes les exigences satisfaites, soit le 30 juin de la même année. Il génère 100 000 euros par mois jusqu’à la fin de l’année (soit sur six mois, 600 000 euros de recettes).
•  Le scénario B commence à livrer la partie fonctionnelle offrant la valeur client la plus élevée de manière progressive dès le 31 janvier après quatre sprints d’une semaine, cinq mois plus tôt que le projet A. Les recettes mensuelles sont inférieures, car elles croissent chaque mois à partir de la première livraison (soit 50 000 euros en février, 60 000 euros en mars, 70 000 euros en avril, 80 000 euros en mai et 90 000 euros en juin) jusqu’à ce que l’ensemble du projet soit terminé, donc en juin.

Ces recettes supplémentaires des cinq mois de février à juin donnent au projet 950 000 euros de revenus pour l’année, soit 350 000 euros de plus que le scénario A.

Comme le temps de mise sur le marché, les mesures du retour sur investissement sont un excellent moyen pour une entreprise d’apprécier la valeur instantanée d’un projet Scrum. Ces mesures permettent de rendre compte des projets dès le début, parce que les entreprises peuvent financer les projets en fonction de leur potentiel de retour sur investissement. Les entreprises peuvent suivre la rentabilité des projets individuels ainsi que celle de l’entreprise dans son ensemble.

Total de la durée et du coût du projet

Pour calculer le retour sur investissement, vous partez de la durée et du coût. Ces deux valeurs doivent faire partie des mesures fondamentales des projets Scrum.

 

Un retour sur investissement plus élevé grâce à la réduction des délais et des coûts est la preuve que les équipes Scrum essaiment davantage, réduisent les échecs et améliorent l’efficacité globale.

Les nouvelles demandes dans les budgets de retour sur investissement

La capacité de générer rapidement un retour sur investissement plus élevé fournit aux entreprises utilisant Scrum l’opportunité de financer le développement de produits supplémentaires. Les nouvelles fonctionnalités du produit se traduisent souvent par des recettes plus élevées.

 

En conservant l’exemple précédent, supposons que l’équipe du projet ait identifié une nouvelle fonctionnalité début juin et que sa réalisation demanderait quatre sprints d’une semaine. Elle permettrait d’augmenter les revenus de 100 000 euros par mois à 120 000 euros par mois.

 

Dans le scénario B, si la nouvelle fonctionnalité est identifiée plus tôt, le retour sur investissement augmentera encore plus.

 

Si un projet génère déjà des revenus, il est intéressant pour l’entreprise de placer cet argent dans un nouveau développement pour augmenter ses revenus.

 

Suivre le retour sur investissement fournit les informations nécessaires pour prendre cette décision.

Redéployer le capital

Lorsque le coût du futur développement est plus élevé que la valeur de ce développement, il est temps de mettre fin au projet.

 

Le propriétaire du produit priorise les exigences, notamment en évaluant la capacité de chacune à générer des recettes. Si seules les exigences à faible rentabilité restent à faire dans le backlog, on peut mettre fin au projet avant que l’équipe Scrum ait épuisé tout son budget. L’entreprise peut alors utiliser le reliquat de l’ancien projet pour en commencer un nouveau, plus rentable. La pratique consistant à transférer le budget d’un projet à un autre est appelée redéploiement du capital.

 

Pour déterminer la fin d’un projet, tenez compte des mesures suivantes :

•  La valeur (V) des exigences en attente de production dans le backlog de produit.
•  Le coût actuel (CA) du travail pour réaliser les exigences du backlog de produit.
•  Le coût d’opportunité (CO), ou la valeur de l’équipe Scrum qui travaille sur un nouveau projet

Si V < CA + CO (ou CA + CO > V, comme expliqué au Chapitre 5), le projet doit être arrêté. Le coût de production de la fin du projet sera supérieur à la valeur que ces compléments vont apporter.

 

Le redéploiement du capital permet à l’entreprise d’investir efficacement dans un développement de produits viable et de maximiser le retour sur investissement global de l’entreprise.

Enquête de satisfaction

La première priorité d’une équipe Scrum est de satisfaire le client, très tôt et souvent, en lui fournissant de la valeur. En même temps, l’équipe Scrum doit motiver ses membres et promouvoir des pratiques de développement durable.

 

Une équipe Scrum tire avantage des connaissances plus détaillées qu’elle a de sa clientèle et des expériences de membres de l’équipe. Une façon d’obtenir des informations mesurables sur la façon dont une équipe Scrum atteint ses objectifs sont les enquêtes de satisfaction :

•  Les enquêtes de satisfaction sur les clients mesurent l’expérience du client avec le projet, le processus et l’équipe Scrum.
  L’équipe Scrum peut utiliser les enquêtes clients à plusieurs reprises au cours d’un projet, y compris dès le début pour définir un point de référence pour de futures comparaisons. L’équipe Scrum peut utiliser les résultats de l’enquête de satisfaction clients pour examiner les processus, continuer les pratiques positives et ajuster un comportement, si nécessaire.
  
•  Les enquêtes de satisfaction de l’équipe mesurent l’expérience des membres de l’équipe Scrum avec l’entreprise, l’environnement de travail, les processus, les autres membres de l’équipe de projet et leur travail. Tous les membres de l’équipe Scrum peuvent participer aux enquêtes.
  Comme pour l’enquête de satisfaction des clients, l’équipe Scrum peut soumettre des enquêtes en cours d’un projet. Les membres de l’équipe Scrum peuvent utiliser les résultats de l’enquête régulièrement pour affiner et ajuster les comportements du personnel et de l’équipe. L’équipe Scrum peut également utiliser les résultats pour résoudre les problèmes organisationnels. Les enquêtes de satisfaction client sur le long terme permettent de porter un regard quantitatif sur la maturité de l’équipe.
  

Vous pouvez faire des enquêtes papier ou utiliser l’un des nombreux outils d’enquête en ligne. Certaines entreprises ont même un logiciel d’enquête disponible dans leur service des ressources humaines.

Rotation des membres de l’équipe

Les membres d’équipe qui travaillent sur des projets Scrum ont tendance à avoir un meilleur moral. Mesurer la rotation des membres de l’équipe permet de quantifier ce moral. Observez les chiffres suivants :

•  Rotation des membres de l’équipe : Une faible rotation des membres de l’équipe est signe d’un environnement sain. Si le taux de rotation est élevé (dû à un surmenage professionnel, à un propriétaire de produit inefficace qui abuse de l’engagement de l’équipe de développement, à des incompatibilités de personnalité ou à un Scrum Master qui ne parvient pas à éliminer les obstacles, ce qui fait paraître inefficace l’équipe de développement dans des revues de sprint) c’est signe qu’il y a des problèmes avec le projet, l’organisation, le travail, entre les membres de l’équipe Scrum ou plus généralement qu’il y a une mauvaise dynamique de l’équipe.
  Les membres de l’équipe pourraient démissionner, ou les managers pourraient écarter certains membres de l’équipe en les affectant à d’autres projets. Quoi qu’il en soit, le résultat sera une augmentation des conflits ce qui mettra au jour les questions d’organisation qui devront être résolues.
  
•  Rotation au sein de l’entreprise : Le taux de rotation du personnel de l’entreprise, même si elle ne possède pas d’équipe Scrum, peut avoir un impact sur le moral et l’efficacité. Un taux de rotation élevé est signe de problèmes au sein de l’entreprise. Si l’entreprise adopte Scrum, une diminution de la rotation du personnel devrait se faire sentir.
  Lorsque l’équipe Scrum prend connaissance de ces chiffres, elle comprend les raisons qui se cachent derrière et peut alors prendre des mesures pour maintenir le moral et améliorer son environnement de travail.
  

Abandon de projets

Les entreprises ayant des portefeuilles de projets de toute taille doivent suivre le taux des projets avortés. Le redéploiement du capital ne doit pas se confondre avec une surcharge de projets des équipes selon le bon vouloir des cadres supérieurs. Comparer le suivi de la durée des projets à l’analyse de redéploiement du capital permet de mettre en lumière des tendances : abandon prématuré de projets ou poursuite plus longtemps que nécessaire.

 

À partir de ces tendances, les gestionnaires de portefeuille peuvent se demander pourquoi ces projets ont avorté. Un taux d’abandon élevé peut révéler des problèmes de planification, de priorisation, d’obstacles, ou de polyvalence.

 

Pour en savoir plus sur la façon dont Scrum améliore la gestion de portefeuille, reportez-vous au Chapitre 12.

Polyvalence

Les équipes Scrum fortes sont généralement les plus polyvalentes. En éliminant les points de défaillance dans une équipe Scrum, vous augmentez sa capacité de progresser plus rapidement et de mieux produire qualitativement. Faire le suivi de la polyvalence des compétences permet à l’équipe Scrum et aux managers de mesurer la croissance de la polyvalence.

 

Reportez-vous au Chapitre 13 pour en savoir plus sur la motivation et le développement des compétences des équipes Scrum.

 

Au début du projet, notez les compétences et les niveaux actuels contenus dans chacune des structures organisationnelles suivantes :

•  compétences et niveaux par personne ;
•  compétences et niveaux par équipe ;
•  compétences et niveaux par entreprise.

Au fil du temps, chaque personne augmente sa palette de compétences et son niveau. De même pour chaque équipe. Ce n’est pas le nombre de managers ou d’administrateurs par service qui doit déterminer la livraison de produits et de services de qualité. L’équipe Scrum doit être formée par des membres qui peuvent tous contribuer à l’objectif de sprint, chaque jour, sans risquer l’échec.

Ratio managers/créateurs

Généralement, plus l’entreprise est grande, plus la hiérarchie est importante. De nombreuses entreprises n’ont pas compris comment bien fonctionner sans managers pour gérer le personnel. Vous devez trouver le juste équilibre entre managers et personnel de production.

Chaque euro dépensé pour une personne qui gère le processus organisationnel est un euro non dépensé pour un créateur de produit.

 

Faites le suivi du ratio manager/créateur pour identifier le surnombre de managers et les façons de réduire les investissements en personnel d’encadrement (qui ne produisent pas directement).