Second volet de mon feuilleton “en finir avec…”. Ma victime du jour est le backlog.
Je rapelle mon mot d’avertissement : J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.
C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !
De la roadmap au backlog
Lors du premier opus, nous avons vu les conséquences d’une roadmap gérée en tant que portefeuille de projet: plan, stock, frein au changement, etc… Mais ce qui est vrai à grande échelle peut-il l’être à une échelle moindre ? Car le backlog ressemble au portefeuille de projet à plus petite échelle.
Nous considérons naturellement la backlog, brique fondamentale de Scrum, comme un outil agile indispensable. Qui penserait à le remettre en cause ?
Pourtant, dévié de sa bonne utilisation il peut avoir des conséquences néfastes.
Pourtant il peut servir à déguiser les anciennes pratiques.
Pourtant les conséquences évoquées ci-dessus ne sont pas seulement des travers d’usages, elles prennent naissance dans la nature intrinsèque du backlog. C’est un peu abstrait pour l’instant. On va illustrer tout ça.
Je veux un backlog complet
Tout d’abord, c’est quoi un backlog ?
“The backlog represent everything that anyone interested in the product or process has thought is needed or would be a good idea in the product” (1)
En clair toutes les idées qui pourraient s’avérer bonnes sont aptes à y figurer. Cela soulève plusieurs points :
- Est-ce que seuls les éléments qui vont être effectivement réalisés doivent figurer dans le backlog ?
- Le backlog doit-il comprendre initialialement tout ce qui sera réalisé ?
- A-t-on le droit de changer le backlog, et surtout d’y ajouter des choses passée la “phase initiale” ? Vous aurez noté les guillemets.
Ce sont de fausses questions car Scrum y répond. Pourtant j’y reviens car c’est déjà une source de travers.
Le backlog contient des éléments qui vont être effectivement réalisés
Scrum répond “non” à cette question. Il s’agit juste d’une liste de fonctionalités candidates.
D’un autre côté, Scrum nous invite à lister ce que les différents acteurs ont en tête à un moment donné. A créer du stock, aurais-je envie de dire (vous voyez certainement où je veux en venir), mais je reviendrais plus tard sur ce point.
Là où le bât blesse, c’est que ce backlog en son état initial correspond à un périmètre produit. Et le client souhaite souvent avoir une estimation de ce périmètre. En soi, aucun mal à cela. Sauf que le périmètre se transforme souvent en engagement, surtout quand le client n’est pas réellement agile. A partir de ce point, je vous souhaite bonne chance dans le monde merveilleux du suivi budgétaire. Je ne prend même pas la peine d’évoquer l’antagonisme entre le mode “suivi budgétaire” et la gestion du changement …
Le backlog initial est complet
Là aussi Scrum répond clairement “non”.
Sauf que là aussi, si ce backlog sert d’estimation initiale du projet, il vaut mieux ne pas être trop à côté de la plaque. Certes on pourra toujours troquer une fonctionnalité contre une autre… Mais qu’en est-il si les premières étapes du projet mettent en lumière de nouvelles idées, des aspects du fonctionnel qui onté été occulté ? Ou simplement des oublis ? A l’extrême on devrait être en mesure de “pivoter” comme l’on dit en language Lean Startup et c’est un des aspects que l’approche agile en général et Scrum en particulier permettent.
Mais ce backlog que l’on construit à l’avance à souvent tendance à se transformer en carcan.
Notre client pas très agile va arguer “faites des ajustements, mais il faut avoir une idée claire de là où l’on va au départ”. Eh bien non, ce n’est pas obligé. C’est certainement un confort si l’on peut, mais Scrum nous donne la flexibilité qu’il faut le cas échéant. On a quand même donné le bâton pour nous faire batttre avec ce foutu backlog…
Le backlog ne peut pas être changé
Là aussi Scrum est clair : “oui on peut le changer”. C’est même l’essence du processus de tirer profit du feedback pour le faire évoluer !
Oui, mais …
On a constitué cette (longue) liste, un processus coûteux en temps et en énergie. Cela va nous freiner dans une certaine mesure pour opérer des changements qui seront eux-même coûteux dans leur introduction mais aussi dans la remise en cause des items existants !
Bien sûr ce frein sera encore plus important dans le cas d’un changement radical. Il pourra même se transformer en blocage : “remettre en cause ? Alors que l’on a là une liste de fonctionnalités bien établies ?”
Je veux un backlog détaillé
Le backlog “complet” ne suffit même pas toujours pour démarrer un projet, surtout si l’on souhaite utiliser ce backlog pour effectuer une estimation comme je l’ai indiqué plus haut. Il nous faut alors savoir ce qu’il y a derrière chaque item afin d’avoir une idée valable de la complexité de celle-ci ! Vous l’avez probablement remarqué : on a déjà quitté Scrum depuis un certain temps. Mais qu’importe, on parle de backlog ! Tout va bien !
Cette affaire de backlog détaillé m’inspire trois choses.
Détailler
Détailler ou au moins rentrer dans le coeur de chaque fonctionnalité c’est échafauder le système alors que l’on a rien commencé, que rien ne peut nous aider à soutenir notre reflexion ou etayer nos hypothèses. J’ai fait référence au “lean startup” plus haut. Eux nous suggèrent de ne pas oublier que justement ce que nous appelons “expression des besoins” sont en fait des hypothèses. Personnellement, cela me rapelle une citation du “Mythical Man-Month”, elle s’adresse au developpeur mais pourrait aussi concerner celui qui construit le backlog : “Le programmeur, comme le poète, manie des abstractions voisines de la pensée pure. Il construit des cathédrales dans les airs, à partir de l’air lui-même, par le pouvoir de son imagination” (2). Construire des cathédrales dans les airs avec de l’air, c’est pas facile…
Faire mûrir
Ma seconde réflexion va vers ce que l’on apelle parfois le “mûrissement du backlog”. Vous avez peut-être déjà entendu cette expression : “il faut que ça mûrisse” ? Voilà qui nous invite à une petite pause bucolique.
Il y a bien sûr un concept derrière ça : c’est que quand une idée est seulement une ébauche, le simple passage du temps va permettre de rafiner l’idée qui tombera alors toute seule tel un fruit mûr ! C’est pas beau ? J’ai bien entendu de gros doutes sur ce processus spontané. Mes seules certitudes à ce propos sont:
- Si on ne fait rien, il ne se passe rien.
- La seule conséquence inéluctable du passage du temps, c’est la génération d’un délais.
Il existe des techniques, actives celles-ci, pour développer des idées à l’état d’ébauches :
- Le brainstorming
- L’expérimentation, que ce soit sur la base d’un prototype ou non.
On retrouve ces techniques dans les processus de développement orientées vers l’innovations comme le Design Thinking. Mais pour ça, il faut lâcher le backlog 5 minutes …
Backlog a.k.a. “cahier des charges”
Finalement, ce backlog complet et détaillé portait autrefois un nom: le cahier des charges. Par un effet pervers, nous avons reconstitué ici sous une forme certes différente, ce que nous voulions abandonner dans les anciennes approches. Il ne reste plus qu’à en confier la confection à une MOA (auquel on aura donné un autre nom) et on aura fait le tour !
Bien sûr Scrum ne dit pas du tout d’en arriver là. Mais il est tellement facile de glisser progressivement pour en revenir à ce que l’on faisait avant. Tout en se donnant bonne conscience, souvent même de bonne foi, car on apelle cela “backlog”.
L’effet de bord de ce backlog “complet et détaillé” est le délai que cela nécessaire pour en arriver là.
Une phase d’analyse ?
Scrum a poussé le concept d’itération zéro, pour amorcer un projet. Mais pour débuter avec un backlog complet et détaillé, cela ne suffit pas. Aussi voit-on le product owner ou l’équipe PO commencer un travail qui n’est pas seulement exploratoire mais un travail de fond en avance de phase afin que l’équipe de développement puisse débuter son oeuvre avec une matière première solide.
C’est la négation même de l’approche agile dont le fondement est le cycle court et le feedback. C’est en fait la réincarnation de la phase d’analyse !
L’autre conséquence de cette phase d’analyse, outre le délai, est la création d’un stock. J’en ai parlé plus haut et j’ai l’air d’insister, mais en terme “lean”, le stock est assimilé à du gâchis: c’est du travail dont on ne sait s’il va être utilisé et demande une charge d’entretien : relecture, réévaluation régulerière, etc…
Ma liberté de penser !
Vous finissez un sprint et allez commencer le suivant. Il est temps de choisir les prochains items de backlog à développer.
Qu’est-ce qui importe vraiment ?
Sont-ce les prochains items de backlog selon la priorité qui leur a été attribuée ? Pas vraiment, ou du moins pas comme ça.
Ce qui importe vraiment c’est ce que nous avons appris à la lumière du sprint écoulé : approfondir des fonctionnalités sur lesquelles nous avons travaillé, se diriger vers une direction complètement différente et parfois oui, prendre des items du backlog tel que nous l’avions dressé.
Mais par rapport à ce focus sur le feedback et l’apprentissage le backlog agit régulièrement comme un frein ou plutôt comme un gros élastic que nous aurions dans le dos, qui nous ramène inoxorablement vers la voie que nous avions tracé au départ.
Qu’est-ce qui empêche d’utiliser le backlog pour prendre en compte l’apprentissage et le feedback ? Absolument rien. En fait, il est fait pour ça. Comment l’utilisons-nous dans les faits ? Je vous laisse le soin d’y répondre.
Dans un projet agile, ce qui s’interpose entre vous et le feedback est un problème. Ne laissez pas le backlog devenir un problème, ne le laissez pas entraver votre liberté de penser. Un backlog n’est pas un cahier des charges.
A quoi ça sert vraiment ?
J’ai l’air de dire jusqu’à présent que le backlog est l’oeuvre du malin. Donc est-ce utile ? Voilà un point sur lequel nous allons pouvoir répondre aisément.
S’assurer que l’on fait les choses les plus importantes
Imaginez que vous avez un backlog de 50 items alors que vous n’allez pouvoir en traiter que 3 dans la prochaine itération. A quoi servent donc les 47 autres ? Eh bien essentiellement à s’assurer que l’un des 3 items importants ne se trouve pas parmi ces 47 autres !
Donner de la perspective
Certes, quand on fait un projet hautement innovant, voir de la R&D, construire un backlog a peu ou pas de sens. On est d’ailleurs là en dehors de la zone de Scrum. Mais lorsque cela est possible, en fait assez souvent, avoir du contexte donc une idée de ce qui est considéré comme le périmètre du projet à un instant donné, aide à la réflexion et est plus stimulant pour l’équipe.
Quelle(s) alternative(s) ?
Elles sont essentiellement déterminées (ou limitées) par notre créativité. J’en propose 3. Et je vais tricher un peu.
Arrêtez ça
Ce n’est pas une alternative mais un conseil : ne faites pas le backlog “complet et détaillé”. C’est mal. Arrêtez de faire ça, simplement.
Pas de backlog
Si on n’a plus de backlog, on ne fit plus du Scrum, n’est-ce pas ? Mais certains projets à forte composante exploratoire ne se prêtent pas à cela. Nous sommes alors dans le cas où la backlog va générer plus d’entrave que d’aide. Il est peut-être temps de sortir de Scrum. D’autres approches agiles s’accomodent de l’absence de backlog :
- Extreme Programming parle juste de User Stories (on s’occupera de leur cas dans un épisode futur) à traiter et ne fige même pas celles-ci pour l’itération en cours. Toutefois XP n’est pas hostile à la présence d’un stock de stories.
- Kanban n’a pas de backlog, mais des files d’attente. Et celles-ci ont des capacité déterminées et limitées. On a bien du stock dans une certaine mesure, mais celui-ci est limité et contrôlé.
- Lean Startup ne parle ni de backlog ni de stock de features. En fait, cette approche s’oppose intrinsèquement à ces notions car le focus est ici uniquement sur l’apprentissage scientifique qui est fondamentalement antagoniste avec la présence d’un “stock d’hypothèses”.
Le backlog à géométrie variable
C’est mon préféré. C’est aussi un compromis entre les avantages (donner de la perspective, identifier les fonctionnalités candidates) et les inconvénients (créer du stock, générer de la charge et du délais). Fort heureusement, c’est aussi ce qui est préconisé par de nombreux auteurs, dont Claude Aubry (3).
Dans cette approche on limite le découpage fin des stories et leur détail qu’aux fonctionnalités classées les plus prioritaires. Je ne vais pas entrer dans le détail ici, ce n’est pas le but de ce post. Vous en trouverez la description ailleurs.
Alors le backlog, c’est mal ?
J’utilise des backlogs et j’aime bien ça. Je serais donc bien en peine de dire que c’est mal.
Mais ce n’est pas non plus de la magie. Le backlog est un outil. Mais aussi bénéfique soit-il un outil porte en lui-même les germes de ses propres travers. Je me limiterais à deux conclusions:
- Ne dénaturez pas le backlog et la façon dont il doit être utilisé.
- Soyez conscients des inconvénients. Ils joueront contre vous si vous les ignorez.
Références
(1) Agile Software Development with Scrum, Ken Schwaber & Mike Beedle, Prentice Hall 2002 ; p. 33
(2) The Mythical Man-Month anniversary eat, Frederik Brooks, Addison Wesley 1995
(3) Scrum Le guide pratique de la méthode agile la plus populaire 2nd édition ; Claude Aubry ; Dunod 2011 ; p. 67
Software Freethinker 
