Les éléments de votre carnet de produit sont périssables

Durant la rédaction de ce billet, je me suis rendu compte que la communauté agile francophone n’a toujours pas trouvé de traduction qui fasse consensus pour les différents termes agiles. La discussion sur Wikipédia autour de l’article français sur Scrum est un exemple parmi tant d’autres. J’ai donc décidé, pour cet article, de ne pas utiliser une des traductions du terme « User Story » mais je permettrai tout de même le terme « carnet de produit » comme traduction de « Product Backlog ».

C’est en visionnant une conférence d’Allan Kelly, intitulée « Beyond Projects, Or The End of Projects and what happens next« , que j’ai eu l’idée de ce sujet. En effet, durant cette présentation on apprend que selon une étude de Caper Jones les besoins exprimés par vos clients changent à un taux de 2% par mois.

It is also known that for large software projects requirements grow and change at a rate of about 2% per calendar month.  

Caper Jones & Associates LLC, MEASUREMENTS, METRICS AND INDUSTRY LEADERSHIP Version 7 – December 26, 2007

Si nous nous basons sur ces chiffres et que nous prenons un gros projet informatique dont les développements s’étaleront sur une période de 2 ans comme exemple, à la fin de la première année de développement les éléments restant dans le carnet de produit auront accumulé un changement dans le besoin de plus de 25%.

En discutant de ces chiffres avec quelques-uns de mes collègues, certains d’entre eux ont trouvé ce taux de changement de 2% par mois bien inférieur à ce qu’ils constatent dans leur travail. En effet, le taux auquel les besoins changent dépend de nombreux paramètres tels que: le degré de compétitivité du secteur dans lequel vous évoluez, votre degré de dépendance aux évolutions technologiques ou encore des lois ou normes auxquelles vous êtes contraints.

Sachant que les éléments de votre carnet de produit sont périssables, vous allez devoir reconsidérer votre gestion de ce dernier, surtout si vous aviez l’habitude que celui-ci soit une liste sans fin de besoins. Un collègue a d’ailleurs eu la judicieuse idée de comparer le carnet de produit à un réfrigérateur. Cette comparaison est assez intéressante pour 2 raisons : tout d’ abord elle donne une dimension finie au carnet de produit (ce que Ron Jeffries recommande d’ailleurs), ensuite elle sous-entend une gestion particulière de ce qu’il contient. En effet, après avoir fait vos courses (la collecte des besoins) vous devez les ranger dans votre réfrigérateur (le carnet de produit), mais avant de ranger ces nouveaux articles (les nouveaux besoins) vous devez vous intéresser aux articles restants (les anciens besoins). Vous allez donc devoir trier vos anciens articles afin d’optimiser la gestion de votre réfrigérateur. Vous serez alors peut-être amener à sortir des articles de votre réfrigérateur car ces derniers seront périmés (besoins obsolètes).

J’espère que ce billet vous fera reconsidérer la manière dont vous gérer les besoins de vos clients ainsi que de votre carnet de produit.

Advertisements

Stratégies de livraison

Dans un précédent billet nous avions vu l’importance de livrer de la valeur aux utilisateurs, nous allons donc ici nous intéresser aux différentes stratégies de livraison qu’il est possible de mettre en place pour livrer cette fameuse valeur.

Nous verrons, entre autre, comment une bonne stratégie de livraison permet d’aligner la solution développée avec les vrais besoins des utilisateurs.

Pour information ce billet reprend les stratégies de livraison que l’on peut retrouver dans les différentes présentations d’Henrik Kniberg.

La livraison « Bigbang »

HK_BigBangÉvidemment c’est le modèle de livraison le plus connu, on le retrouve traditionnellement dans les projets conduits en cascade ou dans un mode « Agile à minima » (ou Water-Scrum-Fall). Le produit est livré lorsqu’il est considéré comme terminé, et par « terminé » on entend que toutes les fonctionnalités prévues, en amont, ont été développées, et testées (dans le meilleur des cas).

Ce modèle de livraison offre malheureusement un risque élevé de livrer un produit qui ne correspond pas aux attentes des utilisateurs. En effet, dans ce modèle de développement (qui peut-être itératif) les utilisateurs sont souvent peu ou pas impliqués.

Nous retrouvons généralement ce type de stratégie dans les développements conduits en mode projet.

La livraison itérative

C’est la stratégie de livraison que l’on retrouve le plus souvent en agilité. Dans ce HK_BigIncrementmodèle la solution logicielle est livrée de façon itérative, généralement à la fin d’une itération ou d’un nombre fixe d’itérations. Chaque livraison comporte plusieurs améliorations/modifications à la solution logicielle, ce qu’Henrik Kniberg appelle « Big Increments ». Le contenu de ces livraisons est généralement défini dans ce que l’on appelle des plans de livraisons.

Le modèle reste avantageux par rapport au modèle « Bigbang » mais il pousse souvent le Product Owner à attendre qu’une fonctionnalité soit développée dans sa totalité avant de la livrer. Risquant ainsi de livrer, après de longs efforts, une fonctionnalité qui n’apporte pas ou peu de valeur à ses clients.

La livraison continue

HK_SmallIncrementOn commence ici à quitter le monde de l’agilité pour entrer dans le monde du Lean. La taille des incréments livrés va être diminuée au maximum (Small Increments) afin qu’il puisse être possible de les livrer le plus rapidement, et dans un flux continu.

Ce que cherche ici le Product Owner c’est d’être capable de livrer continuellement de la valeur à ses clients tout en limitant les investissements dans des solutions non-viables.
Généralement l’incrément livré est de la taille d’un récit utilisateur (User Story), sa taille favorise ainsi sa livraison rapide.

Valeur la plus élevée en premier

Ce dernier modèle reprend les principes du modèle précédent, mais cette fois-ci les HK_HighestValueFirstincréments dont la valeur est la plus élevée, mais pour lesquels l’effort de développement est faible, vont être priorisés. Le but souvent recherché ici est de maximiser le retour sur investissement dès le début du projet.

Ce modèle bénéficie généralement des retours utilisateurs dans le choix de priorisation des incréments, les incréments ne sont plus « poussés » par le Product Owner mais « tirés » par les utilisateurs.

« Fail fast, Learn fast! »

Les deux derniers modèles, basés sur la livraison continue de petits incréments, offrent certains avantages. Le premier avantage c’est que l’on est capable de répondre rapidement aux besoins de nos clients, un avantage concurrentiel. L’autre avantage c’est que l’on est capable d’obtenir rapidement des retours de la part des utilisateurs sur les solutions que nous avons pensées pour répondre à leurs besoins, nous permettant ainsi d’aligner plus rapidement notre solution logicielle avec les besoins de nos utilisateurs.

Mais pour profiter des deux derniers modèles, nous devons envisager nos nouvelles fonctionnalités sous la forme de Minimum Marketable Features (MMF). Ainsi les efforts investis dans une fonctionnalité qui ne rencontre pas les attentes de nos utilisateurs seront minimaux. Mais en cas de succès, la fonctionnalité pourra être bonifiée continuellement par la livraison de petits incréments.

Le coût de l’inutile

Dans le merveilleux monde du développement logiciel il n’y a rien de pire que des fonctionnalités non utilisées, soit par ce qu’elles ont été développées trop tôt (le client n’en a pas encore besoin) soit parce qu’elles ne rencontrent pas le marché attendu (mauvaise compréhension du marché). Leurs coûts ne doivent pas être calculés uniquement sur leurs coûts de développement, ils doivent aussi inclure les coûts « collatéraux ».

« You Aren’t Gonna Need It »

J’ai récemment lu l’article de Martin Fowler sur le principe YAGNI, un principe venant de l’eXtreme Programming (XP). Le principe YAGNI stipule que nous ne devons pas ajouter de nouvelles fonctionnalités à notre logiciel tant que celles-ci ne sont pas jugées nécessaires. Ce principe tend à combattre le fameux « tant qu’à… » dont nous sommes souvent victimes.

En tant que développeurs cela se traduit par notre aversion à dépasser la portée du récit utilisateur (User Story) sur lequel nous travaillons. Tant qu’à travailler sur ce récit utilisateur, pourquoi nous n’en profiterions pas pour ajouter/modifier…. De plus nous risquons de tomber dans un cercle vicieux du « tant qu’à… ». Car il y a toujours un « tant qu’à… » à un « tant qu’à… ».

Cela à plusieurs implications :

  1. nous retardons ainsi la disponibilité de la fonctionnalité que nous devions livrer, le retour sur investissement est donc lui aussi retardé.
  2. nous ajoutons de la complexité dans le code de la fonctionnalité que nous devions livrer, cela implique plus de tests et un entretien plus difficile.
  3. nous décalons la livraison de fonctionnalités qui sont plus prioritaires, nous impactons donc le plan de livraison. De plus ce dernier a pu être bâti en tenant en compte de travaux coordonnés entre plusieurs projets, nous retardons alors les livraisons de plusieurs autres projets.

Toutes ces implications induisent des coûts collatéraux!

Une fonctionnalité non utilisée s’appelle une dette!

Il nous arrive parfois d’avoir un regard objectif et critique sur les logiciels que nous développons et nous nous apercevons alors (grâce à l’instrumentation du code source notamment) que les fonctionnalités que nous pensions si utiles à nos utilisateurs ne sont que rarement utilisées. C’est à ce moment-là que nous prenons conscience du temps passé, livraison après livraison, à entretenir et exécuter des tests de régression (automatisés ou non) pour des fonctionnalités que (presque) personne n’utilise. Le temps n’est-il pas de l’argent?

Michael Feathers, dans son article intitulé « The Carrying-Cost of Code: Taking Lean Seriously », nous recommande d’effacer le code des fonctionnalités non utilisées afin de réduire la complexité (inutile) du code de nos applications. Nous bénéficierions ainsi d’un code source pour lequel les efforts d’entretien et d’évolution seront réduits, nous offrant, par conséquence, la possibilité de livrer plus vite.

Retarder ses livraisons à un coût celui d’arriver sur le marché après ses concurrents!

Feature Card

This article was written with my friend and colleague Yasmina B.

We recently read Neil Williams article about using roadmaps within the UK government. In this article we discovered a very smart and simple tool for managing the development of our product’s features: the Feature Card.

uk_feature_card

The Feature Card is not a User Story or something like this. In fact, a feature may be developed through one or many user stories. Its intent is different, unlike user stories, the features help stakeholders to get the big picture of your product.

What we really like about this card is how it is simple to point out every contributors who would be involved in the feature’s development. This also help you to explain to your product’s sponsors or your managers why a feature will be hard to deliver or not.

But a feature name is not always enough for everyone to understand the meaning or the scope. So we had the idea to add a simplified Business Model Canvas to the Feature Card for this purpose. We used the one you can find in the Adobe’s Kickbox as the model.

BMC_Feature_Card

As the original version, this Feature Card stands on a folded sheet. On the front side, you’ll find the feature title and its dependencies, on the back side you’ll find space for conversations. When you unfold the sheet you’ll have access to our simplified Business Model Canvas.

There is the list of sections you can find on our canvas:

  • Problem: a simple description of the problem you intent to solve with this feature.
  • Target Users: list the kind of users your feature will touch.
  • Minimum Acceptable Solution: describe what is the minimum solution (think MVP) you will deliver in the worst case scenario (lack of time or budget).
  • Measuring Success: list metrics you will use to measure the success of your feature.
  • Estimated Efforts: just an estimation of the effort that will be necessary to deliver the feature (feel free to use your favorite estimation tool).
  • Expected Benefits: describe what kind of benefits the feature will be deliver.

So, with this canvas added to the Feature Card everyone will be able to understand the meaning of the feature for the product and the users.

En passant

Livrer de la valeur avant tout!

Vous avez sûrement lu ou entendu quelque part que les systèmes informatiques développés selon les principes agiles répondent mieux aux besoins des utilisateurs, non? Malheureusement ce n’est pas toujours vrai, de nombreux produits développés en agile (ou du moins de façon itérative) continuent à ne pas répondre aux besoins de leurs utilisateurs, et donc à leur apporter aucune valeur.

Un bon Product Owner sait qu’il lui faut livrer de la valeur à ses utilisateurs pour garantir le succès de son produit. Si cela paraît évident, déterminer ce qui pourrait être perçu comme de la valeur par le client l’est moins.

Apportez-vous de la valeur à vos clients?

Je vais vous donner un indice, si vous vous apercevez que vos clients remplacent ou complètent votre offre logicielle par ceux d’autres fournisseurs ou par des développements internes c’est sûrement parce qu’il ne tire aucun bénéfice de ce que vous leur livrez.

Vos utilisateurs restent les seuls à pouvoir juger de la valeur de ce que vous leur livrez. Donc leurs retours vont être votre principale source d’informations pour déterminer si oui ou non vos livraisons leur apportent de la valeur.

Prenons comme exemple une société dont le corps de métier est la vente à distance. Celle-ci gère encore les commandes de ses clients avec des feuilles carbones. Toutes les commandes expédiées sont archivées dans des classeurs dans le sous-sol de la société. Une opératrice traite en moyenne 60 commandes par jour.

Le patron de cette société vient vous voir car il voudrait informatiser son processus de gestion des commandes (80% des activités), et surtout il voudrait qu’il soit plus facile de retrouver une ancienne commande d’un client en cas de litige (5% des activités), par exemple.

Vous partez donc avec les besoins que vous a exprimé le patron de la société et, comme promis, 6 mois plus tard vous revenez vers lui avec votre solution logicielle. Elle respecte totalement ce que vous a exprimé le patron dans le sens qu’il est facile de retrouver une commande particulière parmi les commandes archivés. Par contre, après plusieurs mois d’utilisation le nombre moyen de commandes traitées par une opératrice ne dépasse pas les 20 commandes. On peut donc dire que vous apportez donc plus de contraintes opérationnelles à votre client que de valeur.

Pourquoi? Parce que vous avez oublié que votre logiciel est avant tout un outil dont le rôle est de supporter un processus. Les acteurs du processus de gestion des commandes de votre client sont avant tout les opératrices, elles sont donc les utilisatrices de votre solution logicielle!

Votre client aurait été satisfait avec une solution qui gère minimalement les archives mais qui lui permette de gérer plus de commandes quotidiennement. Avec ce type de solution vous auriez pu apporter de la valeur à votre client.

Vos idées ne sont que des hypothèses!

Idéalement vous voudriez connaître le plus tôt possible si votre solution logicielle va apporter ou non de la valeur à vos clients (même avant sa livraison), ceci dans le but de limiter les risques d’investir dans des solutions qui ne répondront pas aux besoins de vos clients.

Dans son billet Lean Product Design in Practice, Natalie Hollier nous enseigne ceci :

« You need humility to recognize that any product ideas from you, your team or your organization might not be the right ideas to meet the users’ needs. »

Il va donc vous falloir revoir votre façon de développer des systèmes informatiques. Accepter que vous n’avez pas forcément compris les besoins que vous a exprimé votre client ou que ce dernier vous les a mal exprimé. Considérer vos idées de solution pour répondre aux besoins de votre client comme des hypothèses qu’il vous faudra valider. Ce concept est d’ailleurs très bien résumé dans un excellent billet de Barry O’Reilly, How to Implement Hypothesis-Driven Développent.

Mais comment pouvez-vous donc valider vos hypothèses tout en limitant vos investissements?

The Lean Startup

Depuis sa sortie en 2011, le livre The Lean Startup de Eric Ries est devenu le livre de référence pour tous les aspirants entrepreneurs. L’article “Why The Lean Startup Change Everything” de la revue “Harvard Business Review” nous apprend aussi que ce modèle va bien au-delà du monde des startups et qu’il est autant enseigné dans les cursus de type MBA des grandes écoles qu’utilisé dans de grandes organisations pour faire émerger l’innovation. General Electric est un très bon exemple de ces grandes organisations qui ont adopté ce modèle.

Il semblerait d’ailleurs que le Lean Startup soit traité dans la quatrième édition du très populaire livre de Claude Aubry sur Scrum.

Pour faire simple, le modèle Lean Startup propose donc d’adopter une démarche permettant de valider une hypothèse en 3 étapes par l’intermédiaire d’un concept appelé Minimum Viable Product (MVP).

Étape 1 : Construire et livrer un produit le plus minimaliste possible permettant de tester l’hypothèse (MVP).

Étape 2 : Mesurer l’adoption du MVP en collectant un maximum de données.

Étape 3 : Apprendre des données collectées afin de décider de la poursuite ou non de l’idée.

C’est ce que l’on appelle Build-Measure-Learn dans le jargon du Lean Startup.

Grâce au concept de MVP vous pourrez donc avoir une meilleure compréhension des besoins de vos clients, tout en limitant vos investissements, et vous serez ainsi capable de leur livrer de la valeur en apprenant rapidement des données que vous aurez collecté.

L’exemple d’Henrik Kniberg

L’image suivante a été maintes fois reprise sur des blogues ou dans les réseaux sociaux, nous la devons à l’excellent coach agile Henrik Kniberg.

Deux idées sont exprimées dans ce dessin. Premièrement, le besoin du client n’est pas compris de la même manière dans les deux parties de l’image. Pourtant le besoin exprimé par le client est le même : « je veux une voiture ». En haut, il a été pris pour acquis que le vrai besoin du client est de posséder une voiture. Alors qu’en bas de l’image, le besoin a été analysé et compris, le client a besoin avant tout de se déplacer rapidement, sans effort et sur de longues distances (voir cas Henry Ford).

Deuxièmement, le concept de livraison agile n’est pas perçu de la même manière dans les deux parties de l’image. En haut, la voiture est réalisée morceaux par morceaux de façon itérative, le client doit alors attendre la dernière itération pour satisfaire son besoin. En revanche, en bas, le client reçoit de la valeur à chaque itération, il peut combler minimalement (et avec satisfaction) son besoin à partir de la troisième itération.

C’est une bonne illustration pour comprendre ce qu’est le développement agile et comment cela apporte de la valeur au client à chaque itération. Malheureusement on observe plus souvent l’application du modèle itératif du haut de l’image.

L’exemple de l’iPhone

Voici un autre exemple souvent cité dans la littérature tournant autour de l’agilité et du Lean Startup, l’exemple de l’iPhone.

Les heureux possesseurs de la toute première version de l’iPhone, sortit en 2007, se rappelleront (avec une petite émotion) que les fonctionnalités suivantes étaient absentes :

  • GPS
  • App Store
  • 3G
  • Copier-coller
  • Recherche
  • Gestion multitâches
  • Appels vidéo
  • Service de messagerie multimédia (MMS)
  • Filmer

L’absence de ces fonctionnalités, pourtant présentes dans les modèles concurrents, n’a pas empêché l’iPhone de devenir si populaire!

Cela a permis à Apple de tester rapidement son concept de téléphone en limitant les investissements dans l’éventualité où l’iPhone aurait été un échec. C’est ce que l’on appelle un Minimum Viable Product (MVP) ou encore parfois Minimum Marketable Product (MMP).

Il est donc possible de livrer de la valeur à ses clients avec un produit qui offre un minimum de fonctionnalité.

L’indispensable Product Owner

Dans ce troisième billet je vous propose d’explorer le rôle du Product Owner, qui reste, à mon sens, le moins bien compris des 3 rôles que propose Scrum.

Ce que dit le guide

Commençons par revoir ce que dit le guide Scrum (dans son édition 2013) sur ce rôle :

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

Disons que c’est un bon début, mais cette définition n’aide pas les personnes qui endossent le rôle de Product Owner à comprendre toute la dimension de ce rôle. Ces personnes finissent par se limiter à gérer le contenu du fameux Product Backlog.

Mais nous allons voir que le rôle de Product Owner va bien au-delà de la gestion du Product Backlog.

Un entrepreneur

Dans son excellent livre “Agile Product Management with Scrum : Creating Products that Customer Love”, Roman Pichler présente le Product Owner comme un entrepreneur (voir un intrapreneur).

Pour Roman Pichler, le Product Owner devrait avoir les caractéristiques suivantes :

  • Être un visionnaire et être capable de mettre en place sa vision
  • Être un leader et un équipier
  • Être un communicateur et un négociateur
  • Être habilité et engagé
  • Disponible et qualifié

Tel un entrepreneur, un Product Owner croit en son produit, il est capable de le vendre à ses clients, à ses supérieurs hiérarchiques, à son équipe de développement ainsi qu’à toutes les parties prenantes. Il bouscule ses clients et ses utilisateurs pour aller chercher le vrai besoin. Il négocie avec ses clients pour construire son plan et sa stratégie de livraison.

Mais le Product Owner ne peut offrir tout son potentiel que si sa hiérarchie lui accorde l’autorité dont il a besoin pour effectuer sa mission avec succès. C’est le seul responsable du succès du produit.

Le rôle de Product Owner est à rôle à temps plein et exigent! No pain, no gain!

Mais qui est le Product Owner?

Bien souvent on prend le terme « Product Owner » (Propriétaire du produit) de façon trop littérale, ce qui conduit à prendre le client pour endosser le rôle du Product Owner.

Voyez-vous le problème? Dans mon précédent billet nous avons vu que le client a du mal à exprimer son besoin. Et vous voulez lui donner le rôle de Product Owner?

Ce choix de prendre le client comme Product Owner sous-entend une vision projet de ce qui doit être livré, avec une portée,  des coûts et une durée qui seront fixes. Ce n’est pas ce que l’on pourrait appeler une approche Agile, et on pourrait tout aussi parler de Project Owner plutôt que de Product Owner.

Pour ma part, je pense qu’il faut voir le Product Owner comme le propriétaire moral du produit dont il a la charge. Il est le garant de l’orientation du produit ainsi que de son succès.

Je vous propose donc une petite comparaison de ces deux approches :

Le Product Owner comme client (une vision projet)

Risque À considérer
Connaissance du domaine Nul. Une personne avec un profil d’utilisateur expérimenté pourrait être un plus.
Disponibilité Élevé.

La personne désignée occupe sûrement déjà une fonction dans son organisation.

Éloigné de l’équipe de développement.

Informer le client que son PO doit être dédié à 100 % au projet.
Stratégie de livraison Élevé. N’entre pas forcément dans le champ de compétences de la personne désignée.
Priorisation et valorisation Modéré. Peut-être difficile d’introduire des besoins n’appartenant pas aux clients.

Le Product Owner en tant que propriétaire moral (vision produit)

Risque À considérer
Connaissance du domaine Modéré. Le PO peut avoir des connaissances limitées au début du projet mais celles-ci vont augmenter tout au long du projet.
Disponibilité Faible. Son gestionnaire l’a dédié à 100 %.
Stratégie de livraison Faible. Son gestionnaire l’a nommé PO pour cette compétence.
Priorisation et valorisation Modéré.

Certaines parties prenantes peuvent lui imposer des choix.

Il reste le seul responsable de la priorisation et de la valorisation des besoins, mais il doit être soutenu par sa gestion dans ses décisions.

Dans mon prochain billet nous verrons comment le Product Owner s’y prend pour comprendre le vrai besoin de ses clients.

Comprendre le besoin

Ce billet fait suite au précédent que j’ai posté, « Pourquoi veut-on travailler en agile? », et il va nous permettre de mieux comprendre le besoin de nos utilisateurs.

Notre priorité en tant qu’équipe Scrum (ou Agile) est d’apporter de la valeur à nos utilisateurs. Et pour atteindre cet objectif, il nous faut commencer par comprendre leurs besoins.

Mais cet exercice n’est pas toujours facile. Ce n’est pas parce que l’un de vos utilisateurs commence sa phrase par « je veux… » ou « j’ai besoin de… » qu’il vous exprime forcément son vrai besoin. Loin de là!

Développer une solution logicielle à partir d’un mauvais besoin vous amènera sûrement à livrer quelque chose qui n’apporte pas de la valeur à vos utilisateurs.

Je vous propose donc, dans ce billet, que l’on étudie ensemble quelques cas communs de problèmes liés à la collecte du besoin.

Henry Ford et la Ford T

Pour commencer, je vous propose l’étude d’une citation du très célèbre Henry Ford :

Si j’avais demandé aux gens ce dont ils ont besoin, ils auraient répondu des chevaux plus rapides.

Nous savons tous qu’il n’a jamais vendu de chevaux à ses clients, par contre il leur a vendu la célèbre Ford T. Pourquoi? Parce qu’il y avait parfaitement compris le besoin de ses clients! Mais quel était donc le vrai besoin de ces derniers?

Pour comprendre ce fameux besoin, nous pourrions imaginer la conversation suivante entre Henry Ford et son client :

H.F. : « Pourquoi as-tu besoin d’un cheval? »

Le client : « Pour pouvoir me déplacer. »

H.F. : « Si tu as besoin de te déplacer, pourquoi n’utilises-tu pas tes jambes? »

Le client : « Parce que j’ai besoin de me déplacer rapidement et sur de longue distance. »

H.F. : « OK, alors pourquoi ne prends-tu pas simplement un vélo? »

Le client : « Parce que je veux me déplacer sans effort. »

H.F. : « Donc ton besoin n’est pas d’avoir un cheval plus rapide, mais de pouvoir te déplacer rapidement sur de longue distance et sans effort. Est-ce bien ça? »

Le client : « Oui. »

Donc le vrai besoin du client d’Henry Ford est de pouvoir se déplacer rapidement sur de longue distance et sans effort. Besoin que comble la Ford T avec une vitesse maximale de 70 km/h et une autonomie de plus de 250 km. Mieux qu’un cheval, non ?

C’est l’histoire d’une balançoire

Il arrive parfois que le client sache exactement ce dont il a besoin, mais il n’est malheureusement pas toujours capable de nous le transmettre, de nous le décrire, et cela provoque des confusions lors de la livraison de la solution à son besoin.

Pour illustrer ceci je vous invite à regarder l’image suivante qui conte l’histoire (très connue) d’un client qui veut se faire fabriquer une balançoire :

balancoire

Nous pouvons voir sur cette image la belle différence entre le besoin exprimé/décrit par le client (première vignette) et la solution qui l’aurait simplement satisfait (dernière vignette).

De plus, dès la deuxième vignette, nous nous apercevons qu’il y a une différence entre ce qu’a décrit le client et ce qu’a compris le chef de projet. D’où la difficulté à pouvoir livrer une balançoire qui pourrait satisfaire le client.

D’ailleurs, cela nous amène à un autre problème que l’on peut observer dans certaines entreprises ou organisations…

Du bruit sur la ligne 

Nous pouvons aussi appeler ça le syndrome du « téléphone arabe ».

Cela se produit lorsqu’il y a trop d’intervenants entre le client et l’équipe de réalisation. L’information provenant du client se corrompt à chaque fois qu’elle passe par un intervenant qui doit la communiquer à l’intervenant suivant. Cette « corruption » de l’information entraine fatalement une mauvaise compréhension du besoin du client se traduisant dans la livraison d’une solution logicielle qui n’apporte aucune valeur à nos utilisateurs.

Il existe bien entendu d’autres raisons pour lesquelles le besoin utilisateur n’est pas bien compris, et donc pas satisfait, mais cela reste en dehors de la portée de ce modeste billet.

Mais qui peut donc nous sauver de ces situations? Qui va nous permettre de comprendre le besoin des utilisateurs dans un contexte Agile?