SAFe et WSJF

Auteur : Black Swan Farming
Source : SAFe and Weighted Shortest Job First (WSJF)
Date : 27/09/2014

---

Traducteur : Fabrice Aimetti
Date : 03/04/2022

---

Traduction :

En 2012, lorsque Dean Leffingwell a lancé le Scaled Agile Framework (SAFe), il était évident que les enseignements de Don Reinertsen avaient un impact sur certains éléments de la conception. En particulier, SAFe spécifie la méthode recommandée par Don pour l'ordonnancement : Weighted Shortest Job First (WSJF). Quelle que soit votre opinion sur le reste de SAFe, il convient de le féliciter pour avoir encouragé les organisations à aller plus loin dans certains domaines spécifiques :

1. Il est formidable qu'un public beaucoup plus large soit sensibilisé à l'importance des méthodes d'ordonnancement et que le Weighted Shortest Job First (WSJF) soit plus largement utilisé pour la priorisation et la gestion des files d'attente. Peut-être que les organisations qui mettent en œuvre SAFe deviendront moins ignorantes des files d'attente, et du coût de ces dernières dans leur organisation ?
2. SAFe suggère également que le WSJF devrait être appliqué au niveau des fonctionnalités, ce qui correspond à notre expérience. Peut-être que lorsqu'ils commenceront à voir la distribution de la valeur dans leurs backlogs, ils commenceront à se rendre compte que les gros projets sont un moyen désastreux de développer des logiciels.
3. SAFe suggère également d'utiliser le Coût du Retard comme pondération dans le WSJF. Peut-être cela signifie-t-il que les Product Owners feront apparaître leurs hypothèses sur la nature de la valeur, et élaboreront de meilleures expérimentations pour tester et apprendre ce qui a de la valeur, plutôt que de se fier à leur instinct ? Peut-être que les managers du monde entier commenceront à parler et à se concentrer davantage sur le Coût du Retard et non sur des choses beaucoup moins intéressantes comme la productivité, la vélocité et les estimations de dates et de coûts. Et peut-être les équipes auront-elles enfin un moyen de prendre de bien meilleures décisions en termes de choix et de découvrir, d'entretenir et d'accélérer la création de valeur plus rapidement.

Je suis très intéressé par le dernier point en particulier. D'après mon expérience, c'est un levier vraiment puissant. Je suis sûr que Don est d'accord, car il ne pouvait pas le décrire plus clairement quand il a dit :

Si vous ne devez quantifier qu'une seule chose, quantifiez le coût du retard.

En fait, cette citation de Don se trouve en haut de la page où SAFe explique le Coût du Retard, donc je suis sûr qu'ils y ont porté attention. Voyons comment SAFe explique et recommande aux organisations de quantifier le Coût du Retard. J'ai déjà eu l'occasion de le faire dans un certain nombre de contextes, donc je suis vraiment intéressé de voir comment ils l'abordent...

L'interprétation du Coût du Retard par SAFe

SAFe enseigne que le Coût du Retard est constitué de trois éléments principaux, qui s'additionnent pour former le Coût du Retard. Examinons chacun de ces éléments et je réfléchirai un peu à voix haute pendant l'exposé :

Valeur utilisateur-entreprise : Nos utilisateurs préfèrent-ils ceci plutôt que cela ? Quel est l'impact sur les revenus de notre entreprise ? Y a-t-il une pénalité potentielle ou un autre impact négatif si nous tardons à agir ?

Nous sommes sur un terrain assez solide avec "l'impact sur les revenus". (Cela correspond bien aux critères "Augmenter les Revenus" et "Protéger les Revenus" du framework de valeur que nous utilisons pour amener les gens à quantifier le Coût du Retard). Je ne suis pas sûr de la question de la préférence des utilisateurs. Si vous parlez d'utilisateurs internes (un cas courant dans le marché cible de SAFe), c'est souvent un indicateur de valeur assez faible. Le fait de demander s'il y a une pénalité potentielle "si nous tardons" semble se recouper avec le paramètre suivant - mais peut-être parlent-ils d'amendes, de perte de licence ou de capacité à fonctionner ? Cela pourrait être plus explicite, je pense.

Criticité temporelle : Comment la valeur pour l'utilisateur/l'entreprise se dégrade-t-elle avec le temps ? Y a-t-il une date limite fixée ? Vont-ils nous attendre ou passer à une autre solution ? Quel est l'effet actuel sur la satisfaction du client ?

Les trois premières questions sont toutes excellentes. Je placerais la satisfaction du client sous la rubrique précédente de la valeur pour l'entreprise. Ce qui n'est pas clair cependant, c'est la façon dont les réponses à ces questions doivent être traitées. Une "date limite fixée" est-elle un facteur de criticité élevé ou faible ? En principe, le Coût du Retard pour un projet à échéance fixe est initialement nul, jusqu'au moment où vous devez le commencer. Ensuite, le Coût du Retard correspond éventuellement à tous les revenus liés à cette date. Dans de nombreux cas, il est trop risqué de reporter le projet jusqu'à l'expiration de l'option ; le Coût du Retard peut donc augmenter un peu avant pour refléter ce risque. Tous les travaux devraient avoir un certain degré d'urgence, ou de "criticité temporelle". S'il n'y a pas d'urgence, il est préférable d'investir ailleurs. La façon dont SAFe traite la criticité temporelle n'est pas claire - j'aimerais bien voir des exemples de l'utilisation de ce modèle en situation réelle.

Valeur de réduction des risques et de création d'opportunités : Qu'est-ce que cela apporte d'autre à notre entreprise ? Est-ce que cela réduit le risque de cette livraison ou d'une livraison future ? L'information que nous recevrons a-t-elle de la valeur ? Cette fonctionnalité permettra-t-elle de créer de nouvelles opportunités de marché ?

Encore une fois, ce sont de bonnes questions, mais ce sont toutes des questions qui constituent un sous-ensemble de, ou affectent la probabilité de fournir, de la valeur à mon avis. Ne serait-il pas plus simple de les ajouter simplement au premier paramètre ? La réduction du risque consiste principalement à éviter les coûts ou à affecter d'une manière ou d'une autre l'asymétrie de la fonction de gain. (Certains pourraient même affirmer que toute valeur est simplement un filtrage d'un ensemble d'informations). Créer de nouvelles opportunités de marché semble être une question d'Augmentation des revenus. En traitant ces types de valeur comme une chose distincte de la Valeur pour l'Entreprise, le risque est qu'ils soient traités différemment de la "Valeur pour l'Entreprise". Cela me semble alambiqué et confus, mais c'est peut-être juste moi.

Globalement, je pense que la définition de ces paramètres mériterait d'être simplifiée et clarifiée. J'ai cependant quelques questions supplémentaires :

Pourquoi est-ce une addition ?

Selon moi, le Coût du Retard est une façon de combiner la Valeur et l'Urgence. Si l'un de ces deux paramètres est nul, alors le Coût du Retard est nul. Ajouter la "Criticité Temporelle" à la "Valeur pour l'Entreprise" n'a pas de sens économique pour moi. Je pourrais en théorie avoir quelque chose qui a zéro valeur pour l'entreprise, mais qui est hautement critique en termes de temps - et cela serait tout de même comptabilisé ? Il en résulte que l'utilisation de l'algorithme SAFe vous donnera presque certainement un ordonnancement sous-optimal des options.

Pourquoi est-ce relatif ?

Plus inquiétant encore est la thèse selon laquelle "nous n'avons pas besoin de nous soucier des chiffres absolus". Je ne peux que supposer que cette décision a été prise par des personnes ayant une expérience principalement dans le domaine des technologies de l'information. Il est dommage que la communauté Lean et Agile semble penser que l'objectif premier du Coût du Retard est la priorisation. C'est bien plus que cela. Les estimations relatives ne vous apportent tout simplement aucun des avantages potentiels que j'ai évoqués plus haut. Même des estimations très grossièrement quantifiées (peut-être dans des fourchettes assez larges) seraient meilleures que cela. Il y a quelques autres problèmes liés aux estimations relatives de la valeur à prendre en compte :

1. Il est très difficile de se souvenir du raisonnement qui sous-tend le positionnement relatif de plus d'une vingtaine d'éléments. L'application de Fibonacci n'a pas non plus de sens pour moi. Pour les estimations de coût ou d'effort, nous avons un biais d'optimisme évident, qui s'aggrave avec la taille de la tâche, principalement en raison des incertitudes. C'est pourquoi la distribution fréquentielle du lead time est conforme à la loi de Weibull - c'est la propagation des incertitudes. Il n'y a aucune preuve (à ma connaissance) que ce même biais s'applique à la partie valeur de l'équation. Nos surestimations ont tendance à être compensées par nos sous-estimations - ce sont en fait les Cygnes Noirs qui dominent la partie valeur de l'équation. Sur quelle base utilise-t-on Fibonacci ? (Je crains que cette obsession de Fibonacci ne nous transforme tous en enfants naïfs).
2. Les estimations relatives ne sont pas d'une grande utilité si vous avez plus d'une partie prenante. La note relative de 2 d'une personne correspond à celle de 8 d'une autre. Le score relatif de 2 d'une personne est le 8 d'une autre. Si vous gérez trois ou quatre parties prenantes, les estimations relatives deviennent soit une escalade vers le HiPPO (l'opinion de la personne la mieux payée - Highest Paid Person's Opinion), soit un douloureux exercice de marchandage. D'après mon expérience, il s'agit là d'un point sensible pour la plupart des grandes organisations - qui, à mon avis, constituent le marché cible de SAFe.
3. Les estimations relatives ne nous encouragent pas à mettre à plat les hypothèses. La quantification du Coût du Retard a le mérite de nous obliger à passer à la pensée analytique du Système 2 afin de remettre en question notre instinct du Système 1 (NdT : les deux vitesses de la pensée). Comme nous l'enseignons dans les ateliers que nous avons animés avec divers clients et lors de conférences, l'intérêt de cette démarche n'est pas vraiment le chiffre obtenu, bien que tout Coût du Retard quantifié vaille mieux que rien. Il s'agit plutôt de faire apparaître les hypothèses et d'identifier la partie la plus incertaine de toute l'entreprise : "où est la valeur ?". Parler de nos estimations du Coût du Retard, les écrire et les rendre visibles, c'est comme désinfecter nos backlogs à la lumière du soleil. Ce n'est pas que nous recherchons la certitude, mais nous devrions au moins partager ces incertitudes avec le plus grand nombre afin que les gens puissent concevoir des expérimentations plus efficaces pour découvrir si la valeur est là ou non.
4. En nous cachant derrière des estimations relatives, nous ne faisons rien pour changer l'orientation de la conversation. En renonçant à quantifier la partie valeur de l'équation, on tend à se concentrer sur la partie durée ou estimation des coûts. Comme nous le savons tous, il s'agit là d'une perte de temps et d'effort pour tout le monde, notamment en raison de l'asymétrie de l'information, sans parler de l'incertitude.

Comme Jason Yip l'a déjà souligné, l'ingrédient clé de tout ceci est le Coût quantifié du Retard. Sans cela, la plupart des avantages s'évaporent. Vous ne pouvez tout simplement pas prendre de décisions de compromis avec des estimations de valeur relative. Le coût des files d'attente sera toujours invisible. Le coût des gros lots ne sera toujours pas évident. Les hypothèses sur la valeur resteront probablement cachées. Nous serons toujours obligés de négocier des estimations de dates et de coûts et d'être obsédés par des choses inutiles comme la "vélocité". En bref, ce n'est pas le Coût du Retard que je connais.

En conclusion

Comme je l'ai dit au début de cet article, c'est formidable que SAFe ait adopté le WSJF et le Coût du Retard. Malheureusement, il semble que la plupart des points positifs potentiels que j'ai énumérés ci-dessus ont été édulcorés ou brouillés - au point que, à mon avis, nous nous retrouvons surtout dans une situation floue et avec très peu de matière. Pour être clair, je suis pour la simplification : je l'ai pratiqué pour de vrai avec des organisations et lors de conférences au cours des 5 dernières années. Si SAFe est vraiment intéressé par l'amélioration de son Framework, je suis sûr qu'ils nous contacteront et nous demanderont de contribuer à cette amélioration - nous serions plus qu'heureux d'aider.

MISE À JOUR : J'ai fait la plus petite et la plus simple des suggestions pour améliorer l'approche SAFe du Coût du Retard ici.

Si cela vous intéresse, j'ai également publié une approche qualitative du Coût du Retard, pour ceux qui ont peur des chiffres.