Citation

Regardez donc si le problème ci-dessous vous semble familier :

Votre équipe agile vient de dérouler une série de sprints, elle travaille toujours sur les éléments les plus prioritaires choisis par votre product owner. Mais après cette série de sprints, vous jetez un coup d’œil en arrière sur ce que l’équipe a réalisé. Et ce n’est pas très satisfaisant. Tout ce que l’équipe semble faire c’est d’aller d’urgence en urgence, éteignant un feu après l’autre.

Il est très probable que l’équipe ait fait plein de travail. Mais sans apporter vraiment grand chose.

Que s’est-il passé ? Vous êtes tombé dans le piège de la priorisation basée sur ce qui paraît être le plus important au démarrage de chaque sprint, un effet de bord assez fréquent de la nature itérative et incrémentale de l’agilité. Il existe une bien meilleure façon d’aborder les choses.

Le piège de la priorisation agile : sélectionner le travail à chaque itération

Sélectionner un élément à traiter ou un autre qui semble important au début de chaque itération peut aboutir dans certains cas à une sous-optimisation. Cela peut conduire les product owners à prioriser le travail en mode crise du jour, que ce soit

  • Une anomalie technique importante
  • Quelque chose ayant pu entraîné, la veille, le perte d’une vente
  • Le dernier caprice d’une partie prenante importante

Bien que n’importe lequel de ces élements puissent être l’élément le plus important sur lequel travailler, trop souvent ces éléments ne s’avèrent pas être stratégiques. Et en choisissant de travailler sur quelque chose que quelqu’un vous réclame à cors et à cri sur le moment, le product owner renonce à l’opportunité d’avancer sur quelque chose de plus gros, de plus important ou de plus stratégique.

Prioriser sans objectifs est comme escalader des montagnes sans avoir de cartes

Mes concitoyens du Colorado et moi-même sommes fiers de nos 53 “Fourteeners”, qui sont un ensemble de sommets atteignants les 14 000 pieds d’altitude (4 267 mètres). Il existe deux manières de gravir un Fourteener.

Dans la première approche, vous allez au pied de la montagne et vous commencez gravir simplement la paroi la plus haute que vous voyez. À tout les coups, ce ne sera pas le vrai sommet, et s’il ressemble au sommet c’est pour la seule raison qu’il cache le vrai sommet.

Mais, après avoir gravit ce faux somment, vous pouvez voir désormais un pic plus élevé. Croyant qu’il s’agit du vrai somment, vous le gravissez. Et vous découvrez qu’il s’agit, ici aussi, d’un faux sommet.

montagne et objectif

Vous procédez de cette manière jusqu’à ce que finalement vous voyez le vrai sommet. Mais entre vous et le sommet il y a une vallée encaissée. Et pour atteindre le sommet de 14 000 pieds, vous devez d’abord descendre 10 000 pieds avant de recommencer à grimper.

Il est évident qu’il ne s’agit pas de la bonne manière pour gravir l’un des Fourteeners du Colorado.

La seconde approche implique d’acheter une carte topographique dans un magasin d’alpinisme du coin. Avec la carte en main, vous pouvez alors planifier une route plus efficiente à travers la montagne pour éviter d’avoir besoin de descendre et de ré-escalader les 10 000 pieds.

Les objectifs sur plusieurs itérations : la carte du product owner

Pour le product owner agile, l’équivalent d’une carte topographique est d’avoir un objectif très grand sur plusieurs itérations. Sans un objectif sur plusieurs itérations, le product owner ne ferait que grimper de faux sommet en faux sommet. Ce product owner et cette équipe pourraient éventuellement arriver à leur destination ultime, mais seulement après avoir descendu et ré-escaladé l’équivalent de la vallée encaissée de 10 000 pieds.

Et c’est tellement tentant de gérer à la place ces crises à court terme.

Tout d’abord, cela donne au product owner un sentiment d’accomplissement. Quelque chose a été terminé et peut être barré de la liste de courses. Ensuite, cela apaise la ou les personnes ayant demandé une solution immédiate. La plupart d’entre nous aiment faire plaisir aux gens, et ceci entraînant cela, avec souvent un impact inconnu ou non prévu sur l’objectif plus gros, à plus long terme et généralement plus important.

Lorsque vous priorisez, rappelez-vous que ce qui est urgent est rarement important

Le président des États-Unis Eisenhower savait combien il est essentiel de faire la distinction entre ce qui est important et ce qui est urgent. Même si l’histoire n’est pas très précise si Eisenhower l’ait bien exprimé ainsi, il est souvent cité de la manière suivante,

“Ce qui est important est rarement urgent, et ce qui est urgent est rarement important.”

Néanmoins, il l’a dite tout de même, Eisenhower disait que les crises urgentes que nous sommes tous tentés de résoudre ne sont pas importantes généralement par rapport à l’atteinte de notre objectif global.

Un bon product owner fera attention à prendre considération les deux aspects que sont l’importance et l’urgence des items du product backlog lorsqu’il priorisera le travail pour l’équipe.

Les product owners devraient identifier un objectif trimestriel significatif

Mais si un product owner ne sait pas ce qui est important, l’urgent gagnera toujours. Et ceci conduit à la série insatisfaisante de sprints que j’ai décrite au début de cet article. Lorsqu’une équipe agile court d’urgence en urgence, le sentiment de gratitude s’efface lorsque l’équipe et les parties prenantes réalisent qu’aucun progrès n’a été fait vers les objectifs importants.

Cela signifie qu’il est vital pour un product owner de définir un objectif significatif important. Je trouve que les meilleurs objectifs significatifs seront ceux que l’équipe mettra trois mois à accomplir.

Prendre plus d’une itération est important parce que cela focalise l’équipe sur un horizon à plus long terme. Cela veut dire que l’objectif significatif devrait être un résultat métier important, telle que la migration d’une partie d’un système vers une nouvelle technologie ; ajouter une grosse, une importante, une fonctionnalité visible ; ou n’importe quoi d’autre.

Mais il doit être significatif. Pour un nouveau produit, cela pourrait être créer un produit viable à minima (MVP). Pour un produit existant, cela pourrait être ajouter une fonctionnalité minimale vendable (MMF). Certaines organizations pourront utiliser le terme d’objectif extrêmement important (WIG).

Avec un objectif significatif - que ce soit sous la forme d’un MVP, MMF ou WIG - le product owner sera plus d’autant plus capable d’évaluer les besoins urgents. Si gérer une urgence est plus important qu’avancer vers l’objectif significatif, alors l’équipe devra, par tous les moyens, être mise sur l’urgence.

La volonté de mettre en place un objectif significatif n’est pas de créer une dévotion servile vers un objectif sur plusieurs itérations. C’est plutôt de mettre en place un mécanisme pour soutenir le product owner dans la priorisation de ses décisions.

Sans un objectif significatif à comparer aux urgences, l’urgent l’emportera toujours.

Quelle est votre expérience ?

Avez-vous déjà expérimenté le résultat insatisfaisant d’une série de sprint qui se focalisaient uniquement sur les urgences ? Comment votre product owner ou votre équipe gèrent-ils l’urgent et l’important, les objectifs à long terme ? Venez partager vos réflexions dans les commentaires ci-dessous1.


Auteur : Mike Cohn
Source : How to Ensure You’re Working on the Most Important Items Each Iteration
Date de parution originale : 8 Mai 2018


Traducteur : Nicolas Mereaux
Date de traduction : 21/05/2018


Licence Creative Commons
Cette traduction 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.

Le texte original en vo et les images sont copyright ©1998-2015 Mountain Goat Software. All Rights Reserved.


  1. sur le site de l’auteur - NdT