Peu d’équipes pratiquent le Lean et l’agilité de manière efficace, surtout quand elles ne comprennent pas en leur sein des personnes avec de vraies compétences en design de service et en commerce. Marty Cagan est un coach produit expérimenté qui milite pour de vraies équipes multi-disciplinaires à même d’aller encore plus vite dans la résolution de problème et dans la livraison d’une solution adaptée et bien conçue.
Il y a un peu plus d’un an, Henri Kniberg, un de mes coaches Agile préféré, publiait un article qui explique très bien comment les équipes de développement peuvent s’appuyer sur le concept de MVP pour s’assurer de bien comprendre les valeurs fondamentales des méthodes agiles. Si vous n’avez pas encore lu l’article d’Henrik, j’espère que vous prendrez quelques minutes pour le faire avant de continuer à lire celui-ci.
Je mets volontairement en emphase « les équipes de développement » car je vais essayer ici de nuancer le concept lorsqu’il s’applique à de véritables équipes produit multi-disciplinaires.
Soyons clair, par « équipes de développement » j’entends des équipes soit uniquement composées de développeurs, soit qui comprennent un membre qui fait office de product owner (et non un vrai product manager).
À contrario, une équipe produit comprend un vrai product manager, un product designer expérimenté et quelques développeurs.
Ne vous méprenez-pas, beaucoup d’entreprises n’ont que des équipes de développement, avec un product owner désigné chargé de faire respecter les rituels de l’Agile et de la gestion du backlog, mais avec peu ou pas de compétences pour être capable d’assurer les fonctions plus larges de responsable produit.
C’est souvent la même chose avec le product designer. L’équipe peut avoir accès à un graphiste, mais pas au product designer dédié auquel je fais référence, avec des compétences en design d’expérience utilisateur, en prototypage, en recherche utilisateur et en design d’interaction.
En tout cas, si l’équipe ne possède pas un vrai product manager ou un vrai product designer, je les redirige généralement vers l’article d’Henrik et je leur dis que c’est ce qu’ils peuvent faire de mieux.
Mais si c’est une vraie boîte qui développe un produit basé sur de la technologie, alors je leur indique qu’ils doivent et qu’ils peuvent faire bien mieux que ça.
Donc si vous disposez d’une véritable équipe produit multi-disciplinaire, avec un product manager expérimenté ainsi qu’un product designer qui travaillent tous deux aux côtés des développeurs, comment allez-vous vous attaquer à ce problème ?
Dans l’exemple d’Henrik, l’équipe travaille à la fois sur le produit le plus adéquat à concevoir ainsi que sur sa réalisation. Et ils n’ont qu’un seul outil générique à leur disposition : les développeurs. On a donc un produit développé progressivement, avec un soin particulier apporté à avoir quelque chose qu’on peut tester avec de vrais utilisateurs à chaque itération.
Henrik insiste qu’ils sont en train de développer pour apprendre, mais ils font avec le seul outil dont ils pensent disposer : des développeurs qui écrivent du code. Si vous lisez attentivement, Henrik dit bien que les développeurs n’ont pas vraiment besoin de développer les produits — ils pourraient développer des prototypes, mais dans la plupart des équipes que j’ai rencontré, ce point passe souvent inaperçu, car elles ne comprennent pas qu’ils existent plusieurs types de prototypes, donc la majorité n’ont pas vocation à être crées par des développeurs.
Considérons à présent le premier principe que j’énonce dans Au-delà du Lean et de l’Agilité. Si vous n’avez pas encore lu cet article, faites-le dès maintenant sans quoi ce qui suit n’aura pas forcément de sens pour vous.
Le premier principe consiste à minimiser les risques dès le départ, avant que nos développeurs n’aient à écrire la moindre ligne de code pour la production. Plutôt que de nous contenter de la notion relativement simpliste du skateboard et de l’itération testable au plus tôt, nous analysons les risques beaucoup plus en détail et considérons explicitement la valeur, l’utilisabilité, la faisabilité et la viabilité commerciale du produit.
Ensuite, en fonction des zones considérées comme risquées, nous choisissons le bon outil ou la bonne technique pour faire le job (le but de cet article n’est pas de vous les décrire tous, mais sachez qu’il y a quatre types principaux de prototypes) et nous décidons si cela doit être testé qualitativement ou quantitativement. Et non seulement nous faisons des tests avec de vraies personnes et des clients, mais aussi avec les autres membres de notre équipe et les différentes parties impactées de notre modèle commercial.
C’est la phase d’exploration du produit. Nous cherchons quel est le produit adéquat à développer.
C’est le product manager et le product designer qui guident la majeure partie de cette activité d’exploration, le designer crée la plupart des prototypes dont nous avons besoin pour évaluer ces risques. Et les développeurs sont inclus dans chaque étape de recherche, à la fois pour mesurer la faisabilité de la solution proposée, mais aussi et surtout pour aider à améliorer la solution en elle-même.
Ce n’est pas que nous ne pourrions pas avoir recours aux développeurs pour créer les itérations d’apprentissage, que décrit Henrik, c’est juste que ça prendrait beaucoup plus de temps (d’après mon expérience, d’au moins un ordre de grandeur), et que ce serait en grande partie du gâchis, sans parler des coûts d’opportunités1.
Un produit peut nécessiter un travail oscillant entre 5 et 15 itérations avant qu’il ne fonctionne comme il devrait (également parfois appelé « time to money », soit la période pendant laquelle le produit ne permet pas de gagner de l’argent).
Si toutes ces itérations demandent de faire appel à des développeurs et que chacune demande des mises en production, on parle ici de plusieurs mois voire de plusieurs années, si le management ou l’équipe n’as pas encore perdu patience. Toutefois, si nous pouvons réaliser 10 à 15 itérations pendant une semaine d’exploration, le temps nécessaire à proposer la bonne solution (à savoir à la fois développer le bon produit et bien le développer) à nos clients passera de quelques mois à quelques jours.
J’aimerais aussi vous faire une autre remarque que le modèle conceptuel d’exploration/livraison illustré sur le graphique ci-dessus (au risque de trop vous en dire d’un coup, mais je pense que celle-ci est importante).
Une fois que nous connaissons le produit que nous avons besoin de développer, les développeurs vont devoir non seulement développer et livrer ce produit, mais ils vont devoir le faire de façon scalable, performante, sûre et maintenable et dans beaucoup des entreprises avec qui j’ai travaillé, qui sont déjà d’une taille considérable, ce n’est pas si simple. Et ce n’est certainement pas le genre de chose qu’on va vouloir reconsidérer nonchalamment à chaque itération.
Les ingénieurs vont vraiment devoir savoir qu’ils doivent construire une voiture avant de proposer une architecture qui réponde au besoin et il se peut qu’ils choisissent d’implémenter cette solution avec une stratégie de livraison différente de celle utilisée pendant la phase d’apprentissage rapide.
Par exemple, ils vont peut-être finir par d’abord tester un ensemble de micro-services (les pneus et le moteur de la voiture pour vous donner une image grossière) et s’attaquer à l’expérience de la partie client plus tard. Nous cherchons toujours à éviter la livraison façon Big Bang, mais encore une fois c’est une décision qui revient aux ingénieurs et qui n’a pas besoin d’être une stratégie de livraison optimisée pour l’apprentissage —la phase exploratoire est là pour ça.
Il y a en outre un deuxième effet important à faire de l’exploration de produit de la sorte. Comme on s’attaque aux risques dès la phase exploratoire et qu’on a plus de certitudes sur ce qu’on doit livrer, ce travail de livraison progresse plus vite qu’il ne le ferait autrement.
Vous avez peut-être déjà entendu ce vieux dicton « un problème bien énoncé est un problème à moitié résolu ». Quand les développeurs peuvent jouer avec un prototype crée pendant la phase exploratoire, poser des questions et identifier les cas d’utilisation manquants, alors si on décide qu’on doit vraiment bâtir une implémentation robuste de cette solution, ce travail de mise en production pourra être effectué plus rapidement, et ce sans toutes les circonvolutions et les délais si coûteux en temps en en argent.
L’article d’Henrik explique très bien les valeurs de base de l’agilité — et ce n’est pas rien car beaucoup d’équipes n’ont toujours pas compris ces valeurs. Ce que j’essaie d’expliquer ici c’est comment les équipes produit multi-disciplinaires expérimentées ont dépassé le Lean et l’Agile pour attaquer les risques de front, résoudre les problèmes difficiles pour leurs clients et leur business grâce à la collaboration entre le produit, le design et l’ingénierie, et pour porter leur attention sur les résultats commerciaux et non pas la simple mise en production de fonctionnalités.
Merci à Jeff Patton pour ces commentaires encourageants pendant la rédaction de cet article et à Henrik pour toutes ses contributions à notre industrie.
-
Le coût d’opportunité est le manque à gagner potentiel entre deux investissements ou deux types de financement. Le coût d’opportunité mesure la perte des biens auxquels on renonce en affectant les ressources disponibles à un autre usage. Le coût d’opportunité d’un investissement est le coût de la non-réalisation d’un investissement. Ce critère est l’un de ceux utilisés dans les choix d’investissement. Le coût d’opportunité sert ainsi à faire des arbitrages entre placements. (source) ↩