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 :
- 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 ?
- 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.
- 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.