Un but plus qu'un backlog

Les backlogs sont une bonne idée. Les backlogs facilitent la transition entre l’ancien monde des « exigences en amont » et ce nouveau monde plus dynamique qu’est l’agile. Les backlogs offrent aux équipes agiles une couche de compatibilité qui fait office de transition avec la gouvernance et la gestion plus traditionnelle de projet. Les backlogs vous permettent même de prendre un pari sur une date de fin possible !

Les backlogs vous permettent également répartir le travail entre des périodes calmes et des périodes chargées. Les backlogs vous offrent un lieu pour y mettre toutes les bonnes idées que vous n’êtes pas en mesure de faire tout de suite. De cette manière, les parties prenantes peuvent voir que leurs requêtes ne sont pas oubliées et n’ont donc pas besoin de crier pour l’avoir aujourd’hui.

Oui, les backlogs sont quelque chose de bien. Je les ai vu bien fonctionner correctement de mes propres yeux et j’ai enseigné à plusieurs équipes comment les utiliser de manière efficace.

Mais - vous saviez bien qu’un mais allait venir, n’est-ce pas ? - mais …

Les backlogs présentent des problèmes, bien trop d’équipes ploient sous la tyrannie du backlog, elles deviennent des esclaves du backlog et font ce que nous pourrions dénommer du DPBL - autrement dit du Développement Piloté par le Back Log.

(Pour être tout à fait clair, lorsque je dis « backlog » je pense tout d’abord au backlog de produit - c’est-à-dire à la longue liste de choses que l’équipe fait ou pourrait faire dans le futur. Le backlog de sprint est tout à fait autre chose (il s’agit du backlog de l’itération). Le backlog de sprint est une liste de choses plus courtes que l’équipe a pour objectif de réaliser au cours de l’itération en cours. J’utilise ici la terminologie Scrum mais l’idée est plutôt d’ordre « générique agile » et je pense au-delà de Scrum. Un certain nombre d’implémentations Kanban utilise une sorte de backlog donc même si Kanban est moins assujetti à ce problème, il n’est pas épargné.

1) Idée fausse à propos la masse de travail à faire

Il existe généralement une hypothèse selon laquelle le backlog représente la totalité du travail à faire — une impression renforcée par les toutes premières implémentations de Scrum. À court terme cela conduit les équipes agiles à être considérer comme étant inflexibles en privilégiant un processus de priorisation plutôt que les besoins, aucun nouveau besoin n’étant admis dans le backlog.

Dans certains cas, les équipes luttent pour, ne serait-ce, que pour commencer à travailler car les activités de recensement de l’ensemble des exigences et d’analyse sont exigées en amont avant toute création de backlog. Dans le pire des cas, ce travail, fait lui-même l’objet d’estimation et de date de fin prévisionnelle avant que la toute première ligne de code ne soit écrite ou que les développeurs ne soient recrutés.

À long terme, il est tout simplement irréaliste de prendre comme postulat qu’un backlog doit demeurer figé. Même en ajoutant davantage d’analyses ou des analyses plus poussées, il est impossible de prévoir les futures demandes. L’adage agile « c’est en faisant le travail que nous le comprenons » fonctionne dans les deux sens : les développeurs comprennent ce qu’ils ont à réaliser (en le faisant - NdT) et les clients/parties prenantes/analystes comprennent ce qu’ils veulent (en le voyant - NdT).

De nouveaux éléments à faire apparaîtront donc après que vous ayez commencé, tout système n’ayant pas intégré cette vérité échouera d’une manière ou d’une autre.

2) C’est bien plus gros que vous ne le pensiez

Non seulement le backlog grossi avec des éléments complètement nouveaux, mais aussi avec des éléments qui changent - et qui grossissent. Il existe plusieurs raisons expliquant cela : de nouvelles opportunités apparaissent, des choses auparavant floues deviennent claires, certaines demandes exigent plus de travail que prévu et ainsi de suite.

Les humains sont très mauvais pour faire des estimations (vo) et plus particulièrement en ce qui concerne le futur, et, il s’avère qu’ils sont aussi très mauvais pour estimer le temps écoulé dans le passé. Si vous voulez des prévisions précises, vous devez investir là-dessus, vous devez faire des changements structurels et vous devez utiliser des statistiques.

Toutefois à cause de l’idée fausse quant à la masse de travail, de la croyance que les humains peuvent faire des estimations, des projections médiocres quant aux dates de fin prévisionnelles — eh bien lorsque ces différentes promesses ne sont pas tenues (parce que tout cela était pipeau depuis le début), tout le monde devient contrarié.

3) L’idée fausse à propos de « Terminé »

Les backlogs sont souvent accompagnés de graphiques de suivi d’avancement sous la forme de burn-down, avec comme postulat qu’il existe une fin ; et que cette fin arrive lorsque tout est « terminé ». L’équipe aura terminé lorsque le backlog sera vide. Ce postulat fait partie du développement piloté par le back log, de la gouvernance et de la gestion traditionnelle de projet.

J’ai argumenté en long, et en large qu’un logiciel n’est jamais terminé (vo). Je veux bien accepter que je pourrais avoir tort, toutefois à l’âge du numérique, lorsque le numérique (c’est à dire le logiciel) fait tourner le business alors vos produits (numériques) ne seront terminés que lorsque votre business sera terminé. La technologie est le business, et le business est la technologie. Si vous arrêtez de faire grossir le backlog, vous arrêtez de faire grossir votre technologie et vous tuez le business.

4) Le backlog un trou sans fin

Mettez toutes ces raisons ensemble et le backlog devient un trou sans fin. Dans les premiers jours de l’agile, lorsque je gérais des équipes, le backlog trônait souvent sur mon bureau, écrit sur des fiches cartonnées, tenu par des élastiques. Je pouvais voir la taille du backlog en un clin d’œil.

Aujourd’hui tout le monde utilise un système de suivi numérique. Non seulement cela autorise un nombre infini d’items, mais cela nous enlève aussi la notion de perspective. Pour paraphraser le Camarade Staline : « 2 items exceptionnels dans un backlog est une tragédie, 200 est une statistique ».

5) La stratégie obscure des backlogs & le but

Avec autant d’items dans le backlog, il est facile de se perdre - c’est l’arbre qui cache la forêt. Les discussions pour savoir ce qui va être fait la prochaine fois commencent à ressembler à qui devrait avoir la place dans le canot de sauvetage lors du naufrage d’un navire, ajouter à cela au niveau des demandes « quand cela sera t’il terminé » (plus l’explication en quoi la date a changé) et « la vision globale » est perdue.

Avec le développement piloté par le back log le sens de la finalité du but et des objectifs stratégiques sont perdus car les équipes luttent avec les demandes quotidiennes de faire seulement leur taf.

6) Un product owner impuissant (c’est-à-dire un administrateur de backlog)

La tyrannie du backlog semble encore pire lorsque les product owners manquent d’une réelle légitimité et de compétences. Ils sont rien de plus que des administrateurs de backlog (vo). Ils passent la plupart de la semaine à ajouter des demandes au backlog, puis à passer quelques rares items bien choisis aux développeurs dans les réunions de planification. Un cercle vicieux se met en place, le product owner ne peut pas gagner donc les gens lui font moins confiance, sa légitimité décline, et le backlog part en vrille.

Peu d’organisations donnent aux product owners le pouvoir dont ils ont besoin pour avoir prise sur la situation. En effet, beaucoup de product owners sont issus des équipes de développement ou du support et sont envoyés sur le champ de bataille en guise de promotion mais ils leur manquent les compétences requises. (Cf. Le problème avec les Product Owners (vo).)

Une solution ?

Depuis des années, je suggère que les équipes devraient jeter leurs backlogs - ne vous inquiétez pas, vous n’allez pas oublier les choses importantes. Mais alors, comment allez-vous savoir ce que vous devez faire ?

Prenez un peu de recul, commencez avec votre but, votre mission, la raison pour laquelle votre équipe, votre entreprise, votre organisation existe. Que devriez-vous faire ? Comment pouvez-vous atteindre ce but et servir vos clients ?

C’est là que je vois un rôle pour les OKRs¹ et les jobs to be done². Ces deux techniques - prises ensemble ou séparément - peuvent être utilisées comme des générateurs de story. À chaque fois que vous devez faire davantage de travail, davantage de stories, retournez à vos OKRs et demandez-vous « qu’est-ce que nous pouvons faire pour avancer vers nos objectifs ? ».

Lorsque j’ai écris Succeeding with OKRs in Agile (livre en vo), je suis devenu de plus en plus convaincu qu’il s’agit du chemin à prendre. J’ai résumé ceci sous l’expression « un but plus qu’un backlog ».

Notes après publication : Jari Mäkelä m’a fait la suggestion via Twitter d’appeler cela : le développement piloté par le but ou PDD (Purpose Driven Development).

Étape 1 : Clarifier votre but — quel est votre raison d’être ultime d’exister ?
Étape 2 : Clarifier comment votre stratégie existante vous aide à atteindre ce but, et si vous n’avez pas de stratégie, créez-en une.

Répéter annuellement les étapes 1 & 2.

Étape 3 : Penser avec une perspective élargie, mettre en place vos OKRs en équipe afin que vous puissiez continuer à avancer vers votre but en suivant votre stratégie.
Étape 4 : Passer les 12 semaines suivantes à atteindre ces OKRs.

Répéter trimestriellement les étapes 3 & 4.

Étape 5 : Lors de chaque réunion de planification, prendre note de ce tout ce que vous avez fait et de votre avancement par rapport aux OKRs.
Étape 6 : Demander « qu’est-ce que nous devons faire faire ensuite pour atteindre les OKRs»

Répéter toutes les deux semaines les étapes 5 & 6.

Et si vous êtes plutôt Kanban alors garder les étapes 1, 2, 3 et 4, ajuster comme bon vous semble les étapes 5 et 6.

Après avoir fini, terminé et publié Succeeding with OKRs, je souhaiterais avoir été plus clair dans le livre. Les idées sont là mais avec le temps elles sont devenues beaucoup plus claires … peut-être bien que j’ai besoin de faire d’un autre livre.

Auteur : Allan Kelly
Source : Purpose over Backlog
Date de parution originale : 15 Février 2021

Traducteur : Nicolas Mereaux
Date de traduction : 16/03/2021

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.