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

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?