Voici comment bien comprendre et optimiser la valeur d’affaires en quelques étapes faciles afin de maximiser le rendement de vos investissements à l’aide du cadre Scrum!

Scrum, c’est comme un hachoir à viande moderne et sophistiqué. Qu’on le compare à une méthode de hachage au couteau ou à un moulin manuel en fonte, ce cadre est conçu pour transformer votre « viande crue » en délicieuses galettes de viande que vos clients vont adorer. Grâce à un processus d’inspection et d’adaptation transparent, non seulement vous obtiendrez des galettes de la manière la plus efficace, mais vous aurez aussi une boucle de rétroaction rapide nécessaire pour améliorer votre production tout en allant de l’avant avec votre produit.

Comme pour le hachoir à viande, la qualité finale ne dépend pas uniquement du hachoir en soi. Vous choisirez bien sûr une viande de la meilleure qualité. De plus, tandis que la mise en place du processus Scrum est assez simple, la qualité et la valeur du produit livré dépendent en grande partie des gens y participant : c’est-à-dire l’équipe de développement, le Scrum Master et, bien entendu, le Product Owner.

L’objet de ce billet n’est pas de parler de la collaboration entre les différents rôles selon Scrum; vous pouvez vous reporter au Guide Scrum pour en savoir plus sur le sujet. Mon but ici est d’aborder le concept clé au cœur de tout modèle d’affaires : la valeur d’affaires. Votre capacité de la comprendre, de la mesurer et de l’utiliser pour ordonner et optimiser votre carnet de produit, c’est ce qui fera la différence dans la livraison de votre produit : soit des galettes savoureuses dont tout le monde raffole ou des bouts de viande immangeables dont personne ne veut.

La valeur d’affaires ou comment trouver votre « nord vrai »?

Le monde dans lequel nous vivons est rempli de choix : nos vies personnelle et professionnelle respectives débordent de « choses » que nous pouvons faire n’importe quand. Bien sûr, nous n’avons pas besoin de faire tous nos choix de la manière illustrée dans le diagramme de Venn suivant :

sa7juillet

Si vous avez deux éléments sur trois, ça ne peut simplement pas marcher! Disons que vous avez le temps de faire quelque chose et aussi l’argent nécessaire sans toutefois en avoir la capacité : les chances sont grandes que le résultat obtenu soit insatisfaisant. Le sweet spot se situe à l’intersection des trois cercles; nous devrions tenir compte de ceux-ci pour les choix importants que nous avons à faire.

C’est la même chose pour les affaires et les organisations. Sur une plus grande échelle, il faut définir la ligne de conduite qui vaut la peine d’être suivie. En tout temps, cette façon de faire devrait être le « nord vrai » auquel tout Product Owner se reporte lorsqu’il joue son rôle dans une équipe Scrum. Voici un diagramme de Venn similaire permettant de trouver le « nord vrai » d’une entreprise :

 

sa7juillet1

Comme Jeff Sutherland l’indique quand il décrit ces liens dans son livre Scrum : the Art of Doing Twice the Work in Half the Time :

« Si vous vous concentrez uniquement sur ce que vous pouvez créer, vous pouvez vous retrouver à fabriquer quelque chose dont personne ne veut, et ce, même si c’est quelque chose qui vous passionne. Si vous vous concentrez seulement sur ce que vous pouvez vendre, vous pouvez promettre quelque chose que vous n’êtes pas en mesure de fabriquer. Si vous fabriquez uniquement ce que vous pouvez vendre sans en avoir la passion, vous allez vous retrouver à travailler très fort pour créer quelque chose de médiocre. Cependant, au centre, dans cette zone d’impact, se trouve une vision ancrée dans la réalité — il s’agit d’une vision offrant une possibilité réelle de devenir quelque chose de grand. » (Traduction libre)

Voici votre « nord vrai » : la ligne de conduite qu’il vaut la peine de suivre. Une fois que vous l’avez trouvé, vous devez savoir qu’entre deux entreprises qui suivent la même direction celle qui obtiendra l’avantage réel sera celle en mesure de livrer plus tôt et mieux que n’importe qui d’autre. Et c’est exactement ce pour quoi Scrum a été conçu.

Le Product Owner ou comment livrer de la valeur dans l’ordre idéal?

Des milliers d’articles et de livres ont été écrits sur le sujet, ce qui indique l’importance de ce rôle dans toute équipe Scrum. Tandis que beaucoup de ces écrits nous offrent des nuances pertinentes, lorsqu’il est question de ce que l’on peut s’attendre du Product Owner, il y a quatre caractéristiques essentielles qui ressortent (selon Sutherland) :

  • Être bien informé (knowledgeable) — Savoir ce qui peut et ne peut pas être fait pour traduire les heures de travail en incréments significatifs dont la valeur est alignée sur le « nord vrai ». Lyssa Adkins utilise le terme « microdéfinitions de la valeur d’affaires » (business value microdefinitions) pour faire référence à ceci : équilibrer chaque aspect de la définition de la valeur d’affaires (rendement de l’investissement, profit, réduction des risques, connaissances acquises) afin de fixer le prochain jalon critique à court terme dans le but d’atteindre le « nord vrai » de l’organisation.
  • Avoir l’autorité nécessaire (empowered) — Prendre des décisions judicieuses et finales en ce qui a trait à ce qui doit être fait pour traduire la vision en un produit de qualité supérieure de manière itérative et incrémentale.
  • Être disponible (available) — Aider l’équipe à comprendre ce qui doit être fait et pourquoi il faut le faire.
  • Être responsable (accountable) — Avoir la responsabilité de la valeur finalement livrée.

Je n’ai pas détaillé les différents aspects puisque ça finit habituellement par des termes relatifs au flux monétaire (rendement de l’investissement, profit, réduction de coûts, investissement avec gain monétaire prévu au fil du temps, etc.).

Le client final : qui est-il et que souhaite-t-il vraiment?

Une fois que vous savez ce que vous pouvez faire et vendre et qu’en plus c’est une passion, vous devez maintenant penser à qui va acheter votre produit. Vous voulez plus qu’un client satisfait, qu’un acheteur d’un jour… Ce que vous désirez vraiment, c’est ce que Ken Blanchard appelle un raving fan (qu’on pourrait traduire par « fan fini »). Il définit ce type particulier de client comme suit : « il s’agit d’un client qui est tellement fidèle à vos produits et services qu’il ne penserait jamais à faire affaire ailleurs et qui n’hésiterait pas à chanter sur les toits combien vous êtes bons. »

Pour trouver ces fans finis, vous pouvez bénéficier d’un coup de pouce de la chance. Cependant, vous préférerez sûrement utiliser une approche plus empirique. Pour ma part, j’adore ce que Menlo Innovations a mis en place, comme le décrit si bien Richard Sheridan dans son livre intitulé Joy, Inc.: How We Built a Workplace People Love. En continuant de bâtir Menlo Innovations, Sheridan et son équipe ont réalisé que les méthodes traditionnelles (même les approches Agiles, mais dans une moindre mesure) comportaient de sérieuses limites dans leurs façons de créer des produits logiciels qui enchantent le client final.

Les sciences sociales, et plus précisément l’anthropologie, lui ont permis de combler l’écart. L’anthropologie (c.-à-d. la science de l’être humain) requiert l’observation des êtres humains dans leur milieu naturel afin de déceler leurs comportements, artefacts, interactions et systèmes sociaux. Un nouveau rôle a vu le jour, celui d’anthropologue high-tech. Celui-ci participe à tous les projets de Menlo. Il fournit à l’équipe des connaissances directes uniques qu’il a acquises en observant les utilisateurs finaux dans leur environnement naturel.

Par exemple, si vous avez à concevoir un logiciel de planification de mariage, l’anthropologue ira observer les activités à accomplir au cours des différentes étapes de la planification d’un mariage (salons de la mariée, églises, synagogues, boutiques de robes de mariée, pâtisseries, salles de banquet, etc.). Il observera les différentes personnes participant au processus de préparation de mariage et il discutera aussi avec elles.

Cette façon de faire est également alignée sur le principe Gemba Gembutsu Genjitsu issu du système de production de Toyota créé par Taiichi Ohno, qui indique que pour bien comprendre comment un travail se fait, il faut aller voir par soi-même directement là où il est réalisé.

Une fois cette phase initiale terminée, on crée des personas en se basant sur les observations. Chaque personnage doit être le plus précis possible. Supposons que vous voulez représenter une belle-mère. Il pourrait s’agir de Kathleen Turner, 52 ans. Celle-ci aidera à la préparation du mariage de sa bru. Elle n’utilise pas beaucoup son ordinateur. Ses objectifs sont de planifier le mariage du siècle, d’utiliser un ordinateur pour y arriver si cela lui permet de gagner du temps et d’éviter toute situation où elle se sent bête parce qu’elle ne comprend pas les termes utilisés.

Une fois plusieurs personnages créés, le Product Owner choisit le client final (un personnage précis qui sera probablement le plus enchanté par le produit) ainsi que deux ou trois cibles secondaires (que nous tenterons d’enchanter sans empiéter sur l’engouement du client final). Pourquoi un seul client final? Parce que si vous essayez de plaire à tout le monde, vous allez probablement finir par ne plaire à personne.

Grâce à l’anthropologie, on découvre certains besoins que l’utilisateur final n’aurait jamais soulevés dans un contexte artificiel (ex. : war room, salle de réunion, groupe de discussion, etc.). Essentiellement, vous observez cet utilisateur final afin de voir ce dont lui-même ne se rend pas compte. Puis, vous travaillez avec le Product Owner pour ordonner le carnet de produit en conséquence.

Le fait de connaître votre client final vous donne également une bonne idée de sa capacité à accepter le changement ainsi que du rythme optimal auquel il est prêt à l’intégrer. Il est parfaitement inutile de raccourcir la boucle de rétroaction à une journée s’il n’y a personne pour vous faire part de ses commentaires.

Par où commencer?

Vous êtes quasi prêt! Vous avez compris où se situe votre valeur d’affaires et vous savez qui est votre PO et qui est votre client cible. Il ne vous reste plus qu’à répondre à la question suivante : par où dois-je commencer?

Heureusement, la science économique ne manque pas de notions pertinentes pour vous aider à démarrer. Le but de ce billet n’est, bien sûr, pas de vous enseigner les notions de base de la microéconomie, mais plutôt de vous fournir des outils pour vous aider à démarrer rapidement. Un modèle en particulier émerge du lot, notamment en raison de ses racines solides ancrées dans la théorie scientifique : le modèle Weighted Shortest Job First ou WSJF (le plus court processus pondéré en premier).

Plus court quoi, pondéré comment?

Don Reinertsen, père fondateur du cycle Lean de développement de produits, a indiqué que si vous aviez à vous concentrer sur une seule variable lorsque vous ordonnez votre carnet de produit, la meilleure option serait le coût des retards. On peut résumer cette variable comme suit : combien ça nous coûte à titre d’entreprise de retarder la livraison de cet item particulier du produit fonctionnel au client final? Il faut la pondérer en fonction de la durée du retard afin d’avoir une base significative de comparaison des éléments. On utilise le modèle WSJF dans Scaled Agile Framework® (SAFe®) afin de prioriser les tâches lorsqu’on détermine le contenu du prochain Agile Release Train (ART).

La formule est la suivante :

sa7juillet2
Scaled Agile®, SAFe 4.0

User-Business Value — Cette valeur représente précisément ce que vous avez compris à ce jour.

Time Criticality — Cette valeur-ci est un peu plus complexe. En résumé, on peut dire que c’est la dégradation naturelle de la valeur d’un élément au fil du temps aux yeux du client. Par exemple, une fonctionnalité conçue pour aider à la vente d’articles de Noël perd énormément de valeur aux alentours du 24 décembre.

Risk Reduction|Opportunity Enablement Value — Il s’agit de l’avantage « caché » (ou moins apparent) de la fonctionnalité. Est-ce que cette valeur nous aidera à réduire considérablement le risque (et les coûts potentiels liés à sa matérialisation) pour le produit dans son entièreté? Nous permettra-t-elle d’identifier des occasions d’affaires ayant une plus grande valeur que ce que nous faisons actuellement? En apprendrons-nous suffisamment pour réduire considérablement les coûts supplémentaires de développement du produit? Etc.

Puisque nous parlons de toutes les valeurs et réductions potentielles et futures, il vaudrait mieux utiliser les valeurs relatives pour déterminer chacune d’elles. En raison de ce qui nous appelons communément le « cône d’incertitude » (ou le « graphique en entonnoir » introduit dans le domaine du développement logiciel en 1981 par Barry Boehm), il y a une certitude scientifique que notre estimation de l’effort et de la durée en valeurs absolues est très imprécise avant de déployer les efforts, et elle devient plus précise au fil du temps, avec l’expérience.

Plusieurs pratiques Agiles reposent sur cette théorie, en particulier en ce qui concerne la planification de l’itération suivante et l’estimation du travail à faire. Par conséquent, SAFe recommande l’utilisation d’une technique de comparaison relative comme la suite de Fibonacci ou autre pratique similaire.

Comme pour tout le reste dans Scrum, vos estimations initiales seront sûrement inexactes. Toutefois, vous vous améliorerez au fil du temps. Ainsi, vos estimations seront de plus en plus justes. Par conséquent, n’arrêtez pas d’apprendre afin de tirer le meilleur parti de votre carnet de produit.

Et finalement…

Bien entendu, alors que vous progressez, vous obtiendrez la rétroaction qui vous aidera à améliorer vos connaissances de la valeur d’affaires. De plus, vous voudrez l’optimiser et en obtenir le maximum. Mais cela j’en parlerai dans mon prochain billet. D’ici là, essayez de trouver votre « nord vrai »!

Billet précédent

Avoir de l’audace, c’est beaucoup plus que seulement réussir!

Billet suivant

DevTeach, la conférence pour les développeurs Web

pawel mysliwiec

Diplômé en 2004 et certifié Professional Scrum Master, Pawel a joué divers rôles depuis le début de sa carrière – programmeur, analyste, chargé de projet, coordonnateur, responsable de produit et, plus récemment, architecte d’affaires – dans des contextes de réalisation de projet tant traditionnels qu’Agiles. Depuis 2011, il met en application les méthodes Agiles dans des équipes de projets informatiques et aussi dans celles responsables des activités commerciales.

Convaincu de la force des principes Lean et de la philosophie Agile, Pawel s'est joint à Pyxis en 2015 pour continuer à aider les personnes et les organisations à découvrir une façon de travailler valorisante, responsabilisante et efficace et qui demeure centrée sur la valeur pour le client.

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *