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é.