Il était une fois un économiste qui essayait de comprendre pourquoi les projets de développement logiciel qui marchaient bien étaient en fait ceux qui utilisaient des principes qui étaient censés ne pas fonctionner. En l’occurrence, il avait remarqué que dans les projets qui marchaient bien, ses membres ne cherchaient pas à être efficaces. Ils n’essayaient pas non plus d’éviter que les imprévus surviennent. Et lorsqu’ils étaient alors en retard, il ne cherchaient pas à tout prix à refaire rentrer les choses dans le planning. D’ailleurs, ils évitaient de trop planifier d’une façon générale. Autre chose : au lieu de gagner du temps en regroupant les tâches similaires pour les traiter d’un coup, ils essayait d’aller jusqu’au bout de chaque petit développement. L’économiste remarqua aussi qu’ils évitaient de trop se spécialiser. Et, finalement, il semblait que les projets n’avait pas de point central de contrôle.
Pour résoudre ce paradoxe, l’économiste postula alors qu’il fallait mesurer l’ensemble des coûts/bénéfices d’un processus de développement en les rapportant à la Valeur Actuelle Nette du produit logiciel (c’est à dire au résultat financier du produit cumulé sur l’ensemble de son cycle de vie), directement, et ne plus passer par des objectifs intermédiaires.
Cela lui permit de démontrer qu’il fallait bien réduire les cycles, introduire des rythmes régulier de traitement par petits lots, abaisser les capacités de production de l’ensemble de la chaîne et ainsi diminuer la la longueur des files d’attente, pondérer financièrement les décalages par rapport aux gains attendus, et alors traiter les imprévus avec un surcoût minimal.
L’histoire que raconte alors notre économiste c’est que les méthodes agiles promeuvent des processus qui ont tendance à augmenter la VAN du produit, ce qui permet à l’entreprise d’améliorer ses bénéfices (qui reste, pour notre économiste, le seul objectif d’une entreprise).
Plus précisément, notre économiste expliquait que les méthodes qu’il dénonçait se basaient sur des croyances en des objectifs indirects, sans véritable mesure économique, comme : augmenter l’efficacité des développeurs, réduire les temps de développements, suivre les planning, et non sur leur impact sur la VAN elle-même. Cela était notamment dû au fait qu’une partie des impacts était cachée ou non mesurée, comme : le coût des files d’attente, le coût des décalages, le coût des défauts en fonction du moment de leur découverte, mais aussi dû au fait que objectifs étaient interdépendants, et qu’on ne pouvait les faire varier “toute chose étant égale par ailleurs”.
Cité dans sur http://www.arolla.fr/blog/2018/06/raconte-moi-une-histoire/