Les divers modèles et cadres de travail Agile (DAD, SAFe, etc) contribuent à apporter beaucoup de rigueur à l’application de l’Agilité, mais on se retrouve quelques fois dans des contextes de grand projets ou dans des organisations qui utilisent et diffusent des concept de gestion de projet plus traditionnels bien ancrés dans leur culture. La Valeur Acquise (VA = Earned Value EV en anglais),utilisée pour générer les Indices de Performance Coût (IPC) et Délais (IPD) est l’un d’eux. Elle est utilisée pour mesurer la rigueur et l’efficacité à « suivre la planification détaillée » qui a été faite par le chargé de projet.

Dans leur appropriation de l’Agilité, les organisations peinent à se détacher de ces concepts jugeant que les abandonner devient une « perte de contrôle ». Pour répondre à cette prérogative, la Valeur Acquise Agile a été développée, mais attention, il est (quasi) suicidaire de ne suivre la progression d’un projet qu’à partir de métriques… Genchi Genbutsu!

Mais d’abord qu’est-ce que la valeur acquise?

En une ligne, dans la gestion de projet traditionnelle, c’est l’effort investi qui a procuré un avancement réellement en ligne directe avec l’objectif de la livraison. Prenons une analogie de golf:

• La distance au trou est de 400 verges. C’est la valeur prévue (VP)
• Au départ, Tiger Rousseau s’élance et envoie la balle 200 verges plus loin, mais légèrement désaxée sur la gauche de l’objectif. C’est le coût réel (CR).
• La progression réellement acquise vers l’objectif est de 175 verges. C’est la valeur acquise (VA). On voit donc un effort perdu de 25 verges. Ce coût est improductif puisqu’il n’a pas contribué à progresser vers l’objectif.
• En assumant que ce travail n’ait pas généré de situation où il faut « défaire ce qui a été fait » (c’est à dire que la nature des activités dans la planification n’a pas changé), dans cette analogie, Tiger peut replacer sa balle sur la ligne de l’objectif et, s’il travaille efficacement, il devra investir un coup (coût!) supplémentaire de 225 verges pour atteindre la cible.
• Le budget à l’échéance (BAC) sera alors de 425 (200 + 225), sur un prévu initial de 400 (6.25% d’écart).

La valeur acquise est un concept issu de la gestion de projet traditionnelle. La valeur acquise, c’est le coût des jours-personnes (ou en dollars) qui nous approche réellement de la fin des travaux planifiés. C’est une mesure de dépense, de laquelle on dérive des métriques d’avancement. Implicitement, elle justifie son existence sur l’acceptation (et l’absence de remise en question ) que les trois contraintes: délais, budget et portée soient fixes. Elle juge de la capacité à suivre le plan établi.

Deux principales failles de cette métrique sont:

1. les restes à faire justes et exacts sont difficiles à obtenir, et;
2. la présence ou l’absence, et l’application des politiques de replanification du bureau de projet (changer le baseline a comme effet de réinitialiser les indices de performance, donc de déclarer que « tout se déroule comme prévu »!).

La valeur acquise Agile a été développée sur des bases similaires. On pourrait argumenter que la portée n’est pas fixe parce qu’on la négocie continuellement, mais au global, on ne change rien au fait que trop souvent « on veut tout ».  On veut tout l’essentiel, ou tout l’essentiel plus la moitié des importants, ou quoi encore. On se retrouve dans un climat de négociation constante (ce qui en soit n’est pas une mauvaise chose) où le PO et la gouvernance veulent, ou s’attendent à un niveau de portée bien défini. Donc, un contexte similaire aux pressions de la gestion de projet traditionnel.

La valeur acquise Agile a la particularité d’être très binaire puisqu’elle repose essentiellement sur la définition de terminé. Elle met donc la pression sur la rigueur d’application et la maturité de la définition de terminé. La dette, ou une définition de terminé pas assez robuste, sont ses principaux talons d’Achille, d’où l’importance des pratiques de développement rigoureuses.  Elle s’exprime en pourcentage, comme les points de fonctionnalités (p. ex.: les stories) terminées sur l’ampleur totale du carnet de produit. Évidemment, on peut aussi l’exprimer en dollars.

Est-ce souhaitable de suivre la valeur acquise Agile? Absolument. Par contre, personnellement, je n’y vois pas de pérennité souhaitable. Pour moi, la valeur acquise n’est qu’une mesure intérimaire que les projets devront utiliser pendant un bon bout de temps. Alors pourquoi l’utiliser en « Agile »?

1. Parce que c’est familier et rassurant;
2. Parce que c’est comptable;
3. Parce que c’est facile;
4. Parce que ça facilite la transition;
5. Parce que ça génère quand même de superbes discussions, riches en contenu très concret.

On va l’avoir encore longtemps parce que nos organisations et la profession ne sont pas encore prêts ou pas encore équipés à migrer vers une conversation orientée sur la valeur d’affaires et le rendement.  Selon moi, une vraie reddition c’est une notion de rendement et non de progression, de coût ou d’épuisement de budget. Pourquoi? Parce que le rendement commande deux choses:

1. Un choix sur la bonne valeur qui s’exprime par le choix des bonnes stories par le PO. Le facteur bénéfice attendu doit être limpide, et;
2. Une rigueur d’exécution qui s’exprime non seulement par la livraison à haute vélocité des équipes, mais qui doit aussi interpeller toute l’organisation à les supporter dans la livraison de la valeur (le facteur moindre coût).

Les modèles de reddition devront évoluer vers ces réalités. Le vrai rendement est l’affaire de toute l’organisation et pas seulement celle des équipes de développement.