Etymologie d'un terme Agile: le backlog

Si vous êtes agiliste, vous connaissez le mot "backlog", mais vous êtes-vous interrogé sur ses origines et ses connotations?



Le terme "backlog" est attesté dans la langue anglaise à partir de 1684: c'est "la bûche du fond", pièce maîtresse d'une flambée bien préparée; le petit bois démarre le feu mais c'est cette bûche plus grosse qui fournit une réserve de chaleur. Les cheminées cédant la place à des chauffages plus modernes, le mot perd vers la fin 19è son sens figuratif pour devenir métaphorique: c'est une réserve, une accumulation.

Le terme acquiert dans l'industrie manufacturière un sens plus nuancé au 20è; vers 1930-1940 plus précisément, le diagramme fourni par Google n-grams est éloquent quant à la popularité soudaine de ce mot. Il désigne un "empilement" de choses (souvent des commandes de produits industriels) derrière ce qu'on appelerait maintenant un goulot d'étranglement. Positif lorsqu'il évoque la vigueur de l'économie, il devient plus tard négatif lorsqu'il dénote un retard de traitement.

C'est bien cette connotation moins franchement positive qui est à mon sens évoquée par le backlog de Scrum, et que ne rendent pas certaines traductions alternatives: "carnet de produit" (par analogie au carnet de commandes) ou même "exigences".

Dès les premiers articles sur Scrum, vers 1995, ce terme est associé à cette démarche de gestion de projets, en net décalage avec le discours dominant qui parle plus volontiers de "spécifications", "d'exigences" (requirements). Le terme français de "cahier des charges" capture très bien les connotations véhiculées par "requirements document" - on ne conçoit pas l'information entrante, "l'input" d'un projet logiciel autrement que comme un document. Un célèbre article de Parnas et Clements, "A rational design process" en fait même un critère de rationalité du processus, excusez du peu: qui ne produit pas de document est donc irrationnel.

L'usage que font les concepteurs de Scrum du terme "backlog" semble donc idiosyncratique, propre à leur approche individuelle des choses. En examinant les archives du site ControlChaos.com préservées par The Internet Archive, on découvre des traces des origines de Scrum, traces que son créateur n'a hélas pas choisi de préserver (on peut même se demander s'il n'a pas souhaité, délibérément, les effacer). On découvre ainsi que le premier véhicule de Scrum est l'outil MATE (Methods and Tool Expert), un environnement logiciel d'aide au développement vendu par ADM, l'entreprise de Ken Schwaber. La terminologie de Scrum semble être celle utilisée dans le module "gestion de produit" de l'outil MATE. (D'autres termes mentionnés dans ces premiers écrits sur Scrum, comme "packet" qui désigne un composant logiciel, ont depuis disparu.)

Le sens d'origine, donné dans l'article de 1995, est très éclairant: "une liste de tout ce qui n'est pas adéquat dans la version actuelle".

En d'autres termes, à l'origine Scrum ne fait pas de distinction entre la création d'un produit nouveau d'une part, et d'autre part la maintenance d'un produit existant, déjà livré entre les mains d'utilisateurs. On considère la création d'un nouveau produit comme un cas particulier de la maintenance! C'est un des aspects les plus importants de la rupture que marque ce qu'on appellera plus tard l'approche Agile.

En caractérisant le backlog comme une liste de ce qui rend l'actuel inadéquat, Scrum donne une vision nettement moins rationalisante que ce qui s'attache au terme "exigences": on peut envisager que les "exigences" du produit soient un ensemble platoniquement parfait, dont on ne dévierait que par erreur; alors qu'un "backlog" est implicitement le résultat ET le lieu d'une négotiation.

Le sens actuel donné par le Scrum Guide est donc nettement moins intéressant: "la liste de tout ce qui est nécessaire pour réaliser le produit".

Je regrette que la version actuelle du Scrum Guide tende à effacer ces connotations d'origine et adopte une version plus proche de ce qu'évoque le terme "exigences"; également qu'il se soit gaspillé un temps considérable à traiter de la subtile différence entre "ordonné" et "priorisé", coupage de cheveux en 256èmes alors que le véritable débat est celui qui porte sur ces idées de négotiation, et sur l'incertitude (voire l'irrationalité) inhérente à la définition des exigences.

La nécessité pour un discours Agile tel que Scrum à soigner son acceptabilité, son aspect "politiquement correct", conduit ses auteurs à tenter d'effacer les traces de sa construction historique. A mon sens, c'est une erreur: l'étymologie des mots, l'origine des idées, sont comme les miettes de pain du Petit Poucet... des repères indispensables mais fragiles. Ces miettes doivent être préservées, sans quoi nous risquons ne plus pouvoir comprendre comment nous en sommes arrivés là où nous sommes, et reproduire des erreurs déjà commises - celles-là mêmes contre lesquelles l'approche Agile s'est mobilisée au départ!