Pourquoi les backlogs sont inefficaces ?

(Image d’illustration : Un backlog à l’abandon dans sa version zippée. Photo de Alfonso Navarro sur Unsplash)

💡 A noter :
Cet billet est issu d’une de mes récentes lectures et en est la libre traduction / interprétation / remaniement. Si le coeur vous en dit, l’article original est disponible sur le site de Lucas F. Costa

Les backlogs ne rétrécissent jamais tout simplement parce que la liste des choses qu’on pourrait hypothétiquement faire (notez l’usage du conditionnel) ne diminue jamais, elle non plus. Et c’est grosso-modo ce que sont les backlogs : une liste de choses pas si importantes que ça qu’on pourrait éventuellement faire un jour.

Mais pas aujourd’hui.

Et pourquoi donc, à votre avis ?

Tout simplement parce que les tâches importantes n’atterrissent jamais dans le backlog : on les créé, on travaille dessus, et on les pousse en prod (un vendredi, si on est courageux 🤓). Point final.

Demandez à votre Product Manager préféré à quand remonte la dernière fois qu’un ticket a été exhumé du backlog : une forte probabilité que ça réponse soit “Jamais” (mais laissons une marge de manoeuvre, comme toutes les règles, une exception peut la confirmer. La légende raconte qu’une fois, dans des temps immémoriaux, un ticket a pu ressortir du backlog, accompagné de sa couche de poussière séculaire)

Dans la pratique, on se doit de savoir quelle tâche est la plus importante pour le business. Et c’est cette tâche qui va rafler la mise et prendre le pas sur les autres. Et si par malheur vous ne savez pas quelle tâche/fonctionnalité est la plus prioritaire, clairement, un backlog n’aidera pas à trier et vous sortir de ce problème.

Pourquoi les backlogs existent ?

La réponse va peut-être vous paraître brutale, mais pourtant la réalité est là : le backlog est la solution de facilité pour éviter les conflits.

Lorsque quelqu’un demande au Produit d’ajouter telle ou telle nouvelle fonctionnalité “qui va disrupter l’internet” (insérer ici une feature liée au metavers, aux cryptomonnaies ou encore aux NFT 😂) , il est clairement plus facile de répondre : “ok, ajoutons cette tâche au backlog” que de passer 1 heure à argumenter sur “non, on ne le fera pas, parce que c’est une mauvaise idée”.

A partir du moment où le demandeur (appelons-le “le Client Interne”) obtient l’accusé réception de sa demande “ajoutons-le au backlog”, la magie opère. La responsabilité a été transmise, le demandeur a fait son travail, la patate chaude est dans le camp de quelqu’un d’autre (mais reste à déterminer qui)

Et si par malheur, le Client Interne vient à demander des comptes sur sa demande un mois plus tard ?

Double combo de magie : il ne viendra pas demander où en est sa tâche. La responsabilité ayant changé de camp, cela reviendrait à faire l’inspecteur des travaux finis et jouer d’un certain aplomb hiérarchique envers le Produit. Et personne n’a envie de faire ça.

Pire encore : il est largement envisageable que d’ici un mois, le Client Interne ait oublié sa requête (aka HTTP 408 : Request Timeout). Et dans le cas où ça se produirait quand même : répondre “c’est dans le backlog” est la clé.

Analogie pour les parents qui peuvent me lire : que celui qui n’a jamais répondu “on verra plus tard” à sa progéniture pour éviter le débat sans fin lève la main 😂

Pourquoi les backlogs sont néfastes pour votre organisation ?

Prenez l’exemple d’un constructeur automobile. S’il produit des véhicules plus vite qu’il ne peut les vendre (au delà d’un stock tampon, évidemment), il ne produit pas de la valeur, il produit des déchets.

De la même manière, un Product Manager qui produit nettement plus de tickets que ne peut éponger une équipe technique sur une base régulière produit tout simplement des déchets (numériques, mais tout de même).

Mais étant donné que c’est du déchet numérique (non, vous ne me ferez pas dire digital), le résultat est beaucoup plus insidieux : les tâches/tickets végètent ad vitam dans le backlog, et personne ne les voit, ni personne ne les regarde.

(Je suis un ticket du Backlog, traite moi 😿)

Mais il en va de même pour toute équipe devant gérer une roadmap et un planning ! Il n’est pas rare non plus de voir une demande tech envers une équipe tech :

• “Et si on installait tel composant / tel lib. parce que ça a l’air cool ?”.
• “Ok, mettons ça dans le backlog”

C’est la réponse la plus probable lorsque ce n’est pas une killer feature ou que la tâche semble plus que conséquente en l’état (aka : non dégrossie)

Et plus ce “never ending story backlog” s’allonge, moins nombreux seront les candidats à son nettoyage. Félicitations : vous avez inventé une belle usine (à gaz). Et plus le temps passera, moins les tickets en état de décomposition seront même en mesure d’être traités : pertinence de la tâche, inexactitude des infos, contexte ayant changé entre temps, etc.

Et comme dans tout bon système, cette infobésité ne finira que par rajouter de l’inertie à votre organisation. Il est clairement plus difficile de naviguer dans un backlog conséquent et trier les bons tickets, savoir s’ils sont encore d’actualité, etc que de traiter un sujet qui sera passé par la “fast lane” traitée immédiatement et aura un contexte actuel et précis.

Comparaison backlog ouvert vs backlog filtré

Tout bon Product Manager vous le dira : la Tech prend du temps. Que ce soit en conception, en développement, qu’en refinement des tâches, un ticket qui entre dans le backlog sera rarement traité en 5 minutes. Ou alors, il n’aurait limite même pas dû y rentrer.

C’est pour cela qu’il est important de préserver ce maillon de la chaîne (je ne dis pas ça car je suis un tech à la base 😇) qui, bien qu’important, est aussi rapidement un goulot d’étranglement sur la chaîne de production.

Comment le préserver ? En mettant un bon vieux filtre en amont ! (Et non, aligner 2x le nombre de devs n’aidera pas à traiter plus de ticket, arrêtons avec cette légende urbaine)

En filtrant ce qui rentre dans le backlog, le gain de temps est double.

• Gain direct : vous arrêtez d’alimenter le backlog avec des tâches qui ne verront peut être jamais le jour en prod. Vous réduisez ainsi le bruit et la surcharge liée à la maintenance du backlog.
• Gain indirect : vous gagnez du temps. Il est moins coûteux en temps de refouler un ticket en devenir dès son apparition. A ce moment-là, les conversations et les analyses autour de la tâche sont encore de haut niveau. Le go / no-go se limite alors à la pertinence / faisabilité à la grosse maille et l’alignement avec les objectifs business.

Et par conséquent, il sera encore moins coûteux de traiter le ticket par l’équipe Tech en phase de refinement. Dans l’idéal, comme sur un schéma classique d’offre et de demande, il est plus intéressant de faire correspondre le volume en entrée et le volume en sortie que de créer un déséquilibre.

Comme dirait Gandalf : You shall not pass!

Ainsi, il est donc préférable de refuser en entrée si l’on atteint pas les critères des pertinences / alignement business, plutôt que de rentrer une tâche “au cas où”. Pour aider à cette prise de décision et l’importance de la tâche, je vous laisse jeter un oeil à la matrice d’Eisenhower dont j’ai parlé il y a quelques temps de cela.

Si les backlogs sont inefficaces, par quoi les remplacer ?

C’est tout simple : par rien.

Concrètement, ne faites pas de backlog qui s’étale au delà des quelques semaines à venir (et encore, relativement faible, le nombre de semaines)

S’il vous faut plus de 2-3 semaines pour sortir en prod tout ce qui traîne dans le backlog, c’est que vous empilez de la tâche, et que vous planifiez trop loin, trop gros.

Au delà de ce délai arbitraire, c’est une roadmap que vous êtes en train de faire. Pas besoin de rentrer dans le même niveau de détail. Et même, cette roadmap devrait être re-challengée entre les équipes, et ce de manière régulière, afin de trier le bon grain de l’ivraie, et déterminer les véritables priorités. L’idée étant au final de trouver le terrain d’entente entre Tech et Produit et être parfaitement alignés vers les objectifs stratégiques de la société.

Reste cependant le cas particulier des bugs. Ok pour les ajouter dans un backlog ou une sorte de todo-list si vous n’êtes pas en capacité de le traiter immédiatement, ou que sa priorité n’exige pas qu’il soit taclé tout de suite. Mais là encore, appliquez des règles d’hygiène strictes pour votre backlog : si c’est plus vieux que quelques semaines, et que ça n’a même pas été abordé, supprimez le bug. Une stratégie à la Marie Kondo en quelques sortes :

Si ce bug est trop vieux, trash-le !

Et il est donc de même pour les tâches accumulées dans le backlog. Que vous utilisiez Jira (je compatis 🤗) ou un autre système de gestion de tickets, configurez-le pour qu’à minima il mette en avant ces tickets qui pourrissent paisiblement au fond de votre backlog. Vous pourrez alors faire votre ménage de printemps, sans pour autant attendre le prochain printemps !