“Cessons les estimations!” : Frédéric Leguedois réveille les PO/Chefs de projet

Forcément, un tel titre, c’est un hameçon à Product Owner ou autre chefs de projet. Je me suis laissée tentée par cette intervention ce matin au Web2day (Nantes) car justement, on a abandonné les estimations à point lors de nos derniers sprints. Curieuse de voir comment Frédéric Leguedois justifiait cela. Conférence rythmée et intéressante en tout cas !

Et donc sur son intervention au sujet de la non estimation, voici les quelques notes que j’ai prise :

“Est-ce que respecter ce qui est prévu, c’est un échec ou une réussite ?”

Une fois qu’on s’est vrillé les chevilles avec une deadline et qu’on a figé la quantité de travail à tomber, est-ce qu’on a l’air si gagnant que ça? Apparemment certaines personnes en charge des estimations pensent que si et arrivent à sortir pleins d’arguments :

  • Le client change tout le temps d’avis : moui mais si ça veut dire que c’est un client qui réfléchit et qui évolue, c’est plutôt bon signe, non ?
  • Les devs sont nuls : et si ce n’était pas plutôt le responsable du planning qui évaluait mal les performances des équipes ?
  • Il y a eu des imprévus : ah ça, sans boule de cristal c’est sûr que c’est compliqué de tout prévoir.

Les méthodes d’estimation ont la vie dure et sillonnent les confs et les bouquins depuis plusieurs décennies. D’où la difficulté peut-être à les remettre en cause et discerner les effets de bords négatifs de l’estimation.

Quelles sont les conséquences de la planification ?

Frédéric en distingue plusieurs :

  • Qui dit deadline à respecter, dit sanction si pas respectée. La manière dont vont s’exprimer les devs sur l’avancée du projet, va dépendre de la sanction. Plus il y en aura, moins la communication sera facilitée. Et donc on perd beaucoup en visibilité et efficacité à l’échelle d’une équipe.
  • La deadline est la plus grande génératrice de bugs : à trop vouloir shiper sur la deadline, on peut se retrouver à faire des choix techniques qui induisent une dette technique. Et l’ouverture d’un cercle vicieux qui se traine sur toutes les prochaines fonctionnalités à créer.
  • Le summum de la dette technique, c’est quand on entend la phrase “ça couterait moins cher de tout refaire”. Dans ce genre de contexte, cela devient beaucoup plus difficile de réagir face aux demandes d’évolutions.
  • Les estimations mettent les devs en situation de simple exécutants, ce qui est un gachis absolu face aux compétences qu’ils peuvent proposer.
  • La vélocité dépend aussi du client : challengeant ou baton dans les roues, cela ne donne pas la même chose sur la charge réelle des consultants par exemple.

Trois solutions pour piloter sans faire d’estimation :

  • Quitter le management par la peur
  • Prévoir des temps de partage et d’échanges entre devs
  • Générer de la confiance avec les clients, et pas de la promesse

Frédéric termine avec un graphique représentant un carré avec dans chacun des coins : qualité, coût, délais et périmètre fonctionnel. Selon lui, impossible d’empiéter sur les trois premiers coins. Seul une approche par petites briques du périmètre fonctionnel peut permettre de s’approcher vraiment d’une démarche Agile.

J’espère avoir retranscris correctement ses propos, n’hésitez pas à me signaler tout ajout/correction.

Et pour en savoir plus sur le speaker : http://www.leguedois.fr/