Lors d'un BBL organisé chez mon client, et facilité à la dernière minute avec panache par Chloé Mahalin (consultante Itametis), nous avons pu nous pencher un peu plus en détail sur ce qu'est le mouvement #NoEstimates et ses enjeux. Le débat qui a suivi nous a amené à questionner, dans une plus grande mesure, des différents cas d’usage d’une estimation et de ses prérequis pour en permettre la fiabilité.
Mais ce fut surtout pour moi une illumination politique : j'ai pu découvrir qu'une bonne estimation ne devrait pas vous enfermer dans une relation maître-esclave hégélienne, mais introduire un prétexte à un dialogue permettant une meilleure compréhension des attendus et des implications, en construisant la confiance.
Contexte
Qu'est-ce que faire une estimation ? Et d'ailleurs, qu'estime-t-on ? Dans la conversation, le mot estimation était lancé, sans préciser souvent de quelle estimation nous parlions. Nous étions dans un contexte IT grosse entreprise, et les mesures estimées, implicites, étaient en fait variées, mais tournaient a priori autours des trois grandeurs classiques de la gestion de projet (le « triangle de fer[i] ») : délais/planning, coût/ressource, périmètre. Premier rappel de Chloé : on ne peut estimer l'une des trois grandeurs sans connaître ou estimer les deux autres. Ça va mieux en le disant, je me rappellerai que la prochaine fois qu'on me demandera une estimation d'un délai, je m'assurerai qu'on a bien fixé ensemble ressources et périmètre.
Puis, rapidement, dans la discussion, j'ai eu l'impression qu'il fallait aller plus loin : veut-on estimer ce qu'on va produire ? Ne faut-il pas plutôt estimer ce que ça va apporter au client ? Ou, mieux, ce que ça va rapporter à l'équipe ? Pour essayer de répondre à tout ça, je vous propose un petit tour de ce que Chloé a présenté, des échanges qui ont suivi et ce à quoi ça m'a fait penser.
Conditions de fiabilité d’une estimation, et ce qu’elles entraînent
Il y a trois conditions générales pour qu'une estimation simple soit fiable, que ce soit à partir d'abaques ou de projections.
Premièrement, elle doit se baser sur l'expérience d’une réalisation similaire, et non sur l'idée qu'on pourrait se faire d'une tâche. En gardant à l’esprit que le temps passé sur une tâche ne reflète pas le délai nécessaire à l’accomplissement de la tâche, car il ne prend pas en compte les temps d'attente, ni les temps de dérangements (qui viennent souvent de l’entreprise, et peuvent être bénéfiques, comme aider un ou une collègue, et c’est ce que propose de résoudre Henri Kniberg avec ses « jour-personne parfaits »[ii]).
En résumé, on ne peut estimer que ce qui est connu, et comparable. On s’oblige donc à conserver les mêmes conditions que le passé pour garantir la fiabilité des estimations. Ainsi, croire dans ses estimations limite l'innovation et l'expérimentation.
Deuxièmement, le périmètre ne doit pas varier dans le temps : il faut être sûr qu'il y a dedans tout ce qui sera nécessaire pour que ça « marche ». C'est donc fixer plein d'hypothèses, autant sur les livrables et leur capacité à satisfaire l'utilisateur, que sur l'usage que celui-ci en fera. Sortir du cadre de ces hypothèses aura des conséquences sur l’ensemble de la production et mènera à des arbitrages douloureux.
Ainsi, on ne peut estimer que ce dont on est sûr du périmètre. De ce fait, croire dans ses estimations empêche de s'assurer que le produit réponde au besoin in fine.
Troisièmement, une estimation n'est possible que dans un contexte constant : il faut supposer que le passé est comparable au présent. Que ce soit en termes d'équipe, mais aussi de technologies. Ainsi, on ne peut estimer que sur des technologies qu'on maîtrise et avec des équipes constantes, en limitant les imprévus : croire dans ses estimations limite les changements d'organisation et d'architecture.
Je commence à voir déjà se dessiner quelque chose : les estimations n'engagent que ceux qui y croient. Et cela pourrait expliquer le chiffre du CHAOS Report comme quoi seuls 30% des projets informatiques tiennent leur estimation originelle (sur ce sujet, ce chiffre n'engage aussi que ceux qui y croient, je n'ai pas trouvé de fondements méthodologies suffisamment solides à ce chiffre)[iii].
A quoi peut servir une estimation
Une fois ce tableau à charge fait, le public a néanmoins assez spontanément affirmé qu'estimer reste nécessaire. Ou, pour le reformuler par rapport au chapitre précédent, qu'on a besoin d'estimation dans lesquelles on peut croire. Plusieurs bonnes raisons sont sorties autours de la table : en simplifiant, demander des estimations fiables permettrait un, de sélectionner un partenaire par ses coûts ; deux, de se rassurer quant aux risques ou même de déléguer les risques à un tiers ; trois, de faire des choix de périmètres ; quatre, de renforcer l'engagement des parties.
Néanmoins, sachant que les conditions pour avoir une estimation correcte sont rarement atteintes, voici quelques réponses données par l'auditoire, qui pourraient permettre d'atteindre ces objectifs sans avoir besoin d'estimation fiable.
Concernant le besoin de se baser sur des estimations pour gérer ses risques, de voir ce qui est possible, de faire les bons compromis comme de réduire ses ambitions sur un périmètre financièrement viable ; bref, de prendre des décisions stratégiques, les solutions suivantes ont été proposées :
- Ne pas tout miser d'un coup, mais commencer par investir un minimum pour voir, que l’on acceptera de perdre sans regret. Par exemple, avant d'engager la totalité du budget, voyez ce que votre prestataire peut faire pour 5% du budget, (et s’assurer a posteriori qu'il n'a pas dépensé plus).
- Faire travailler par itération plusieurs équipes en parallèle, avec sélection et financement à chaque étape, concept de l’émission la Nouvelle Star.
- Plutôt que parler du livrable, parlons de la promesse (UX).
Cela permet en outre de contourner le biais, étudié par l’économie comportementale, des « coûts irrécupérables » : quand celui ou celle qui paye, ayant engagé énormément de frais, poursuit son escalade de l’engagement en refinançant un projet au-delà de son seuil de rentabilité[iv]. Cela se rapproche du cas, évoqué en session, d’une course Uber, qui est estimée à priori et que l’on pense accepter en connaissance de cause alors que, si votre VTC se retrouve coincé dans les bouchons, vous risquez de voir des frais additionnels s’ajouter à votre facture.
Concernant le fait qu'une estimation est nécessaire au dimensionnement d’une équipe dans le cas où le périmètre et la date limite sont figés (comme l'implémentation d'une demande réglementaire par exemple), les alternatives à l’estimation sont :
- De distribuer les tâches dans différentes équipes, chacune orientée valeur client, pour que chacune puisse arbitrer le risque avec d'autres projets qui ne comporteraient pas les mêmes contraintes
- Automatiser les changements réglementaires (via paramétrage, pour rendre l'avenir conforme au passé).
- D’accepter de mettre en place des actions manuelles sur du court terme et de prioriser ce qui apporte le plus de valeur, en terminant l’automatisation de la chaîne après la date butoir
Enfin, concernant le fait que donner des estimations et vouloir s'y tenir permettrait aux différentes parties prenantes de se sentir plus engagées, sans même forcément contractualiser. Mais dans l'assistance, il a été avancé contre cela que
- On obtient d’avantage d'adhésion en mettant en place des boucles de feedback courtes,
- On n'arrive à ne générer de l'engagement que sur des estimations à taille humaine.
Un dernier point : estimer permet aussi de générer un dialogue entre ceux ou celles qui pensent connaître le besoin, et ceux ou celles qui sauraient le satisfaire (et finalement entre tous ceux ou toutes celles qui participent au produit). Mais dans ce cas, il n’est plus nécessaire de croire en l'estimation, elle devient objet de dialogue et de compréhension, abandonnant son statut d’objectif à atteindre.
Et le #NoEstimates dans tout ça?
Le point de départ du BBL était de parler du mouvement #NoEstimates dans les méthodes agiles. Cela s'applique en particulier pendant les exercices d'estimation en équipe des cérémonies Scrum (Sprint Plannings, Grooming Sessions, avec ou sans Planning Poker). Remarquons que les objectifs de ces rituels sont bien ceux donnés plus haut : permettre au PO de se rendre compte de ce qu'il pourrait avoir dans deux semaines, comprendre les réalisations à faire derrière chaque demande, engager les équipes, et ce qui est le plus important pour moi, engager la discussion pour aligner les objectifs.
Ma compréhension du #NoEstimates, dans ce cadre, est de ne plus chiffrer les User Stories, même pas en Story Points, et surtout pas en heures, mais juste de compter les User Stories que l'on va produire. Une fois les stories proposées, on peut distinguer ce qui prendra 1 à réaliser de ce qui prendra plus de 1. Si la story prend plus de 1, alors elle doit être découpée pour n’avoir que des éléments à 1. C'est pousser la préférence à l’extrême entre compter la valeur de ce qu'on produit, à la quantité produite (Outcome vs Output). On change son rapport au Burn Down Chart pour commencer un suivi en US. On mesure ce que le client verra, et non la complexité de développement de la story ou le temps passé dessus : on gagne en sens, on se rapproche de ce qui a de la valeur ! Et cela permet d’amener un flux continu de production permettant la transition entre un Scrum itératif vers un Scrumban (ou un flow) continu, plus en adéquation avec la notion de continuous delivery. Que des points positifs !
Prototype de cartes de planning poker #NoEstimates, par Constantin Guay.
Cela correspond bien à mon expérience personnelle aussi : en phase de croisière dans mes équipes Scrum, toutes les US faisaient 1, 2, ou 3, rarement 5. Au-dessus nous essayions de découper. Et nous savions bien qu'à la fin, des 1 faisaient finalement 3, et des 3 faisaient 1. Le seul intérêt que je trouvais alors au Planning Poker était l’échange et la communication qu’il permettait entre l’équipe et le Product Owner. Le consensus sur les estimations devenant alors inutile. Sans compter les cas où les estimations reflétaient plus une posture de groupe qu’une conviction propre.
En appliquant les conditions de fiabilité d'une estimation vues plus haut, on pourrait donc estimer le périmètre des sprints en utilisant #NoEstimates, sous les conditions suivantes :
- Il faut que les Stories soient de la même taille, de même raffinement ;
- Que l’on ait la même confiance dans nos capacités à réaliser chaque US à peu près similaire (d'où la notion de spike) ;
- Que la qualité attendue soit identique entre les US ;
- Qu’il n’y ait rien à jeter (qu'il n'y pas d'US presque déjà faite) ;
- Qu’il n’y ait rien à découper : de toutes façons, une US trop grosse va poser un problème au niveau du flow (Merge, Test…).
Rien de nouveau sous le soleil, il faut apprendre à slicer (découper finement) ! L'équipe doit se mettre d'accord sur des règles, comme par exemple l’obligation de testabilité à la fin de la journée.
Un exemple typique lorsque l’on doit développer dix règles similaires, très simples, est de mettre dans une US les deux premières règles, incluant le côté générique, et les huit autres dans une seconde US.
Dans ces conditions, le #NoEstimates est une méthode simple et rapide d'estimation pendant les sprints Scrums.
On peut donc dire d'une façon générale, que le « No Estimates » s’appliquera plus facilement à une équipe mature qui a déjà éprouvé l’échange sur l’estimation, par exemple au terme de plusieurs itérations agiles Scrum, et ayant tissé des liens de confiance les uns avec les autres, mais aussi avec son environnement, puisque ce dernier ne sera pas en mesure de lui demander des estimations fines.
(Et pour ceux qui sont plutôt orientés Kanban, le découpage des US en éléments nominaux reste essentiel afin de garder un flux continu. Cela n’empêchant pas une estimation rétrospective.).
Retour à la première question, fondamentale : quoi estimer ?
Qu'essaie-t-on de résoudre avec la planification ? Pourquoi prend on encore des décisions via des estimations basées sur de l’incertitude ?
Je pense que la réponse à ces questions tient dans celle-ci : qui fait une estimation, pour qui ?
C'est a priori un échange entre deux parties ayant chacune leur compétence : celle qui a un besoin, et celle qui pourra y répondre. Mais très vite, une troisième partie s'invite : celle qui vérifie, ou celle qui gère. Le contrat est-il tenu ? Le budget est-il maîtrisé ?
Alors pourquoi est-ce une tierce partie qui demande des estimations, et non le client ?
Je suis persuadé de connaître déjà une partie des réponses : autant l'agilité réduit la nécessité de contractualiser et de contrôler, et préfère apporter un maximum au client pour une production minimale, autant les estimations permettent d'améliorer le contrôle, et de maitriser nos peurs face au changement.
Et c'est là ma conclusion, ce que je retiendrai j'espère toute ma vie dorénavant : produire une estimation s'inscrit la plupart du temps dans une relation de pouvoir. Elle permet d'inscrire la relation dans la domination voire l'aliénation, et réduit les libertés. C'est hégélien, on pourrait dire : je me reconnais ton esclave parce que je t'ai donné une estimation. Qui n’a jamais connu cette tension au creux de l’estomac lorsque l’on vous demande de manière récurrente de vous réengager sur les dates données au début ? Mais cela fonctionne aussi dans l'autre sens parfois : je me reconnais ton esclave parce que j'ai cru en ton estimation. Si l’estimation est un objectif à tenir, alors le jeu sera de vous promettre la lune pour récupérer l’appel d’offre.
Ainsi, #NoEstimate est pour moi une condition d'émancipation des deux parties, celle qui produit, et celle qui commandite.
Par prolongement, dans une très grosse entreprise, les estimations participent aux différents jeux qui permettent à une minorité d’individus d’organiser le contrôle, que ce soit quand un employé ou une employée s’engage pour une échéance, que quand ce ou cette dernière inscrit cette estimation dans une négociation pouvant mettre en jeu d’autres revendications[v].
Au contraire, les estimations devraient se limiter à favoriser l'échange, créant alors une relation de partenariat par la confiance qu’elle construit. Dans ce cas, pourquoi ne pas conserver le vote pendant le poker planning, pour faire discuter l'équipe, et oublier l'estimation une fois que tout le monde est d'accord ? Mais pour cela, pas de relation de pouvoir au sein de l’équipe (et à condition que la vélocité en Story Points ne soit pas partagé avec d’autres acteurs dans l’entreprise si celle-ci s’inscrit dans une relation de pouvoir).
Il existe d’autres manières plus concrètes de s’émanciper de l’estimation. On a déjà évoqué préférer mesurer la valeur apportée au client (c’est à dire la pertinence de la solution apportée) plutôt que le temps passé dessus : cibler la valeur d'usage plus que la valeur d'échange (les jour-personne).
Un autre élément concret est de préférer travailler sur les causes de retard, plutôt que sur les moyens de prendre en compte ces causes de retard dans les estimations : résoudre le problème, et non pas optimiser le processus d'estimation.
Enfin, cela donne envie de se plonger dans des approches budgétaires de type Beyond Budgeting.
Je suis alors encore plus convaincu qu'on pourra retrouver dans beaucoup de pratiques véritablement agiles des conditions d'émancipation entre développeur ou développeuses d'une part, et utilisateur ou utilisatrice d'autre part, et la récupération du sens du travail avec le plaisir de se lever tous les matins !
Édouard Gomez-Vaëz, en partenariat avec Chloé MAHALIN, ITAMETIS
[i] Petit rappel sur le triangle de fer : dans le cas où le périmètre est indiscutable par contractualisation, et la deadline déterminée avec le client, identifier les ressources nécessaires pour la tenue de ces deux contraintes passe par une estimation complète des éléments à produire, et la rédaction d'un plan (aussi appelée roadmap). Il ne reste alors qu'à identifier en avance de phase tous les risques et aléas que l'on va rencontrer dans le but de tenir ces trois variables toutes puissantes. C'est la promesse d'une gestion de projet traditionnelle. Premier rappel de Chloé : On ne peut proposer une estimation de l'une des trois grandeurs sans commencer à estimer les deux autres.
[ii] Voir « Scrum depuis les Tranchées » - Henrik Kniberg
[iii] Par rigueur intellectuelle, je glisserai ici qu'il existe néanmoins des moyens, dont on en n'a pas beaucoup parlé pendant le BBL, qui permettraient de s'affranchir partiellement de ces limitations. Cela reste des méthodes d'estimation beaucoup plus complexes. Par exemple celle se basant sur abaques de patterns abstraits d'architecture : en dessinant l'architecture, cela nous permet de négliger le temps passé à produire à l'intérieur d'une équipe/composant, devant celui nécessaire à ce que deux équipes/composants communiquent, en prenant en compte leur éloignement. Néanmoins, cette approche par la prescription architecturale reste contraire aux principes du design émergent et à l’adaptabilité de l’architecture en fonction de l’évolution des besoins. Il s’agit donc de rajouter une nouvelle prescription à la gestion du projet.
Ou encore celle consistant à distribuer la marge en fin de projet sans le dire aux équipes, pour réduire le biais qui fait que tout temps dédié lors de la planification à une tâche sera consommé entièrement par cette tâche.
Les limites de ces méthodes restent leur coût et l'expertise requise pour être pertinentes. Il n’est pas donc pas surprenant de les voir principalement mises en application dans des environnements malgré tout peu innovants pour la première, ou d'industrialisation intense pour la seconde, comme l'aéronautique de mémoire.
[iv] On illustre souvent ce biais avec l’exemple du Concorde, dont le financement a dû être complété suite à un trop gros investissement des pays.
[v] De notre point de vue, cet aspect est d’autant plus renforcé avec la spécialisation des tâches (taylorisme). Dans ce contexte, le contrôle ne se fait plus par les pairs, mais par la hiérarchie. Des pans entiers de nos entreprises sont dédiés à l’encadrement d’une minorité qui répond aux contrats. Le management est en miettes. Ainsi, si l’on considère que ce contrôle ne peut ensuite s’exprimer que la remontée de métriques et d’indicateurs, mesurant une vision de la performance qui ne passe pas par l’innovation mais par le respect d’un plan, alors l’estimation n’est alors qu’une métrique, qui par son usage, sert à légitimer les stratégies décisionnelles prises par les experts et les expertes de la gestion du risque, des budgets, des coûts, de l’humain. Cela n’est pas l’objet de cet article, mais reste une de nos convictions fortes.
