L’agilité coûte-t-elle plus cher ?

Dernièrement j’ai eu plusieurs discussions avec des personnes qui considèrent que l’agilité coûte plus chère qu’une approche traditionnelle. Le sujet me semble intéressant alors je prends le temps d’en faire un article.

Tout d’abord, il faut regarder à quel moment est posée la question, c’est à dire avant le démarrage du projet ou après la mise en production.

Avant le démarrage du projet

Généralement les personnes qui considèrent que l’agilité va couter plus chère présentent différents arguments, parmi ceux ci :

• Les réunions sont nombreuses, elles diminuent le temps utile (à produire) et augmentent les coûts du projet
• Comme il faudra forcément refaire des choses puisque le besoin global n’est pas figé, cela va générer des coûts supplémentaires
• Si l’on demande tout le temps l’avis des utilisateurs, le projet ne va jamais se terminer et le budget va augmenter

Bien entendu, leur dire que ce n’est pas vrai et qu’elles ont tort ne sert absolument à rien !

Il vous sera nécessaire de prendre le temps suffisant pour écouter leurs arguments, identifier les croyances sur lesquelles ils sont fondés, comprendre leurs mécanismes de réflexion, pour adapter votre réponse et trouver la meilleure façon de faire bouger les lignes.

A titre personnel, si l’on me parle de temps ou de durée, j’essaye d’orienter la discussion sur la valeur produite. Je donne en exemple des situations personnelles (comme la correction d’un bug qui m’apparaissait durant la nuit alors que j’avais passé +10 heures dessus au bureau) et j’invite mon interlocuteur à réfléchir à des situations similaires dans son quotidien (n’est-il pas plus efficace en télé travail alors qu’il travaille moins d’heures que lorsqu’il est au bureau ?). Malgré tout certains restent convaincus que la valeur produite dépend du temps passé, alors pour eux la transformation agile sera plus longue.

Pour ce qui est des coûts supplémentaires à refaire les choses, j’adopte souvent une approche basée sur une comparaison des modèles de risque des approches en V et agile. En V, il faut faire le bon produit du premier coup car les reprises coutent chères (car il faut souvent repartir au début du cycle) et pour réduire les risques de reprise l’approche en V préconise de passer un temps important à bien définir ce qui va être fait. En Agile, il faut faire le bon produit et nous préconisons de démarrer vite afin d’apprendre en faisant (approche empirique). Nous sommes donc certains qu’il y aura des reprises et le risque est d’en avoir beaucoup plus que ce que nous imaginions au départ. Il est difficile de dire avec certitude si le cout du cycle en V pour faire bon du premier coup est supérieur ou inférieur à la somme des couts de reprises de l’agilité … quoique ma conviction personnelle est faite et je mise sur l’agilité. Par contre il est certain que si le risque de reprise en cycle en V devient avéré, cela coutera nettement moins cher en Agile.

Enfin je suis convaincu que l’Agilité présente une meilleure garantie de faire le bon produit, c’est à dire celui qui apporte réellement de la valeur à l’utilisateur, et que si l’équipe arrive à bien prioriser ce qui est à faire, un sous-ensemble du produit sera forcément utilisable à la date prévue et dans le budget prévu initialement.

Après la mise en production du projet

La première fois que j’ai entendu cette remarque, j’ai été vraiment surpris !

Le projet s’était déroulé comme d’autres, quoique de très nombreux imprévus étaient arrivés (humains, techniques, organisationnel …) et j’avais trouvé que l’agilité nous avait permis de prendre en compte tous ces imprévus rapidement et de la meilleure façon possible.

Lorsqu’à la fin du projet le responsable me dit « c’est bien l’agilité, mais cela nous aurait couté nettement moins cher de faire le projet en cycle en V », cela m’a vraiment questionné et je me suis demandé ce qui avait pu le faire conclure de cette façon.

Après réflexion, la raison en est très simple, et elle se rapproche beaucoup de la notion de ligne droite.

En effet, tout le monde sait que le plus court chemin pour atteindre un point donné est la ligne droite, donc lorsque le but est atteint (projet réussi) et que l’on regarde le chemin parcouru, nous comparons toujours le chemin parcouru et la ligne droite théorique entre point de départ et point d’arrivée.

En agile, il est parfaitement clair que le point d’arrivée n’est pas connu initialement (je suis même convaincu qu’il est impossible à définir précisément compte tenu de la complexité des projets) et les équipes travaillent sur la base d’une vision partagée. Les méthodes agiles reposent sur une approche itérative et incrémentale basée sur des feedbacks utilisateurs pour découvrir, par étape, quel sont leurs besoins précis. Donc à chaque étape la cible finale évolue et la trajectoire pour atteindre l’objectif ne ressemble pas du tout à une ligne droite (Cf. diagramme ci-dessous).

En fin de projet, un simple regard sur la trajectoire peut laisser à penser que le projet aurait couté moins cher si l’équipe était allé directement du point de départ à celui d’arrivée.

Cela semble vrai sur le papier, quoiqu’il était impossible de définir le point d’arrivée au moment du départ … ou alors pour un coût surement prohibitif et nettement supérieur à celui d’expérimenter en faisant le chemin étape par étape.