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.

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.