Les indicateurs de performance, ou KPIs, sont essentiels pour mesurer la progression du projet, et mener les équipes vers le succès. Sans eux, impossible d’assurer un suivi de qualité du projet.
Le problème, c’est que les indicateurs de performance utilisés traditionnellement ne sont pas adaptés aux projets agiles. Il faut donc utiliser d’autres indicateurs.
Dans cet article, je passe en revue les indicateurs les plus courants utilisés en agile, et je vous explique pour chacun d’entre eux comment ça marche, et dans quel cas l’utiliser.
Qu’est-ce qu’un indicateur de performance agile ?
Un indicateur de performance agile, ou KPI (Key Performance Indicator), permet d’évaluer la qualité du produit développé, et de mesurer la progession de l’équipe dans l’atteinte de ses objectifs. Il s’agit de métriques quantitatives, telles que la vélocité de l’équipe, le burndown chart, le Net Promoter Score, ou encore le diagramme de flux cumulé.
Ces indicateurs, ou métriques, ne sont pas imposés par les parties prenantes, la direction, ou le chef de projet, comme cela peut parfois être le cas dans la gestion de projet traditionnelle.
Comme l’équipe agile est auto-organisée, c’est à elle de définir quels sont les indicateurs les plus à même de refléter le travail réalisé. Ces métriques peuvent bien sûr évoluer avec le temps, et l’équipe peut également décider de les supprimer si elle juge qu’il n’y a plus d’utilité à les calculer.
Le suivi de ces KPI permet à l’équipe agile de s’adapter en cours de projet, et de gagner en flexibilité. Par exemple dans Scrum, chaque sprint se termine sur une rétrospective, permettant à l’équipe de faire le point sur le travail réalisé et la manière de travailler, et d’apporter des améliorations dans le processus.
Dans ce cas, il peut être utile d’avoir quelques métriques sous la main pour identifier des axes de progrès.
Parmi les indicateurs agiles les plus connus, on peut citer la vélocité de l’équipe, le burndown chart de sprint, et le burnup de release.
KPI traditionnels vs KPI agiles : Quelles différences ?
Les indicateurs de performance utilisés dans les méthodes prédictives de gestion de projet ne se prêtent pas bien au mode agile.
En effet, ceux-ci sont principalement concentrés sur la mesure du résultat (le nombre de tâches terminées par exemple), alors qu’en agilité on met le focus sur la valeur apportée et l’ouverture au changement, plutôt que le respect d’un plan.
J’ai listé pour vous dans ce tableau les principales distinctions existantes entre les métriques traditionnelles et les KPI agiles :
Caractéristiques | Indicateurs traditionnels | Indicateurs agiles |
---|---|---|
Utilisation | Analyse le respect de la roadmap et du plan d’action. | Mesure la qualité de l’incrément (la livraison). |
Mesure | Mesure la réussite du projet, via les triples contraintes : Qualité, Coûts, Délais. | Mesure la valeur ajoutée du produit, et la satisfaction client. |
Objectif | Déterminer si les exigences documentées dans le cahier des charges sont toutes respectées. | Définir si l’objectif du produit est atteint. |
Demandes de changement | Mesurer le nombre de changements apportés par rapport au plan initial et au cahier des charges. | Déterminer si les feedbacks client ont permis de réaliser des ajustements rapidement (C’est la boucle de rétroaction). |
Travail d’équipe | Analyse le travail individuel, et réduit les goulots d’étranglements au sein de l’équipe projet. | Analyse l’efficacité de la collaboration entre membres de l’équipe agile et les parties prenantes. |
Destinataires | Membres du Comité de Pilotage, Management hiérarchique, Parties prenantes. | Avant tout l’équipe de développement agile. |
Pour aller + loin : Je vous invite à consulter cet article sur les KPI ou indicateurs de performance utilisés dans les méthodes prédictives, pour mieux comprendre la différences avec les métriques agiles.
Quelles métriques agiles utiliser ?
Avant de vous précipiter dans la mise en place de KPI agile, vous devriez toujours vous poser ces quelques questions :
- Pourquoi vouloir mettre en place cet indicateur ? Qu’est-ce que je cherche à mesurer ?
- A qui cet indicateur est-il destiné ?
- En quoi cette métrique peut-elle aider l’équipe agile à s’améliorer au fil des sprints ?
- Quels sont les effets de bord ou les effets pervers que cet indicateur pourrait engendrer ? Comment s’en prémunir ?
Gardez en tête que ces indicateurs doivent être quantitatifs et qualitatifs, qu’ils ne se suffisent pas forcément à eux-mêmes, et qu’il peut être utile d’en combiner plusieurs ensemble, en fonction du but que vous recherchez.
Il existe au total 3 types d’indicateurs agiles :
- Les indicateurs d’efficacité et de prévisibilité.
Il s’agit généralement de mesurer la vélocité de l’équipe, de regarder le nombre de user stories commencées vs terminées, … Ces indicateurs permettent ainsi d’avoir une idée de l’efficacité de l’équipe, et d’anticiper ce qui pourrait se passer sur les prochains sprints. - Les indicateurs de qualité.
Ces indicateurs s’intéressent à la qualité du produit et de ses incréments. On peut donc mesurer la valeur apportée par le produit, le nombre de bugs en production, le respect de la definition of done, … - Les indicateurs de satisfaction.
Il peut s’agir de mesurer la satisfaction du client, des utilisateurs finaux, ou encore l’humeur et la motivation de l’équipe. Il s’agit des indicateurs les plus intéressants, car la satisfaction client et utilisateurs finaux est ce qu’on cherche in fine à atteindre en mode agile.
1 ) La vélocité de l’équipe
La vélocité est un indicateur de mesure agile qui permet de déterminer la quantité de travail qu’est capable de fournir une équipe agile sur un sprint. L’indicateur de vélocité se calcule à chaque itération d’un projet agile, et correspond à la somme totale des points d’efforts des items réalisés à la fin du sprint.
Pour calculer la vélocité, rien de plus simple : il suffit d’additionner les story points des user stories entièrement développées durant le sprint. On ne prend en compte que les fonctionnalités 100% terminées d’après la definition of done.
Par exemple, si j’ai les user stories du tableau ci-dessous en fin de sprint, alors ma vélocité est de 5 + 3 + 1 + 8 + 3 = 20 points.
User Stories | Story Points | Etat |
---|---|---|
Tâche 1 | 5 | Réalisée |
Tâche 2 | 3 | Réalisée |
Tâche 3 | 1 | Réalisée |
Tâche 4 | 8 | Réalisée |
Tâche 5 | 3 | Réalisée |
Tâche 6 | 5 | En Cours |
Exemple de vélocité agile
2 ) Burndown du sprint
Le burndown chart est un graphique à deux axes, qui comprend sur l’axe horizontal le temps de travail compris dans un sprint (le nombre de jours) et sur l’axe vertical le total des points d’efforts pour atteindre l’objectif de sprint.
Le burndown graph comprend généralement deux courbes :
- La baseline, ou courbe de référence.
Il s’agit de la courbe idéale d’avancement du travail dans un sprint. Il s’agit d’une courbe linéaire partant du nombre total de points d’efforts à réaliser dans le cadre du sprint le jour 0, pour arriver au dernier jour du sprint à un « reste à faire » égal à zéro. - La courbe d’avancement réel.
Il s’agit de la courbe représentant dans le temps l’avancement du travail de l’équipe sur le sprint, ainsi que le « reste à faire ». Cette courbe n’est pas linéaire. Elle peut monter si de nouveaux éléments intègrent le sprint backlog. Elle baisse dès lors qu’un élément du backlog est considéré comme terminé, c’est à dire en respectant la definition of done.
Exemple de Burndown Chart réalisé sur Excel
3 ) Burndown d’epic & burndown de version
Le burndown d’epic ou burndown de version est un indicateur similaire au burndown de sprint, sauf qu’il s’étale sur un temps plus long. Il montre l’avancement du développement d’un travail, étalé sur plusieurs sprints.
Il peut être intéressant de le suivre, en plus du burndown de sprint, car les sprints agiles peuvent contenir des tâches issues de plusieurs epics et versions différentes.
C’est donc un bon indicateur pour suivre l’avancement de ces epics et versions, en plus du travail réalisé / restant du sprint en cours.
Exemple de burndown d’epic ou de version
4 ) Burnup de release
Le burnup chart est un graphique à deux axes, qui comprend sur l’axe horizontal le nombre de sprints et sur l’axe vertical le total des points d’efforts pour atteindre l’objectif de sprint.
Le burnup graph comprend généralement deux courbes :
- Le périmètre.
Il s’agit de la courbe représentant l’évolution du périmètre à réaliser afin de livrer un produit, une feature ou une release. Cette courbe peut évoluer à la hausse ou à la baisse, le périmètre étant variable en gestion de projet agile. - La courbe d’avancement de l’équipe.
Il s’agit de la courbe représentant le travail accompli par l’équipe de développement au fur et à mesure des itérations, en prenant en compte la vélocité de chaque fin de sprint. Cette courbe n’est pas linéaire.
Exemple de Burnup Chart
5 ) Diagramme de flux cumulé
Le diagramme de flux cumulé est un indicateur très populaire en agilité, qui provient de l’univers du Kanban, et qui consiste à mesurer le nombre de story points (ou de tickets) dans chaque étape du cycle de vie du produit à un instant t.
Concrètement, on crée un graphique à deux axes :
- A l’horizontal, on représente le nombre de jours passés, afin de mettre à jour quotidiennement l’indicateur.
- A la verticale, on représente le nombre de story points (ou de tickets).
On trace ensuite une courbe représentant pour chaque jour le volume de story points dans chaque étape (ou colonne) du board de l’équipe, en commançant par la dernière colonne du board (s’affichera tout en bas du graphique), puis en ajoutant les autres par-dessus.
Il peut être également intéressant d’ajouter le nombre de story points des user stories dans le sprint backlog ou le product backlog qui n’ont pas été démarrées.
A ce stade, un graphique est sûrement plus parlant. Voici à quoi un diagramme de flux cumulé ressemble :
Exemple de diagramme de flux cumulé
6 ) Stories terminées vs stories engagées
Ce KPI permet de mesurer la prévisibilité de l’équipe, et est un bon complément à la vélocité de l’équipe. Il permet de voir ce sur quoi l’équipe s’est engagée pour le sprint, et ce qui est réellement terminé actuellement.
Un écart important entre la vélocité et le nombre de user stories engagées par l’équipe nous fait dire que l’équipe s’est engagée sur plus de travail qu’elle ne pouvait produire, ou alors s’est lancée sur trop de tâches à la fois.
Cet indicateur est aussi rapide à calculer que la vélocité, et s’affiche généralement via une ligne au-dessus de la vélocité.
En haut le nombre de US engagées par l’équipe (planifiées pour le sprint), en bas la vélocité de l’équipe (travail 100% terminé)
7 ) NPS – Net Promoter Score
Le Net Promoter Score, ou NPS, est un indicateur permettant de mesurer la fidélité et la satisfaction des clients et utilisateurs finaux. Il permet notamment de quantifier ce que le client pense d’un produit.
Contrairement à certaines enquêtes de satisfaction client qui peuvent être complexes à analyser sans introduire de biais, le NPS est un score simple et efficace afin de recueillir du feedback rapidement.
On le retrouve notamment dans des questions comme « Quelle est la probabilité entre 1 et 10 que vous recommandiez ce produit à un ami ou un collègue ? ». Plus la note est élevée, plus la fidélité et la satisfaction est élevée.
En plus de cette réponse, on peut aussi aller chercher un verbatim au format texte, pour compléter celle-ci et donner plus de contexte.
Méthode de calcul du Net Promoter Score
8 ) Nombre de bugs en production
Il peut être intéressant pour une équipe agile ou Scrum de s’intéresser au nombre de bugs rencontrés en production. Plus le nombre de bugs rencontrés est important, moins la qualité du travail est bonne.
Il y a deux écoles à ce sujet :
- Compter le nombre de bugs.
On compte tout simplement d’un sprint à ‘lautre ou d’une version à l’autre le nombre de bugs (et de tickets) recensés en production. - Analyser le ratio User Stories buguées / US livrées.
On compare le nombre de US buguées versus le nombre de US livrées au travers de l’incrément de produit ou de la version.
Personnellement, je préfère analyser le ratio, car plusieurs bugs peuvent concerner la même User Story. On peut ainsi déterminer s’il y a eu un couac unique sur une US, ou si il y a un problème sous-jacent plus profond et plus grave.
9 ) Lead time
Le lead time est le délai qui s’écoule entre l’expression de besoin d’une fonctionnalité et sa livraison dans un incrément de sprint.
Cet indicateur permet notamment de mesurer l’agilité de l’équipe, et sa réactivité face à une nouvelle fonctionnalité.
10 ) Time to market
Le time to market est un indicateur mesurant le délai entre l’émergence d’une idée et la mise sur le marché du produit.
Une équipe agile efficace fera tout pour réduire le time to market, ce qui permettra également de collecter du feedback utilisateur plus rapidement.
Afin de mesurer le time to market d’une release ou d’un produit, il est primordial de connaître en amont quel est le lead time.
11 ) Temps moyen de résolution des incidents
Le temps moyen de résolution des incidents permet de mesurer la réactivité de l’équipe face à un bug avéré en production.
Plus la vitesse de résolution des incidents est élevée, plus vos utilisateurs et clients seront satisfait de votre réactivité et de votre professionnalisme.
12 ) Niko Niko
Le niko niko est un mood board permettant de mesurer l’humeur et la motivation de l’équipe dans le temps. Chaque jour, lors du daily Scrum, chaque membre de l’équipe indique comment il se sent : Vert – tout va bien, Jaune – Neutre, peut mieux faire, Rouge – Mauvaise humeur.
Il peut être intéressant de suivre le mood de l’équipe au fur et à mesure de l’avancement du sprint et de la release, afin de corréler cette information avec d’autres.
Dans son livre Management 3.0, Jurgen Appelo propose la mise en place d’un calendrier Niko-Niko, afin de suivre sur un mois complet l’humeur de chaque membre de l’équipe.
Calendrier Niko-Niko
13 ) Confiance dans l’atteinte du sprint goal
Cet indicateur permet de mesurer la confiance de l’équipe dans sa capacité à atteindre le sprint goal, ou l’objectif de sprint. Il est intéressant de suivre cet indicateur quotidiennement lors du daily Scrum, afin d’identifier de potentiels problèmes et blocages, qui peuvent être résolus sans attendre.
Il est important que l’équipe agile maintienne un haut niveau de confiance dans sa capacité à atteindre l’objectif de sprint.
Je vous conseille de mesurer cet indicateur, puis de le regarder de manière objective lors de la rétrospective afin d’identifier des axes de progrès, notamment s’il est trop bas par rapport à vos standards.
14 ) Lead time improvement
Le lead time improvement permet de mesurer la santé de l’équipe, au travers du nombre d’axes de progrès identifiés et définis lors de la rétrospective de sprint, puis en mesurant le pourcentage de ces actions qui ont été mises en place lors du sprint suivant
Une équipe en bonne santé aura tendance à mettre rapidement en place les actions identifiées, selon le principe de l’amélioration continue.
Il peut également être intéressant de vérifier quelques sprints plus tard si la mise en place de ces actions à bien porté ses fruits.
15 ) Taux de couverture du code
Le taux de couverture du code est un indicateur mesurant le pourcentage de code qui a été couvert par les tests unitaires.
Plus le pourcentage de code informatique couvert par les tests est important, plus faible est la probabilité d’obtenir des bugs en production.
Attention, ne vous méprenez pas cependant. Ce n’est pas parce que le taux de couverture du code est élevé que la qualité du travail fourni est élevé.
Cela représente simplement les efforts mis en place par l’équipe de développement pour garantir la qualité du produit.
16 ) Nombre de user stories reportées sur les sprints ultérieurs
Le nombre de user stories reportées sur les sprints ultérieurs est un indicateur intéressant pour mesurer la fiabilité de l’équipe agile.
Un taux élevé signifie que l’équipe agile n’arrive pas à finir ce qu’elle a commencé, ou encore qu’elle a du mal à estimer la capacité de travail qu’elle peut réaliser dans le cadre d’un sprint.
Je vous recommande d’avoir une certaine marge de tolérance, de l’ordre de + ou – 20%, pour accepter la variabilité, les imprévus, etc.
Cet indicateur devrait également être suivi lors de la rétrospective de l’équipe.
17 ) Taux de turn-over
Le taux de turn-over permet de mesurer le nombre de collaborateurs qui quittent la société. C’est un bon indicateur pour la santé d’une équipe, d’un service ou encore d’une entreprise.
Un taux de turn-over élevé peut indiquer une inadéquation entre ce que l’entreprise propose et les attentes de ses salariés, et entraîne souvent une perte de savoir, et un coût de recrutement et de formation important pour remplacer la personne qui vient de partir.
18 ) Coefficient de focalisation
Le coefficient de focalisation est un indicateur qui mesure le nombre de story points validés, en comparaison avec le nombre de jours travaillés. Il vient en complément de la vélocité, et permet d’obtenir une tendance pour l’équipe agile :
- A équipe constante, la tendance baissière indique une augmentation de la dette technique, une démotivation des membres de l’équipe ou un blocage important.
- A équipe constante, la tendance à la hausse indique que les améliorations et autres actions portent leurs fruits. Il faut continuer sur cette lancée.
- Lorsque l’effectif de l’équipe augmente, il est normal qu’il y ait une baisse avant de remonter. La montée en compétences et la formation prennent du temps.
- Lorsque l’effectif de l’équipe diminue, il est normal de constater une baisse, puisque la charge de travail réalisable a également diminuée (-1 personne).
19 ) Business value livrée
La business value livrée permet de mesurer dans le temps la valeur business délivrée via le produit, au fur et à mesure des sprints. L’objectif est de délivrer un maximum de valeur le plus tôt possible.
Pour cela, on va indiquer pour chaque User Story quelle est la valeur business délivrée, et mesurer sous forme de ligne cette information, au fur et à mesure de la livraison des incréments de sprints.
La business value délivrée se présente généralement sous forme de graphique à deux axes :
- A l’horizontal, le nombre de sprints.
- A la verticale, la valeur business livrée.
Une équipe agile bien rôdée, qui délivre beaucoup de valeur rapidement, devrait avoir un graphe ressemblant à celui-ci :
Exemple de graphique de valeur business livrée
20 ) Squad Health Check
Le squad health check est un indicateur mis en place chez Spotify, permettant de mesurer la santé d’une équipe ou de plusieurs équipes à la fois.
Les équipes de Spotify ont fait un retour d’expérience complet de la manière dont ils implémentent cet indicateur, dans cet article. C’est en anglais, et je vous recommande chaudement de le lire, et pourquoi de le tester dans votre équipe.
L’avantage, c’est qu’on obtient à la fois un indicateur permettant à l’équipe de s’améliorer dans le temps. Mais on peut également consolider ces indicateurs afin d’avoir un tableau récapitulatif de la santé de toutes les équipes agiles de l’entreprise.
Exemple de Squad Health Check
Tableau consolidé des Squad Health Check des différentes équipes
5 erreurs à éviter en choisissant ses indicateurs de performance agile
Pour bien choisir et définir vos indicateurs agiles, je vous recommande de prêter attention aux 5 erreurs suivantes, qui sont les erreurs que l’on rencontre le plus souvent, et que vous devez absolument éviter de reproduire :
- Ne pas aligner les enjeux et les moyens.
Lorsqu’on crée un indicateur, il est nécessaire d’aligner les enjeux (ce qu’on cherche à mesurer) et les moyens (comment influer sur cet indicateur). Un bon KPI est donc un indicateur sur lequel l’équipe a la main dessus, et peut réagir en cas de problème avéré. - Laisser les parties prenantes et le management hiérarchique choisir les indicateurs.
Le principe de l’agilité est que l’équipe agile est auto-organisée. On ne peut donc pas lui imposer une manière de travailler ou de mesurer ses résultats. C’est à l’équipe, et à elle seule, de définir quels sont les indicateurs pertinents à utiliser pour répondre aux attentes des parties prenantes. - Définir des objectifs chiffrés sur les indicateurs agiles.
Demander sur le prochain sprint de « doubler la vélocité » est idiot. Le seul focus de l’équipe doit être d’apporter de la valeur, pas de doubler un chiffre pour faire plaisir au top management. De plus, ce genre d’injonction peut engendrer des effets néfastes, tels que des estimations gonflées sur les user stories pour atteindre le chiffre. Ce qui valait un 5 avant vaut maintenant un 8. Cela peut aussi inciter l’équipe à traiter plus de user stories par sprint, au détriment de la qualité et de la definition of done. - Considérer la vélocité comme un KPI.
La vélocité permet à l’équipe d’avoir de la prédictibilité pour ses prochains sprints. On peut ainsi estimer le nombre de fonctionnalités à développer dans les sprints suivants, mais ce n’est en aucun cas un indicateur présumant des résultats de l’équipe. - Ne pas évaluer l’intérêt ni le pourquoi d’un indicateur.
Un indicateur doit être revu sur une base régulière. S’il n’est plus pertinent, on l’élimine. Posez-vous pour cela les questions décrites au prochain paragraphe, afin de juger de son intérêt.
Comment savoir si mes indicateurs KPI sont vraiment nécessaires ?
Pour savoir si vos KPI agiles sont vraiment nécessaires, je vous invite à vous poser la liste de questions suivantes, en équipe. La rétrospective de fin de sprint peut être le moment idéal pour cela :
- Pourquoi mettre en place cet indicateur ? Qu’est-ce qu’on cherche à mesurer ?
- A qui cet indicateur est-il destiné ? Pour qui cet indicateur apporte t-il de la valeur ?
- Est-ce que cet indicateur fait encore sens ?
- En quoi cet indicateur apporte t-il de la valeur pour mon entreprise ? Pour les utilisateurs finaux ? Pour les clients ?
- En quoi cette métrique aide l’équipe agile à s’améliorer tout au long du projet ?
- Quelle est la source de mon indicateur ? Sur quelles données je me base pour le construire ?
- Ces données sont-elles fiables, et permettent-elles une analyse objective ? Ou peuvent-elles engendrer de mauvaises interprétations et des effets néfastes pour le projet et pour l’équipe ?
- Ce KPI a t-il engendré des effets pervers au sein de l’équipe, de l’entreprise, ou dans la communication avec les parties prenantes du projet ? Comment s’en prémunir à l’avenir ?
- Le rapport bénéfices / coûts est-il en faveur des bénéfices apportés ? Autrement dit, ce KPI a t-il démontré qu’il apporte plus de bénéfices à l’équipe, l’entreprise ou les clients, que ce qu’il demande (en temps et en argent) à produire ?
- Cet indicateur remplit-il les 3 caractéristiques suivantes : fiable, précis et opportun ?
- Fiable : Mesurable de manière constante dans le temps et de la même façon.
- Précis : Clair et sans ambiguïté.
- Opportun : Fournit une mesure des changements opérés.
Faut-il vraiment mesurer la progression d’une équipe agile ?
Certains agilistes vous diront que l’utilisation d’indicateurs de performance en agilité est une hérésie. Je ne suis pas d’accord. Cela peut en effet apporter des bénéfices certains. A condition de prendre cependant quelques précautions.
1 ) Les risques des indicateurs agiles
Il existe en effet quelques risques dont il faut absolument se prémunir :
- (Re)tomber dans le faux agile.
On peut vite se faire avoir et retomber dans une relation de reporting constant auprès du management hiérarchique, où l’on doit rendre des comptes sur sa productivité, comme dans les projets traditionnels. C’est contre-productif car le focus en agilité n’est pas la productivité de l’équipe, mais plutôt la qualité du travail fourni ainsi que la valeur apportée au client. - Le phénomène des indicateurs « pastèque ».
Des KPI mal pensés peuvent créer ce phénomène, où tout va bien en apparence, tout semble vert (pour faire plaisir au Scrum master, au Product Owner ou aux parties prenantes), mais lorsqu’on gratte un peu le sujet, on s’aperçoit que cela cache de véritables problèmes. - Les mauvaises interprétations et les effets pervers.
Les indicateurs doivent être clairs et factuels, pour éviter les vanity metrics, et ne pas laisser de place à l’interprétation, qui pourrait engendrer des effets pervers, néfastes et allant à l’inverse de ce que l’on avait imaginé à la base.
Dans ces livres, l’auteur Christian Morel évoque de nombreuses décisions managériales, qui ont amené un effet contraire à ce qui était recherché. C’est clairement tout ce que vous voulez éviter !
2 ) Les avantages des indicateurs agiles
Pour autant, les indicateurs peuvent apporter beaucoup à l’équipe agile, l’entreprise, les clients et les utilisateurs finaux.
- Aident l’équipe à s’améliorer.
Les KPI permettent à l’équipe en rétrospective d’analyser le travail réalisé et la manière de collaborer, afin d’identifier constamment de nouveaux axes de progrès. - Amélioration de la qualité.
Lorsqu’elle est suivi, la qualité à tendance à s’améliorer. La definition of done s’affine et devient de plus en plus rigoureuse, et le nombre de bugs en production diminue. - Maximisation de la valeur apportée.
Bien définis, les indicateurs permettent à l’équipe agile et à l’entreprise de se concentrer sur la valeur du produit et sa maximisation, plutôt que sur des vanity metrics sans intérêt, focus uniquement sur la productivité. - Augmentation de la satisfaction client.
En mesurant la satisfaction client, cela permet de mieux comprendre leurs attentes et leurs besoins, et d’adapter le projet en conséquence. - Pilotage d’un projet par la valeur, plutôt que par la performance.
On peut tout à fait respecter l’ensemble des exigences d’un cahier des charges, respecter les échéances, les coûts et se planter. Malgré ça, le projet est un échec. C’est le pilotage par les indicateurs, ou par la performance. Le pilotage par la valeur permet justement d’éviter cela. On considère alors qu’un projet réussi est un projet qui a apporté de la valeur au client et pour lequel il est satisfait.
Le pilotage par la valeur s’assure du succès d’un projet, même si tous les indicateurs de performance classiques ne sont pas respectés. Crédit : Henrick Kniberg.
Pour aller plus loin, Eric Ries propose dans son livre Lean Startup de mettre en place des indicateurs AAA : Actionnable, Accessible et Auditable.
- Actionnable.
Lorsque l’indicateur n’est pas dans le vert, l’équipe peut directement agir dessus en réalisant une action spécifique. Mesurer des choses sur lesquelles l’équipe n’a pas la main dessus n’a aucun sens. - Accessible.
L’indicateur est visible et accessible de tous. On l’affiche généralement sur le Scrum Board ou le Kanban Board de l’équipe. - Auditable.
Chacun comprend comment l’indicateur est alimenté, et sur la base de quelles données. Il n’est donc ni falsifiable, ni interprétable.