L’histoire et la théorie

WSJF ou Weighted Shortest Job First rendu populaire grâce au framework Agile à l’échelle SAFe permet entre autre de prioriser les fonctionnalités à développer et est défini de la manière suivante dans SAFe :

Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs

La formule mathématique pour prioriser les éléments est la suivante :

Regardons maintenant rapidement les composantes du coût du retard qui est la somme de 3 éléments : la valeur utilisateur/métier, le coût lié aux contraintes de temps, le coût évité grâce à l’information (risque et opportunités) apportée par la fonctionnalité. Pour simplifier, on part alors du principe que plus on met de temps à mettre une fonctionnalité sur le marché (ou entre les mains de l’utilisateur final) , plus il devient urgent de livrer celle-ci afin de ne pas bloquer les autres items à développer.

Sans chercher trop longtemps sur le net, vous pouvez trouver ici un excellent article qui explique la provenance de cet outil ainsi qu’une vidéo ci-dessous de Don Reneirtsen son inventeur expliquant le coût du retard.

Le WSJF répond au premier principe Lean Agile de SAFe qui consiste à prendre des décisions se basant sur une vue économique. Vous pouvez utiliser le WSJF pour motiver toutes vos décisions concernant les fonctionnalités à réaliser, du moins c’est ce que dit la théorie. Mais en pratique ?

Les réflexions autour de la mise en pratique

Voici en vrac quelques réflexions et constats sur les ateliers WSJF :

• La simplification par la suite de Fibonnaci dans le coût du retard
• La simplification du délai de mise en oeuvre par la charge de développement
• La fausseté des chiffres
• Les biais cognitifs
• La satisfaction client
• Les fonctionnalités techniques

La simplification par la suite de Fibonnaci dans le coût du retard

Lorsque Don Reinersten a défini le coût du retard, il l’a envisagé avec une vision économique et c’est en toute logique que chacun des éléments du coût du retard s’exprime en devise financière et qu’ils peuvent donc être facilement additionnés puisqu’on effectue une opération sur des nombres ayant la même unité de mesure. On est ici dans une estimation absolue et non dans une estimation relative (on n’estime pas les éléments les uns par rapport aux autres). Donc pas de problème dans la théorie.

Mais en pratique, il est très difficile de pouvoir estimer le coût du retard en espèces sonnantes et trébuchantes. Heureusement qu’un certain framework à l’échelle a pensé à tout et propose de simplifier les valeurs du coût du retard en estimant de manière relative chacune des composantes de ce dernier. On va donc pour chacune des 3 composantes rechercher l’élément le plus petit et estimer les autres de manière relative par rapport au premier en utilisant la suite de Fibonnaci simplifiée (1,2,3,5,8,13,20,40). Voici un exemple avec deux fonctionnalités pour vous expliquer :

Valeur utilisateur/métier :

• Fonctionnalité A : valeur estimée 1000 € c’est la plus petite de la liste donc elle prendra la valeur de référence 1
• Fonctionnalité B : valeur estimée 100 000 €, elle est 100 fois plus importante que A donc avec la suite de Fibonnaci simplifiée elle sera probablement à 40.

Valeur du coût lié aux contraintes de temps :

• Fonctionnalité B : perte de 10 € par semaine où la fonctionnalité est absente. C’est la plus petite et prend la valeur de référence 1.
• Fonctionnalité A : perte de 1000 € par semaine où la fonctionnalité est absente. C’est 100 fois plus important que la fonctionnalité B donc on attribuera probablement la valeur 40 à cette fonctionnalité.

Valeur liée à l’information apportée par la fonctionnalité : A = B = 1

Coût du retard :

• Fonctionnalité A : 1 + 40 + 1 = 42
• Fonctionnalité B : 40 + 1 +1 = 42

On a donc le même coût du retard pour les deux fonctionnalités et si on s’arrête là, on ne peux pas prendre de décision sur cette valeur. Alors que si nous étions resté sur des considérations purement économiques , nous aurions probablement choisi de réaliser la fonctionnalité B avant A. On voit ici que le changement d’échelle entre les composantes amène à additionner des éléments qui n’ont finalement pas la même grandeur car exprimés en relatif. Au passage, les résultats perdent leur unité.

La simplification du délai de mise en oeuvre par la charge de développement

Le dénominateur est normalement le coût de mise en oeuvre de la fonctionnalité souvent simplifié par le coût de réalisation. Si on reste sur une évaluation économique, on a donc un coût du retard exprimé en devise par unité de temps (ex 500 €/semaine) et en dénominateur un coût qui correspond à un délai. Donc en multipliant le temps de réalisation par le coût du retard nous aurions le coût du retard pour le délai de mise en oeuvre. Vous suivez toujours ?

Prenons un exemple :

• Une fonctionnalité A me fait perdre 1000€ par jour où elle n’est pas mise à disposition des utilisateurs. Si il faut 15j pour la mettre à disposition des utilisateurs alors je perdrai 15 000 euros (1000 * 15). Si au contraire il ne faut que 2j pour la mettre à disposition, je ne perdrai que 2000€.

Donc plus le délai de mise à disposition de la fonctionnalité est petit, moins je perds d’argent.

L’ambiguïté est encore une fois apportée par la simplification : le fait qu’une équipe puisse développer la fonctionnalité en 1 semaine ne signifie pas qu’elle pourra être mise à disposition dans le même délai. J’ai déjà rencontré des équipes programmes qui devaient attendre plusieurs mois pour voir livrée une fonctionnalité de quelques jours parce qu’elles n’avaient pas la main sur la priorisation de l’équipe de réalisation. Et je vous passe le fait que la suite de Fibonnaci simplifiée va encore rendre l’opération encore plus fausse. Vous pouvez trouver d’autres justification ici

La fausseté des chiffres

Nous avons donc des résultats complètement faux et ils sont faux car :

• Une estimation est fausse de base et donc tous les chiffres fournis sont faux
• L’opération mathématique est fausse car on ne tient pas compte des ordres de grandeur

Pourtant les chiffres et les mathématiques nous invitent à penser que ces résultats sont d’une exactitude implacable. Un petit peu comme dans les sondages. Un petit biais cognitif ici ? Au passage, j’en profite pour dénoncer le fait que certaines personnes pendant l’atelier savent très bien tirer parti de ces approximations pour infléchir les résultats vers les fonctionnalités qu’ils souhaitent voir développées en premier. Avec ces constats, je rappelle souvent aux participants que les résultats du WSJF ne sont pas une vérité immuable et que ce n’est qu’un outil d’aide à la décision.

Les biais cognitifs

Voici 2 biais cognitifs parmi les nombreux biais qui peuvent se manifester dans une séance de WSJF :

Le biais des coûts irrécupérables : l’exercice a pour vertu de se baser sur une vision économique et de contrer le biais des coûts irrécupérables; le biais des coûts irrécupérables est celui qui nous pousse à continuer à investir dans un élément même si il n’apporte plus de valeur parce que nous avons trop investi dedans :

• Exemple : vous attendez un bus depuis 10 min et il n’arrive toujours pas, le tableau des horaires indique un retard de 20 min supplémentaires. Vous continuez à attendre à cause des 10 min que vous avez déjà dépensé au lieu de choisir un autre moyen de locomotion qui pourrait vous amener plus vite à votre destination.

En effet, imaginons qu’une fonctionnalité a été développée à moitié à la fin d’un incrément (cf SAFe). Il y a de fortes chances que lorsqu’on va recalculer le WSJF pour cette fonctionnalité, le délai de mise à disposition chute et donc que la fonctionnalité remonte mathématiquement dans la priorisation. Si cette fonctionnalité métier pour une raison ou une autre perd de la valeur utilisateur/métier alors le numérateur baisse et le résultat fera descendre le résultat du calcul.

Le biais de conformité : l’atelier doit permettre à tous les acteurs présents de s’exprimer librement lors du poker planning des items. après un premier tour de vote, on peut voir apparaître un biais qui force les personnes qui n’ont pas vraiment d’avis à se ranger dans le camp de la majorité.

La satisfaction client

Bon, faisons fi du calcul et des biais, vous obtenez une liste d’items ou de fonctionnalités priorisées et vous vous dites donc que vous allez donc prendre les premières et les développer pour le Minimum Marketable Produit (produit minimum répondant au besoin utilisateur). Mais au final, qu’en est-il de la satisfaction client ? Est-ce que les fonctions produisant un effet wahou sont effectivement dans cette liste ? Comme on aurait pu les trouver à l’aide du diagramme de KANO ? Pas certain que la valeur utilisateur du coût du retard ou la valeur liée à l’information ait inclus cet aspect. Qui par la même sera très difficile à chiffrer…

Les fonctionnalités techniques

Autre difficulté rencontrée : que faisons nous lorsqu’un item à prioriser n’apporte pas directement de valeur au client ? Dans le cas de fonctions purement techniques par exemple ? Problème de découpage vous me direz ? Mais parfois des API Back Office doivent être développées et mises à disposition avant que les services consommateurs puissent être disponibles. Dans ce cas, c’est la composante liée à l’information qui porte la valeur du composant. Encore une fois, cette valeur est difficile à estimer… Le WSJF va permettre grâce aux différentes composantes du coût du retard, de redonner du poids à tous les items qui ne sont pas visibles de l’utilisateur (comme les items techniques) mais qui sont néanmoins nécessaires à toutes les autres fonctionnalités.

Le WSJF, cela fonctionne !

Donc au final, nous avons des items difficiles à estimer, des estimations fausses, des opérations fausses…Et pourtant cela fonctionne quand même le WSJF ! Oui cela fonctionne ! Alors comment ? Et Pourquoi ?

Briser les silos et transmettre la stratégie de l’entreprise!

Le WSJF est selon la théorie une instance de décision et sa vertu réside surtout dans le travail préparatoire sur les items et des personnes effectuant ce travail. En effet, nous allons pendant ce travail préparatoire à la recherche des coûts, faire collaborer les personnes du marketing avec les architectes, les développeurs, les sponsors… Ces personnes vont se retrouver ensemble dans des séances de WSJF qui peuvent parfois durer plusieurs heures alors qu’elles n’auraient peut être pas pu avoir cette occasion d’échanger. Le format de l’atelier doit en théorie permettre à chacun de s’exprimer librement… Ces échanges et recherches autour de la valeur sont aussi le moyen de faire passer des informations sur la stratégie de l’entreprise !

Le consensus et l’alignement !

Tout le monde va se retrouver dans un même atelier et choisir de s’aligner autour d’une liste d’items. Que celle-ci soit juste ou fausse, importe moins que l’alignement et le consensus autour de cette dernière. Le consensus est obtenu après plusieurs échanges; charge quand même à l’animateur de faciliter les débats : à la vue des approximations, inutile de débattre plusieurs heures pour trancher entre une valeur de 1 ou 2 même si on passe du simple au double. L’exercice d’alignement fait prendre conscience à tous les acteurs, des enjeux et contraintes de chacun. La DSI prend connaissance des enjeux métiers et contraintes de temps liées au marché et le métier à son tour est informé des contraintes liées à la réalisation des fonctionnalités.

Donc le véritable sens ou but des séances de WSJF seraient moins de prioriser des items que de faire collaborer des personnes entre elles et de les faire commencer à s’aligner sur des objectifs . Du moins c’est mon interprétation de l’exercice !

Encore une suggestion avant de terminer, pourquoi ne pas intégrer dans le coût du retard une composante indiquant le coût carbone de la fonctionnalité ? Je pense que cela pourra bientôt être fort utile. Qu’en pensez-vous ?

Remerciements : Merci à Anne Doublier, Maud Guyot et Yann Tisseyre pour leurs retours et aide sur cet article.

Ressources :

• Site officiel SAFe sur WSJF : https://www.scaledagileframework.com/wsjf/
• Site consacré au WSJF :
  • http://blackswanfarming.com/wsjf-weighted-shortest-job-first/
  • http://blackswanfarming.com/why-duration-and-not-cost/
• Diagramme de KANO : https://fr.wikipedia.org/wiki/Mod%C3%A8le_de_Kano