Pourquoi les estimations échouent (et pourquoi elles restent indispensables)

• En développement logiciel, l’estimation du travail relève du domaine complexe (Complex), et même une équipe très expérimentée ne peut pas produire d’estimations exactes par nature
• Le mouvement #NoEstimates était une réaction légitime au fait que les estimations sont détournées en objectifs de performance, mais rejeter l’estimation elle-même prive l’organisation de sa capacité de coordination
• La valeur centrale de l’estimation n’est pas de prédire l’avenir, mais de communiquer et se coordonner sous incertitude ; elle est indispensable pour les contrats externes, les dépendances entre équipes et les arbitrages de ROI
• Selon le cône d’incertitude (Cone of Uncertainty) de Steve McConnell, l’erreur d’estimation peut aller jusqu’à un facteur 4 au début d’un projet, et la fourchette ne se resserre qu’au fil de l’apprentissage
• Il faut changer l’habitude organisationnelle qui transforme une estimation en promesse, et adopter une pratique d’estimation fondée sur des fourchettes, des hypothèses explicites et des ajustements progressifs

---

Le problème que le mouvement #NoEstimates a réellement résolu

• Les équipes se voient demander des estimations alors qu’elles connaissent encore très peu le problème, puis ces chiffres sont intégrés à la roadmap et promis aux clients
• Quand la réalité diverge de l’estimation, l’équipe est accusée d’« avoir raté la deadline », alors qu’elle n’avait jamais validé cette échéance au départ
• La pathologie centrale est que l’estimation cesse d’être une prévision pour devenir un engagement (commitment)
• Dire « n’estimons pas » revient, face à un thermomètre cassé, à nier jusqu’à l’existence de la température
• Comme le formule Maarten Dalmijn, estimer ne change pas la quantité réelle de travail ; le développement d’une fonctionnalité prend le temps qu’il prend
  • Ce que l’estimation influence, ce n’est pas le travail lui-même, mais les attentes (expectations) autour de ce travail
  • Gérer ces attentes de façon honnête et claire est un travail qui en vaut largement la peine

Pourquoi les organisations ont réellement besoin d’estimations

• Un point presque toujours absent des discussions #NoEstimates : les estimations ne servent pas d’abord à l’équipe qui réalise le travail, mais à l’organisation qui l’entoure

• Il existe trois situations où l’estimation est inévitable

• Engagements externes (External commitments) : contrats clients, sorties liées à des campagnes marketing, échéances réglementaires, etc. ; dans ces cas, il faut un modèle de durée du travail pour juger de la faisabilité

  • « Nous ne faisons pas d’estimations » n’est pas une réponse que l’on peut donner à un client, et cela peut mener à la perte du contrat

• Dépendances inter-équipes (Inter-team dependencies) : si l’équipe B doit attendre la fin du travail de l’équipe A, alors sans prévision de l’équipe A, l’équipe B ne peut rien planifier

  • Un signal approximatif (« probablement 6 semaines, 8 au maximum ») est infiniment plus utile que le silence, et ce n’est pas du contrôle mais une marque de respect envers les équipes en aval

• Calcul du ROI : pour décider s’il faut développer la fonctionnalité X ou Y, il faut un modèle de coût relatif

  • Si tout est considéré comme inconnaissable, aucun arbitrage rationnel n’est possible ; et s’il faut de toute façon faire une supposition, mieux vaut une supposition structurée avec des hypothèses explicites

Ce que Joseph Pelrine montre sur la difficulté intrinsèque de l’estimation

• Joseph Pelrine est le premier Certified Scrum Trainer d’Europe et étudie l’agilité logicielle à travers le prisme des sciences de la complexité sociale
• Il a mené une expérience consistant à placer les activités quotidiennes de plus de 300 personnes travaillant dans le développement logiciel agile dans les domaines du framework Cynefin (le modèle de sensemaking de Dave Snowden)
  • Cynefin classe les problèmes en quatre domaines : Clear, Complicated, Complex et Chaotic
• L’estimation du travail est placée de manière cohérente et répétée dans le domaine Complex
• La différence entre Complicated et Complex est cruciale :
  • Dans le domaine Complicated, les relations de cause à effet peuvent être comprises, des experts peuvent les analyser, et l’expertise permet de produire des prévisions fiables
  • Dans le domaine Complex, les relations de cause à effet ne peuvent être comprises qu’a posteriori ; le système est trop imbriqué, trop dépendant du contexte et trop sensible aux petites variations
• Si le développement logiciel n’est pas de la fabrication industrielle, c’est parce qu’il consiste presque toujours à construire quelque chose qui n’existait pas auparavant, sur une base de code unique et avec une dynamique d’équipe unique
  • C’est pourquoi l’analogie du menuisier ne tient pas : des placards se ressemblent globalement, mais une fonctionnalité ne ressemble pas globalement à une autre fonctionnalité
• Même les très bonnes équipes ne peuvent produire que des estimations d’une précision moyenne ; ce n’est pas un manque de compétence, mais une limite intrinsèque à la précision dans le domaine Complex
• L’objectif n’est pas de « réussir » l’estimation, mais de prendre des décisions utiles malgré son imprécision intrinsèque

Ce que dit le cône d’incertitude (Cone of Uncertainty)

• Le cône d’incertitude de Steve McConnell montre qu’au début d’un projet, l’erreur d’estimation peut aller jusqu’à un facteur 4 dans les deux sens (soit une amplitude totale de 16x)
• À mesure que le projet avance et que les inconnues se résolvent (clarification des exigences, stabilisation de l’architecture, découverte et résolution des points difficiles), le cône se resserre
• Ironie du sort : le moment où l’estimation devient la plus précise est juste avant la fin, c’est-à-dire quand on en a le moins besoin
  • Au début, quand elle serait la plus utile (alors qu’on peut encore pivoter ou arrêter le projet), on en sait le moins
  • Et c’est justement à ce stade initial que la plupart des organisations prennent les engagements les plus fermes
• Deux implications supplémentaires :
  • Le cône décrit le meilleur cas pour des estimateurs compétents, et la plupart des équipes font moins bien
  • Fixer une date ferme au stade du concept initial n’est pas de la planification, c’est faire un vœu puis bâtir un calendrier dessus
  • Le cône ne se resserre ni avec le temps ni avec l’attente, mais uniquement grâce aux décisions qui réduisent l’incertitude
  • Définir le scope, lever les inconnues d’architecture, écrire du vrai code et découvrir les difficultés resserrent le cône ; passer 3 semaines en réunions ne le resserre pas
• Il faut dire explicitement aux parties prenantes que « la qualité de l’estimation dépend de l’endroit où nous nous trouvons dans le cône »
  • En semaine 1, on ne peut pas donner un chiffre « de 2 semaines », mais on peut fournir une fourchette et expliquer ce qu’il faut vérifier pour la resserrer
  • La plupart des parties prenantes l’acceptent quand on leur explique le cône ; on ne leur a simplement jamais dit qu’elles avaient le droit de demander une fourchette

Pourquoi utiliser l’échelle de Fibonacci

• La non-linéarité de l’échelle de Fibonacci (1, 2, 3, 5, 8, 13, 21) remplit une fonction épistémique
• Entre 2 et 3, on perçoit une « différence grossière », mais le saut de 8 à 13 encode le fait que la bande d’incertitude est plus large que l’estimation elle-même
  • Une user story à 13 points ne signifie pas « exactement 13 », mais « clairement plus incertaine qu’un 8, sans aller jusqu’à un 21 »
• L’écart entre les nombres de Fibonacci reflète la manière dont la complexité se développe réellement
  • Les petites choses peuvent être estimées à peu près ; les grosses sont exponentiellement plus difficiles à prévoir à cause des inconnues, des points d’intégration et des imprévus
  • Une story à 21 points (ou même 13) signifie généralement : on ne comprend pas encore assez le travail, donc il faut la découper
• Une autre fonction sous-estimée des estimations en Fibonacci tient à ce qui se passe pendant la discussion d’estimation
  • Si une personne dit 3 et une autre 13, le chiffre en lui-même compte peu ; ce qui importe, c’est pourquoi la même équipe perçoit la même story de manière si différente
  • L’une a peut-être repéré une dépendance, ou connaît une contrainte technique absente du ticket
• La plus grande valeur de l’estimation n’est pas le nombre, mais la vérification qu’une compréhension commune s’est formée
  • Si l’on retire ce mécanisme de mise en évidence, la compréhension partagée ne se construit souvent que lorsqu’une complexité cachée surgit au troisième jour du travail
• C’est aussi pourquoi il est difficile d’adhérer à l’argument #NoEstimates selon lequel les « réunions d’estimation sont une perte de temps » : bien menées, ces conversations produisent de l’alignement (alignment)
  • La réponse à une réunion mal conduite n’est pas de supprimer la réunion

Le piège de l’engagement (Commitment Trap) et comment l’éviter

• Le dysfonctionnement le plus profond auquel réagissait le mouvement #NoEstimates est que les estimations sont transformées en engagements sous l’effet de la pression sociale plutôt que de la logique
• Un mode d’échec fréquent : des personnes qui n’exécutent pas le travail fabriquent une timeline et la jettent à l’équipe, produisant la pire combinaison possible : estimation inexacte + équipe sans appropriation du chiffre
  • Quand la réalité diverge, personne ne sait qui est responsable et tout le monde se renvoie la faute
  • Ceux qui font le travail doivent toujours être propriétaires de l’estimation ; imposer une estimation de l’extérieur n’est pas de l’optimisme, c’est le prélude à un jeu de reproches
• Une fois l’obsession de la deadline installée, toutes les conversations convergent vers « comment tenir la date ? », et la question de savoir si l’on construit la bonne chose disparaît du champ de vision
• Il faut séparer trois notions que la plupart des organisations confondent :
  1. Estimation (Estimate) : prévision probabiliste compte tenu du niveau d’incertitude actuel, qui doit s’accompagner d’une déclaration explicite de la fourchette et des hypothèses
     • Exemple : « en supposant qu’il n’y ait pas de changement de besoin et que nous recevions les réponses sur l’API d’ici vendredi prochain, nous pensons à 4 à 6 semaines »
  2. Plan (Plan) : engagement sur le processus, pas sur le résultat
     • Exemple : « nous travaillons dessus pendant 2 semaines, puis nous faisons un point et fournissons une prévision mise à jour »
  3. Engagement (Commitment) : promesse portant sur le résultat, qui doit rester rare et n’être formulée avec prudence que lorsque le cône s’est suffisamment resserré
     • Au stade du concept initial, prendre un engagement n’est pas audacieux, c’est imprudent
     • Si l’on vous force à vous engager, essayez de vous engager sur les priorités plutôt que sur une timeline ; et si ce n’est pas possible, incluez le niveau de confiance dans l’engagement lui-même
• La racine du dysfonctionnement est la pratique organisationnelle qui traite toute estimation comme un engagement dès qu’elle est prononcée
  • La solution politique de #NoEstimates (ne plus donner de chiffres du tout) est compréhensible, mais elle coûte à l’organisation sa capacité à allouer les ressources, ordonner les dépendances et parler honnêtement avec les parties prenantes externes
• Une meilleure réponse consiste à enseigner le cône, former les parties prenantes et rappeler explicitement la différence entre estimation et engagement chaque fois qu’un chiffre est donné
  • C’est plus difficile et plus long que de refuser d’estimer, mais cela permet de construire la confiance au lieu de simplement éviter les situations où elle pourrait se briser

Bonnes pratiques d’estimation

• Estimer tard : le cône ne se resserre qu’avec l’apprentissage ; il faut donc d’abord faire des spikes, écrire du code exploratoire et parler avec les équipes concernées par les intégrations
  • Il faut résister à la pression qui pousse à fournir des chiffres avant d’avoir appris assez pour produire quelque chose de significatif
• Éviter la sur-décomposition avant de commencer : face à l’incertitude, on a envie de découper le travail en morceaux toujours plus petits, mais une décomposition suffisante ne produit pas pour autant une estimation fiable
  • Une planification détaillée en amont devient vite rigide et pousse l’équipe à s’y accrocher même lorsqu’elle ne reflète plus la réalité ; l’écart devient alors encore plus confus
  • Il vaut mieux partir d’un plan simple et facile à ajuster
• Fournir des fourchettes plutôt que des points : « 3 à 5 semaines » est plus honnête que « 4 semaines » tout en restant presque aussi exploitable
  • Si l’on vous impose un chiffre unique, donnez le milieu de la fourchette, en précisant bien qu’il s’agit d’une valeur médiane
  • Mettez-vous d’accord avec les parties prenantes sur l’usage du cône d’incertitude et référez-vous-y à chaque communication d’estimation
• Rendre les hypothèses visibles : une estimation ne vaut que par ses hypothèses ; il faut donc expliciter l’absence de changement de scope, l’hypothèse d’une approche technique donnée, ou la livraison d’une autre équipe à une date précise
  • Des hypothèses qui restent dans les têtes se transforment en malentendus au pire moment possible
• Suivre la précision sans punir : l’objectif est le calibrage, pas le blâme
  • Une équipe qui estime ensemble pendant 6 mois et examine sa précision développe progressivement une intuition commune sur les cas où elle surestime ou sous-estime systématiquement
  • Punir les estimations inexactes pousse l’équipe à gonfler ses chiffres par réflexe défensif, et une estimation gonflée est encore moins utile qu’une estimation honnête mais incertaine
  • Dans le domaine Complex, une mauvaise estimation n’est pas un défaut de caractère, c’est une propriété du domaine
• Au-delà de 8, on découpe : une story estimée à 13 ou 21 en Fibonacci contient presque toujours une complexité cachée qui n’a pas encore émergé
  • Le fait de la découper oblige à exprimer clairement ce que l’on sait réellement
  • On découvre souvent que, sur 3 sous-stories, 2 sont petites et que toute l’incertitude est concentrée sur la troisième

Une vérité inconfortable pour les deux camps

• L’estimation n’est pas un calcul, mais une forme de communication ; son but n’est pas de prédire l’avenir, mais de soutenir la coordination et la prise de décision sous incertitude
• Les modes d’échec de l’estimation ne sont pas aléatoires mais systématiques : estimer trop tôt, traiter une fourchette comme un point, traiter une estimation comme un engagement, ignorer la position épistémique du cône d’incertitude, imposer une estimation à ceux qui exécutent le travail
• Ce que Dalmijn appelle la Complex Work Estimation Fallacy, c’est la croyance qu’en estimant plus souvent, en améliorant le process et en travaillant plus longtemps ensemble, on finira par obtenir des estimations exactes
  • Dans le domaine Complex, la limite de précision n’est pas une fonction de la maturité de l’équipe, mais une fonction du domaine lui-même
  • On peut s’améliorer, mais on ne devient pas exact ; confondre les deux conduit les organisations à punir les équipes pour des choses qui sont fondamentalement hors de leur contrôle
• Refuser d’estimer revient simplement à sortir du jeu de la coordination
  • Cela peut fonctionner pour des équipes totalement indépendantes, en déploiement continu et sans engagements externes, mais la plupart des carrières ne se déroulent pas dans ce contexte
• Le vrai choix n’est pas entre « mauvaises estimations » et « absence d’estimation », mais entre des estimations implicites et de faible qualité (que l’organisation produira de toute façon sans vous) et des estimations explicites, modestes, fondées sur des fourchettes et appuyées sur des hypothèses visibles
• Puisque l’estimation du travail relève du domaine Complex, il faut l’aborder avec un état d’esprit adapté à la complexité : explorer, observer, réagir, estimer, suivre, recalibrer, puis recommencer
• Le cône ne se resserre pas en attendant, mais en apprenant