Quand on considère l'adoption de l'Agilité, la question peut se poser de savoir comment mesurer la valeur métier que peut rapporter le développement logiciel agile.
Dans la publication Métriques Agiles : Mesurer la valeur du processus, Michael Moore explique pourquoi il est important de mesurer la valeur apportée par l'Agilité :
(...) L'Agilité n'est pas seulement une question de rendement, elle se concentre aussi sur l'efficacité (apport de valeur). Après tout, que vaut un processus/une méthode qui aide à faire ce qui doit être fait plus vite/moins cher, mais qui au final n'apporte pas de valeur supplémentaire à délivrer aux clients finaux ? L'Agilité, de ce fait, offre à la fois la promesse de réduire les coûts, mais aussi celle d'améliorer le rendement.
Donc, si votre principale, et peut-être unique, raison de choisir de passer à l'Agilité est d'être plus efficace, vous verrez probablement les résultats que vous attendez : votre travail ira plus vite. Par contre, si cela exclut de se focaliser sur l'amélioration de la rentabilité/valeur (i.e. les résultats du produit), alors en fin de compte vous ne faites que retarder la mort inévitable de votre entreprise. Aucune réduction de coûts ne peut compenser un manque de production de revenu.
Michael parle d'appliquer les "métriques pirates" pour mesurer la valeur de l'Agilité : acquisition, activation, rétention, référence et revenu. Quand on mesure la valeur, on doit initialement se concentrer sur les métriques qui donnent des informations sur l'acquisition de l'Agilité. Quand l'acquisition a augmenté, la focalisation doit passer sur l'activation :
Avec ce modèle en exemple, si nous l'appliquons à l'aspect opérationnel/processus de la Transformation Agile, que considérerons-nous comme métriques ? Est-ce que l'équivalent du revenu sera la vélocité (je sais, on ne compare pas !) ? Est-ce que l'acquisition sera l'équivalent du nombre de personnes formées par session d'entraînement ?
Précédemment, InfoQ a interviewé Capers Jones à propos de la mesure de l'adoption de l'Agilité. Capers a mentionné des mesures simples qui peuvent être utilisées quand on migre d'une méthodologie à une autre ; elles peuvent être utilisées pour mesurer la valeur de l'Agilité :
Pour mesurer la productivité, les deux métriques les plus largement utilisées dans le monde sont "points fonctionnels par mois de travail" et sa réciproque, "heures de travail par point fonctionnel". Dans le but de juger la productivité, des taux supérieurs à 10 points fonctionnels par mois de travail sont bons ; les taux en dessous de 7 points fonctionnels par mois de travail ne sont pas excellents. Certains projets agiles ont atteint 15 points fonctionnels par mois de travail, et cela n'arrive quasiment jamais pour le waterfall.
Pour mesurer la qualité, les mesures les plus efficaces sont "les potentiels d'anomalie" normalisés avec des points fonctionnels, et "l'efficacité à supprimer des anomalies". Les potentiels d'anomalie sont la somme des bugs qui seront trouvés dans les spécifications, la conception, le code, les documents et les mauvaises corrections. Un potentiel d'anomalie supérieur à 5 par point fonctionnel est mauvais ; un potentiel en dessous de 3 par point fonctionnel est bon.
Ken Schwaber a écrit l'article Valeur agile, dans lequel il parle de la manière de mesurer la valeur créée par les investissements IT :
(...) la valeur est définie comme étant le bénéfice financier qu'une entreprise reçoit de ses dépenses. Quand elle est mesurée, la valeur peut guider une entreprise entière, ou être restreinte, par exemple à une unique division ou ligne de produits. Dans tous les cas, elle doit englober les zones affectées par les dépenses.
La valeur des investissements de l'entreprise peut être mesurée avec une métrique unique appelée l'index d'agilité, qui est définie dans l'Agile Path Framework. Cette métrique combine les résultats de plusieurs métriques :
- Métriques opérationnelles, qui mesurent l'efficacité de la société. Ces métriques sont fortement inclinées vers l'IT, que ce soit au niveau du développement ou du déploiement logiciel. Elles comprennent le débit, la durée du cycle, la stabilisation, la qualité, le taux d'utilisation et la durée du cycle de livraison. L'efficacité opérationnelle fonctionnelle n'est pas incluse dans ces mesures, mais sera abordée en 2014 dans le cadre du programme Kotter International (John Kotter) Accelerate!
- Métriques organisationnelles, qui mesurent l'impact de l'efficacité des investissements sur le marché et la croissance de la valeur de l'entreprise. Ces métriques sont le revenu par employé, la satisfaction du client et des employés, et le ratio produit/coût du système.
On peut mesurer la valeur délivrée à la fin d'un sprint Scrum, comme Ken le décrit :
Dans un projet agile, chaque Sprint ou Itération est un projet complet. Il contient des spécifications, un budget et une date finale. A la fin, il comprend un ensemble de fonctionnalités logicielles terminées. Selon ce qui est terminé, un autre projet peut être initié, ou non, ajoutant plus de fonctionnalités à celles qui viennent d'être terminées. Chaque Sprint est mesuré séparément.
Le blog Cutter a publié il est trop simple de mesurer la valeur de l'Agilité de la mauvaise façon, qui explore les exigences pour mesurer la valeur de l'Agilité. Tom Grant fournit des directives sur ce qu'il faut calculer et les pièges à éviter :
- "La valeur des méthodes agiles n'est pas la même que celle du logiciel produit par les équipes agiles" : Estimer la valeur métier des stories n'aide pas à garantir l'investissement de l'adoption de l'Agilité dans l'entreprise.
- "La valeur métier existe au niveau des activités métiers" : Ce ne sont pas les stories qui ont une valeur métier, mais les actions métiers qui utilisent le logiciel délivré. Tom déclare que "La valeur existe au niveau des epics et des themes".
- "Le portfolio doit jouer un rôle dans le calcul de la valeur" : La valeur métier du logiciel délivré est aussi en partie liée aux fonctionnalités qui ne sont pas incluses.
- "La valeur est une mesure réciproque" : Mesurer la valeur nécessite d'impliquer à la fois les producteurs et les clients de la technologie.
- "Personne ne croit aux mesures exactes, mais elles sont tout de même utiles" : Même si vous ne pouvez pas calculer la valeur exacte, les gens veulent toujours un chiffre pour en discuter.
- "Les calculs du ROI peuvent être si grands qu'ils semblent incroyables" : Les gens peuvent être sceptiques quand ils voient de gros chiffres, mais ils peuvent tout de même être corrects.
- "L'investissement sur le retour peut être plus important que le retour sur investissement" : Ne pas suffisamment investir dans l'Agilité peut résulter en un échec de l'adoption.
- "Il y a beaucoup d'autres mesures que le ROI" : D'autres métriques peuvent aussi être utiles dans la prise de décision de l'adoption de l'agilité.
Mesurez-vous la valeur métier de l'adoption de l'Agilité?