La valeur d'un Scrum Master : baisser le coût de ce que l'équipe livre.

Tu ne prouveras jamais ta valeur de Scrum Master en montrant que l'équipe travaille "mieux". Par contre, tu la prouveras en montrant ce qui coûte moins cher depuis que t'es là.

Moi, je l'ai compris trop tard. J'étais coach agile, et un VP m'a posé la question frontalement :

Mais concrètement, c'est quoi ton impact sur la transformation ?

J'ai pas su répondre sur le moment mais entre-temps j'ai compris.

J'avais beau avoir des années de Scrum Master derrière moi, j'avais pas un seul chiffre sur ce que mon travail changeait pour l'entreprise. Et surtout je n'avais que le "langage métier".

C'est la croyance que je veux démonter ici : l'idée que si tu montres que l'équipe va mieux, ta valeur va de soi. Non, ta valeur a quand même besoin d'être traduite. Et si tu le fais pas toi-même, personne le fera à ta place, surtout pas la personne qui regarde ta ligne dans le budget.

Comment prouver la valeur d'un Scrum Master ?

C'est montrer, avec les unités que la direction utilise déjà (revenus, coûts, délais, risque), ce qui a changé parce que tu étais là.

Toute la différence est dans le verbe : "j'ai animé 14 rétros" décrit ton activité, "le coût d'un item livré a baissé de 20% depuis janvier" décrit un résultat que quelqu'un peut répéter dans une réunion où t'es pas là.

Le pont entre ton travail et les finances de l'entreprise, c'est le temps (les story points ou la vélocité ne sont pas le langage du directeur financier) : le temps qu'il faut pour que le travail sorte, et ce que ce temps coûte. C'est ce que j'appelle traduire ton travail en langage business, et c'est une version de l'angle mort qui m'a déjà coûté un emploi : du bon travail, sans aucun chiffre qui remonte jusqu'à ceux qui décident.

Ton salaire est fixe. Le coût de ce que l'équipe livre dépend de toi.

Voici le cœur du mécanisme. Après j'irai dans le détail...

Un Scrum Master a un coût fixe. C'est dans les dépenses opérationnelles de l'entreprise, au même titre que n'importe quel développeur de l'équipe. Il coûte le même prix de janvier à décembre, qu'il ait fait un travail exceptionnel ou pas. Ce prix-là reste fixe.

Ton levier, c'est le coût unitaire du travail terminé.

La masse salariale de ton équipe est à peu près fixe sur un trimestre. Si l'équipe termine plus d'items avec les mêmes personnes, chaque item coûte moins cher. Si moins d'items reviennent en correction, on arrête de payer plusieurs fois pour le même travail. Si le travail sort plus vite, ce qu'il rapporte arrive plus tôt.

C'est ça que la direction peut lire : le prix de chaque chose livrée.

Un exemple (chiffres fictifs) : une équipe de 7 personnes coûte à l'entreprise environ 58.000$ par mois, toi compris.

• Au 1er trimestre, elle termine 20 items par mois. Chaque item livré coûte donc 2900$
• Au 3e trimestre, elle en termine 26 par mois, avec exactement les mêmes personnes. Chaque item coûte maintenant 2230$ environ.

À dépense égale, l'entreprise "achète" maintenant 30% de travail terminé en plus. Ça, c'est une phrase qu'un contrôleur de gestion peut lire sans traduction.

J'ai eu la version douce de cette conversation avec un de mes managers, en fin d'année :

Oui, mais de combien est-ce que t'as réduit le cycle time de l'équipe ?

Il me donnait déjà une unité mesurable. Il me tendait la perche, en fait. Tout ce qu'il manquait, c'était la dernière marche : relier ce délai à ce qu'il coûte et à ce qu'il rapporte.

Comme un food truck à l'heure du lunch

Imagine un food truck avec 2 personnes à bord. Elles coûtent le même salaire, qu'il y ait 3 clients ou 50 dans la file. Le proprio regarde une seule chose : combien d'assiettes sont sorties par la fenêtre à l'heure du lunch, et combien sont revenues car la commande était mauvaise.

Si la file avance assez vite pour servir 120 assiettes au lieu de 80, avec le même salaire, chaque assiette coûte beaucoup moins cher à faire, et le camion encaisse 40 repas de plus pendant la même heure de pointe.

C'est comme ça que je vois la position du Scrum Master : la 2e personne dans le camion, c'est toi. Les assiettes renvoyées, c'est les livraisons qui reviennent en correction. Ce qu'on regarde, c'est combien sortent par la fenêtre, et à quel coût par assiette. Ton travail est de faire avancer la file (sans retour), augmenter le compte d'assiettes et la valeur réalisée, et autonomiser ton équipe à le faire par elle-même.

Un angle mort même chez les très bons Scrum Masters

C'est la partie la moins intuitive. C'est celle qui m'a eu. Plus t'es bon dans le métier, plus tu passes de temps dans l'équipe, là où le travail se fait, et moins tu en passes dans la pièce où on parle d'argent. Et quand ça va bien, on voit pas le problème : c'est exactement pour ça que je n'avais rien préparé le jour où la question est tombée.

Les 4 leviers business qu'un VP comprend sans traduction

Ton VP lit un compte de résultat : ce qui entre, ce qui sort, ce qui reste. Pour lui parler, 4 leviers suffisent, avec une phrase prête pour chacun. Les 3 premiers reprennent la logique du "Througput Accounting" de Goldratt (ce que le système produit, ce qu'il garde en stock, ce qu'il coûte à faire tourner), traduite pour une équipe de développement.

La vélocité n'en fait pas partie. Sans unité monétaire, elle change de sens chaque fois que l'équipe réestime, et n'importe quelle équipe peut la gonfler en un sprint. Out.

1. Le coût des opérations : ce que coûte chaque chose livrée

Même mécanisme que pour le food truck. La masse salariale ne bouge pas, alors tout ce que l'équipe termine en plus, et tout ce qu'elle arrête de refaire, fait baisser le coût de chaque livraison.

Deux sources de gains à regarder : combien d'items l'équipe termine par semaines, et combien reviennent en correction. Une livraison refaite, c'est du travail payé plusieurs fois.

Au lieu de dire :

L'équipe a livré 52 points ce sprint.

Dis plutôt :

Ces 3 dernières semaines, l'équipe a terminé 26 items avec les mêmes personnes qu'au trimestre dernier. Avant, c'était 20 items en moyenne. Chaque item livré nous coûte environ 25% de moins.

2. Le coût de l'inventaire : l'argent qui dort

14 items commencés et pas finis (le fameux carryover), vu depuis les finances, ça ressemble à 14 petits investissements qui ont tous coûté des heures et qui ne rapportent rien tant qu'aucun n'est livré. C'est la même logique qu'un stock qui dort dans un entrepôt : payé, pas encore vendu. Cette analogie d'entrepôt vient du Lean (gestion du développement de produit de Reinertsen), pas de la comptabilité : ton travail en cours n'apparaît nulle part comme un stock dans les états financiers. Mais n'importe qui aux finances comprend l'idée en 10sec, et c'est une ligne facile à sous-estimer.

Au lieu de dire :

On a trop de travail en cours.

Dis maintenant :

On a 14 items commencés et pas finis. C'est des heures déjà payées qui ne rapporteront rien tant qu'on ne les termine pas.

3. Accélérer la valeur : chaque semaine d'attente a un prix

Plus le travail sort vite, plus tôt il commence à rapporter : des revenus si la fonctionnalité vendue est déployée, des gains si c'est un outil interne. Reinertsen a aussi popularisé l'idée inverse : chaque semaine où une capacité attend a un coût. J'ai détaillé une façon simple de le calculer pour ton équipe dans le retard est gratuit sur papier, je la refais pas ici.

Parfois, c'est pas évident de savoir combien une fonctionnalité rapporte exactement. Mais il y a bien une personne en face qui le sait mieux que toi. Donne-lui le délai gagné, elle fera la multiplication.

Au lieu de dire :

Notre vélocité augmente de plus en plus.

Dis lui :

Une fonctionnalité typique met maintenant 12 jours à sortir au lieu de 21. Ce qu'elle rapporte commence 9 jours plus tôt. À l'échelle du projet c'est 2 mois d'avance sur l'échéancier.

4. Réduire le risque : une fourchette fiable plutôt qu'une date inventée

La direction engage des budgets et des promesses sur tes dates. Une date qui glisse, c'est un risque qu'il porte devant son propre patron. Une fourchette calculée sur ce que l'équipe a réellement livré donne quelque chose sur quoi s'engager sans se griller. Cette façon de prévoir, je la dois aux travaux de Daniel Vacanti et Troy Magennis. J'en montrais le calcul à la main dans mon édition sur le carryover.

Au lieu de dire :

On pense finir en mars.

Dis à la place :

Sur la base de ce que l'équipe a réellement livré ces 12 dernières semaines, on a 85 % de chances de livrer avant le 15 mars, et à peu près une chance sur deux avant le 1er.

Ce qu'on comprend mal sur la valeur d'un Scrum Master

"Il faut calculer un coût par story point "

Ça paraît logique : on connaît le coût de l'équipe, on connaît le nombre de points, on divise. J'ai trouvé souvent cette pratique sur internet. C'est le piège parfait. Les points sont estimés par l'équipe elle-même. Dès qu'un coût y est attaché, les points gonflent (comme dit Goodhart : une mesure qui devient un objectif cesse d'être une bonne mesure) et un directeur te démonte ça en une seule question : "Donc si l'équipe estime 2 fois plus gros, on devient 2 fois plus productifs ?". Fais-toi une faveur, évite cette discussion embarrassante et parle en items terminés.

"Il faut attribuer des revenus à chaque fonctionnalité"

Ça paraît être la preuve ultime : "cette fonctionnalité doit rapporter 400.000$". Sauf que dans une grande organisation, une fonctionnalité rapporte presque toujours avec une combinaison d'autres facteurs et équipes. Le marketing, les ventes, le prix, le moment du marché : tout se mélange. Si tu revendiques un revenu, la première personne qui connaît les chiffres va te demander comment tu l'as isolé, et tu n'auras probablement pas de réponse. Et je parles même pas des fonctionnalités techniques...

Parle plutôt d'acquisition, de rétention, de délai avant que la valeur commence, et relie-les à un objectif que ta direction s'est déjà fixé (c'est l'approche Evidence-Based Management). Tu restes crédible parce que tu revendiques que ce que tu peux défendre.

"Si je n'ai pas le chiffre exact, je n'ai rien à dire"

Devant le VP, je n'avais aucun chiffre, et je n'ai pas su répondre. Une estimation honnête vaut mieux que ce silence-là.

Entre 15 et 25 % de coûts en moins par item livré, selon comment on compte la maintenance.

C'est une phrase qui tient devant un contrôleur.

Comment prouver ta valeur de Scrum Master cette semaine

Une seule chose, et c'est la plus petite.

Prends le premier levier, le coût des opérations : c'est celui que tu peux sortir de ton outil préféré en 15 min. Il te faut le nombre d'items terminés par semaines sur les 2 derniers trimestres. Divise la masse salariale approximative de l'équipe (demande-la à ton manager, ou prends une estimation raisonnable et dis-le) par ce nombre. Tu as ton coût par item livré, avant et après.

Écris ensuite ta phrase reformulée, avec tes vrais chiffres. Une seule phrase.

Et utilise-la dans ton prochain 1:1 avec ton manager, pour lui donner quelque chose qu'il peut répéter le jour où quelqu'un, dans une pièce où tu n'es pas, lui demandera à quoi tu sers.

Comment ça se connecte

Cet article est le point de départ d'une série sur la dimension Business du métier de Scrum Master. Si tu veux aller plus loin tout de suite :

• Tu parles agile, il pense budget. Personne ne traduit. pose les 4 questions avec lesquelles le management évalue ton travail. Cet article-ci descend d'un niveau : de la question au levier.
• Il sait ce que tu coûtes. Il ne sait pas que tu es gratuit. calcule le coût du statu quo : ce que ça coûte de ne rien faire. Ici, on parle du coût de chaque chose livrée. Les deux se combinent bien.
• L'Impediment Value Calculator te donne la valeur d'un blocage résolu, en dollars, en quelques minutes.
• Et si ton équipe devient autonome au point que ton rôle semble superflu, le paradoxe de l'autonomie explique pourquoi c'est précisément le moment où cette traduction devient vitale.

T'en es où, toi, sur la dimension Business ?

Le SM Survival Score mesure ta position sur 5 dimensions : Visibilité, Preuves, Business, Autonomie, Stratégique. La dimension Business, c'est exactement ce dont parle cet article : ta capacité à relier ton travail à ce que la direction regarde.
5 minutes, et tu sais si c'est ton angle mort.

Et toi, si ton VP te posait demain la question qu'on m'a posée ("mais concrètement, quel est ton impact sur la transformation ?"), quelle ligne de ton travail il ne voit pas encore aujourd'hui ?

FAQ