Le retour sur investissement en entreprise se traduit par des gains plus importants que les dépenses engagées, à un horizon intéressant dans le cycle de vie de l'entreprise. Cela nécessite une bonne idée de ce que sera l'avenir dans cet horizon du ROI. Et l'époque étant ce qu'elle est, les certitudes ne sont plus ce qu'elles étaient.

La question est alors récursive, le temps que l'on passe à discuter du ROI est il bien investi ?

L'Agilité nous donne une règle qui n'existe pas dans les autres modes de gestion de projet : éviter de prédire ce qui va se passer, se baser sur ce que l'on sait davantage que sur ce que l'on croit.

Je n'emploie pas souvent le terme de ROI mais la question du rapport dépense/gain est implicite en permanence dans les actions du projet Agile. Cette question n'est pas facile pour les équipes, elle fait appel à de la projection pour estimer ce qui pourrait se passer dans un cas ou dans un autre mais elle demande de vérifier ce qui nous semble être évident. Il faut souvent accepter de reconnaître que l'on ne sait pas (et cette réflexion ne doit pas prendre davantage qu'une poignée de secondes !).

La production Agile amène à une sorte de conscience permanent du ROI, mouvement naturel finalement, qui introduit dans le choix des actions la notion de meilleur "probable" comme critère de décision. Ce probable n'étant pas une certitude, l'étape d'après est hypothétique, et la meilleure décision est celle qui est parfaitement adaptée à l'action présente tout en laissant les options ouvertes pour l'avenir. Point final.

Le point problématique de la documentation en mode Agile est un bon exemple des difficultés que pose cette vision pragmatique des choses. Faut-il de la documentation dans un projet, si oui, laquelle ? C'est un point sensible, une question qui se pose à chaque fois qu'un nouveau client découvre l'agilité.

Pourquoi pose-ton cette question ? Parce qu'on n'a jamais réussi sans doute à poser correctement le ROI sur la documentation. Si on peut dire ce que ça coûte, on ne sait pas ce que cela rapporte. Il y a une sorte d'évidence à cette nécessité de rédiger avant de développer. Le besoin évident n'est pas celui auquel on pense, la documentation permet davantage de se rassurer que de bien communiquer.

Posons la question au métier et voyons sa réponse : je vous donne un premier livrable dans 2 mois.
Pour le même effort on peut vous fournir :
- des spécifications complètes et détaillées ainsi que le PAQ et le schéma de la base de données,
- ou bien une première version du logiciel pleinement opérationnelle qui vous permettra déjà de faire les devis automatiquement même s'il ne permettra pas encore d'enregistrer les commandes ?

- d'accord posé de cette façon bien évidemment … sauf que si on a pas la documentation vous ne pourrez pas développer.
- si, on sait le faire. On a l'expérience, on a juste besoin que vous soyez accessible pour répondre aux questions de l'équipe chaque jour. Ça peut paraître contraignant mais vous verrez vite que c'est très efficace et que ça va vous plaire.
- admettons, mais quand même, à un moment ou à un autre il faudra bien la documentation de toute façon.
- oui bien sur, pas de problème , vous nous direz simplement quand vous en avez absolument besoin et on suspendra le développement pour rédiger la documentation en priorité.
- ah oui mais alors je vais devoir payer pour la documentation plutôt que pour du développement !
- hé bien étudiez le ROI généré par la documentation et vous fixerez le budget documentation en conséquence. On s'adaptera...


... mais ne vous penchez pas sur le ROI de la documentation maintenant, le temps que vous allez investir à calculer votre ROI risque d'être perdu, attendez d'être certain de ce dont vous avez besoin. ...