Estimations : la battle !

Cet article fait suite au KōKan Day de janvier 2024 au cours duquel j’ai eu envie de (re)lancer un échange/débat autour de la notion des estimations.

Ce sujet étant régulièrement abordé dans les contextes dans lesquels nous intervenons <troll>POUR CALCULER LA VÉLOCITÉ CAR TU COMPRENDS SINON ON NE SAIT PAS SI L’ÉQUIPE EST PERFORMANTE</troll> et faisant l’objet de débat sur les sites, blogs et autres réseaux sociaux professionnels.

Afin de rendre l’activité ludique et malgré la gravité de ce sujet ô combien important, j’ai proposé à mes collègues de le faire sous forme de battle. 3 équipes s’affrontaient :

• l’équipe pro Story Points
• Les pro Jours/Homme
• et enfin l’équipe NoEstimates

Evidemment, je me suis fait un malin plaisir à choisir les équipes à l’opposé de leur “conviction” du moment 😈.

Les règles de la battle

Aucune règle !

Ou presque 😉

Sur fond de Snoop Dog, Eminem ou 2Pac, chaque équipe a 2 minutes pour expliquer pourquoi sa pratique est la meilleure… et ridiculiser la pratique défendue par les 2 autres équipes.

Au-delà des magnifiques joutes verbales et de l’ingéniosité de l’équipe, l’activité visait surtout à prendre du recul sur ce sujet : 

• Pour “quoi” estimer?
• Quand estimer?
• Faut-il estimer?

Avons-nous trouvé la réponse à ces questions ? Non. Dommage, tout le monde semble la chercher et certains semblent même penser qu’il y a une solution unique ! Par contre, nous sommes sortis de cet exercice avec la conviction que nous pouvons vivre sans. 

Nos idées à propos des estimations

En revanche, nous nous sommes accordés sur les idées suivantes :

• Comme souvent, les pratiques quelles qu’elles soient, peuvent être mal utilisées. Ou pas utilisées à bon escient (au services des personnes, des clients, de l’organisation). 
• Les estimations peuvent être utiles à certains moments dans le cycle de delivery d’une équipe. Ou à certains moments clés de la vie d’une équipe et/ou d’un projet.
• Les estimations peuvent avoir des utilités au-delà d’un simple chiffre : partage d’expérience, apprentissage collectif, montée en compétences…
• Qui sommes-nous pour imposer un changement de pratique à une équipe sous prétexte qu’elle “devient agile” ?
• Nous ne pouvons pas juger de l’efficacité, de l’expertise ou de quoi que ce soit d’autres d’une équipe en se basant sur la manière dont elle estime !

Sur ce dernier point, je pense qu’il est difficile d ‘aborder quoi que ce soit sans regarder le contexte. Et cela est valable pour ce sujet et bien d’autres d’ailleurs :

• l’historique du produit;
• l’historique de l’équipe (quels profils à l’intérieur de l’équipe, leur ancienneté sur le produit, leur expérience générale);
• la communication et la collaboration entre l’équipe de réalisation et les parties prenantes;
• ….

De plus, il faut comprendre l’idée que le développement logiciel s’apparente à de l’ingénierie plus que du manufacturing dans la manière de concevoir et produire.

Ce qui implique – entre autres – une “incertitude” qu’il faut accepter. On peut faire toutes les estimations du monde, elles n’apporteront pas plus de visibilité sur ce qu’il sera possible de réaliser dans les mois à venir.

Un exercice très KōKannien…

Chez KōKan, nous avons des profils différents (coachs, scrum master, devs) et cet échange visait à confronter nos croyances, habitudes et discours vus de nos différentes fenêtres. Et ouvrir nos chakras pour nous permettre à tous d’être un cran au dessus pendant nos missions !

Et chez vous, qu’est-ce que vos expériences vous ont amené à découvrir sur ce sujet ?

EDIT : Si vous cherchez à savoir s’ il y avait des gagnants de la battle… Sur le fond, aucune équipe n’a pris le pas sur les autres. Sur la forme en revanche ! Le jury impartial que je suis donnerait une petite pièce à Dr Elouen Dre et MC Aurélien avec des répliques déjà cultes chez nous. Un jour peut être ils publieront leur rap sur les Story Points…

Matthieu

J’évolue depuis près de 15 ans dans le développement applicatif.

D’abord développeur, j’ai pendant plusieurs années eu des activités de Scrum Master et de Coach Agile qui m’ont permis de naviguer dans des environnements variés et de collaborer avec les multiples acteurs des organisations.

Je suis maintenant revenu à mes premiers amours et propose mes services en tant que Développeur Back-end et Scrum Master.