NoEstimates : soyez vraiment agile

Pour ne pas estimer, il faut vraiment être agile

L’édition 2015 de la conférence Lean Kanban France, c’est la rencontre avec des orateurs remarquables de l’agilité en IT et en dehors de l’IT. En ouverture de la deuxième journée, Vasco Duarte, qui plaide pour l’arrêt de l’estimation des tâches dans les projets informatiques, nous a livré une vision détaillée de son analyse. C’est convaincant mais suffit-il de convaincre les parties prenantes d’un projet pour pouvoir mettre cela en place ? Estimer c’est s’engager. Donc prendre la responsabilité et en décharger l’autre. Nos organisations sont-elles assez agiles pour cela ?

Le message

Le message de Vasco Duarte est plutôt simple :

  1. Pour augmenter la productivité, vous devez produire le même volume de résultats avec moins de travail.
  2. Si vous organisez votre travail par ordre de priorité, que vous travaillez toujours sur les choses les plus importantes, alors la tâche « estimer » n’aura pas d’impact sur votre plan de travail.

Mais pourquoi estimer ne serait-il pas prioritaire ? Vasco Duarte démontre sur de nombreux exemples concrets que « l’estimation exacte » n’existe pas. Il montre également comment les estimations sont utilisées à tort pour répondre à des questions essentielles de la gestion projet, telles que la taille de l’équipe, durée prévisionnelle du projet, ce qui se traduit ensuite en budget à allouer pour le projet. Sa posture critique reste pour autant toujours constructive et ne l’empêche pas de proposer des outils alternatifs pour répondre avec les bons outils à ces questions. Voici par exemple un résumé de ce Vasco Duarte appelle « Applied capacity planning with no estimates« .

  1. Analyser – Procéder à une analyse détaillée des informations collectées pour pouvoir les exploiter.
  1. Collecter des mesures – Il est nécessaire de mesurer pour prévoir.
  2. Temps – Le temps est en général un facteur limitant du projet.
  3. Prévoir – Utiliser les données collectées pour établir des prévisions par rapport aux contraintes temporelles.
  4. Hypothèses – Le travail de prévision n’est valable que lorsque certaines conditions sont réunies. Les expliciter sous forme d’hypothèses est essentiel.
  5. Similitudes – Utiliser la prévision et comparer avec d’autres références.
  6. Penser – À partir savoir ainsi collecté, réfléchir et évaluer la faisabilité du projet, sinon prendre les décisions adaptées.

Globalement, la démonstration est très convaincante. Mais le problème n’est-il pas au-delà des faits qu’il énonce si brillamment ?  Ne pas estimer c’est aussi ne pas entrer dans le jeu de la prédiction. Et assumer ensemble la réussite du projet. #NoEstimates serait-il en fait une autre manière de dire « Préférons la collaboration avec le client à la négociation contractuelle » ?

 La démonstration

Visiblement, Vasco Duarte ne cherche pas à convaincre. Pas d’appel à nos émotions ou d’effets ronflants dans sa présentation. Il énonce tranquillement des faits. Et c’est très convaincant.

Il rappelle par exemple l’impact énorme des files d’attente dans nos projets. Une tâche donnée passe en moyenne entre 80 et 90% du temps de son « existence » à attendre qu’on s’occupe d’elle. Il est donc plus important, mathématiquement, de mesurer et d’optimiser le débit du flux que d’estimer des temps de travail sur chacune des tâches.  Logique non ?
Vasco présente également le résultat d’expérimentations très concrètes. Il s’agit par exemple de comparer la date de fin du projet d’après les estimations et en remplaçant les estimations par la valeur 1. La date finale est peu impactée.  Un participant de la conférence en profite pour twitter avec malice sa propre expérience :

Tweet

Vasco rappelle également que les incidents, totalement imprévisibles ont un poids aussi important que la nature du projet dans l’issue finale. En d’autres termes, quand on regarde le coût par unité de temps, la complication accidentelle est aussi importante que la complication intrinsèque :

Estimer ... la complication accidentelle aussi ?
Estimer … la complication accidentelle aussi ?

La conclusion semble donc sans appel. Les estimations échouent à prédire convenablement l’issue d’un projet. Il appelle donc les dirigeants d’entreprises à ne pas « parier l’avenir de leur entreprise sur la base de méthodes qui ont de si mauvais résultats ». Autrement dit : « l’espoir est une mauvaise stratégie de management ».

L'espoir n'est pas une bonne stratégie de management
L’espoir n’est pas une bonne stratégie de management

La démonstration de Vasco Duarte a de quoi ébranler les plus sceptiques. Pourquoi donc continuons-nous massivement d’estimer ?

Il suffit de s’y mettre ?

Nous en discutons entre participants après la keynote et ceux qui ont essayé témoignent. Il pour lutter contre la fausse évidence des estimations, il faut convaincre. Et cela prend beaucoup plus de temps que de ne pas estimer. Ok, mais alors, il ne reste plus qu’à démontrer par l’absurde que cela ne sert à rien, comme nous le suggérait notre twittos taquin ? Oui, c’est une approche efficace bien que radicale. Mais qui présente des risques. Parce que les estimations ne servent pas vraiment, pas seulement, à deviner la date de fin. Dans la discussion qui s’ensuit, nous revenons en fait à ce que Craig Larman appelle le « contract game ».

Le « contract game »

Quand je donne une estimation, je donne aussi à mon interlocuteur la possibilité de me dire en cas d’écart « pourtant tu m’avais dit… ».  Estimer servirait donc (avant tout ?) à transférer la responsabilité sur les épaules de celui qui estime. Estimer c’est s’engager. Donc prendre la responsabilité et en décharger l’autre. Nos organisations sont-elles assez agiles pour cela ? Ne pas estimer nécessiterait d’admettre à la fois que la bonne estimation n’existe pas mais aussi qu’il vaut mieux « favoriser  la collaboration avec le client plutôt que le contrat ». Diantre, il faudrait donc mettre en œuvre vraiment les valeurs agiles ?

Voici la démarche en 10 points que Vasco Duarte propose pour mettre en place une démarche « NoEstimates » :

  1. Faites confiance à votre système (de mesure et de développement logiciel) ou construisez-en un autre,
  2. Réduisez le cycle des retours (de la part du client),
  3. Croyez les données (mesurées), pas les prévisions,
  4. Examinez (systématiquement) des alternatives pour prendre des décisions ,mieux corrélées à valeur ajoutée pour l’activité de votre entreprise,
  5. Tester avant tout la valeur, ensuite seulement la fonctionnalité,
  6. Les estimations sont un gâchis, réduisez leur impact sur votre activité,
  7. Ne mesurez l’avancement que sur la base de logiciel opérationnel,
  8. Apprenez à comprendre votre système (mesures, temps de traversée, débit, …),
  9. Utilisez des méthodes qui ont fait la preuve de leur efficacité,
  10. La transformation commence par vous-même.

On voit que son approche est strictement méthodologique. Très juste et efficace certainement, mais Vasco Duarte ne dit rien du lâcher-prise qui sera nécessaire dans l’organisation. Qui devra accepter dans votre projet que l’équipe ne s’engage pas sur une date de fin estimée a priori ? Qui devra s’impliquer aux côtés de l’équipe pour mesurer avec elle l’avancement réel puis projeter cet avancement ? Qui devra se convaincre qu’un projet efficace c’est avant tout un projet qui délivre de la valeur souvent, peu importe quand on décide de l’arrêter, ni même quel est son coût si son retour sur investissement est à la hauteur des attentes ? Ces questions sont importantes pour vous éviter des efforts inutiles quand il s’agira de convaincre de ne plus estimer.

Pour ne pas pas estimer, il faut vraiment être agile

Être vraiment agile, se remettre personnellement en question, mettre de côté des estimations hasardeuses au profit de mesures rigoureuses… Pas si simple en fait.

C’est peut-être pour cela que la première fois que Vasco Duarte a présenté son analyse, désormais mondialement connue sous le titre de NoEstimates, la réponse fut si sèche. « Ferme la porte…. Et ne parle de ça à personne !».

Pour ne pas estimer, il faut  donc pouvoir vraiment être agile et, au passage, déranger quelques usages. Tout un programme n’est-ce pas ?

Pour aller plus loin

Voici un excellent article sur la question de l’estimation et de l’évaluation dans les projets agiles, par David Morris, avec une belle traduction de @OyoMy. Entre autres idées, on y retrouve celle-ci : estimer est souvent utile, les estimations, elles, sont souvent inutiles. Parce que estimer permet de clarifier et parce que les estimations deviennent une cible de fait, qui renvoie la valeur à l’arrière-plan des priorités.

PS : Merci à yann Gensollen (@Yann_G, play14.org) pour la relecture de cet article et les compléments pertinents et essentiels qu’il y a apportés. Il est également l’auteur d’un article fort intéressant sur cette conférence Lean Kanban France 2015

 

@agilphil

@agilphil

Consultant et coach agile pour l'émergence solutions métier. Product owning, coaching de Product Owner et parties prenantes, coaching d'équipe agile, facilitation.

Laisser un commentaire

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