Mesurer l’Activité vs Mesurer les Résultats

 

Lisez la transcription :

Nous testons la retranscription de nos podcasts à l'aide d'un programme informatique. Veuillez nous excuser pour les éventuelles fautes, le robot n'est pas encore fiable à 100%.

Galen Low : Question surprise : vous êtes à mi-chemin de votre projet et tous vos indicateurs sont excellents. Votre prestataire a passé le nombre d'heures convenu et la vélocité et l’utilisation de votre équipe sont exactement conformes à vos prévisions.

Pourtant, même si votre projet semble en excellente santé, le produit continue de manquer sa cible dans les focus groupes et les tests utilisateurs. La technologie sur laquelle votre sponsor exécutif insistait devient rapidement obsolète, ce qui rend difficile toute adaptation. Et le moral de votre équipe est bas : lorsque vous leur demandez des solutions, ils haussent les épaules et disent avoir fait ce qu’on leur a demandé dans le temps imparti.

Alors, comment se fait-il que votre projet soit en bonne santé alors que ses livrables n’apportent pas la valeur escomptée ?

Si vous vous rendez compte que vos indicateurs de projet mesurent davantage l’activité que la valeur, restez à l’écoute. Nous allons plonger dans les aspects pratiques de la manière dont les équipes projets peuvent mesurer la valeur et explorer des pistes pour déplacer l’incitation des heures passées vers la valeur créée.

Bonjour à toutes et à tous, merci de nous écouter. Je m'appelle Galen Low et je fais partie du Digital Project Manager. Nous sommes une communauté de professionnels du digital en mission pour nous entraider à gagner en compétences, en confiance et à élargir notre réseau, afin d'amplifier l'importance de la gestion de projet dans un monde numérique. Si cela vous intéresse, rendez-vous sur thedigitalprojectmanager.com.

Très bien. Aujourd'hui, nous allons parler de la différence entre mesurer la santé du projet et le suivi de son avancement, versus mesurer le succès du projet. Est-il suffisant de suivre la vélocité de l'équipe et la performance des coûts ? Ou est-ce aussi de notre responsabilité, en tant que chefs de projet, de mesurer les résultats et l'impact du projet ?

J’accueille aujourd’hui Fred Fowler — Scrum master niveau 3 certifié, auteur de plusieurs ouvrages sur la méthodologie Scrum, organisateur du meetup Silicon Valley Professional Scrum qui compte près de 2 000 membres, leader d’une communauté Scrum en Chine à Shanghai, et organisateur du tout premier sommet Silicon Valley Scrummit. En d’autres mots, quelqu’un qui s’y connaît vraiment en Scrum.

Bienvenue Fred !

Fred Fowler : Bonjour ! Merci de m’accueillir dans votre émission.

Galen Low : Ravi de vous avoir avec nous.

Fred Fowler : Je me présente souvent comme un gars scrum. Bien que certains disent que je suis « scrumcieux ».

Galen Low : Eh bien, c’est sans doute mieux que moi qui dirais Fred « scrum-of-the-earth ».

Fred Fowler : On peut s’amuser de toutes sortes de façons avec le mot scrum. On peut inventer plein de jeux de mots. Bref, allons-y. Continuez.

Galen Low : Effectivement. Génial. Vous avez un parcours vraiment intéressant, et je pense que cela donnera beaucoup de perspective à nos auditeurs sur votre vision des indicateurs projets. Si je ne me trompe pas, vous avez débuté comme programmeur informatique, puis vous êtes passé par la politique, êtes devenu maire, ensuite DSI, avant de mettre à contribution votre rarissime certification Scrum niveau 3 pour aider les autres.

Je me demande, pourriez-vous nous raconter un peu votre parcours, et comment vos expériences ont modifié votre façon de voir les choses aujourd’hui ?

Fred Fowler : Eh bien, je pourrais dire que ma carrière a ressemblé à une bille dans un flipper.

J’ai commencé comme programmeur en 1980. À l’époque, je travaillais sur une machine si grosse et lourde qu’elle nécessitait un appareillage spécialisé pour l’installer et était moins puissante qu’un smartphone actuel. Mais nous faisions tourner une division d'une société de semi-conducteurs dessus et c'est là que j'ai appris mon métier.

Puis, j’ai changé de voie, parce que c’était la Silicon Valley à ses débuts, synonyme de beaucoup de volatilité. Durant les huit premières années de ma carrière, j’ai travaillé pour cinq entreprises différentes : c’était incroyable, je le répète, très instable. Finalement, je me suis dit que j’avais besoin de sécurité, alors autant travailler à mon compte.

Je suis devenu consultant et j’ai travaillé pour 60 entreprises différentes en 10 ans. Toujours à essayer de mettre la technologie au service des problématiques business, c’est-à-dire l’essence même de ce métier. Puis, une société pour laquelle je consultais m'a fait une offre irrésistible. Résultat : j'ai géré leur service IT, je suis devenu DSI et j’ai implémenté beaucoup de techniques qui aujourd’hui relèvent de Scrum, même si je ne le savais pas ; donner du pouvoir aux gens pour résoudre les problèmes, justifier le travail par le retour sur investissement …

À cette époque, j’ai mené beaucoup de projets qui ont façonné ma conception de l’organisation. J’en suis fier. Par exemple, la société avait tenté de construire un site e-commerce avec un célèbre éditeur international (indice : trois lettres), pour 250 000 dollars, sans succès. J'ai vu là une grande opportunité d’amélioration. J’ai donc mené un projet — en Scrum.

Nous avions deux technologies différentes : l’arrière-plan était un mini-ordinateur IBM AS/400 ; il fallait une interface web. Je suis parti en Chine, j’y ai trouvé une jeune entreprise ambitieuse qui allait créer le front-end. L’équipe US faisait le back-end, l’équipe chinoise le front, il ne restait plus qu'à les faire communiquer.

Ça s’est révélé assez simple. Résultat : nous avons remplacé le site bâclé à 250 000 dollars par un nouveau site web qui, en six mois, réalisait 40% du chiffre d’affaires de l’entreprise, pour… 14 000 dollars ! Voilà. On a laissé des experts résoudre le problème, partout dans le monde. Il faut juste bien gérer les interfaces entre eux.

Galen Low : Voilà, des équipes légères, un contrat de données, et c’est parti.

Fred Fowler : Exactement. Et la clé, c’est vraiment de comprendre ce qu'il faut mesurer.

Quand on parle d’équipes offshore, tout le monde panique : « Mais comment savoir ce qu’ils font ? » On veut toutes sortes d’outils pour mesurer à quel point ils travaillent, à quel point ils sont occupés. Parce qu’on veut qu’ils soient occupés en permanence.

N’est-ce pas ? Eh bien, devinez quoi ? Cela n’a aucune importance. Peu importe que les équipes offshore soient occupées ou pas, ce n'est pas pertinent. Ce qui compte, c'est ce qu'elles livrent réellement, la valeur de ce qu'elles produisent. Voilà ce qu'il faut mesurer ! Oubliez le chronométrage des gens, cela ne sert à rien …

Prenons un exemple : une équipe de plus de 200 personnes travaille 8 à 10 heures par jour pendant 2 ans versus une équipe de 5, 6 ou 10 personnes travaillant des horaires réguliers pendant un an. Selon vous, qui livre le plus de valeur ? Eh bien, les 200 personnes ont conçu le site healthcare.gov (site américain pour la santé), qui a été un fiasco total.

Il devait mettre en place l’ObamaCare, mais il s’est écroulé car ces 200 personnes étaient évaluées sur leur niveau d’occupation. Ensuite, une équipe de 10 personnes en un an a tout réécrit et fait fonctionner le site, créant beaucoup plus de valeur que l’équipe précédente.

Galen Low : Justement, parlons-en, c'est un point crucial. Vous évoquez une raison pour laquelle on mesure l'activité mais dans le milieu des agences et des cabinets, tout est basé sur les heures facturables, l’utilisation, le nombre de bugs corrigés, de tâches terminées. Pourquoi donc cette obsession pour mesurer l’activité ?

Fred Fowler : C’est simple : parce que c’est facile à mesurer. Il suffit d’une horloge. On utilise un calendrier pour vérifier si les échéances sont respectées, c’est facile et, d’ailleurs, c’est la base de la rémunération.

Vous avez parlé des heures facturables, c’est un énorme mythe : croire que le temps des gens est précieux. Leur temps compte pour eux, mais pour vous ce qui compte c’est ce qu’ils font de ce temps. Ce serait bien mieux si le monde disposait d’un bon indicateur pour mesurer le résultat du temps passé.

Et moi, dans mes discussions avec les entreprises, j’essaie de leur expliquer qu’il faut surtout tenir compte de la valeur de ce que vous souhaitez créer et la diviser en parties mesurables, puis suivre l’avancement sur cette base. Dans le lean, il y a la notion de produit minimum viable.

On développe juste assez pour avoir quelque chose à mettre entre les mains du client. Savez-vous pourquoi c’est pertinent ? Parce que ce « quelque chose » a de la valeur et le client peut vous en faire part. Dès lors, vous pouvez jauger si la valeur créée valait l’effort investi.

Si vous développez une appli qui coûte 500 000 dollars à construire, est-ce un bon investissement ? Cela dépend. Si elle est téléchargée 3 millions de fois à 2 dollars, vous avez généré 6 millions avec 500 000 d’investissement : bonne opération. Si, avec le même coût, il n’y a que 25 000 téléchargements à 2 dollars, cela ne fait que 50 000 — effort identique, heures facturables identiques, mais la valeur résultante n’est pas la même. Ce qui compte au final c’est la valeur générée.

Galen Low : J’adore ce que vous dites sur le produit minimum viable. On mesure parfois l’activité par manque de confiance envers les gens, mais cela ne mesure pas la valeur. Beaucoup me disent : « Il nous faut les heures facturables, sinon pas de contrat, ni de compensation ». Mais comme vous l’indiquez avec le produit minimum viable, il s’agit d’investir, de livrer, puis de voir la valeur constatée côté client. Ce n’est jamais garanti à l’avance ! J’ai 50 000 dollars, je construis ma solution, mais je ne suis pas certain qu’elle créera la valeur espérée à la fin…

Pensez-vous que c’est un mal nécessaire pour faire tourner le business, ou devrions-nous dépasser ce modèle ?

Fred Fowler : D’une certaine façon, c’est un mal nécessaire. Mais il faut recadrer les gens en comparant leurs coûts avec la valeur créée. Dans le framework Scrum, il faut avoir livré un produit fini, prêt pour le client à chaque sprint. Pourquoi pensez-vous que c’est si important ?

Galen Low : Peut-être justement pour qu’on puisse mesurer la valeur ?

Fred Fowler : Exactement. La seule fois où quelque chose prend de la valeur, c’est lorsque c’est terminé et livrable au client. Voilà comment on mesure la valeur : par le montant que le client est prêt à payer. Scrum impose que toutes les deux semaines, on crée quelque chose de valeur pour le mesurer et comparer ce résultat au coût de production.

Ainsi, vous savez à l’avance si vous êtes sur la bonne voie (créer un produit d’une valeur de 6 millions pour 500 000 d’investissement ou non). Il faut fragmenter pour que chaque morceau ait une valeur mesurable, et non estimative.

C’est ce sur quoi Scrum insiste : des décisions guidées par la mesure, pas l’intuition. Et la chose la plus importante à mesurer, c’est la valeur.

Galen Low : Pourriez-vous nous guider dans cette évaluation de la valeur ? Si mesurer l’activité ne sert à rien, quels sont les indicateurs qu’une équipe doit suivre ? Et qui juge la valeur d’une livraison sprint après sprint ? Et comment le suit-on ?

Fred Fowler : D’abord, dans le Scrum, la mesure de la valeur n’appartient réellement qu’à une seule fonction : le Product Owner. Scrum répartit les responsabilités en trois rôles : propriétaire du produit, développeurs, scrum master.

La mission du Product Owner est de maximiser la valeur du travail de l’équipe. Cela implique de pouvoir la mesurer. Impossible d’optimiser sans mesure. Il faut un étalon.

On peut augmenter la valeur de quatre façons : la plus courante, c’est le revenu. Un exemple : vendre une appli téléchargée pour 2 dollars par 3 millions de clients, valeur = 6 millions. Autre façon, réduire les coûts.

Si vous fabriquez un million d’objets/an et que vous baissez le coût unitaire de 0,50 dollar, c’est 500 000 dollars gagnés. Troisième : réduire les risques (je l’ai fait en tant que DSI : on a sécurisé le datacenter et éliminé le risque d’une coupure annuelle coûtant 1 million de dollars, le tout avec un investissement de 50 000 $).

Galen Low : Seulement 50K pour déplacer un datacenter ? Incroyable.

Fred Fowler : Oui.

Galen Low : J’aurais dit oui aussi !

Fred Fowler : On a juste loué des racks dans un site ultra sécurisé… Bref, réduire le risque, c’est de la valeur. Enfin, la quatrième façon consiste à augmenter les opportunités. Exemple : passer d’un succès sur six appels d’offres à deux sur six, et calculer la différence.

Galen Low : Donc le Product Owner mesure la valeur selon ces quatre leviers et fait redescendre l’info auprès de l’équipe… Comment cela fonctionne-t-il dans la pratique ?

Fred Fowler : Effectivement, le product owner mesure, décide ce sur quoi l’équipe se mobilise. On ne mesure pas la valeur de ce qui n’existe pas encore ! Il doit donc deviner ce qui pourrait être précieux (c’est un pari, comme l’achat d’actions). Puis l’équipe délivre, et c’est au client d’estimer la valeur. On la mesure ensuite, on ajuste la stratégie d’investissement dans la suite.

C’est une question de rendement sur investissement. Si le sprint a coûté 50 000 dollars, génère-t-il plus de valeur pour le client ? Même les développeurs devraient se soucier de cette équation, car elle conditionne leur rétribution.

Galen Low : Résumé parfait ! Souvent, on se focalise sur « J’ai fait mes 80 heures, on doit me payer » … alors qu’on piège soi-même son projet ! C’est un échange de temps contre argent, pas de valeur.

Fred Fowler : Exactement. Et une fois qu’on a compris cela, les développeurs réalisent qu’ils sont directement concernés par la création de valeur.

Il y a un véritable partenariat entre Product Owner et équipe de développement. Le product owner désigne la direction business, les développeurs l’exécution technique. Ils négocient pour décider quoi faire, de la façon la plus efficace et la plus précieuse possible. Scrum instaure une vraie négociation basée sur ces deux expertises.

Galen Low : J’adore le terme partenariat. Beaucoup voient cela d’abord comme une relation de servitude : le product owner décide, l’équipe exécute… alors que non ! Scrum, c’est d’abord l’autonomisation, la négociation sur la valeur business versus la faisabilité technique.

Fred Fowler : Oui, et l’équipe de développement peut avoir une vraie influence sur les coûts, parfois par des actions contre-intuitives. Imaginons qu’on doit développer une fonction d’authentification utilisateur. Plutôt que de développer tout un système de login, les développeurs pourraient proposer : « Pourquoi ne pas utiliser Sign in with Google ou Facebook ? » Ce sont des solutions déjà prêtes, très fiables, qui permettent d’éviter de refaire ce qui existe.

Le but du Product Owner est de résoudre un problème business, pas d’imposer la solution technique. L’équipe propose les options les plus efficientes. La négociation sert à choisir la solution la plus facile qui soit aussi la plus précieuse pour le client, le tout segmenté de façon à pouvoir mesurer la valeur créée à chaque étape.

Galen Low : J’avoue avoir mesuré l’activité… même la vitesse (vélocité), les burndown charts. À quoi ressemblent les discussions dans vos équipes scrum autour de la valeur ? Est-ce que le PO revient en disant « On visait 65 $, mais le marché ne paie que 60 » ? Est-ce qu’on ajuste les objectifs, ou est-ce juste un recalibrage progressif sprint après sprint ?

Fred Fowler : Cela se ramène à la question de la rémunération. Quand tout le monde est payé à l’heure, ça pousse à faire compliqué et à occuper le temps. Certaines grandes entreprises mondiales l’ont appris à leurs dépens : deux ans, 500 millions de dollars, et à la clé… zéro valeur, malgré une activité frénétique ! Toute cette agitation n'a produit que du code à jeter et pas de résultat.

Concernant la compensation, il y a deux dimensions : attirer les talents et récompenser la valeur. Il faut certes payer le taux de marché pour recruter, mais pour motiver la production de valeur, le plus pertinent serait d’en reverser une part à l’équipe. Si une équipe crée 100 000 dollars de valeur, l’entreprise pourrait en reverser 20 % à répartir entre ses membres, selon leur propre appréciation de la contribution de chacun. Ce système valorise l’apport réel et crée une dynamique de groupe profitable.

Galen Low : C’est un modèle voisin de la participation aux profits ! Mais effectivement, la répartition optimale de la rémunération, c’est d’abord un salaire d’entrée, puis un bonus basé sur la valeur produite et mesurée objectivement.

Fred Fowler : Exactement, c’est ça qui aligne les bons leviers d’incitation. C’est aussi ce que Scrum fait bien : placer la décision au bon endroit et le contrôle dans les mains des personnes capables et responsables.

Le Product Owner est un investisseur. C’est lui qui décide de l’allocation du temps : à lui ensuite d’être jugé sur les résultats. Il doit assumer les conséquences de ses décisions. Même logique pour l’équipe : elle doit s’auto-organiser, personne ne doit lui dire quoi faire. Les développeurs en général détestent ça, pourtant cela leur donne la possibilité d'être responsables de leur réussite — ou de leur échec.

Galen Low : Notre secteur n’a pas suffisamment favorisé la responsabilisation: souvent, on nous dit quoi faire et basta…

Fred Fowler : C’est contre-productif, car aucune leçon n’est retenue par les décideurs. Scrum impose que les équipes soient auto-organisées ET pluridisciplinaires. Si une équipe ne peut pas mener à bien une livraison de bout en bout, cela ouvre la porte au renvoi de responsabilité. Mais si elle gère tout elle-même, plus d’excuses possibles.

Ensuite, elle doit s’auto-gérer. Car sans liberté de décision, elle peut toujours blâmer un autre, tandis que ceux qui donnent les ordres apprennent peu des échecs. On dit souvent « Rien n’est impossible quand ce n’est pas vous qui le faites. »

On nous a tous demandé l’impossible. Moi aussi !

Galen Low : Drôle… C’est vraiment l’équilibre entre l’autonomie et la responsabilité, qu’il faut construire !

Fred Fowler : Oui, mais c’est aussi la capacité. L’autonomie et la responsabilité ne veulent rien dire sans la compétence. Le Product Owner doit pouvoir investir des centaines de milliers voire des millions de dollars pour créer de la valeur. Les développeurs doivent pouvoir créer le produit ensemble pour être responsables de la réussite. C’est le défi du Scrum Master : faire travailler l’équipe comme un vrai collectif, lui inculquer la prise de responsabilité.

Un levier tel qu'une rémunération liée à la valeur créée peut aider : « Si on ne fait pas de bon travail, on n’aura pas de bonus » !

Galen Low : J’aime ça : « Mesurer la valeur et récompenser la valeur. »

Fred Fowler : Oui, et j’ajoute ceci : un produit doit avoir une valeur mesurable. Si sa valeur est impossible à mesurer, ce n’est pas un produit, et aucune décision rationnelle ne peut être prise.

J’ai travaillé pour une société qui avait une appli web financière segmentée en trois : front, API, back-end. Chacun avait son propre Product Owner … ce qui générait des conflits de priorités, allant jusqu’à bloquer des mises à jour cruciales pendant deux ans ! La chaîne de valeur doit être considérée dans sa globalité, avec un seul Product Owner pour éviter perte de temps et tensions : c’est la seule façon de mesurer la vraie valeur créée.

Galen Low : Parfois, la politique interne est l’obstacle majeur à la création de valeur !

Fred Fowler : Exactement. Surtout si la valeur n’est pas mesurable. On avance alors au hasard, sans repère rationnel…

Galen Low : On parle aussi d’expérience minimum viable : il faut scinder le produit verticalement, pas horizontalement, sinon on rate la chaîne de valeur totale … Ce que vous dites, c'est qu’il existe des équipes qui pensent ne pas pouvoir faire du Scrum ou de l’incrémental, mais c’est juste qu’elles ne voient pas leur livraison comme un vrai produit — il faut adopter cet état d’esprit !

Fred Fowler : Oui, c’est même validé par Jeff Sutherland (co-créateur de Scrum) : un produit est quelque chose ayant une valeur objectivement mesurable, sans opinion. On mesure la valeur d'un produit en le vendant, en le monnayant auprès du client. Si personne ne veut de votre livraison, ce n’est pas un produit, mais une sous-partie ; et c’est ce produit « global » qui doit guider la priorisation.

Galen Low : Une dernière question : au-delà de Scrum, cette philosophie s’applique-t-elle à d'autres méthodes ? Quels conseils pour ceux qui ne sont pas scrum ?

Fred Fowler : D'autres méthodes? Oui ! Scrum n’est qu’une couche parmi d’autres. L’Agile également. Scrum vise à faire des produits sans suivre une recette trop rigide. Le modèle Waterfall est basé sur le plan, la recette … mais dans la pratique, tout change. Un exemple : Roman Pichler, dans « Agile Product Management with Scrum », raconte un projet de deux ans parfaitement exécuté… mais dont le livrable était déjà obsolète avant même d’être déployé ! Les recettes toutes faites ne fonctionnent pas.

Au fond, quelle que soit la méthodologie, le cœur, c’est d'avoir des personnes qualifiées, responsables de leurs décisions business/produit, capables de délivrer et de s’auto-organiser. Ajoutez à cela la capacité à mesurer l’avancement produit incrémentalement — c’est l’esprit Scrum, Kanban, Lean, tout ce que vous voulez !

En clair, peu importe le framework, du moment que vous mesurez la valeur et non l’activité, les résultats et non les outputs, et que vous en tirez des enseignements. C’est cela, la voie du succès.

Galen Low : Voilà, vous avez tout résumé.

Fred, vous parliez de votre meetup et de vos livres. Où les auditeurs peuvent-ils retrouver ces ressources ?

Fred Fowler : J’anime depuis 2015 un meetup sur Scrum, intitulé Advanced Scrum Case Studies. Toutes les deux semaines, nous nous réunissons en ligne. Je publie au préalable un cas, souvent une problématique de gestion de projet Scrum (ex : offshore, mesure de la valeur...). Rejoignez-nous : recherchez Silicon Valley Professional Scrum meetup sur Meetup, puis Advanced Scrum Case Studies. Nous serions ravis de vous accueillir. Ce groupe a généré beaucoup de matière. J’ai compilé 60 cas en notes, dont 15 repris dans mon livre disponible sur Amazon et sur mon site www.siliconvalleyscrum.com. Un deuxième volume est en préparation, avec encore 15 cas supplémentaires.

Galen Low : Je n’avais pas réalisé que le livre compilait les discussions du meetup, c’est très cool !

Merci beaucoup Fred d’avoir accepté cette invitation. J’ai adoré vos anecdotes, vos perspectives, notre conversation sur la rémunération (qui mériterait un épisode dédié !). J’espère que les auditeurs en tireront beaucoup de valeur. Merci.

Fred Fowler : Merci, ce fut un réel plaisir d’échanger avec vous.

Galen Low : Et vous, qu’en pensez-vous ?

Est-il possible pour une équipe projet de s’orienter autour de la création de valeur, plutôt que les heures ou les user stories bouclées ? Ou sommes-nous trop dépendants du modèle monétaire par heures travaillées ?

Partagez vos expériences : quels indicateurs ont été les plus pertinents sur vos projets ? Quels changements avez-vous observés en analysant vos données projet ?

Laissez-nous vos réflexions dans les commentaires ci-dessous !

Envie de développer vos compétences en leadership de projet stratégique ? Rejoignez notre collectif !

Rendez-vous sur thedigitalprojectmanager.com/membership pour accéder à une communauté bienveillante qui échange ses savoirs, relève ensemble des défis complexes et façonne le futur de notre métier.

Des modèles puissants, des formations mensuelles pour gagner du temps et de l’énergie, au soutien entre pairs via Slack, des événements en direct ou des masterminds, être membre de notre communauté c’est avoir plus de 1000 pros avec vous pour avancer et progresser dans la gestion de projets digitaux.

Vous avez aimé cet épisode ? Abonnez-vous et restez connectés via thedigitalprojectmanager.com.

À bientôt et merci de votre écoute !