[note, l’enfer a souvent été représenté sous la forme de 7 cercles, chacun dédiés à différents types de péchés]
Cette semaine, j’ai eu l’occasion de lire l’un des pires articles sur les estimations que j’ai pu lire jusqu’à présent dans ma carrière. C’est tellement gros et tellement asséné avec aplomb que je me fais un devoir d’y réagir en ligne.
Afin de rendre cette expérience un peu plus divertissante, j’ai décidé de vous la raconter en brodant sur la métaphore de la descente aux enfers.
Un mot sur le contexte de ma découverte. Je me baladais dans un outil de gestion produit (product board) dans le but d’aider à préparer le plan de livraison pour notre prochain incrément de six semaines lorsque je vois une colonne « T-shirt size » dans un tableau qui regroupe les prochaines features à livrer. À côté du titre de la colonne, un lien vers un article censé expliquer les estimations en taille de t-shirt.
Je sais ce que sont les estimations en taille de t-shirt et d’ailleurs, je m’intéresse particulièrement à ce sujet des estimations au sens large, qu’elles se veuillent agiles ou pas d’ailleurs. Si je clique donc sur ce lien, c’est pour voir ce que l’organisation dans laquelle j’évolue met en exergue comme explication.
Et là ça déraille, je vais essayer d’expliquer dans le détail tous les maillons de ce déraillement.
Cercle numéro 1, où suis-je ?
Je tombe donc sur https://asana.com/resources/t-shirt-sizing et mon premier réflexe est de me questionner sur ce nom de domaine qui ne me dit rien du tout. J’en déduis tout de suite que je suis sur une page qui n’a pour raison d’exister que le fait de générer du contenu dans le but de capter les âmes en perditions qui souhaitent en savoir plus sur les estimations en taille de t-shirt et ce afin de vendre un produit quelconque. Premier mauvais signal.
Cercle 2, la folie
Là où ça se gâte encore plus, c’est quand on entre dans le sujet des estimations agiles.
Agile and Scrum teams initially popularized t-shirt sizing as a way to measure story points. Story points—also known as planning poker—are a way to estimate effort or relative size of work during sprint planning.
Bon la première phrase n’a en elle-même aucun sens, « trouver une manière de mesurer les story points » ? On parle là de mesurer une unité de mesure, on reviendra plus tard sur l’idée qui se cache derrière tout ça.
Cercle 3, la confusion
Ici, on retrouve la confusion, non marginale, entre story point et planning poker. Alors pour éclaircir cette confusion une bonne fois pour toutes : le seul point commun entre les deux, c’est Mike Cohn, le créateur des jeux de cartes de poker planning basés sur la suite de Fibonacci légèrement modifiée. L’auteure aurait grandement bénéficié de la lecture d’Agile estimating and planning, un des livres de référence de Mike Cohn pour tous ceux qui s’intéresse sérieusement au sujet des estimations agiles, dommage.
Autre maladresse, ce n’est pas parce que certaines équipes estiment sous forme de planning poker et durant leurs séances de planification que c’est une règle. On peut très bien estimer en story point lors de session d’affinage des besoins ou de séances de macro-estimations (xtreme quotation).
Cercle 4, la paresse (du développeur bien sûr)
When the Scrum master begins the next sprint cycle, they pull tasks from the backlog until they hit a certain number of story points. That way, the Scrum team ensures they have enough to work on during the sprint—without biting off more than they can chew.
Là, on retrouve une peur viscérale très largement partagée, l’équipe aura-t-elle assez de travail pour le prochain sprint ! Quiconque ayant un tant soit peu d’expérience au côté des équipes de développement sait que le risque est majoritairement d’avoir les yeux plus gros que le ventre. Si gérer se risque était aussi simple que faire une addition de story point ça se saurait. Au passage, le scrum master est le roi ici. On se demande où sont passés le product owner ainsi que l’équipe de développement et ce qu’il en est de leur implication dans le choix des items du sprint, mais attention, tout ça c’est pour le bien de l’équipe.
Cercle 5, L’impatience (mais c’est prêt pour quand bordel !)
La phrase suivante confirme l’incompréhension de l’usage d’une suite mathématique en entretenant l’idée que si nous utilisons un numéro, nous l’associons systématiquement à du temps. Peut-être pour l’auteure, mais pas pour les centaines de personnes que j’ai accompagné jusqu’à présent… Elle confond certainement avec la tentation inavouée de vouloir reconvertir les story point en jour homme. Je vois bien un cercle de l’enfer entouré de cascades de lave et dédié aux déviants qui ont de telles pratiques (c’est ici que me sont venus l’idée du titre et de la métaphore 👹).
Cercle 6, bonus, la gourmandise
Après petit conseil nord américain, il me semble, ne pas utiliser toutes les tailles de t-shirt, mais elle recommande quand même d’user de XS, S, M, L et XL, on évitera donc XXL, XXXL et XXXXL, merci ! D’après l’auteure, c’est pour éviter que les gens ne soient confus ! Si on ne l’était pas déjà, c’est une occasion de plus de l’être.
Une vraie bonne raison d’éviter le trop grand nombre de tailles ou de jalons est le peu de valeur que cela apporte par rapport au temps que cela pourrait prendre.
Cercle final, Le boss aux 3 visages aka le chef de projet
Vient ensuite certainement le pire paragraphe, divisé en trois parties et qui traite de qui a le droit d’estimer, vous sentez déjà que ça ne sera jamais l’équipe de développement ?
For product backlog projects, the product owner assigns t-shirt sizes, because they’re closest to the work.
Alors pour moi, mais ce n’est pas que mon humble avis, les plus proches du travail sont ceux qui le réalisent, soit l’équipe de développement. Ça c’est le premier boss, disons Baal déguisé en product owner.
For Agile teams running Scrum, the Scrum master reviews t-shirt sizes, which were previously assigned by a product owner, before a sprint.
Double faute en une phrase et même dans l’hypothèse où le scrum master est un développeur de l’équipe, d’où ce mec aurait l’outrecuidance d’estimer le travail à la place de ses pairs développeurs ? Ça on va dire que c’est Asmodée déguisé en scrum master.
For general project teams, each team member sets their own t-shirt sizes, based on the team’s understanding of what each size of work represents.
Donc chaque contributeur individuel sort son t-shirt et là ça se complique extrêmement sévèrement si on pense « équipe agile » sinon ça passe crème, vous allez voir :
Première hypothèse, on a une équipe de 5 dev, chacun estime, mais disons que ça ne converge pas. Eh bien, vous n’en saurez pas plus, mais à mon avis, ce n’est pas bien grave, car à la fin, c’est le chef de projet, pardon le scrum master, pardon le product owner de toute façon ses trois termes sont complètement intervertibles (et non pas réversibles comme un t-shirt) qui choisira !
Deuxième hypothèse qui s’avérera la bonne comme le montrerons les captures d’écran de cet immonde outil, chacun estime ses tâches et basta, car chacun travaille dans son coin, ne chezchez pas les bénéfices du travail en équipe ici.
Conclusion
Beaucoup d’effort ici pour nous vendre un outil qui sert qu’à traquer l’avancement individuel au final. Beaucoup de déguisements qui sont à la fois signes d’ignorances, de duperie, mais surtout de la persistance d’une mentalité tayloriste, dont les seules véritables préoccupations sont :
- S’assurer que 100% des ressources sont occupées à 100% (j’utilise le terme sciemment, car pour l’auteure les gens sont des ressources). Je vous invite à lire là-dessus les concepts de théorie X et Y du travail.
- Isoler la ressource ou diviser pour mieux contrôler, l’équipe ici est une coquille vide qui ne recouvre rien, le travail est atomisé, chaque poste est censé être autonome en dépit de la réalité. Pas d’équipe donc, mais au mieux un groupe d’individus.
- Contrôler, les tâches sont estimées à votre place puis vous sont assignées, ensuite, on relèvera vos compteurs individuels en temps réel.
Bon courage pour travailler dans un tel environnement et bon courage pour en sortir quelque chose de valeur dans un contexte impliquant de travailler à plusieurs à la résolution de problèmes complexes.
J’aimerais tout de même finir sur une note positive, dans un prochain article, je reviendrais sur les diverses manières agiles d’estimer, à adapter bien sûr à votre contexte.
French 
English
0 Commentaire