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 ?

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 :

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 :

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 ? »

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.

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.

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.

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

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 :

• 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 :

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 :

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

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 :

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 :

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 :

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

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.

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

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.

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 !

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 :

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 :

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 :

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 !

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 ! 😉