#NoEstimates, beaucoup en parlent, certains le font. Retour d’expérience.

Durant plus d’un an, j’ai eu la chance de faire partie, en tant que Product Owner et Directeur de projet, d’une équipe fonctionnant selon les principes #NoEstimates. Notre cheminement a été riche d’enseignements. Ce sont ces enseignements, issus de notre expérience, que je vous propose dans ce texte.

La démarche est empirique et ce qui est décrit reste lié à notre contexte. L’objet de ce post n’est pas de revenir sur les fondements théoriques du mouvement #NoEstimates. Je vous renverrai pour cela, en premier lieu à l’ouvrage de Vasco Duarte, et aux nombreux articles de blogs et vidéos sur le sujet.

Je m’attacherai plutôt à décrire notre cheminement : comment, béotiens au début du projet, nous avons, à force d’améliorations et de questionnements, progressé dans notre utilisation de la méthode pour en faire un des facteurs majeurs de notre efficacité. J’espère que ce retour d’expérience permettra à d’autres d’éviter certaines erreurs, de partir mieux armés et de bénéficier de tous les avantages d’un principe qui non-seulement remet de la sérénité dans le pilotage des projets agiles mais, par effet de bord, a l’avantage de rendre assez naturel le recours aux bonnes pratiques de collaboration, BDD notamment (Behaviour-Driven Development).

Notre Contexte

• Nous développions une application web aux règles métiers très spécifiques.
• Notre core-team était composée de 7 Développeurs et 2 Product Owners (1 PO client et moi). Un temps, un Ops a fait partie de l’équipe pour mettre en place l’usine de développement qui, entre autres, automatise nos déploiements.
• Nous avions adopté un fonctionnement de type Scrumban. Nous privilégiions l’optimisation de notre système de production et la régularité de notre flux de livraison, en recherche d’un rythme durable et stable. Nous conservions la notion d’itération issue de scrum et les rituels d’amélioration continue associés.
• Les membres de l’équipe étaient sensibilisés, sinon maîtrisaient, les bonnes pratiques de développement logiciel, portées notamment par le Software Craftsmanship.

La décision originelle

Dès le commencement du projet, nous avons décidé que la métrique qui permettrait de suivre l’avancement de nos développements serait l’US (User Story) : Nous n’estimerons pas ces US et ne compterons pas de points de complexité, de Jours-Hommes, de tailles de T-shirt ou autre ; nous compterons seulement les US terminées (Done : dans notre cas, déployées sur l'environnement de production).

Et notre burn-up chart aura ainsi pour unité l’US Done.

Ci-dessous notre burn-up chart de début Avril (Itération 0) à début Décembre 2017.

Devenir prédictibles

Parmi nos devoirs d’équipe se trouve la prédictibilité : pouvoir donner à nos sponsors et parties prenantes une visibilité suffisante sur notre avancement et nos dates de livraison. C’est à cet égard qu’on pense communément que les estimations sont nécessaires : estimer un reste à faire, le comparer à une capacité à faire et en déduire des dates. #NoEstimates se propose de faire aussi bien, voire mieux, que cette approche classique. Voyons ce qu’il en est dans notre cas.

Prédictibilité long terme

#NoEstimates fonde son approche sur la notion de prévision (forecast) et suggère qu’une équipe saura prédire sa vitesse de progression, en termes d’US produites, grâce aux données de 3 à 5 itérations de deux semaines, y compris lorsqu’il s’agit d’itérations de début de projet, peu représentatives du futur rythme de croisière de l’équipe.

Ci-dessous, en jaune la projection de notre progression issue des données de nos 4 premières itérations, comparée à la moyenne réelle en orange foncé.

L’écart est d’une dizaine d’US à horizon 7 mois, soit une marge d’erreur de moins de 10% entre la prévision et la moyenne constatée, ce qui est remarquable de précision. Nous avons donc constaté que l’approche peut être pertinente pour ces prévisions long terme.

Notons tout de même que le choix du nombre d’itérations à considérer pour tracer la projection (3, 4, 5, voire plus) doit être fait en conscience. Il s’agit de savoir déterminer lorsque l’équipe est entrée dans un rythme nominal. Dans notre cas, 4 itérations ont été nécessaires.

Prédictibilité moyen terme

Pour assurer notre prédictibilité, nous devons assurer notre régularité : c’est un principe de base. Or, on constate sur le graphe ci-dessous présentant le nombre d’US produites par itération que ce nombre varie de manière importante. Nous avons de fortes disparités d’une itération à l’autre, ce qui rend la prédictibilité moyen terme - à horizon 4 à 8 itérations - assez hasardeuse. Comment savoir si mes prochaines itérations se solderont par des livraisons de 1 ou 20 US ? Nous avons dû en premier lieu questionner la mesure de notre régularité.

Choisir la bonne mesure

La régularité doit-elle seulement se résumer au nombre d’US produites par itération, à la hauteur de nos barres bleues ? La réponse est non, car ces barres bleues ne tiennent pas compte des variations de notre capacité à faire (CAF). Il s’agit en effet du nombre brut d’US produites sur une durée calendaire de 2 semaines (une itération), sans considération des spécificités de ces périodes (absences, les jours fériés, etc.), et leur influence sur notre CAF.

Afin de pouvoir comparer plus justement nos itérations les unes aux autres, nous avons choisi d’introduire dans nos métriques la notion d’ETP (Equivalent Temps Plein, exprimés en Jours-Hommes - JH) disponibles sur la période. Utilisant cette notion, nous avons construit un indicateur simple : le nombre d’ETP moyen nécessaire à la production de chaque US livrée - soit le nombre de Jours-Hommes disponibles sur la période divisé par le nombre d’US livrées - et nous avons ajouté cette courbe au graphique. La courbe verte sur ce graphe représente le nombre de JH par US à chaque itération. Plus elle est basse, moins la production d’US a nécessité d’effort : à l’inverse, plus elle est élevée plus la production d’US a été coûteuse.

Recourir à cette métrique nous permet de rendre comparables les itérations entre elles. Par exemple, nous pouvons constater que les itérations 3, 4, 5, 6, 8 et même 13, sont très similaires malgré un nombre d’US livrées pouvant varier du simple au double.

Détecter et expliquer les anomalies pour s’améliorer

Cette métrique se révèle surtout un très bon outil d’amélioration continue. En comparant des situations comparables, elle nous permet de détecter les anomalies dans notre processus de production.

Procéder à l’analyse de cette courbe nous permet de faire la distinction entre deux types de phénomènes à l’origine des anomalies :

• Moins de temps sur les US : La proportion de temps que l’équipe a consacré à produire des US est plus faible que d'ordinaire (au bénéfice de tâches techniques, de corrections de bugs, du remboursement de dette technique, de réunions, de l’onboarding de nouveaux arrivants, etc.)
• Plus de temps sur chaque US : La quantité d’effort ou de temps nécessaire à la livraison (de passage à Done) des US a augmenté (durée de développement allongée, retravail suite à un problème de compréhension du besoin, difficulté de déploiement, etc.)

En remontant au niveau des causes, on en trouve de deux types :

• Les causes conjoncturelles sont rapidement identifiables et appellent des contre-mesures ponctuelles facilement actionnables.
• Les causes structurelles quant à elles, interrogent bien plus en profondeur nos pratiques méthodologiques. Dans ce cas, les contre-mesures, loin d’être ponctuelles, s’appliquent au coeur de notre fonctionnement d’équipe. Elles sont les plus intéressantes car influençant le plus durablement notre performance.

Les causes conjoncturelles

Ci-dessous quelques causes conjoncturelles majeures particulièrement visibles sur le graphe. Nous en avons croisées bien d’autres, d’ampleur plus limitée. Mais celles-ci donnent de bons exemples d'événements ponctuels ayant un impact sur notre productivité.

Les traits rouges verticaux figurent les jalons où des livraisons majeures étaient attendues. Chaque cause trouvera sa contre-mesure spécifique - en rétrospective notamment. Je ne m’y étendrai pas.

Les causes structurelles

Du point de vue structurel, nous avons identifié deux enjeux majeurs contribuant directement à notre performance :

• La granularité de nos US. La complexité, la taille des US a une influence mécanique sur le temps nécessaire à leur développement. Plus l’amplitude d’effort à fournir pour chaque US est importante, plus le rythme de livraison des US est incertain et donc moins nous sommes prédictibles.
• La régularité de notre flux et la limitation de notre encours. Une fois notre application ouverte au public, nous avons éprouvé des difficultés inédites à déployer sur l'environnement de production. Or une US Done est pour nous une US déployée sur cet environnement. Le décompte des US produites durant une itération, et donc notre prédictibilité, est directement influencé par notre capacité à déployer régulièrement et fréquemment en production. J’ai eu l’occasion de développer plus longuement cet aspect dans un précédent article sur ce blog : WIP de 1, une histoire de WIP limits qui finit bien.

Granularité et loi des grands nombres

Il se trouve que la granularité est la pierre angulaire du fonctionnement de #NoEstimates. Ce qui semble assez logique. Si je caricature : plutôt que d’estimer des US de tailles et de complexités différentes, faites des US qui ont toutes la même taille et comptez-les. Si cette proposition est séduisante, elle est assez peu opérable, et nous avons élaboré une stratégie afin de répondre à l’enjeu.

Nous avons progressé sur ce sujet par paliers :

1. Nous avons rapidement compris l’influence de la granularité sur notre régularité. Nous n’avions pas conscience, dans les premiers temps du projet, de l’importance de cet aspect dans la bonne mise en oeuvre de la méthode.

2. Nous avons ensuite essayé de réduire l’amplitude de cette granularité, avec quelques succès mais sans y parvenir systématiquement.

3. Nous avons fini par faire le deuil de cette injonction, constatant que les variations sont inévitables et avons pris le parti de les maîtriser en rendant explicite le surcoût de certaines US inaugurales. Par inaugurales, nous entendons les premières US de nouveaux domaines fonctionnels supportant les tâches afférentes à cette nouveauté : refactorings, développements back-end, modifications d’API, etc. Ainsi nous pensions notre scope par grappes d’US : l’US inaugurale et les suivantes profitant des développements réalisés à l’occasion de la première. La loi des grands nombres faisant le reste, nous avons ainsi lissé le nombre d’US produites par itération.

Prédire

A force d’actions d’amélioration, de mises en place de contre-mesures, et après quelques déboires conjoncturels, nous avons atteint en 10 mois la régularité à laquelle nous aspirions.

Cette zone de stabilité est encadrée en rouge ci-dessous. Elle s’est poursuivie au-delà des itérations présentées sur ce graphe : Ce second graphe présente le détail de la période stabilisée (encadrée en rouge au dessus), et la moyenne de JH par US correspondante, en jaune : En utilisant cette moyenne et en la rapportant à nos prévisions d’ETP disponibles dans l’équipe, nous avons pu simplement projeter nos livraisons prévisionnelles sur la base du burn-up chart.

La courbe jaune est une prévision tenant compte du nombre anticipé de Jours-Hommes disponibles. On constate l’écart à une simple projection de la moyenne, en gris. Ici, il s’agit du mois de Mai comptant beaucoup de jours fériés et de congés : Cette projection permet ensuite de prédire simplement le nombre d’US que nous serons probablement à même de livrer durant la période, comme on le fait d’ordinaire avec des points de vélocité. Je pourrais également adjoindre de part et d’autre de cette projection médiane une hypothèse pessimiste et une hypothèse optimiste afin de matérialiser un niveau d’incertitude.

Dans cette situation, avec les informations à ma disposition, j’évalue ma capacité de livraison entre le 29 Mars et le 31 Mai à 33 US :

Prédictibilité et efficacité

Nous venons de le voir, avec les bonnes métriques, #NoEstimates nous a permis de mettre en évidence des anomalies et donc de nourrir notre démarche d’amélioration continue pour, dans un même mouvement :

• Fiabiliser notre prédictibilité en nous donnant des moyens d’action sur nos causes structurelles et conjoncturelles d’irrégularité.
• Gagner en soutenabilité et en fluidité de notre flux et donc de notre rythme de travail.

Nous avons atteint une situation où l’estimation ne portait plus sur notre reste à faire (RAF) mais sur notre capacité à faire (CAF). À court ou moyen terme, le nombre d’US nécessaires pour couvrir un besoin est quasi certain. Ce qui l’est moins, tout en restant facilement anticipable, ce sont les perturbations de notre CAF (absences imprévues, recrudescence de réunions, temps nécessaire à la montée en compétence de nouveaux membres, etc.). Notre constat est que non seulement #NoEstimates nous a fait gagner en précision et en sérénité pour nous engager sur des dates et/ou des périmètres de livraison, mais la méthode nous a également permis d’économiser les efforts et le temps qui est consacré aux estimations dans une organisation agile classique.

Catalyseur de bonnes pratiques

La vertu que l’on associe traditionnellement aux rituels agiles d’estimation est l’appropriation par l’équipe de développement des implications des demandes fonctionnelles. L’estimation serait le prétexte à la compréhension, au challenge du fonctionnel et à l’émergence d’un consensus sur un niveau de complexité en fonction d’hypothèses d’implémentation. S’il est certain qu’il est nécessaire de comprendre les implications du fonctionnel et de se projeter dans l’implémentation pour estimer, le contraire n’est pas vrai. La démarche d’appropriation et d’assimilation des enjeux fonctionnels est effectivement nécessaire ; et cette nécessité a permis l’émergence de pratiques salutaires.

BDD et discussions

BDD (Behaviour-Driven Development) notamment propose un ensemble de bonnes pratiques basées sur la discussion, particulièrement propices à la compréhension des enjeux fonctionnels. La politique de test mise en place sur le projet, associée à la nécessité d’alignement, d'appropriation et de challenge des US, nous ont amenés à suivre beaucoup des préconisations de BDD.

Revues de Story Map

Afin de raffiner le découpage de notre périmètre en User Stories, notre Story Map était régulièrement présentée et discutée avec l’équipe de développement. Ces discussions avaient pour objectif de maîtriser notre granularité et d’identifier les domaines fonctionnels inédits faisant l’objet d’US inaugurales. Elles ont également eu pour vertu de donner de la visibilité sur les développements futurs et de faciliter les décisions d’architecture technique.

Co-construction des US

Ces bonnes pratiques ont par ailleurs progressivement modifié notre fonctionnement, nous avons augmenté la porosité entre les profils fonctionnels et techniques. Les premiers montant en compétence sur les questions d’implémentation, les seconds participant à l’élaboration du fonctionnel de chaque US. Ainsi, les US, telles qu’elles arrivent au sommet du backlog avant d’entrer dans le processus de développement ne sont que des propositions, de la matière à discussion. Ce qui sera véritablement développé est ce qui ressortira de cette discussion entre les développeurs et les product owners, optimisant la valeur délivrée et les efforts d’implémentations.

Indéniablement, #NoEstimates a rendu pour nous naturelles les pratiques qui rapprochent la discussion de l’implémentation et a favorisé l’épanouissement de l’état d’esprit agile dans l’équipe.

Mes conclusions

La première de mes conclusions sur cette expérience est que, oui, “estimates are waste in the Lean mindset” ; pour plusieurs raisons :

• Les rituels d’estimation disparaissent en faveur de nombreuses discussions ad hoc, plus constructives, plus concentrées et moins pénibles. Ce qui permet d’économiser l’énergie de l’équipe pour des tâches plus productives et encourage les échanges, facilités par le recours aux bonnes pratiques BDD notamment.
• Avec les bonnes métriques et de l’expérience, les projections obtenues sont aussi bonnes, voire meilleures que celles s’appuyant sur des estimations.
• Au-delà de la prédictibilité, l’approche offre de bonnes mesures de la performance propices à la mise en place de démarches d’amélioration continue et de sain pilotage.

La seconde est que cette méthode s’adresse à des équipes relativement matures, ou en tout cas, concentrant de la séniorité :

• Les pratiques de présentation et d’appropriation du fonctionnel nécessitent un cadre permettant la mise en oeuvre des fondamentaux de l’agilité, notamment pour ce qui concerne les interactions.
• De même, l’équipe devra questionner son fonctionnement et particulièrement veiller à la régularité de son flux de production, en allant chercher ses références vers Kanban par exemple.
• La pratique du découpage en US doit être maîtrisée pour faire face à l’enjeu de la variation de la granularité.

Ma troisième conclusion est que #NoEstimates n’est pas magique. Les incertitudes demeurent :

• La référence à prendre pour effectuer les projections en début de projet (entre 3 et 5 itérations) reste estimative.
• Les changements nécessitent des ajustements de prédictions estimatifs eux-aussi : changements dans l’équipe, changement de phase de projet (avant ou après mise en production).
• L’incidence de facteurs techniques, comme les montées de versions par exemple, dont il est difficile d’estimer l’impact.

Enfin, ma dernière conclusion est que l'environnement où se déroule le projet - le client dans notre cas - doit être en mesure de laisser s'épanouir une manière différente de fonctionner :

• L’organisation, au sens large, dans laquelle et pour laquelle le projet est réalisé doit faire confiance à l’équipe, en acceptant notamment de renoncer aux estimations et à la comparaison estimé/réalisé pour juger de la performance de l’équipe.

#NoEstimates a sans aucun doute été bénéfique au bon déroulement de notre projet. Néanmoins, s’il s’agit d’un facteur important, ce n’est pas le seul. C’est la combinaison de cette méthode avec une approche lean de l’organisation, une démarche itérative et incrémentale côté produit et un état d’esprit résolument agile de l’équipe qui a fait notre succès. Comme beaucoup de méthodes ou d’approches, #NoEstimates est un des moyens que doit contenir la boîte à outils de gestion de projets. Ce n’est pas une fin en soi ni un absolu.

Ce que je recommanderais

Si je devais aujourd’hui débuter le même projet, voici ce que je m’attacherais à faire dès l’initialisation :

• Être attentif à la granularité des US et sensibiliser l’équipe à ce sujet. Établir rapidement une stratégie en la matière pour maîtriser les relations entre US et identifier les domaines fonctionnels spécifiques.
• Monitorer le nombre de Jours-Hommes par US et en faire mon principal détecteur d’anomalies ; en poursuivant l’objectif de la régularité du flux de production.
• Veiller à ce que les conditions soient propices au BDD, en faisant apparaître dans notre flux une étape de discussion avant le développement, comme le 3 amigos par exemple, et en rendant explicite son objet : aboutir ensemble - développeurs et product owners - à l’US telle qu’elle sera développée.

J’espère que ce post vous sera utile.