Soyez vraiment agile : Supprimez votre Backlog !

La nouveauté n’émergera qu’en se débarrassant de vos vilaines habitudes.

Avant de commencer à vous expliquer pourquoi la suppression de votre Product Backlog est la clé d’une réelle agilité, permettez-moi de vous poser quelques questions :

• Combien d’items avez-vous dans votre product backlog ?
• Quel âge a le plus ancien élément de votre product backlog  ?
• À quelle fréquence affinez-vous quelque chose avec votre Scrum team qui ne sera jamais intégré dans un sprint mais qui a toujours une place sûre dans votre product backlog ?

Prenez un peu de temps pour réfléchir et répondre à ces questions.

Soyez le plus honnête possible. Lorsque je me suis soumis à l’exercice, j’ai obtenu ceci :

• 450 éléments au sein de mon backlog.
• Le plus ancien élément avait 3 ans.
• Au moins 100 éléments ont été affinés, estimés et jamais réalisés.

Quand je réfléchissais à cette situation, je n’étais sûr que d’une chose :

Je n’avais alors pas encore compris ce que signifie “être agile”

Maintenant, permettez-moi de partager avec vous pourquoi la suppression de votre Product Backlog peut-être votre salutaire dans votre chemin vers l’agilité :

Un “trop grand” product backlog est un ennemi de l’agilité

Savez-vous ce que signifie être Agile ?

De nos jours, tout le monde en a une interprétation différente. Je dois partager ce que je comprends de l’agilité pour  le reste de cet article :

fournir de la valeur aux utilisateurs finaux en rapprochant ceux qui ont un besoin de ceux qui sont capable de le mettre en œuvre.

Le défi est que la valeur est abstraite et souvent interprétée différemment. Pour moi, apporter de la valeur signifie aider les gens à relever leurs défis tout en générant quelque chose en retour pour l’entreprise.

J’aime beaucoup cette définition du terme de valeur : Elle provient d’un article de Christiaan Verwijs. Il résume la valeur des éléments (ou items) d’un produit en une somme de cinq valeurs :

• La valeur commerciale (cet élément fait-il économiser de l’argent ? En fait-il gagner ?);
• La valeur de l’efficience (cet élément permet-il d’améliorer la qualité du produit ? De faire diminuer le Time To Market ?);
• La valeur future (cet élément constitue t-il un investissement profitable dans le futur ?);
• La valeur marché (combien de clients potentiels sont intéressés par cet élément ?);
• La valeur client (cet élément satisfait-il le client ?).

Maintenant que cette définition est posée, il faut aussi prendre conscience que :

Être à l’aise avec l’inconnu est la clé pour être agile.

Ainsi, je pense simplement qu’être agile se résume à embrasser pleinement l’apprentissage. Nous devrions simplement créer des hypothèses, les valider, apprendre quelque chose, inspecter et nous adapter. Cela ne semble pas compliqué, mais d’une manière ou d’une autre, j’ai observé que de nombreuses personnes le rendaient incroyablement complexe, y compris moi.

Ainsi, de ma vision des choses, un Product Backlog étendu est précisément à l’opposé de l’agilité. Vous pouvez dire que vous êtes Agile, pourtant vous :

• Laissez les éléments moisir dans votre Product Backlog pendant des années.
• N’osez pas supprimer un élément du backlog produit car cela énerverait une partie prenante.
• Faites perdre du temps à l’équipe et aux développeurs en affinant quelque chose qui ne sera pas réalisé.

A mon sens, un backlog étendu est un backlog qui contient des demandes avec plus de 3 sprints d’avance.

Si un Product Backlog contient plus d’éléments que l’équipe Scrum ne peut en prendre en quelques Sprints, c’est un symptôme que la planification est plus importante que l’apprentissage.

Pour apporter de la valeur, vous devez conserver un Product Backlog léger. Ne laissez pas l’illusion d’un plan vous tromper.

Soyez audacieux ! Supprimez votre Backlog

Certaines choses m’effraient plus qu’un trop long backlog. La raison est simple; Je perçois cela comme une approche politique. A l’approche des élections 2022, et pour se prêter au jeu, comparons votre Product Backlog avec une campagne politique :

• Un candidat promet le monde aux électeurs potentiels ; tout est possible pendant la campagne.
• Une fois élu, le candidat ne tiendra pas plus de la moitié de ses promesses et devra trouver des excuses pour calmer les électeurs déçus.
• Les promesses resteront lettre morte jusqu’à la fin du mandat, et les électeurs se sentiront dupés.

Voyez-vous quelques similitudes entre cette vision de la vie politique et un Product Backlog étendu ? C’est une liste massive de vastes promesses qui ne seront JAMAIS respectées. C’est une façon non durable de gérer votre Product Backlog.

Ne trompez pas vos parties prenantes en mettant leurs souhaits dans le Product Backlog.

J’ai été Product Owner dans plusieurs organisations jusqu’à présent, et pendant longtemps, j’ai adopté une approche improductive et inutile lors des mes “on-boardings”. J’avais l’habitude de faire ce qui suit :

• Lire l’intégralité du Product Backlog pour me l’approprier.
• Approcher les principales parties prenantes pour comprendre les besoins derrière chaque élément.
• Enrichir les Items du Product Backlog en fonction de mes échanges avec eux.
• Prioriser le Product Backlog en fonction de la valeur définie plus haut.

Savez-vous quels résultats j’ai obtenus ? Beaucoup de temps perdu et plus de pression de la part de nombreux intervenants différents. Tout le monde voulait quelque chose de toute urgence, et personne n’était prêt à accepter de retirer ses articles du Product Backlog. Mon erreur était courante :

J’ai laissé les intervenants conduire la voiture au lieu de prendre le siège du passager.

Actuellement, les premières choses que j’effectue sont les suivantes :

• Comprendre la stratégie produit.
• Supprimer le backlog de produit.
• Définir les hypothèses à valider.
• Créer des éléments de backlog de produit liés à la stratégie.

Vous pensez peut-être maintenant qu’il est “trop radical” de supprimer le Product Backlog. Vous avez raison. Cependant, pour fournir de la valeur plus rapidement, vous devez être extrême. Jusqu’à ce que vous puissiez supprimer tout le bruit, vous n’aurez plus le temps de faire ce qui compte le plus.
Les parties prenantes se fâchent-elles lorsque je supprime leurs éléments du backlog qui les concernent ? Oui, ils le font. Mais ils seraient encore plus fous de savoir que le produit n’atteint pas le résultat escompté.

Un Product Owner solide fait ce qu’il faut pour créer de la valeur.

Laissez-moi vous dire un secret : une fois, j’ai supprimé environ cinq cents éléments du backlog produit. Devinez combien de parties prenantes m’ont approché à ce sujet. Seulement deux. Tous les autres n’ont soulevé aucune préoccupation. Mon apprentissage, si vous demandez la permission, vous avez plus de chances d’obtenir un rejet, mais si vous êtes prêt à prendre des risques, les résultats peuvent vous surprendre.

Demandez pardon plus que la permission.

Sans conflits, l’agilité se meurt

… Ou plutot sans avis divergents !

“Emmerder” les gens est la partie la plus difficile dans le métier de Product Owner. Pourtant c’est essentiel pour faire ce qui est bon pour le produit. Vous ne trouverez pas de moyens de fournir de la valeur en faisant plaisir à tout le monde. Cela signifie des conflits, et par conséquent, du stress. Votre capacité à gérer les conflits définira votre succès en tant que Product Owner.

Comme pour tout dans la vie, les avantages à court terme garantiront des frustrations à long terme.
Si votre Product Backlog reflète parfaitement les souhaits de vos parties prenantes, elles seront heureuses au début et frustrées plus tard une fois que vous ne répondez pas à toutes leurs attentes.

Pourtant, si vous prenez la voie dure et embrassez les conflits pour atteindre l’engagement, vous pouvez amener l’équipe Scrum à fournir de la valeur.
Pour vous assurer de ne pas tomber dans un piège de validité illusoire, supprimez votre Product Backlog tous les trois mois. Créez de l’espace pour le nouveau et laissez le bruit disparaître. Donnez à l’équipe Scrum le temps de réfléchir aux apprentissages, d’évaluer ce qui a du sens pour le moment et de prendre un nouveau départ.

“Les illusions de validité et de compétence sont soutenues par une puissante culture professionnelle. Nous savons que les gens peuvent maintenir une foi inébranlable dans n’importe quelle proposition, aussi absurde soit-elle, lorsqu’ils sont soutenus par une communauté de croyants partageant les mêmes idées.”
― Daniel Kahneman, Penser, vite et lentement