Derrière ce titre provocateur, il y a ce que toute personne réalisant des projets a déjà constaté. Présenté sous forme de lapalissade, ça pourrait donner :

plus nous avançons dans le projet, plus nous avons de certitudes sur ce qu’il va se passer.

Ceci étant dit, on est donc tous d’accord, le début d’un projet c’est le moment où nous en connaissons le moins, et pourtant c’est le moment où nous nous engageons le plus !

Pourquoi fait-on cela ? Parce que le client le demande, parce que les gouvernances des entreprises le demandent … et puis surtout si on ne s’engage pas, il n’y aura pas de suite …

et pour tenir ces engagements, pas de surprise, des marges, chaque partie prenante prend son lot de 20-40% de marge, et nous commençons un projet avec un environnement qui n’est pas basé sur la confiance et la transparence.

C’est véritablement là où les approches traditionnelles et l’agilité diffèrent … D’un côté, on prend des marges, d’un autre, on assume et on itère, le plus souvent possible, afin de générer un maximum d’apprentissage

Le cône d’incertitude

Vous trouverez ci-dessous la représentation de ce constat tel que Steve Mc Connell, dans le passé chez Microsoft l’a représenté,  « le cône d’incertitude ».

Cone d'incertitude
Le Cône d’incertitude est donc ce terme utilisé en Gestion de Projet pour décrire le degré d’incertitude existant aux différents stades d’un projet.

Qui peut contredire ces observations ?

Et pourtant de nombreuses approches ont renforcé l’idée que les équipes projet doivent prendre des engagements toujours de plus en plus tôt, sur des spécifications fonctionnelles, des choix architecturaux, des estimations de budget, bref … prendre des décisions structurantes pour le projet.

Cette déclinaison pour les estimations émane de nombreuses études réalisées par Mc Connell et la conclusion est simple.

Les organisations sabotent par « inadvertance » leurs propres projets en prenant des engagements trop tôt dans un contexte où l’incertitude est trop grande. Mc Connell dit aussi que : « Si une organisation s’engage au moment du concept initial ou de la définition de produit, elle a un facteur de 2x à 4x d’erreur dans ses estimations. » Décliné sur un projet de 1000 jours.homme, cela signifie que la marge d’erreur du x0,25 à x4, nous amène entre 250 et 4000j.h. Soit un facteur de 16 !

Alors concrètement, ce sont les marges qui gèrent cette incertitude et souvent de très grosses marges. Mais si le fournisseur doit raboter les engagements dans la négociation, que fait-il quand ils ne sont pas réalistes ? il ne le dit pas car sinon il ne gagne pas le contrat. Dès qu’il gagne le projet il dit « désolé cher client, l’engagement doit être revu, ce n’est pas tenable ». Le fournisseur est tenu par la nécessité d’avoir le contrat. Sans contrat il ne gère rien, avec un contrat, il gère les problèmes (et c’est mieux que rien !) 

Les engagements pris trop tôt dans un projet compromettent la prédictibilité, augmentent les risques, augmentent l’inefficacité du projet, nuisent à la capacité de gérer un projet pour réussir et empêchent tout simplement de réaliser le bon produit.

Ok mais comment réduire ce cône d’incertitude ?

Nous nous trompons, nous avons toujours pensé que c’est en « creusant » ou autrement dit en cherchant du détail et en cherchant la complétude sur le besoin mais aussi toute l’architecture que l’incertitude se réduirait. N’entendez-vous pas régulièrement :

  • Plus le projet est spécifié dans le détail, plus le chiffrage réalisé sera proche de la réalité
  • Plus on a réussi à anticiper et planifier le travail, plus on aura un bon plan.
  • Il faudra limiter et contraindre le changement parce que le client n’est pas mature
  • Figer les choix structurants tôt, on aura donc une architecture figée et on aura réduit les risques.

Et si la réalité se trouvait à l’opposé ?

Concernant les estimations budgétaires, d’autres ont pensé que l’expérience de projets passés assurerait une meilleure gestion de l’incertitude … sur le papier excellente idée – l’empirisme. Mais c’était oublier que les projets de développement logiciel sont beaucoup plus proches des projets de recherche et développement que des projets industriels basés sur la répétition de tâches identiques. On utiliserait les performances passées sur des projets similaires, pour tenter d’évaluer les performances futures mutatis mutandis.

Nous nous trompons parce qu’il n’y a pas 2 projets avec :

  • Les mêmes exigences.
  • Les mêmes personnes.
  • Le même contexte commercial.
  • La même technologie.
  • Les mêmes priorités et contraintes.
  • La même équipe

Chaque projet est unique. La grosse majorité des lignes de code sont fabriquées à la main. Et notre construction du bon produit implique des développeurs créatifs et intelligents et ca ne se prête pas à « l’estimation avec précision ».

Alors oui, quand on réalise ce type d’estimations, chaque intermédiaire prend des marges, 30% peut-être, selon le risque, ça peut representer beaucoup plus. Et au global, vis à vis du coût global du projet ?

Cône d’incertitude et agilité

La question est donc « Quand réalise-t-on que nous avons suffisamment appris pour considérer que l’incertitude diminue réellement? ».

Incertitude et waterfall

Sûrement pas en faisant valider un cahier des charges, une liste d’exigences, un dossier d’architecture – le tout sur papier –  qui finalement nous génère plus de faux-positifs que de réels apprentissages et qui confrontés à la réalité du terrain voleront en éclats.

L’agilité considère qu’en livrant régulièrement et fréquemment un produit qui fonctionne puis en le montrant et en le mettant dans les mains des utilisateurs, ne pouvons réduire l’incertitude et le risque.

Cone d'incertitude et agilité

C’est en effet au travers des nombreux feedbacks utilisateurs mais aussi grâce aux tentatives d’intégration et de déploiement que l’on gagne en certitude. C’est donc en se basant sur ces retours concrets que l’équipe peut désormais prendre les bonnes décisions au bon moment. 

« Build the right product and the product right »

C’est aussi pour cela qu’on parle beaucoup de « Juste à temps » quand on parle d’agilité. Savoir attendre le bon moment – celui où on aura récupérer suffisamment de retours, d’expérience et de résultats d’expérimentation – pour prendre la décision. Il y a donc un réel enjeu économique à premièrement assumer l’incertitude ambiante mais surtout différer certains choix au moment où on aura suffisamment d’apprentissage.

Alors, utiliser le MVP ! (un article ici). C’est le minimum à réaliser pour générer suffisamment d’impact pour nous permettre de recueillir du feedback. Ca veut dire qu’il faut identifier dans votre prochain sprint les histoires utilisateurs qui vous permettront de générer des retours et donc des apprentissages nécessaire à votre prise de décision.

L’agilité permet donc d’apprendre au fil du temps sur le bon produit à réaliser, de réduire plus rapidement le cône incertitude et de prendre les décisions au bon moment.

Plus votre cycle d’apprentissage est court, plus vous apprenez. Ne décidez pas tout au tout début, décidez au bon moment 😉

Coach Lean/Agile. Passionné d’humain, j’ai d’abord été développeur agile et Scrum Master, puis j’ai ci-crée une startup du web. J’interviens maintenant pour plusieurs grands comptes pour remettre de l’humain au centre des organisations : depuis la découverte de l’agilité jusqu’à la transformation d’organisations complexes et de leurs cultures.
Mots-clés : Lean, Scrum, Kanban, SAFe.
Citation : « You never change things by fighting the existing reality.
To change something, build a new model that makes the existing model obsolete. » R. Buckminster Fuller