Si vous ne priorisez pas, vous n'êtes pas agiles - Blocage n°1 : Choisir c'est renoncer

La priorisation, un exercice difficile

La priorisation est au cœur d’une approche agile. Dans mon expérience de coach agile, j’ai ainsi de très nombreuses fois été amené à animer des ateliers qui impliquent une phase de priorisation : Storymap, roadmap produit, priorisation du backlog, préparation de sprint ou de PI Planning etc.

A première vue, on pourrait imaginer que c’est un exercice relativement simple, car il s’agit “seulement” de trier les fonctionnalités par ordre d’importance.

J’observe le contraire sur le terrain, car si la forme est assez simple, ça bloque quand on demande “est-ce que <fonctionnalité A> est plus importante que <fonctionnalité B> ?“, ce qui en fait le plus souvent un exercice laborieux, pénible et avec un résultat rarement satisfaisant.

La majorité des agilistes confirmés font le même constat et en sont d’ailleurs très frustrés. Il leur est souvent difficile de se faire comprendre, de trouver un exemple parlant et de convaincre de l’intérêt d’une priorisation faite correctement. On observe des formes de blocages parmi les participants que je vais tenter d’analyser dans cet article.

L’importance de bien prioriser

La priorisation est un exercice central et, si elle est mal faite, a des impacts à moyen-long terme sur le niveau d’agilité du projet.

Aujourd’hui, je me sers fréquemment de ce type d’atelier pour avoir une bonne estimation de la maturité agile de l’organisation.

Prioriser incite à réfléchir quelles parties faire avant lesquelles. Et, même si les participants de l’atelier n’en ont pas toujours conscience, en ne découpant pas le périmètre en éléments petits et déplaçables, on se crée artificiellement une rigidité qui amène à perdre de la marge de manœuvre - qui pourtant se révélerait précieuse à l’avenir (lors de retards par exemple).

Par ailleurs, la boucle de feedbacks avec les utilisateurs, les vrais, est aussi souvent rallongée.

Le périmètre est LA variable d’ajustement indispensable pour pouvoir s’adapter (l’adaptation, la 4ème valeur du manifeste agile), et sans elle, on crée un cycle en V qui ne dit pas son nom (et avec tous ses écueils que nous connaissons bien).

Les blocages qui empêchent de bien prioriser

Blocage n°1 : Choisir c’est renoncer

Le constat

Le phénomène que j’observe le plus souvent dans les ateliers Storymap est cette fâcheuse tendance à tout placer en haut de la pile (“must have”, “essentiel”, “indispensable”, P1, V1 etc.). Et les ateliers aboutissent le plus souvent à des premières versions (parfois appelées à tort MVP) énormes.

Tout ça parce que, et malgré les mises en garde du coach (“si vous placez 90% du scope en P1 alors vous ne priorisez pas vraiment”), les parties-prenantes sont freinées le plus souvent par des tas de contraintes du type :

• “On peut pas avoir une appli digne de ce nom si on n’a pas au moins ces fonctionnalités”
• “J’ai honte de proposer aux utilisateurs quelque chose d’aussi petit”
• “On est obligés de mettre ça en V1, c’est réglementaire”
• “N’oubliez pas la sécurité !”

C’est le genre d’objections que j’ai pu également rencontrer lors de formations agiles, sur des cas pratiques factices, là où on pourrait s’attendre à ce qu’avec l’absence d’enjeux réels on perde ces travers là.

Tout ça part d’une idée reçue : “la première version doit forcément être complètement utilisable et déployée à 100% de la population cible”.

La raison est simple : les participants choisissent de gonfler les V1 pour être certains de tout avoir (“on nous accordera une V1, mais peut-être pas la suite”). Ironique, considérant que la grande majorité des fonctionnalités sont peu ou jamais utilisées (cf. 2019 Feature Adoption report de Pendo ou CHAOS report)

Or, tout placer en “Must have”, ne rend pas mécaniquement les développeurs plus rapides. Bien au contraire : à équipes ou effectifs fixes, ça décale nécessairement la date de fin.

Au moment de la priorisation, on a très peu d’informations sur le temps que les choses prendront. Pour autant, l’exercice de priorisation est souvent détourné pour créer uniquement un lotissement, un séquencement, mais jamais une vraie priorisation avec des choix intégrant bien la possibilité qu’on ne pourra peut-être pas tout faire (dans la mesure des stocks disponibles et du temps imparti).

Du coup, en étant dans cette logique du “de toute façon, il faut tout faire”, on élabore rapidement un plan pour s’en débarrasser, et on pose des certitudes (ou plutôt des vœux pieux) sur l’avenir. Cela crée mécaniquement la rigidité anti-agile dont on parlait plus haut.

Solution (a) : La priorisation comme stratégie de dérisquage

Pour éviter l’effet “MVP mastodonte”, servez-vous de la logique itérative qu’apporte l’agilité par la priorisation.

La priorisation est souvent faite très tôt et on ne sait jamais encore à ce stade l’ensemble du scope qu’on pourra réaliser dans un temps donné. On le suppose, on l’estime, mais on ne SAIT pas encore.

Une priorisation correcte sert justement à pouvoir avoir des marges de manœuvre en cas d’aléa, de changement de priorité, de mauvaise estimation etc. En outre, elle joue un rôle majeur dans le dérisquage du projet, en permettant d'identifier et de minimiser les risques avant qu'ils ne deviennent des obstacles insurmontables.

Du coup, plutôt que de voir la priorisation comme un renoncement, voyez la plutôt comme une façon de dérisquer.

Alors comment faire lorsqu’on n’arrive pas à se décider, si “tout est important” et qu’il est difficile de trancher ?

J’utilise une méthode, certes un peu directe, mais très efficace : j’ai remarqué que la plupart des décideurs, quand ils sont dos au mur, qu’ils n’ont plus le choix, priorisent convenablement.

C’est ce qu’il s’est passé pendant le COVID, où l'urgence a contraint de nombreuses entreprises à prendre des décisions radicales et ont réussi à distinguer l’essentiel du superflu.

Voici la méthode : Lorsque j’anime des ateliers de priorisation, afin de vérifier si l’exercice a été fait correctement, je coupe la roadmap en 2 au hasard et je lance le défi suivant : “Et si un second COVID surgissait à ce moment-là et vous contraint à suspendre les développements par manque de budget. Est-ce que votre stratégie est robuste ? Seriez vous satisfaits de ce que vous aurez réalisé jusqu’à ce point ?”

En général, ça nous permet de constater à quel point les premières versions sont surchargées.

L’agilité, illustrée ici est, justement, de préparer les choix qu’on ferait en temps de crise, mais sans attendre la crise.

C'est-à-dire : au moment où on est encore sereins car n’oublions pas que le stress a des impacts sur nos décisions (comme des mariés qui - en préparant leur contrat de mariage - préparent leur divorce au meilleur moment, quand ils s’aiment encore).

Cela peut paraître contre-intuitif, mais réfléchir dans une logique de pénurie de ressources ou de temps permet d’être beaucoup plus réaliste.

Découpez, faites des choix, changez l’ordre dans lequel vous allez faire les choses et forcez vous à faire des versions vraiment plus petites. Vous aurez toujours la possibilité après coup d’apporter des améliorations.

Par la suite, les versions successives vous permettront - en plus de faire grossir le produit petit à petit - de valider la robustesse et d’actualiser votre plan régulièrement.

Solution (b) : La version “béta”

Il reste néanmoins la question de la viabilité de la V1, le V de MVP. Surtout quand on crée un produit from scratch ou quand on fait une refonte, on a souvent besoin d’un ensemble de fonctionnalités incompressibles pour que le produit rende un service minimum. Sans compter la somme de contraintes réglementaires ou de sécurité imposées à tout produit.

Si vous avez l’impression que votre V1 est toujours trop grosse mais que vous ne savez plus quelles fonctionnalités enlever, il existe toujours la solution de la “beta”.

Au sein de cette première grosse version à mettre en service, réorganisez les travaux en imaginant une ou plusieurs versions intermédiaires : enlevez ce qui est “facile à faire”, ce qu’on maîtrise déjà, et priorisez ce que vous avez besoin de valider au plus tôt (dans l’esprit du Validated Learning cher à l’approche Lean Startup)

• Qu’est-ce qui vous fait le plus peur ?
• Quelles hypothèses vous feraient le plus mal si elles étaient fausses ?
• Qu’est-ce que vous avez besoin de dérisquer ?
• Quels feedbacks du réel avez-vous besoin d’aller chercher au plus tôt pour vous tranquilliser ?

Voici quelques exemples de cas rencontrés :

• “Si on se trompe sur la première version, ça va impacter notre image de marque” => déployez une version beta à une population réduite et représentative
• “C’est la première fois qu’on doit utiliser cette API exotique” => faites un POC pour valider la connexion à l’interface
• “On ne sait pas si les utilisateurs vont comprendre le parcours” => faites en premier une version minimaliste du parcours (avec des écrans “mockés”, ou non branchés) pour aller au plus tôt le tester auprès des utilisateurs (logique du Walking Skeleton)
• “L’architecture est complexe et on risque d’avoir du mal à déployer” => amenez un HelloWorld jusqu’en production pour valider l’ensemble de la chaîne

En conclusion

Pour conclure, la priorisation est un exercice qui semble anodin mais est fondamental pour pouvoir avoir un mode de fonctionnement agile et en obtenir les bénéfices.

Mais pour le faire correctement, ça implique un changement d’état d’esprit profond dans la manière de prendre des décisions, et dans la capacité à accepter l’incertitude pour vraiment piloter cette dernière. D’expérience, il s’agit surtout d’un déclic, après lequel on ne souhaite plus revenir en arrière.

Keep in touch, nous ferons la dissection d’un autre type de blocage dans un prochain article.