Dans notre précédent article, nous avons discuté de faire de plus petites unités de travail et de ne pas en faire plus qu’il n’est nécessaire pour répondre au besoin de notre utilisateur final. De cette manière, nous terminons davantage de choses, nous les livrons plus rapidement, et nous développons moins de code inutile (étant donné que nous avons des retours d’informations réguliers de la part des utilisateurs).

Les fans du développement agile de logiciels reconnaîtront là l’un des concepts axiomatiques derrière agile basé sur des travaux beaucoup plus anciens comme le développement itératif et incrémental (vo). Sans développement incrémental, itératif et sans retours d’informations, un processus quel qu’il soit aura du mal à se dire agile d’une quelconque manière.

Donc, reprenons la conversation à partir de là aujourd’hui.

A : … Mais, j’ai … nous avons obtenu 23 points aujourd’hui et les éléments sont de la même taille que ceux qui correspondaient à 1/19ème de sprint.
B : Il y a deux explications possibles.
A : Quelle est la première explication ?
B : C’est que l’équipe attribue un nombre de points supérieur pour un travail de taille identique, en un mot c’est : l’inflation.
A : Pourquoi feraient-ils cela ?

Les salariés dans une entreprise essayent de satisfaire constamment leurs patrons. Lorsque les entreprises mettent la pression sur les développeurs pour produire davantage de points, les développeurs commencent à trouver des biais pour faire monter le score du nombre de points. Il y a quelques exemples hilarants dans cet article de Joshua Kerievsky sur les story points publié sur le blog d’Industrial Logic. Certaines fois, c’est fait intentionnellement, mais pas toujours.

Lorsqu’une équipe a fait 8 points sur un sprint, une itération ou autre chose d’équivalent, et qu’elle est déçue, elle aura souvent tendance à regarder en arrière sur la semaine écoulée ; elle réalisera qu’elle a sous-estimée certaines stories qui étaient plus difficiles qu’elles ne paraissaient. Et c’est la raison pour laquelle le sprint a fait seulement 8 points alors qu’il aurait dû faire 15 points. En réaction à cela, elle fera des surestimations la prochaine fois. Ce genre d’inflation n’est pas fait dans l’intention de duper, mais pour mieux refléter la réalité et la vérité. Et désormais l’équipe est plus satisfaite de faire un sprint à 15 points avec la même quantité de travail accomplit.

L’interprétation faite par certaines personnes qu’il s’agit d’une certaine forme d’accélération n’est pas dans l’intention de l’équipe. Elle s’octroie simplement le crédit mérité pour le travail réellement effectué.

« Marquer des points » et « avoir des hauts scores » illustrent de manière très classique la loi de Goodhart. Un indicateur (d’un taux de réalisation) qui s’avère un indicateur raisonnable, une fois choisit comme objectif, cesse d’être un indicateur valide.

Vous entendrez certaines équipes de développement engagées dans des processus à là scrum parler de travail “qui explose”. C’est-à-dire « comme un ballon » et non « comme de la dynamite ». Comme par exemple pour une story à qui l’on donne un petit 2, mais qui s’avère prendre la quasi-totalité du sprint parce qu’elle comporte tout un tas de risques et d’incertitudes que personne n’a vu.

Une story peut avoir semblé simple : « ajouter un champ pour un code de réduction ». Le product owner/manager ou le patron a peut-être dit : « cela ne devrait être qu’une story a deux points ».

Cela semble facile. Cela devrait être facile à faire. Qu’est-ce qui pourrait être plus simple que ça ? Il s’agit d’un champ dans un formulaire et vous soustrayez une valeur d’un total.

Mais ce genre de choses sont rarement aussi simple. Le marketing et la comptabilité veulent tracer les remises, les dates d’expiration des réductions, les données à caractère démographiques liées à l’utilisation des réductions. Les réductions doivent apparaître sur la facture du client pour lui montrer qu’il a fait une bonne affaire (marketing !). Les remises doivent figurées sur les rapports de vente.

Il peut y avoir des tableaux de bord dédiés aux remises pour mesurer le succès des promotions. Il peut y avoir aussi des ramifications anti-fraudes.

Puis tout d’un coup quelqu’un décide qu’il devrait y avoir plusieurs codes de réductions et qu’ils devraient se combiner d’une certaine façon et pas d’une autre. Désormais l’expérience utilisateur doit redessiner le nouveau formulaire, et il y a des règles compliquées. Peut-être a t-on besoin d’un nouveau microservice ?

Mais c’était bien une story a 3 points, n’est-ce pas ? Cela amène donc les questions suivantes :

  • Pourquoi l’équipe a fait seulement 5 points à ce sprint ?
  • Qu’est-ce qui se passe MAL chez elle ?
  • Pourquoi ralentit-elle ?
  • Qu’est-ce qui peut la motiver à aller plus vite ?
  • L’équipe X a fait 50 points par rapport à cette équipe qui en a fait 5, pourquoi l’équipe X fait-elle 10 fois mieux ?
  • Est-ce que cette équipe a besoin d’un plan d’amélioration des performances ?

Il s’agit là de mauvaises questions. Elles sont basées sur de mauvaises hypothèses et agir dans leurs sens ne fera qu’empirer les choses. Nous avons discuté précédemment de l’espace de curiosité en relation avec la vélocité évoquée en partie 6 que vous pourriez bien avoir envie d’aller relire désormais.

Enfin, la chose à comprendre à propos des équipes utilisant des temps impartis1 c’est que la même quantité de travail est faite chaque semaine (exception faite des absences, des réunions et des évènements pris sur le temps de l’entreprise). La vélocité est la plupart du temps une illusion (vo).

Réfléchissez donc à la loi de Goodhart, à l’espace de curiosité, aux stories qui explosent et à l’inflation.

Puis revenez vous joindre à nous pour la 9ème partie.


Auteur : Tim Ottinger
Source : Q and A on velocity, Part VIII
Date de parution originale : 19 Décembre 2018


Traducteur : Nicolas Mereaux
Date de traduction : 08/05/2020


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.


  1. ou les timeboxes si vous préférez le terme anglo-saxon - NdT