Estimation et Agilité : un paradoxe ?

Photo by Alex on Unsplash

Le sujet des estimations est au coeur des débats lorsque l’on se lance en Agilité. Comment faire ? Est-ce utile ? sont d’autant de questions auxquelles il y a tout autant de réponses différentes.

Une chose est sûre : la communauté Agile est alignée sur le fait que les estimations, comme utilisées dans le passé, ne sont plus adaptées au contexte actuel et peuvent même être nuisibles à la bonne mise en oeuvre d’une transformation Agile.

Mais comment faire autrement ? Un courant sous le nom de #NoEstimates s’est distingué depuis quelques années en re-questionnant la place de l’estimation et en proposant une démarche alternative.

Je vous propose dans cet article de discuter d’estimation, d’Agilité et de voir en quoi consiste vraiment l’approche #NoEstimates.

Bonne lecture ! 🙂

Pourquoi estimer ?

Photo by rawpixel on Unsplash

L’une des raisons principales de l’estimation, comme utilisée aujourd’hui dans la gestion de projet, est de savoir si le projet va être rentable et donc s’il mérite d’être effectué.

Cette rentabilité est obtenue en faisant le rapport entre le revenu prévu et les ressources employées pour l’obtenir (Wikipédia).

L’évaluation du coût d’un projet est considérée comme une des phases les plus importantes et les plus délicates de la phase de cadrage car une dérive au niveau de ce chiffrage peut générer un risque d’impact conséquent sur le respect du budget et des délais prévus : c’est pourquoi on fournit énormément de temps et d’effort pour s’assurer de la fiabilité de ses résultats.

Estimation et Agilité

Il me paraît intéressant de revenir un petit peu en arrière, pour rappeler quelques éléments clés de l’émergence de l’Agilité.

Dans les années 1990, Internet fait son apparition et les projets informatiques se multiplient.

La manière dont on mène ces projets est simple car comme dans notre habitude, on aime utiliser les bonnes recettes du passé. On sait construire des bâtiments alors on va construire des logiciels de la même manière ! On va donc prendre du temps pour analyser le besoin que l’on croit constant, mettre en oeuvre une solution et la fournir en une fois au client.

Après quelques années de mise en oeuvre, le constat est le suivant :

Chaos Report – Standish Group 1994

Dit autrement : cela ne marche pas.

En effet, la recette du passé ne semble pas fonctionner comme prévu. Il est donc nécessaire de faire autrement. C’est ce qu’ont voulu faire ces 17 experts en promouvant une approche légère de développement logiciel en opposition à une démarche lourde pilotée par la documentation : en 2001, le Manifeste Agile vit enfin le jour.

Sans revenir sur le contenu du Manifeste Agile, en voici quelques idées fondamentales :

Le monde change beaucoup plus vite que l’on a la capacité de le prévoir
L’incertitude fait partie intégrante du monde du développement logiciel
Nous devons naviguer dans cette incertitude en apprenant par petits pas
La meilleure stratégie est de faire confiance aux individus et à leurs interactions
Il y a donc ici un changement important de paradigme

Voyons l’impact sur un référentiel commun de la gestion de projet, le triangle de fer.

Le triangle de fer

Approche Traditionnelle

Dans une approche traditionnelle, pilotée par le plan, l’estimation est déterminante afin de nous assurer de respecter la charge et le calendrier afin d’atteindre l’ensemble du contenu prédéfini. Cela ne fonctionne que si nous avons tout en main pour pouvoir prédire et que les composantes sur lesquelles nous nous basons ne bougent pas trop. On a alors la conviction de pouvoir savoir, dès le départ, comme pour la construction de bâtiments.

La question que l’on se pose est alors : “Pouvons-nous tout faire ?”

L’estimation est alors un moyen de prendre la décision de lancer le projet ou non.

Approche Agile

Si l’on accepte l’incertitude comme une réalité, une approche prédictive n’est plus adaptée. On lui préfèrera une approche empirique nous permettant de nous adapter plus facilement aux mouvements et aux changements de l’environnement. En considérant ne pas savoir au départ, on met en oeuvre une série d’expérimentations pour tenter au plus vite de valider nos hypothèses.

La question que l’on se pose est alors : “Comment optimiser ma production de valeur avec ce que j’ai (temps et personnes) ?”

Dans ce cadre, on réalise un investissement (un nombre de personnes pendant une période de temps) et l’on s’arrange pour fournir le plus de valeur possible avec ce que l’on a.

En Agile, la priorisation prévaut sur l’estimation.

Ainsi, on peut déjà dire que le concept d’estimation, comme défini plus haut, semble inadapté avec la ligne directrice que propose l’Agilité.

L’estimation : une activité inadaptée ?

Comme dans la vie de tous les jours, il est important de choisir les bons outils pour le bon problème.

Je trouve que le modèle Cynefin est particulièrement pertinent dans ce cadre, décrivant différents contextes et leurs stratégies associées.

Framework Cynefin – Dave Snowden

Je n’en reprendrais que 2 ici :

  • Un problème est défini comme Compliqué, si le lien de causalité existe mais n’apparaît pas clair de manière immédiate. La stratégie associée est d’analyser théoriquement le problème puis d’y répondre d’après ces résultats.
  • Un problème est défini comme Complexe, si le lien de causalité n’existe pas et ne peut être défini qu’à posteriori. La stratégie associée est de mettre en place une expérimentation afin de valider ses hypothèses.

Le changement de paradigme opéré par l’Agilité est de concevoir et d’accepter qu’il puisse exister d’autres domaines que le Compliqué – où tout est prévisible, si l’on prend suffisamment le temps. L’estimation, comme définie plus haut, appartient plutôt au domaine du Compliqué.

Le monde du développement logiciel est aujourd’hui tellement dynamique et mouvant qu’il est impossible de prévoir à l’avance quel va être le prochain besoin et par conséquent quelle va être la prochaine solution à mettre en oeuvre. On le placerait alors plutôt dans le domaine du Complexe.

Note : On dit aujourd’hui souvent que l’on évolue dans un monde VUCA dont la Complexité est un des attributs.

Quel est le problème d’utiliser un outil du domaine du Compliqué pour répondre à un problème Complexe ?
BCG Complexity Index

Les résultats de cette étude du BCG montre qu’en 60 ans, alors que l’indice de complexité externe (l’environnement) s’est multiplié par 6, les solutions mises en oeuvre en entreprise pour y répondre a multiplié leur indice de complication interne par 35 !

C’est comme si vous mangiez de la soupe avec une fourchette : vous pouvez tenter, mais il va vous falloir beaucoup de coups de fourchette !

Le problème avec les estimations

Photo by Joao Tzanno on Unsplash

Si l’on décide tout de même d’aller dans le domaine de l’estimation, voici 3 choses à garder en tête :

  1. Cela prend toujours plus de temps que prévu, même en prenant en compte la loi de Hofstadter (Loi de Hofstadter)
  2. Le travail s’étale de façon à occuper le temps disponible pour son achèvement (Loi de Parkinson)
  3. Le coût d’une fonctionnalité correspond au coût de sa Complication Accidentelle

Je vous propose de rentrer un peu plus en détail dans cette dernière notion, introduite par J.B. Raisenberger, que j’ai trouvée particulièrement intéressante.

En effet, il affirme que :

Coût d’une fonctionnalité = f(Complication Essentielle, Complication Accidentelle)
  • Complication Essentielle : la difficulté du problème en lui-même
  • Complication Accidentelle : la complication émergente provenant des structures organisationnelles (comme les processus de validation par exemple) et de la manière dont le code est écrit

Sachant que la complication accidentelle est bien souvent plus grande que la complication essentielle, on peut en conclure que :

Pour connaître le véritable coût d’une fonctionnalité, il faudrait être capable de mesurer le coût de la complication Accidentelle.

Ce que cela nous apprend est que l’estimation de l’effort seul, comme il est souvent fait dans les projets, n’est pas adapté. En effet, le travail passe au travers d’un flux et il serait donc plus adéquat de mesurer des éléments comme le temps de cycle ou Lead Time pour se faire une idée de la véritable capacité de production du système. Le seul problème est que ce système est rarement constant, les équipes dédiées et stables n’étant que trop peu nombreuses au sein des organisations.

Donc pour résumer, lorsque l’on nous demande une estimation :

On n’en sait rien et on fournit beaucoup d’effort pour se prouver le contraire.

Le pire dans tout cela, c’est que l’estimation est souvent demandée au moment où l’on en sait le moins, et où les décisions les plus importantes sont prises !

Note : si la notion de complication accidentelle vous intéresse, je vous invite à regarder cette conférence (7mn26).

L’approche #NoEstimates

Le livre #NoEstimates

Lorsque l’on voit #NoEstimates, on peut penser que l’idée est de ne plus faire d’estimations : ce n’est pas le cas.

Comme le dit bien Àngel Medinilla dans la préface du livre :

Rappelez-vous que #NoEstimates ne s’agit pas de ne plus jamais faire d’estimations, mais de trouver la quantité minimale d’estimations qui feront l’affaire, et de chercher attentivement des moyens de réduire ce besoin encore plus.

Dans cette direction, on peut sentir l’inspiration Lean de la démarche : l’estimation n’a en soi pas de valeur pour le produit final, on va donc la réduire au maximum.

Comment faire sans estimation, qui était à la base de la planification et du suivi de projet classique ?

Le but principal du #NoEstimates est d’aider au suivi de projet de la manière la plus simple possible. Au coeur de la démarche, le principe Agile suivant :

Un logiciel opérationnel est la principale mesure d’avancement.

Pour y répondre, il nous faut fournir un incrément de produit fonctionnel, correspondant à une information actionnable.

Le principe de la User Story semble alors tout à fait approprié pour remplir ce rôle, cette dernière étant considérée comme le plus petit élément de valeur utile au client.

Qui dit User Story, dit INVEST, et c’est tout particulièrement sa composante I (Indépendante) qui va nous aider à suivre au mieux notre projet.

En effet, la recherche d’indépendance implique un travail de découpage du besoin le plus fin possible, ce qui a de nombreux bienfaits :

Options plus on découpe, plus on s’ouvre le champ d’options en se permettant de ne pas faire certaines choses
Valeur plus on découpe, plus l’élément de travail sortira vite, et donc plus on pourra fournir de la valeur au client rapidement
Historisation plus l’élément de travail sortira vite, plus on pourra mesurer son temps de passage au travers de la chaîne de valeur et accumuler de la donnée factuelle
Prédictibilité plus on accumulera de données, plus on apprendra de notre système et sa capacité à produire
Communication plus on apprendra de notre système, plus on pourra communiquer avec nos demandeurs avec des données fiables
Confiance plus on communiquera avec nos demandeurs, plus on tissera une relation de confiance avec eux et moins nous aurons besoin de justifier nos décisions… par des estimations par exemple !  😉

Dans le même sens, Mary Poppendieck affirme que :

La meilleure manière d’obtenir des résultats de développement logiciel prédictibles est de

commencer tôt, apprendre constamment, s’engager tard, et livrer rapidement.

Mary Poppendieck – The Predictibility Paradox

Ainsi, la Priorisation prévaut sur l’Estimation. On peut croire que la priorisation vient après l’estimation, cela vient simplement de notre habitude à focaliser notre attention sur le Retour sur Investissement – correspondant au rapport entre la valeur ajoutée au client et le coût de sa réalisation.

Si vous savez pertinemment qu’une fonctionnalité est LA chose dont vous avez besoin maintenant, même si cela vous coûte cher, ne vaut-elle finalement pas le coup d’être réalisée tout de même ?

Cette phrase risque d’en faire réagir certain(e)s, probablement. Cependant, c’est aujourd’hui la conviction que j’ai : la valeur doit être au centre de nos préoccupations, le ROI vient en second.

En effet, si l’on reprend les différentes catégories du Purpose Alignment Model, un élément n’a pas seulement de la valeur lorsqu’il nous fait gagner de l’argent, mais également lorsqu’il nous empêche de trop en perdre. La notion de valeur est complexe et subjective d’où l’importance de véritablement étudier la question de manière approfondie.

L’approche Agile se décrit comme étant pilotée par la valeur, peu importe ce qu’elle représente pour vous à un instant t, assurez-vous simplement de la délivrer le plus vite possible, incrémentalement, et sans excuses ! 😛

Vers le #NoEstimates

Photo by Bruno Nascimento on Unsplash

Vasco Duarte nous propose un chemin à suivre, étape par étape, pour aller vers du #NoEstimates. Plutôt que de les voir comme des étapes séquentielles, je vous invite à les considérer comme une série d’options selon là où vous vous situez à cet instant.

Note : Je l’ai ré-agencé pour plus de lisibilité mais l’essentiel reste le même.

1. Sortir de l’estimation absolue

a) En utilisant les Story Points

Si vous faites encore de l’estimation absolue en “heures” et en “jour homme”, le passage au Story points est une première étape. En effet, se détacher de l’estimation absolue (subjective et individuelle) pour passer à de l’estimation relative et collective est un bon commencement et a déjà beaucoup de valeur !

Note : Même si cette pratique reste de l’estimation, elle crée un contexte d’échanges à une fréquence plus élevée entre les membres de l’équipe.

Plusieurs pratiques vous permettent d’aller dans cette direction : le Planning Poker ou l’eXtreme Quotation par exemple.

b) En arrêtant d’estimer les tâches

Après avoir estimé leurs User Stories en points, les équipes ont tendance à les découper en tâches puis à estimer ces dernières en heures afin de vérifier que cela reste cohérent. Encore une fois, cela peut apparaître rassurant mais cela ne nous aide pas à prévoir l’imprévu imprévu ! 🙂

Il faut garder en tête que dans une phase de planning, ce qui importe est d’avoir les premières tâches pour pouvoir démarrer et non pas chercher l’exhaustivité. En effet, des éléments vont forcément émerger pendant votre itération / cadence, donc autant commencer au plus vite pour se heurter à la réalité du terrain !

Ce qui nous importe est donc l’élément de valeur (la User Story), pas la manière dont on la met en oeuvre.

Voici un protocle que j’ai utilisé dans une équipe :

1 Après avoir donné un poids aux User Stories et en avoir sélectionnées pour la prochaine itération, elles sont affichées sur une vitre
2 Chaque développeur prend une Story et pendant 1mn, inscrit toutes les tâches qui lui viennent à l’esprit
3 On réitère la même chose pour les Stories restantes
4 Puis en mode gallerie pendant 5mn, chacun repasse sur l’ensemble des Stories afin d’ajouter, supprimer, modifier et surtout échanger.
5  En 15 mn, nous avions un premier découpage en tâches partagé de l’ensemble des stories et ils ont démarré l’itération.

Gardez en tête que l’estimation n’est pas l’objectif, mais plutôt l’alignement sur ce qu’il y a à faire. Et non, on n’a pas besoin de faire d’estimation pour analyser et découper ! 😛

c) En enlevant des cartes d’options du Planning Poker 

L’objectif est de ne pas chercher à être “précis” dans l’estimation.

Dans un premier temps, vous pouvez seulement garder 1, 3 et 8 par exemple. L’idée étant de réduire au maximum le nombre d’options afin d’aller vers un découpage le plus cohérent possible. Ainsi, la question que vous vous poserez par la suite sera plutôt du type : “Est-ce que l’on peut sortir cette Story demain si on la commence aujourd’hui ?”

Dans mes accompagnements, j’invite les équipes à n’utiliser que 3 cartes :

1 Cet élément est suffisamment clair pour pouvoir le prendre et le sortir dans le temps qui nous est imparti.
NFC (“No Fucking Clue”) Cet élément n’est pas suffisamment clair, peut-on le détailler ?
TFB (“Too Fucking Big”) Cet élément est trop gros pour garantir sa sortie dans le temps qui nous est imparti, peut-on le découper ?

De cette manière, chaque carte permet une prise de décision menant à une action plutôt que de chercher la précision de l’estimation.

2. Réduire l’effet de la Loi de Parkinson

Pour réduire l’effet de la Loi de Parkinson, vous pouvez réduire le temps que vous vous donnez pour compléter un élément de travail : par exemple, donnez vous un objectif de finir chaque story en 2 jours. Ici, c’est surtout l’intention qui compte, la réalité est bien souvent toute autre ! L’idée est de prendre une habitude de découpage cohérente et partagée.

Cela risque d’être dûr au début mais cette approche vous apportera des bénéfices concrets.

3. Mieux appréhender son système

a) En accumulant de la donnée

L’objectif est de mieux comprendre son système de production. L’idée reste néanmoins de garder la mesure la plus simple possible afin que cela ne devienne pas une surcharge pour l’équipe.

Vous pouvez par exemple simplement noter la date d’entrée et la date de sortie de vos stories : on parle communément de Lead Time.

L’accumulation de ces données vous permettra de créer des histogrammes, comme la carte de contrôle Kanban :

https://fr.slideshare.net/morisseau/dessine-moi-une-obeya-kanban

Ces informations visuelles vous permettront dans un premier temps d’avoir une idée de votre capacité de production. Cela vous permettra de mieux échanger avec le métier en vous appuyant sur une base concrète de données.

On espère alors voir les questions passer de “Combien cela coûte ?” à “Pour quand pourrais-je avoir cette fonctionnalité ?”.

b) En utilisant le Lead Time moyen

L’accumulation de donnée précédente vous permettra d’avoir une idée – à une période donnée – de votre capacité moyenne de production : c’est ce que l’on appelle le Lead Time moyen.

Vous pouvez également faire l’exercice en évaluant le Lead Time moyen de stories que vous considérez être de tailles différentes : S, M, L par exemple si on utilise les tailles de T-Shirt.

Vous devriez au final vous rendre compte que ces chiffres sont aussi fiables que les estimations !

Note : David Anderson considère que l’impact du temps d’attente sur la sortie d’un élément de travail est bien plus important que sa taille. L’idée reste donc bien de mesurer notre capacité moyenne “à sortir des choses” avant tout. On retrouve ici l’idée que la complication Accidentelle prévaut sur la complication Essentielle.

c) En considérant les stories de même durée

En travaillant sur un découpage cohérent et partagé, sur lequel s’appuiera un ensemble de données concrètes, vous pourrez simplement compter le nombre de stories que vous êtes capables de livrer par période de temps. Vous aurez ainsi une réelle visibilité sur l’avancement de votre projet et une capacité à échanger avec votre métier afin de prioriser au mieux le travail à faire ! #NoEstimates

Conclusion

L’estimation est un sujet très controversé dans la gestion de projet actuelle. En effet, en tant qu’Agiliste, nous devons jongler entre la conviction qu’elle n’est pas adaptée au contexte de nos interventions et la difficulté des entreprises à changer de paradigme en acceptant l’incertitude comme une réalité.

Notre challenge est donc principalement de changer les perceptions pour réinventer notre manière de faire les choses.

Le mouvement #NoEstimates se distingue comme une approche revenant aux sources de l’Agilité : découper le besoin le plus finement possible, se baser sur de l’empirisme en accumulant de la donnée et apprendre en continu afin de pouvoir produire de la valeur le plus rapidement possible ! J’ai personnellement beaucoup apprécié l’esprit, un peu moins le livre de Vasco Duarte !

Je vous invite à tester cette manière de gérer vos projets en commençant doucement et en observant les bénéfices que vous pourriez en tirer ! 😉

Partager

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur pinterest
Partager sur email
Partager sur whatsapp
Olivier MY

Olivier MY

Issu d'un cursus ingénieur, je me suis vite rendu compte que mes appétences et compétences tournaient plus autour de l'humain que de la technique. Je suis alors devenu Coach Agile et Coach Professionnel car j'ai toujours voulu contribuer à rendre le monde meilleur. J'accompagne aujourd'hui des individus, des équipes et des organisations vers une meilleure compréhension d'eux-mêmes afin de bâtir ensemble le futur qui leur correspond.

Commentaires

2 réflexions sur “Estimation et Agilité : un paradoxe ?”

  1. Merci Olivier pour cet article complet.
    Pour ma part, je partage tes conclusions. je m’interroge également sur la pertinence des estimations d”effort, notamment, quand j’observe le peu d’intérêt que cette pratique apporte aux équipes.
    Selon moi, les estimations en sprint planning, par exemple, reste encore utiles car elles provoquent des discussions sur la réalisation d’une fonctionnalité, en fonction des écarts d’estimation relevés.
    Par exemples : le PO pose des questions et précise sa demande lorsqu’il y a des écarts, l’un des dev peut annoncer que c’est difficile alors qu’un autre lui dit le contraire, etc. Ainsi, la parole se libère, Il se crée ensuite un consensus engageant les membres dans l’accomplissement de leur objectifs court terme. Encore une fois, ce sont les personnes et les interactions qui apportent de la valeur.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Articles récents

Thalassagile

Thalass’Agile : une expérience réflexive hors du commun

Il y a des périodes où l’on a besoin de prendre du temps pour soi. Pour faire acte de ce que l’on a vécu, prendre …

LIRE PLUS
Teamwork

Team Building et Matrice Give and Take

Au cours d’une discussion avec Guy Lerat Jr qui me partageait ses aventures d’accompagnement, j’apprends qu’il va devoir organiser un Team Building important pour une …

LIRE PLUS
Photo by Jamie Templeton on Unsplash

Workshop : Améliorer sa posture de conseil

Dans le domaine du coaching Agile se pose souvent la question de la posture de coach. Dois-je être plutôt en posture basse (questionnement, prise de …

LIRE PLUS
Photo by Irina Iriser on Unsplash

L’échec du modèle Spotify

Il y a des articles comme cela qui chamboulent un peu les idées reçues et qui permettent de prendre un peu de recul. C’est le …

LIRE PLUS

Une expérience de facilitation à distance

Dans cette période de confinement où les interactions physiques sont limitées, nous sommes dans l’obligation d’animer nos ateliers à distance à l’aide d’une multitude d’outils. …

LIRE PLUS

Un atelier de clarification de rôle

Transformation Agile petite ou grande échelle, la question des rôles est une problématique assez commune. Pas qu’elle m’apparaisse comme normale, mais souvent car c’est la …

LIRE PLUS
Retour haut de page

Confidentialité et cookies : ce site utilise des cookies. En continuant à naviguer sur ce site, vous acceptez que nous en utilisions. Pour en savoir plus, y compris sur la façon de contrôler les cookies, reportez-vous à ce qui suit : Politique relative aux cookies.

Prenons contact