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…
