La valeur dans l’agilité : comment la repérer ?

Marre des Daily vous paraissant un tantinet ennuyeux et sans queue ni tête ? Alors vous êtes au bon endroit : aujourd’hui, nous parlons valeur. 

Ce titre pouvant paraître “clickbait”, ou piège à clics, devrait cependant vous apporter certaines clés pour aller plus loin dans vos Daily, et vous aider à changer les choses…

Au programme : Sprint Planning, notion de valeur, méthode agile et développement de produits, clients et utilisateurs, pour finir par la vision de produit.

Définitions pour bien rentrer dans le sujet !

• Daily : Daily Scrum, pour être plus précis. Une réunion habituellement le matin, d’environ 15 à 30 minutes, souvent organisée par les équipes agiles. Cela permet à l’équipe de faire le point sur son avancement et identifier les problèmes qui pourraient l’empêcher d’atteindre son objectif.

• Sprint Planning : le Sprint Planning est une réunion de planification dans le framework Scrum où l’équipe de développement définit les objectifs du sprint à venir et sélectionne les tâches à réaliser, en estimant les efforts requis pour les achever. 

• L’agilité : l’agilité est une approche itérative et collaborative du développement de logiciels qui favorise la flexibilité et l’adaptation aux changements. Elle met l’accent sur la livraison régulière de fonctionnalités, la communication constante entre les membres de l’équipe et le client et l’ajustement des plans en fonction des retours d’expérience, dans le but de valider (et donc dérisquer) au plus tôt les développements.

Préparez vos crampons : c’est parti pour un vrai Sprint (Planning)

Avant tout, le culte du cargo

Retournons en Mélanésie, au XXe siècle. C’est l’histoire de soldats américains s’étant tout bonnement installés sur ces îles pendant la guerre. Pour créer leur base, faire tout un tas d’opérations, demander du matériel par radio. (Attention ! Élément essentiel de l’histoire…)

Seulement, sur ces îles, il y avait également des populations d’aborigènes. Et eux ne connaissaient pas toutes ces technologies, les avions, etc.

Cette population a remarqué que lorsque les Américains parlaient dans la radio, hop, des fournitures, ou encore des rations de nourriture et de vivres arrivaient. Les Mélanésiens, pensant à une intervention divine, se mirent à imiter les Américains.

Bien sûr, avec les matériaux dont ils disposaient (bambous, lianes…). TOUT y passait : des casques, des radios, des téléphones, etc. 

Cependant, comme nous l’avons dit, ils étaient loin d’imaginer la logistique qu’il y avait derrière, l’industrie et les technologies maîtrisées par les Américains. Les autochtones, avec leur histoire et leur culture complètement différente, “tentaient de recréer des résultats positifs en reproduisant des circonstances associées à ces résultats.” – Julien M.

Malheureusement pour eux, les circonstances n’étaient pas liées, et le fait même de reproduire n’était pas suffisant.

Mais quel est le lien avec le Sprint Planning ?

Le lien est clair et limpide, comme de l’eau de roche, et vous allez vite le comprendre. Dans la transformation agile, il est facile, à l’instar des autochtones, de vouloir copier ce que les autres ont fait et de l’accomplir. Et, SURTOUT, en oubliant qu’il y a des raisons derrière.

“On va faire une équipe, voilà donc toi t’es Product Owner, vous, vous êtes les développeurs, toi t’es scrum master, vous allez écrire des User Story, et en route pour la richesse et la gloire. On va quand même faire des estimations, parce que bon voilà…” 

Si nous faisons ces choix, c’est parce que les retours que nous en avons eu étaient positifs. “Eux ont fait ça, et ça a marché. Pourquoi pas nous ?” 

Cependant, voyez ça comme un iceberg.

Le Sprint Planning de l’iceberg

Tout ce dont on vient de parler correspond effectivement à la partie émergée de l’iceberg. Mais comme tout bon iceberg, la partie immergée est tout aussi, si ce n’est plus, présente.

Dans cette partie immergée, nous trouvons les raisons qui donnent du sens à ce qui se passe au-dessus. Nous abordons différents sujets tels que l’amélioration continue, le safe-to-fail, et l’approche incrémentale. 

Nous utilisons d’ailleurs le terme « produits » plutôt que « projets » pour ces sujets. Fait que nous expliquerons au fur et à mesure de cet article…

Malheureusement, ces sujets sont souvent rapidement négligés, même s’ils sont mis en place pour prétendre être agiles. Ô grand désespoir quand tu nous tiens… 

Qu’est-ce que la valeur dans tout ça ?

De façon très simpliste, cela va correspondre aux intérêts et à la raison pour laquelle nous faisons les choses.

Par exemple, reprenons depuis le début, le voulez-vous ? Un utilisateur, ça a des besoins. “C’est trop complexe, trop cher, j’ai pas le temps, pas les compétences…”  En face de cet utilisateur, nous avons des personnes ayant plus d’argent, plus de temps, et surtout beaucoup plus de compétences, pour pallier les besoins de cet utilisateur.

Vous voyez où nous voulons en venir ! Ils vont simplement lui dire : “Nous avons ce que vous n’avez pas, nous allons vous construire une solution.”

C’est cette interaction entre l’utilisateur qui a un besoin et l’entreprise qui y répond qui va générer de la valeur. La valeur n’existe que dans l’interaction. 

Cependant, cette valeur existe aussi sous le nom de produit. C’est le vecteur de cette valeur, elle est potentiellement infinie. 

Un autre Homme aurait pu dire :

“Je suis le maître de mon destin, je suis le capitaine de mon âme”.

(Oui, c’est bel et bien William Ernest Henley)

Mais pourquoi produit ?

Nous l’avons dit, un produit, ça a une valeur potentiellement infinie. Et le besoin de l’utilisateur quant à lui, va évoluer au fur et à mesure du temps. 

À contrario, un projet est défini temporellement, et nous n’arriverons donc pas suffisamment à le faire évoluer pour qu’il suive les besoins de l’utilisateur. C’est pourquoi nous passons sur une gestion de produit. Plutôt agile comme combinaison non ? (Pour toute plainte sur ce jeu de mots, merci de contacter le pôle communication d’Amiltone.)

La valeur, avant tout une question de visibilité et de mesurabilité ?

Pour qu’un produit (et par extension l’entreprise qui l’a créé) fonctionne et prospère, il faut continuer à répondre aux besoins des utilisateurs et maintenir, voire améliorer, la valeur au cours du temps.

Mais comment matérialiser cette valeur ?

Avez-vous déjà entendu “Nous ne sommes capables d’améliorer que ce que nous mesurons. Si nous ne savons pas ce que nous mesurons, nous ne pouvons pas savoir si nous l’avons amélioré ou non.” ?

L’adage se trompe rarement !

L’idée est alors de trouver des moyens pour justement mesurer cette valeur. Et face à ça, vous rencontrerez deux types de personnes…

• La n°1, “celui qui connaît son client” : Bah on sait, on fait ce métier depuis 15 ans, donc nous les connaissons nos utilisateurs, nous savons ce qu’ils veulent. Tiens d’ailleurs j’ai pensé à un truc quand j’étais aux toilettes ça va être super à mettre en place pour eux !
  *Insérer ici une fonctionnalité qui prendra 6 mois à être développée et ne sera utilisée que par très très peu d’utilisateurs*.

• La n°2 : fait preuve de prudence et d’humilité face aux clients/utilisateurs, se base sur la data. Et certes, la data peut correspondre à beaucoup de choses. 

C’est pourquoi nous proposons deux catégorisations d’indicateurs de data.

• Les indicateurs avancés (Input) : Indicateurs définissant les actions à effectuer pour obtenir un résultat mesurable. Ces indicateurs sont prospectifs, ce sont des indicateurs sur lesquels on se repose pour déclencher un changement. 

• Les indicateurs retardés (Output) : Indicateurs mesurant la performance actuelle du produit. Ils traduisent le comportement actuel du client. Ils sont donc rétrospectifs, et permettent de s’assurer que les changements inspirés par les indicateurs avancés ont permis d’atteindre les objectifs souhaités. 

  
  

  L’indicateur avancé a donc le pouvoir d’instaurer le changement, c’est celui sur lequel nous nous reposons, quand l’indicateur retardé constate ce qui se passe.

  
  

  Parce qu’un exemple vaut mille motsPrenons par exemple Netflix. Netflix, comme la plupart des entreprises, “veut faire de l’argent” : 

• Ça, c’est un indicateur retardé, car les revenus que nous avons générés avec notre application, c’est une data que nous avons à un instant T ;

• Le nombre de comptes créés passé, c’est la même chose. Nous savons combien de comptes sont créés à la journée, et c’est comme ça ;

• De même pour la satisfaction client. Un client peut être content une journée, et détester vos services et contenus proposés le lendemain…

  
  

  Nous, ce qui nous intéresse, c’est augmenter le CA, ou encore le nombre de comptes créés pour développer le business. La question qui va alors se poser est la suivante : sur quoi peut-on agir pour augmenter le nombre de commandes ?

  
  

Nous pouvons agir sur, par exemple :

• Le temps passé dans le tunnel de commande, pour réduire le nombre de personnes n’allant pas jusqu’à l’achat ;

• L’accessibilité, pour rendre la base plus abordable. Cela peut permettre à plusieurs personnes d’accéder au tunnel de commande, ou à notre application, on va alors gérer plus de business ;

• La motivation des collaborateurs joue aussi : la satisfaction du client va jouer sur la motivation des collaborateurs, et vice versa. 

La notion d’indicateur marche donc de cette façon… mais comment se construit-elle ? 

Maximiser la valeur

Nous savons donc identifier le besoin de notre utilisateur, et nous savons mesurer son comportement. Autrement dit : on sait mesurer notre business.
Mais ! Parce qu’il y a toujours un mais : toujours avec les maîtres-mots, prudence et humilité. 

Par exemple, faire un investissement sur six mois/un an, c’est trop risqué. Parce que nous ne connaissons pas bien notre utilisateur, nous ne savons pas comment il va réagir, et le marché est toujours en mouvement.

C’est pourquoi nous allons chercher à réduire la boucle de feedback. 

La boucle de feedback représente le temps entre le moment où nous allons commencer à faire quelque chose, et le moment où l’utilisateur va nous donner son avis sur la question. Exemple ! Dans un projet de 6 mois, c’est au bout des 6 mois que l’utilisateur va nous donner son avis. Le Framework Scrum propose de transformer cette boucle de 6 mois en de multiples itérations (appelées Sprint) de 2 semaines, qui permettent de s’assurer beaucoup plus fréquemment de la valeur qui a été créée auprès de l’utilisateur.

Comment faire ?

Ce que nous allons également faire, c’est y aller de façon incrémentale : accroître la valeur petit à petit. C’est une très bonne façon de réduire les risques, et de mieux maîtriser les coûts.

Besoin d’une façon relativement simple de se représenter tout ça ? Amiltone est là pour ça : le Plan/Do/Check/Act.

• Plan : Lorsque l’utilisateur a une problématique, il faut la formaliser et obtenir le plus de détails possible sur la cause de cette problématique ;

• Do : Ensuite, on essaye quelque chose, on appuie sur un petit bouton, sur un levier, on va changer un élément ;

• Check : Maintenant que l’on a changé quelque chose sur notre produit, on va vérifier que cela a bien eu l’impact voulu auprès de l’utilisateur. Ou en tout cas, on va vérifier que ce que l’on a fait a bien déclenché le mouvement vers ce que l’on souhaitait ;

• Act : Au moment où on a vérifié que ça commençait à aller dans la bonne direction, on agit réellement. C’est-à-dire que l’on va mettre en place des choses, agir de façon sérieuse. Mettre les petits plats dans les grands si je puis dire !

Ensuite, on reboucle : est-ce que notre utilisateur est satisfait ?

• Si ça a marché : On cherche une autre problématique pour améliorer toujours plus la valeur du produit ;

• Si ça n’a pas marché (ohhhh…) : Pas de déception, on reformule la problématique pour essayer de trouver un autre angle d’attaque pour refaire le process. 

Toute cette valeur, qu’est-ce que nous en retenons ? 

Jusqu’ici, nous avons les premières bases, et je dirais même plus (Dupond et Dupont, quand vous nous tenez !), des indicateurs de valeur, mais également de l’empirisme. 

L’empirisme, c’est partir du principe que nous ne connaissons rien, et donc nous essaierons de progresser pas à pas. Et ainsi,  apprendre à mieux connaître nos utilisateurs et leurs besoins au fur et à mesure. 

Cette façon de faire améliore la transparence de nos actions. Typiquement, sur un projet pour un client, c’est très dur de voir comment ça avance.
Par conséquent, nous, nous allons essayer de mettre en place plus de transparence en les montrant plus régulièrement, et en raccourcissant comme nous l’avons dit plus tôt, les boucles de feedback. 

TAKEAWAYS :

Tout comme le culte du cargo nous l’a enseigné : toujours questionner le fond et le sens des choses, et ne pas se contenter d’en copier la forme.

Et enfin, si nous devions faire un dernier point, Scrum, et l’agilité permettent donc d’avoir : 

• Plus de visibilité sur la valeur créée par l’équipe et les impacts réels sur le business ;

• Un feedback plus rapide et focalisé, ainsi qu’une collaboration plus importante ;

• Une solution plus adaptée au besoin de l’utilisateur ;

• Un levier de motivation et une meilleure cohérence pour votre équipe.

Alors, si cet article vous a plu, n’hésitez pas une seconde de plus à nous contacter ! Nous nous ferons un plaisir d’échanger avec vous et de vous assister !