Benjamin Danel, Product Ops et consultant chez Thiga, s’interroge dans cette tribune sur la raison d’être des estimations. Au point d’arriver à la conclusion radicale qu’elles sont inutiles.
“Mieux vaut une estimation approximativement vraie que précisément fausse”. Cette phrase que m’a un jour confiée un coach Agile a longtemps résonné en moi, au point de me questionner sur la raison d’être des estimations… Pour finalement les abandonner ! Comment est-ce que j’en suis arrivé à cette conclusion radicale ?
Si j’avais lu cette tribune avec ce point de vue à la fin des années 2010, j’aurais sincèrement douté du sérieux de l'auteur… À cette époque, tout le monde baigne dans la culture projet et je ne fais pas exception à la règle. Armé d’un cahier des charges bien rempli, il me paraît alors normal de vite entrer dans une phase d’estimation pour s’accorder sur un engagement autour d’un budget et d’une date de livraison. La réussite du projet repose alors en grande partie sur la qualité de ces estimations. Résultat ? Entre les demandes d’évolution du périmètre initial et les estimations trop optimistes, les discussions animées sont nombreuses au moment d’expliquer les dérapages budgétaires et temporels.
Au rythme des transformations digitales et de l’essor de la tech, l’Agilité s’implante peu à peu en France. Les jours/homme laissent place aux story points, Excel est remplacé par Jira et les chefs de projets deviennent Product Owner ou Scrum Master, amenant avec eux leur goût du pilotage qui prend la forme de “burndown charts” affichés fièrement dans l’open space. Une révolution ! Si vous avez plus de 35 ans, parions que vous voyez de quoi je parle… La culture du “Command & Control” managériale a encore du mal à laisser place au “Trust & Inspire” que requiert une culture Agile et Produit. Au lieu de servir d’aide à la projection, les estimations servent alors d’outil pour mesurer, voire traquer - et parfois comparer - la productivité des équipes. Hélas, cette réalité est encore aujourd’hui un quotidien vécu par un trop grand nombre d’entre elles.
Avec la culture Produit, une bonne équipe est jugée par la valeur de son produit et avoir des estimations de user stories (US) fiables ne la rend pas plus performante. Aussi, le temps consacré à cette recherche utopiste de la prédiction précise du futur disperse notre énergie. Je l’avoue, le cheminement vers cette conclusion implacable m’a pris quelques années. Cinq éléments constatés de manière empirique ont appuyé ma conviction sur l’inutilité des estimations. Voici lesquels :
Des évolutions qui rendent la date de livraison imprévisible
Oui, les estimations sont une aide au pilotage de projet en permettant une projection sur une date de livraison d’un périmètre. Mais dans un environnement Produit, ce périmètre évolue de façon régulière, alimenté continuellement de feedbacks et de nouvelles opportunités apportant toujours plus de valeur au produit. Dès lors, avoir une projection fiable n’est qu’une utopie et n’apporte que peu d’intérêt. Dans le passé, j’ai travaillé sur un projet de refonte chez Axa IM où les développeurs découvraient chaque semaine de nouveaux problèmes. Même en prenant en compte l’évolution probable du scope dans mes modèles de projection, il était dur d’avoir un indice de confiance fort. C’est un peu comme prédire la météo à 15 jours près au printemps (à part si vous êtes en Normandie ou en Bretagne). La seule solution pour avoir une projection stable aurait été alors de geler le backlog, mais est-ce vraiment envisageable en mode Produit ? Je ne parle même pas ici de la gestion des anomalies et de l’éternel débat pour savoir si elles sont à estimer. Certaines équipes considèrent, qu’au même titre qu’une US, c’est un élément à développer et donc qu’elles méritent d’être prises en compte. D’autres, très majoritaires, pensent le contraire ayant pour conséquence indirecte de détériorer encore plus la fiabilité des projections.
Des estimations quasi similaires qui apportent peu
Avec l’expérience, je me suis rendu compte que j’avais toujours la même manière de découper mes US. Lorsque nous estimions les US avec mon équipe, 80% d’entre-elles avaient un chiffrage de 5 story points, le reste étant réparti entre 2, 3 et 8 story points. Considérer que toutes les US avaient une estimation de 5 auraient pu quasiment m’amener au même backlog de sprint et à la même vélocité.
La productivité peut varier
Les membres de l’équipe (développeurs, QA, etc.) ne sont pas des machines. Pour de multiples raisons, ils peuvent tous avoir des moments plus productifs que d’autres. Bien que l’effet de groupe permette en partie de mitiger ces variations individuelles, il est impossible de prédire exactement la productivité globale d’une équipe, surtout si elles nécessitent l’intervention de plusieurs personnes. Je parle ici de membres de l’équipe et j’inclus bien sûr le Product Manager. Ses semaines ne sont jamais les mêmes. Parfois à dominante discovery, parfois delivery, sa disponibilité a un impact sur la productivité de l’équipe, que ce soit pour valider des US ou pour donner plus de détails sur l’implémentation attendue d’une fonctionnalité.
Une mauvaise utilisation faite pour comparer et mesurer la productivité d’une équipe
Je me souviens être arrivé en tant que PO d’une nouvelle équipe qui venait de se construire. À la fin de la première sprint review, la Head of Product s’interroge sur le fait que l’équipe n’a réalisé que 15 points, alors que les autres tournent à 25 de moyenne. A-t-on le même référentiel ? Peut-on comparer une équipe mature et une nouvelle équipe ? A-t-on les mêmes profils ? Sans explication, on peut faire dire à peu près n’importe quoi aux chiffres et ainsi envoyer de mauvais signaux. Comme le dit Vasco Duarte, coach Agile ayant popularisé le mouvement du #NoEstimates : “les équipes humaines ne sont pas liées par l’arithmétique. Il n’est pas possible d’ajouter, soustraire, multiplier ou diviser les personnes”. Avoir une vision très analytique de la productivité est un problème exacerbé par les estimations et la vélocité.
Un intérêt faible par rapport au temps et à l’énergie passée
Je ne compte pas le nombre d’heures passées dans ma carrière à discuter d’estimations. Oui, c’est important que tout le monde ait une vision du backlog de sprint et qu’il soit possible d’anticiper certaines difficultés d’implémentation, mais le temps passé à “pinailler” sur des estimations est trop important pour ce qu’elles apportent.
Les estimations sont le “doudou” des managers avec leur côté rassurant. Elles donnent une sensation de contrôle.
Ces constats, je ne suis pas le seul à les faire. Depuis le milieu des années 2010, le mouvement #NoEstimates s’est fait le porte-parole d’un monde sans estimations. En plein essor en France quelques années plus tard, j’étais persuadé que ce mouvement aurait pris plus d’ampleur. Vasco Duarte dit que “lorsque le sentiment de contrôle et de certitude est plus important pour nous que la connaissance de la vérité, et que la peur du changement nous empêche de chercher à faire mieux, il est temps de se remettre en question et d'affronter nos peurs.” Or, j’ai l’impression que les équipes continuent encore aujourd’hui à appliquer ce qui leur a toujours été enseigné, sans prendre le recul nécessaire pour challenger la réelle nécessité des estimations. Jean-Pierre Lambert, coach Agile, va plus loin concernant les besoins de projection auxquels servent, in fine, les estimations en pointant du doigt les cas “bien trop fréquents, où on demande des dates pour les mauvaises raisons : parce que c’est la seule manière dont un chef de projet, un manager, ou une organisation sait piloter un projet ou une équipe.”
Mais faut-il pour autant tout arrêter ? Le monde n’est pas si manichéen… L’objectif d’une équipe Produit est de fournir un produit délivrant un maximum de valeur aux utilisateurs, tout en étant bien sûr viable pour l’entreprise, comme l’a rappelé récemment Valentin Ménard dans sa tribune. Les estimations peuvent jouer un rôle dans cette équation, mais ce n’est qu’un rôle secondaire et encore faut-il les utiliser à bon escient.
Tout d’abord, pour négocier un budget associé, il est généralement requis d’avoir une macro-estimation du coût total de l’investissement à réaliser pour le produit afin de décider de la taille de l’enveloppe budgétaire allouée. Estimer est nécessaire, mais cela doit se faire à 2 conditions :
- Se concentrer sur une granularité plus haute, telle que l’Épic.
- S’accorder sur le fait que l'estimation ne peut être vérifiée au centime près 6 mois plus tard… À moins d’accepter une restriction du périmètre. Privilégier une estimation en taille de T-shirt puis faire une estimation de la charge selon les tailles et non les epics (ex: 1 Épic Medium = 2 sprints) a, de mon expérience, un meilleur ROI et permet de résister à la tentation du micro-pilotage.
À ce stade de cette tribune, vous vous demandez peut-être comment font les équipes qui n’estiment pas pour gérer leurs risques de dérapage et quelles données surveillent-elles ? Bonne nouvelle : les méthodes Kanban et Shape Up donnent chacune une réponse différente et complémentaires, l’une basée sur l’output (Kanban) et l’autre sur l’outcome (Shape Up).
Kanban, inspiré par le Lean Management, est focalisé sur la productivité du système plus que la valeur délivrée. Kanban surveille en priorité la fluidité de la chaîne de valeur. Tout élément commencé doit être terminé le plus rapidement possible, c’est ce qui compte le plus. Ce temps est appelé le “Lead Time” et ne demande aucun effort d’estimation. Quant à Shape Up, il se concentre sur la production de valeur. Une réévaluation est faite toutes les 6 semaines pour savoir s’il faut continuer à investir sur un sujet ou s’il faut arrêter. Cette décision est prise sur la base de la valeur délivrée et non sur des indicateurs de productivité.
Vous l’aurez compris, arriver à un monde sans estimations d’US n’est pas chose aisée et dépend en grande partie de la culture de l’entreprise. Mes expérimentations du “no estimates” au niveau des US se sont toujours faites dans des contextes où une réelle relation de confiance existait avec mon manager. Plutôt que de demander combien de points l’équipe a fait ou va faire sur un sprint, les bons managers s’intéressent plus au fonctionnel du sprint backlog et ne blâment pas mais interrogent lorsque l’attendu en fin de sprint n’est pas au rendez-vous. De nos jours, un bon Product Leader doit être avant tout au service de l’organisation en fournissant une vision et une stratégie aux équipes, l’opérationnel étant délégué aux équipes qui doivent alors pouvoir lui confier de manière très transparente leurs problématiques et inquiétudes pour qu’il puisse les aider à surmonter ces obstacles. Cela ne peut pas se faire qu’avec de simples indicateurs figurant sur un tableau de bord.
Pour résumer, les estimations doivent être prises pour ce qu’elles sont, et donc être utilisées comme une aide plutôt qu’une vérité précise. Le rôle d’un PM est de guider son équipe vers le succès et non de contrôler sa productivité. Poser ces réflexions m’ont permis de prendre conscience que cet attachement aux estimations est un symptôme éclairant sur le positionnement d’un manager. Elles sont le “doudou” des managers avec leur côté rassurant et donnent une sensation de contrôle. Je suis complètement en accord avec John Cutler, auteur à succès sur le Produit, pour qui le plus important est de “cultiver la confiance et l'alignement sur les décisions et les objectifs à atteindre”.
