Right Product, où comment s'assurer qu'on réalise le bon produit et éviter ainsi de mener nos projets avec la plus grande attention tout en manquant notre cible.

Tel était le thème de l'Open Space organisé par Ekito cette semaine dans les fabuleux locaux d'Air France à Tournefeuille près de Toulouse. Une guest star, Gojko Adzik, trublion salutaire de la qualité logicielle.

Ce thème me parle beaucoup. En effet, à force de nous remettre en question sur notre façon de faire du logiciel (collaboration, acceptation du changement, itérations, développements dirigés par les tests, intégration continue, déploiements rapides etc) nous avons tous atteint plus ou moins un niveau de maturité supérieur. Mais quelque chose de fondamental est passé à la trappe : l'impact.
Autrement dit, comment s'assurer que tous nos efforts seront payants ? Qu'est-ce qui nous assure que notre backlog est le bon, que nous n'allons pas perdre notre temps... et notre argent ?

Format Open Space (rappel) :

Les personnes qui se présentent, sont les bonnes
Ce qui arrive, est la seule chose qui pouvait arriver
Ça commence quand ça commence
Quand c’est fini, c’est fini.
La loi des deux pieds : Si vous n’êtes en train ni d’apprendre, ni de contribuer, passez à autre chose

En bref, des groupes de discussion sont auto-constitués, d'abord par trois. Ils font émerger des sujets de discussion, un seul est sélectionné.
Puis trois groupes se rejoignent, échangent leurs trois sujets sélectionnés et en choisissent un seul.
Ainsi, une dizaine de sujets donnent lieu à autant d'ateliers, libres de participation (alors que certains sujets seront à l'abandon, d'autres emporteront une grande audience)
Chaque atelier dure à peu près une demi-heure et donne lieu à une restitution de dix minutes à l'assemblée, par un rapporteur auto-désigné. Ce qui constitue un run.
La journée a été scindée en deux grandes parties (avant et après le déjeuner), deux runs pour chaque.

Impact mapping

Une exception cependant, un des premiers ateliers était en fait une présentation de Gojko de son fameux Impact Mapping

Son credo : déployer des impacts plutôt que des features, penser positionnement avant produit, s’interroger sur ce qui influence le comportement de l'utilisateur, penser nos user stories en "conditions victorieuses", accepter que nos visions soient des hypothèses et les valider rapidement par des petites réalisations.

Les principes forts que j'ai retenus :

les afin de de nos user stories ne servent pas assez leur objectif. Exemple : en tant que responsable des stocks, je veux un rapport des stocks disponibles, afin de répondre à la demande du service logistique. Ici, le afin de n'apporte rien. Mieux : ... afin de répondre plus rapidement au service logistique. Ajouter plus rapidement n'est certes pas grand chose mais change tout, car renseigne sur le changement de comportement attendu, bref, sur l'impact positif qui sera produit par cette story. Allons plus loin : How much is enough? comme dirait l'autre. A savoir, c'est quoi plus rapidement : … afin de répondre au moins deux fois plus rapidement qu'aujourd'hui à la demande du service logistique. That's it. J'avais déjà noté que cet exercice n'était pas bien maîtrisé dans les projets, les acteurs n'y accordant pas l'intérêt qu'il mérite. Grâce à Gojko, mon intuition est devenu une conviction : cet exercice est capital. C'est l'essence même de la définition de besoin : s'assurer de la valeur du moindre élément demandant du travail.
Miser sur le visuel, et du visuel simple. Le modèle des cartes d'Impact Mapping est simple et lisible : quoi-comment-qui-pourquoi. Il s'agit de faire des hypothèses. Et ces hypothèses s'appliquent surtout aux connexions qui relies les nœuds de notre carte. Notre nouvelle posture est désormais d'accepter que nous faisons des hypothèses et non que nous connaissons a priori la logique qui nous amène du pourquoi (la valeur) au quoi (le produit). En effet, souvent, nous partons de la description d'une vision (ce qui est très bien en soi) et nous la déclinons en fonctionnalités (ou features) dans un backlog de produit. Or il s'avère que la définition du pourquoi est bien plus difficile qu'on ne l'imagine. Nous faisons en fait des hypothèses !
Il s'agit alors de valider ces hypothèses. Pour cela, il suffit d'identifier une réalisation minimum, voire très restreinte. Le Story Mapping peut prendre le pas sur l'Impact Mapping pour définir ce minimum, au niveau du quoi et du comment. Ce produit ultra-minimal qui servira cette cause peut être, par exemple, la première ligne horizontale de user stories de la story map. Notons ici que la solution peut se trouver dans d'autres domaine que le logiciel (exemple : envoi de mails ou utilisation de canaux de communication existants etc) !

Tout projet est-il éligible à l'agilité ?

Bien que ce sujet sorte un peu du thème de la journée, son résultat m'a intéressé. Les points clefs retenu par le groupe pour définir les projets qui ne sont pas éligibles :

Fortes contraintes, organisation et processus lourds, sur lesquels on n'a pas de prise
Le consensus de départ ne peut pas être satisfait en cours de projet car les acteurs ne sont pas suffisamment disponibles
La nature du projet n'exploite pas suffisamment les leviers de l'agilité. Par exemple, une migration technique à iso-périmètre

Comment rester sur l'objectif en cours de projet

Points clefs :

Définir des objectifs vraiment métier (valider le concept)
Assurer la priorisation par ces objectifs avec les outils dédiés
Définir des indicateurs mesurables
Mesurer dès le départ ces indicateurs
Piloter régulièrement par ces indicateurs

Fin de la première partie (deux runs)

Des tendances évidentes ont émergées :

Les métriques permettant de piloter la valeur
Comment valider une vision

Give Them A Hot Hub

Tiens, je n'avais jamais expérimenté ce jeu de la fameuse série des Innovation Games.
Le but : développer la créativité des directeurs de produit et trouver des features vraiment originales et différenciatrices. Déroulement : on scinde en deux groupes. Le premier attend dehors. Le second a charge de trouver des fonctions, n'importe lesquelles. On ne cherche pas de cohérence entre elles. L'animateur aura préalablement construit une liste de produits quelconque. On réunit alors les groupes et on tire au sort un couple produit-fonctions. Il s'agit alors de mettre en lumière ce que peut représenter la fonctions pour le produit et trouver ainsi une fonctionnalité originale du produit. On note ces fonctionnalités derrière la carte du produit. C'est la réunion improbable des deux éléments qui favorise l'originalité... et la rigolade accessoirement (on joue après tout) ! Exemples :

Produit=SEXTOY, Fonction=Chercher une nounou =>un sextoy qui tient éloignés les enfants
Produit=CLIMATISATION, Fonction=Louer un film => une climatisation qui s'adapte à l'ambiance du film
etc

Bref, on a bien ri. Plus sérieusement, cet exercice prend tout son intérêt lorsque le soumet à un groupe d'utilisateurs. Les produits sont alors les leurs (ou des parties de produit), mais les fonctions proposées sont toujours extravagantes sinon ça ne marche pas.

Comment tester une idée sans coder

Points clefs :

Ne pas avoir peur de se faire voler son idée ! En effet, une idée est floue par nature. Elle reste à être validée
Un MVP (Minimum Viable Product) n'est pas forcément une solution informatique
Utiliser le Lean Startup : déployer des versions très rapides pour valider l'idée (thème déjà utilisé dans l'Impact Mapping, les approches se complètent)
Solliciter a priori les utilisateurs (ex: par mails), donner naissance et faire vivre une communauté
Demander une participation financière à la réalisation d'un prototype. En effet, la notion d'argent aide à savoir vraiment ce que l'on veut !

Comment minimiser le déroulement d'une démarche d'Impact Mapping

La démarche peut s'avérer trop longue pour certains contextes (bien que déjà optimisée). Le groupe propose une méthode légère et rapide :

Identification des acteurs clefs : senior business, clients, utilisateurs, ergonomes, product owners, équipe...
Ces acteurs pouvant être trop nombreux, organiser des groupes de travail
Organiser des jeux innovants : Product Box, Speed Boat, Elevator Pitch, etc
Restituer sous la forme d'un World Café
Atelier d'Impact Mapping et de Vision
Atelier de Story Mapping
Établissement du backlog de produit

Tout cela sur quelques demi-journées. De bonnes idées assurément.

Présentation Lean Canvas

La journée s'est terminée par des ateliers animés par les experts.
Le concept de Lean Canvas m'a particulièrement intéressé car il s'applique plus largement à l'entreprise et adresse jusqu'à la problématique marketing/commerciale. Un outil très simple, format A4, qui permet de définir nos hypothèses de développements et de les vérifier sur des bases tangibles. Les points clefs :

Le canevas : description du problème, alternatives, clients, canaux de communication, valeur, ressources clefs, solution, coût, revenue. Il y a un enchaînement privilégié et on itère sur certains
Commencer par l'expression des problèmes car une solution provient toujours de l'expression de problèmes
La réflexion sur les alternatives à la solution et le coût de la solution : S'agit-il réellement d'un problème ? Est-on prêt à payer pour le résoudre, combien ?
Des concepts que j'ai appris. Le CLT : combien j'aurai gagné jusqu'au départ du client ? Le cycle de développement d'une entreprise : Problème/solution (quelques mois), Produit/marché (2 à 3 ans), Passage à l'échelle

Bon, c'est un peu léger comme description de Lean Canvas alors je vous encourage à approfondir par vous même !

Ma rétrospective

Journée très enrichissante apportant de sérieuses pistes de réflexions et de solutions à la thématique Comment s'assurer qu'on développe le bon produit ? Je n'ai pas cité ici tous les sujets traités (exemple : Stage of Growth et d'autres encore).

Je vis cependant une frustration : pour être en mesure de proposer et tester ces fabuleux outils, encore faut-il pouvoir intervenir au bon niveau dans l'entreprise, ce qui est rarement le cas quand on est un simple coach agile ;-) Pour cela il faut pouvoir accéder au niveau des représentants stratégiques des entreprises et arriver au moment propice, par exemple, dès l'étude d'opportunités. Je ne me sens pas très confortable d'expliquer à un client que 80% de son cahier des charges n'a pas d'impacts victorieux et qu'il vient de perdre trois mois à le rédiger...

Espérons que ces acteurs s’intéresseront à ces outils et prendrons conscience qu'ils leur permettront d'optimiser leur argent ou en tous cas, qu'ils en perdront moins ! Combien de projets informatiques n'ont pas apporté la valeur escomptée au regard des coûts engagés ?