🤹 [21-04-2023] La nature bifide de la marchandise et les équipes Agile
En 1867, un vieil économiste barbu démontrait que les marchandises avaient une double valeur : La valeur d'échange et la valeur d'usage. C'est de cette double valeur de la marchandise, désignée comme "bifide" que nous allons parler dans cet article. Plus précisément, nous allons regarder ce que recouvrent ces valeurs et, en quoi, elles peuvent être utiles pour comprendre les sources de fonctionnement et de dysfonctionnement de nos équipes.
La valeur d'échange
La valeur d'échange est quantifiable, c'est le prix d'un produit. C'est ce que l'on paye pour acheter ou pour vendre un produit. Dans un marché, la valeur d'échange, évolue en fonction de l'offre et de la demande.
* Pour être précis, l'économiste barbu estime que la valeur d'échange est déterminée par le temps de travail nécessaire pour produire un produit.
La valeur d'usage
La valeur d'usage est le prix qu'estime le consommateur lorsqu'il "utilise" ce produit. C'est une notion qui n'existe que dans la tête du consommateur et qui n'existe qu'à un seul véritable moment : lorsqu'il utilise réellement ce produit. Par exemple, on connaît la vraie valeur d'un vin qu'on a acheté uniquement lorsqu'on le boit ! La valeur d'usage est donc une valeur subjective, floue et pas vraiment quantifiable mais qui existe tout de même !
On comprend aussi vite que ces 2 types de valeurs sont liées : les gens achètent des produits avec une valeur marchande qui devrait correspondre à une certaine valeur d'usage. Si le produit déçoit (faible valeur d'usage), alors sa valeur marchande risque de baisser. Et inversement !
Dans le logiciel, c'est pareil !
On passe notre temps à produire des logiciels qui devraient, à la fois être utile et plaisant à un client final tout en étant rentable pour celui qui le produit.
Et l'agilité dans tout cela ?
Quand on regarde certains postes de travail que l'on voit dans nos entreprises, on se rend compte qu'ils sont souvent dédiés à une des deux valeurs, prenons le temps de le regarder :
Rôle | Type de Valeurs | Explication |
---|---|---|
UX (User Experience) | Valeur d'usage | C'est clairement le rôle qui cherche à maximiser la valeur d'usage. Il cherche à répondre aux besoins du client en lui faisant tester au maximum le produit |
Scrum Master / Coach Agile | Valeur d'échange | Il va chercher à faire fonctionner l'équipe au mieux en lui permettant de produire le plus rapidement possible dans un cadre le plus agréable possible. Il n'a pas d'impact direct sur la valeur d'usage du produit réalisé. |
Product Owner | Valeur d'usage | Son objectif est de prioriser les tâches pour créer vite de la valeur d'usage à l'utilisateur final. |
Sponsor, Contrôleur de Gestion ou Comptable | Valeur d'échange | On va être sûr des personnes qui vont chercher à maximiser le Retour sur Investissement, donc la valeur d'échange du produit. |
Développeurs et développeuses | Valeur d'échange | SCRUM leur demande d'être garant de la qualité du code. (maintenabilité, performance…) Hors un bon code ne garantit une utilisation plaisante ou utile du produit créé. Il fabrique donc de la valeur d'échange. |
L'OPS | Valeur d'échange | L'idée est d'accélérer les mises en production, donc de réduire les temps et au final les coûts du produit. |
Bien évidemment, nous simplifions la définition des rôles pour la clarté de l'article.
Qu'est-ce qu'on observe ?
Plus de gens travaillent pour la valeur d'échange que pour la valeur d'usage :
La première chose qu'on peut observer, c'est que dans une équipe, il y a, numériquement, plus de personnes qui travaillent à la valeur d'échange qu'a la valeur d'usage.
On comprend donc pourquoi les équipes ont tendances à se fliquer mesurer la productivité, pour être sûr que l'argent ne soit pas gaspillé.
Au final, on comprend mieux la tendance organique qu'on les sociétées à désaligner les objectifs métier des objectifs de rentabilité…
Le Mixe valeur d'échange + valeur d'usage est rarement bon
On observe souvent que des problèmes surgissent dans les équipes à qui on demande à certains rôles de pousser à la fois la valeur d'échange ET la valeur d'Usage.
Exemple :
- Le Sponsor qui pense savoir, à la place du PO ou de l'UX, ce dont l'utilisateur a besoin pour être satisfait.
- Le PO qui met la pression aux dev parce qu'il pense que cette story devrait être réalisée plus rapidement.
- Etc…
Évidement, il y a des limites à cet exercice : il est toujours intéressant qu'un·e dev s’intéresse et comprenne les enjeux métiers. Comme il est intéressant qu'un PO s’intéresse au code. Mais il faut le voir comme une allocation de son temps. Si un dev passait plus de temps à s'occuper des besoins métier, et qu'un PO passait plus de temps à coder qu'à prioriser son backlog, ce serait quelque peu étrange.
Quel application sur le terrain ?
Je vais être honnête, je n'ai encore jamais utilisé ces concepts dans mes missions.
Mais j'imagine facilement utiliser ces concepts dans un atelier "/ rôles et responsabilités/" . Cela permetterait aux équipiers de mieux comprendre ce qu'elles attendent des uns et des autres.
Une autre idée, c'est de poser la question dans un mood meter de rétro : Durant ce sprint, vous avez eu l'impression de travailler pour de la valeur d'usage ou pour de la valeur d'échange ? Je suis certains que les résultats seraient hyper intéressant
Bref, je vais tester cela et je vous re-dirais ici ce que cela a donné !