Notre coach lean (Zach) voudrait comprendre comment on calcule le nombre de « user stories » validées à l’issue d’un sprint.

La coach agile (Clem) lui répond que c’est relativement simple :

1. avant le sprint, le product owner a sélectionné une liste de user stories dans un backlog plus vaste. Les développeurs ont réduit à cette liste à un nombre plus petit de user stories, calculé en fonction de leur capacité à faire pendant le sprint. Ils disposent ainsi d’un backlog pour le sprint,
2. à la fin du sprint, les user stories terminées sont présentées par les développeurs lors d’une démo au product owner et/ou à de vrais utilisateurs,
3. toutes ou une partie des user stories sont validées pendant la démo.

Zach, pour vérifier qu’il a bien compris, traduit cette mécanique en petit indicateur de performance, pratique routinière des coachs Lean :

 

 

 

 

 

 

 

 

Clem n’est pas trop fan de ces notions de réussi / raté – vert / rouge, l’équipe ayant dans les deux cas fait de son mieux dans un contexte pas facile. Mais elle connait Zach et ses habitudes de tout mesurer, donc elle acquiesce.

 

Zach a maintenant une 2^e question, profitant du fait que Clem ait l’air disponible en ce moment. « En fait, lui dit-il, je n’ai pas compris exactement ce que voulait dire « user story validée »« . <soupir de Clem> « Du point de vue lean, on encourage les gens à définir de plus en plus précisément la notion de ok/ko : est-ce que le travail que j’ai fourni est bon ou non ? Cela n’a vraiment rien d’évident, l’un peut aimer et l’autre pas. Il n’empêche, le client comme l’entreprise cherchent des produits de qualité et chacun, à son poste, doit pouvoir être capable de dire si ce qu’il voit est ok ou ko. Parce que quand il y arrive, il peut commencer à progresser en termes de compétences et de maîtrise du process : il faut que je sois plus précis ici, que la machine fonctionne mieux là, etc… »

Clem est certaine qu’il y a moins de deux minutes elle a expliqué à Zach que c’est au cours de la démo que les participants décident si une user story est correcte ou non. C’est pourtant simple. Mais elle aussi commence à savoir jouer au jeu de « je réponds à ta question par une question ». « Aurais-tu un exemple de user story qui te pose problème ? »

Zach est ravi ! Il a assisté à deux démos il y a peu et peut montrer deux exemples à partir des post it affichés :

 

 

 

 

 

 

Dans le premier cas, les responsables de points de vente saisissent le nombre de produits d’une promotion (fête des mères, par exemple) qu’ils doivent avoir en rayon. Le système calcule le total, le divise par la quantité contenue dans une palette et arrondit le chiffre. Par exemple, les tablettes sont conditionnées en lot de 60 ; si le total de ce que veulent les responsables est de 2750, il faudra commander 46 lots (2 750 / 60, soit 45,83, et arrondi au-dessus).

Au cours de la démo, l’une des acheteuses a justement fait ce test et le système a retourné une quantité de 4 583, ce qui les a interloqués, elle et les développeurs. Ils ont fait plusieurs tests ensemble, avec plusieurs types de produits et le résultat a toujours été le même : le calcul est faux car il n’arrondit pas les nombres, il se contente d’enlever la virgule…

• Zach estime que la user story est ko, ce que confirme Clem, puisque c’est un bug.

Dans le 2^e cas, le process prévoit que les personnes de l’entrepôt prennent en photo les produits retournés par les clients (par exemple parce qu’ils étaient abîmés une fois sortis de l’emballage) puis les transmettent au service après-vente SAV.

Au cours de la démo, l’un des participants découvre que la taille des photos est de 12 à 15 Mo et il est certain que ça ne pourra pas être opérationnel : trop lourdes, les photos vont avoir du mal à transiter dans les réseaux puis à être stockées.

• Zach estime que la user story est ko mais Clem n’est pas d’accord.

« On a le droit de faire des découvertes en cours de création de logiciel, dit-elle, c’est même le fondement de l’agilité. » Zach est bien d’accord mais il pense de son côté que ce n’est pas la notion connue / découverte que l’on mesure, c’est la notion ok/ko. Or jamais cette user story ne pourra être mise en production[1] telle quelle.

Clem est d’autant plus réticente à classer la user story dans la rubrique ko que « cela va faire croire que les dev ont mal travaillé alors que c’est le PO qui n’a pas été assez précis ».

Là, c’est Zach qui tombe des nues ! Dans le Lean, 1. on ne cherche jamais le coupable et 2. le résultat est toujours celui d’une équipe et non d’un individu. Pour lui, classer cette user story dans la rubrique ko ne fait que refléter la réalité, sans aucun jugement de valeur. D’ailleurs, si l’équipe l’accepte, elle va certainement changer quelque chose dans sa façon de travailler, ce qui sera une façon d’acquérir plus de compétences, ce qui sera une vraie valeur ajoutée pour eux, le client et l’entreprise. Il faut surtout classer cette user story dans ko !

Olivier, développeur qui écoutait d’une oreille distraite la conversation, intervient à ce moment-là : « je pense que c’est sur la panneau vision qu’on s’est planté, on aurait dû avoir une règle de type « atteindre tel niveau de performance du SI ». On a une définition qui ne parle que du produit, ça ne pousse pas à faire du joli code 😦 ».

Clem et Olivier filent vers le panneau vision pour voir ce qu’il en est.

Zach se dit que le Lean est donc bien soluble dans l’agile puisque quelques questions, ici comme ailleurs, permettent de changer de point de vue sur une situation. Mais aussi que Clem devrait s’approprier le principe du « not guilty », il lui vient un peu trop facilement l’explication que « c’est de la faute de … ».

[1] Deux sprints plus tard, d’ailleurs, suite à une petite erreur de calibrage du backlog l’équipe de développeurs aura un peu de temps devant elle et cette user story sortira du « bac à sable » pour être corrigée.