Des fois, c’est une bonne pratique d’essayer d’adopter un point de vue complètement différent, et le vocabulaire associé, pour mieux comprendre des concepts qu’on est (à peu près) capable d’expliquer avec son dialecte habituel. Du coup, au lieu de rester dans mon jargon informatique, je vais essayer d’expliquer l’agilité en termes financiers.
L’agilité – par rapport au traditionnel cycle en V où on conçoit quelque chose, puis on le fabrique, puis on le teste, puis on le vend – consiste à fournir un produit sous forme de petits incréments qui apportent de la valeur à chaque fois. Par exemple, un robot ménager avec dans un premier temps juste le moteur, le bol standard et le hachoir, qui est l’outil le plus utilisé. Ensuite, on pourra ajouter un blender pour la soupe, un autre outil pour râper, un autre pour faire des tranches, etc.
L’avantage est que l’investissement initial en R&D, production, stockage, vente et autres activités est alors moins élevé. Du coup, le retour sur investissement arrive beaucoup plus tôt :
Comment réussir à atteindre cet état financier enviable ? La solution principale a été rapidement abordée, à savoir réaliser des petits incréments. Mais imaginons maintenant que le robot soit vendu sans moteur, et que nous ayons ajouté les râpes, le blender et tout le bazar, mais toujours pas le moteur. Bref, le robot n’aurait que très peu de valeur pour un potentiel utilisateur. C’est pour cela que nous sommes plutôt parti d’une version minimale mais fonctionnelle, et que nous avons progressivement ajouté des items dont la valeur était moindre. L’idée de l’agilité et du Lean est de commencer systématiquement par les fonctionnalités qui ont le plus de valeur.
Dit comme ça, on pourrait se demander pourquoi ces idiots d’informaticiens (j’en suis) ne commencent pas par les fonctionnalités de plus haute valeur. Il se trouve que le métier étant relativement récent (quelques dizaines d’années, ce qui n’a pas permis une industrialisation pour l’instant), les équipes ont tendance à souvent réinventer la roue et mettre en place des fonctionnalités “de base” mais qui n’ont pas de valeur immédiate, avant de travailler sur le métier, puis seulement en fin de projet mettre en place une interface graphique pour piloter le tout. Or, le client a besoin de l’interface graphique. En fait, il ne voit même que ça et le reste est pour lui du blabla pur et simple…
Pour résumer, l’idée de l’agilité est de mettre le plus possible de valeur dans le produit en amont. Typiquement, là où dans une approche traditionnelle, peu de fonctionnalités sont accessibles à l’utilisateur (20% après consommation de 80% du budget), l’approche agile permet l’inverse du Pareto (80% de la valeur après avoir consommé 20% du budget). Il arrive d’ailleurs assez souvent en mode agile que le projet s’arrête avant la fin de la consommation du budget, car quasiment toute la valeur est atteinte. Si le projet est bien tenu, seules des fonctionnalités peu importantes restent à réaliser, et parfois le client préfère garder son reliquat de budget pour autre chose.
Si jamais des financiers lisent mon blog, je serais heureux de recueillir leur retour pour savoir si j’ai réussi à leur expliquer l’agilité 
.
