Revisite de la métaphore des skateboards et des voitures
Auteur : Marty Cagan
Source : Skateboards vs. Cars Revisited
Date : 31/05/2018
Traducteur : Fabrice Aimetti
Date : 03/02/2024
Traduction :
Il y a près d'un an, l'un de mes coachs Agile préférés, Henrik Kniberg, a publié un article (fr) qui, à mon avis, explique parfaitement comment les équipes d'ingénierie peuvent tirer parti du concept de MVP et s'assurer qu'elles tirent le meilleur parti des méthodes Agile. 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 cet article.
J'insiste ici sur les "équipes d'ingénierie" car, dans cet article, j'essaierai d'opposer le concept à celui des véritables équipes produits multifonctionnelles.
Pour être clair, lorsque je parle d'"équipes d'ingénierie", je décris une équipe composée uniquement d'ingénieurs, où toute personne faisant partie de l'équipe a probablement un rôle de soutien tel qu'un simple product owner (par opposition à un véritable product manager).
En revanche, une équipe produit est composée d'un véritable product manager, d'un designer produit compétent et d'un certain nombre d'ingénieurs.
Ne vous méprenez pas : de nombreuses organisations ont simplement des équipes d'ingénierie, avec une personne désignée comme product owner qui suit les rituels Agile autour de la priorisation et de la gestion du backlog, mais qui n'a que peu ou pas de formation ou de compétences lui permettant d'assumer le rôle beaucoup plus large de product management.
Il en va souvent de même pour le product designer. Il peut avoir accès à un designer graphique, mais pas au designer produit spécialisé dans la conception de l'expérience utilisateur, le prototypage, la recherche utilisateur, l'interaction et la conception visuelle dont je parle.
Quoi qu'il en soit, si l'équipe ne dispose pas d'un véritable product manager ou d'un véritable product designer, je les renvoie généralement à l'article d'Henrik et leur dis que je pense que c'est le mieux qu'ils puissent faire.
Mais s'il s'agit d'une véritable entreprise produit axée sur la technologie, je leur fais comprendre qu'ils peuvent et qu'ils doivent faire mieux que cela.
Donc si vous disposez d'une véritable équipe produit multifonctionnelle, avec un product manager et un product designer compétents travaillant côte à côte avec les ingénieurs, comment vous y prendriez-vous pour réaliser ce travail ?
Dans l'exemple d'Henrik, l'équipe s'efforce à la fois de déterminer le bon produit à construire et de construire ce produit. Pour ce faire, elle dispose d'un outil principal : les ingénieurs. Ce que vous voyez est donc un produit développé progressivement, avec un effort important pour obtenir quelque chose que nous pouvons tester sur de vrais utilisateurs à chaque itération.
Henrik insiste sur le fait qu'ils construisent pour apprendre, mais ils le font avec le seul outil dont ils pensent disposer : les ingénieurs qui écrivent du code. Si vous lisez attentivement, Henrik mentionne que les ingénieurs n'ont pas besoin de construire des produits - ils peuvent construire des prototypes, mais avec la plupart des équipes que je rencontre, cet aspect est perdu de vue parce qu'ils ne comprennent pas qu'il existe de nombreuses formes de prototypes, dont la plupart ne sont pas destinés à être créés par des ingénieurs.
Examinons maintenant le premier principe que j'ai énoncé dans l'article Beyond Lean and Agile (Au-delà du Lean et de l'Agile). Si vous n'avez pas encore lu cet article, lisez-le maintenant, sinon ce qui suit risque de ne pas avoir de sens.
Le premier principe consiste à s'attaquer aux risques en amont, avant d'utiliser nos ingénieurs pour écrire une ligne de code de production. Plutôt que la notion relativement simpliste de skateboard/d'itération testable au plus tôt, nous plongeons plus profondément dans les risques et considérons explicitement la valeur, la facilité d'utilisation, la faisabilité et la viabilité économique.
Ensuite, sur la base des domaines que nous considérons à risque, nous choisissons l'outil ou la technique qui convient (la description des nombreuses techniques dépasse le cadre de cet article, mais je soulignerais qu'il existe quatre grands types de prototypes) et décidons s'il convient de le tester qualitativement ou quantitativement. Et nous testons non seulement avec les utilisateurs et les clients, mais aussi avec les autres membres de notre équipe et les différentes entités concernées de notre entreprise.
C'est le product discovery. Nous nous efforçons de trouver le bon produit à construire.
Dual-track
Le product manager et le product designer pilotent la majeure partie de cette activité de discovery, et le designer crée la plupart des prototypes dont nous aurons besoin pour faire face à ces risques. Les ingénieurs sont associés à chaque étape du discovery, à la fois pour peser sur la faisabilité de la solution proposée, mais aussi et surtout pour contribuer à l'amélioration de la solution elle-même.
Ce n'est pas que nous ne puissions pas utiliser les ingénieurs pour créer les itérations d'apprentissage décrites par Henrik, c'est simplement que cela prendrait beaucoup plus de temps (dans mon expérience, au moins la moitié) et produirait beaucoup plus de déchets, sans parler du coût d'opportunité.
Un travail de moyenne ou grande envergure dans un produit peut nécessiter de l'ordre de 5 à 15 itérations avant qu'il ne fonctionne aussi bien qu'il le devrait (ce que l'on appelle parfois le "time to money").
Si toutes ces itérations sont réalisées par des ingénieurs et que chacune d'entre elles nécessite une mise en production, nous en sommes probablement à plusieurs mois, voire plusieurs années, en supposant que le management ou l'équipe n'ait pas perdu patience. Cependant, si nous pouvons effectuer ces mêmes 10 à 15 itérations en une semaine de discovery, nous avons réduit de plusieurs mois à quelques jours le temps nécessaire pour fournir la bonne solution (définie comme construire le bon produit et bien construire le produit) à nos clients.
J'essaie également de faire ressortir un autre point du modèle conceptuel de discovery/delivery que vous pouvez voir dans le schéma ci-dessus (au risque de vous présenter trop de points à la fois, mais je pense que c'est un point important).
Une fois que nous connaissons le produit que nous devons construire, les ingénieurs doivent non seulement construire et livrer ce produit, mais ils doivent le faire d'une manière qui soit évolutive, performante, fiable et maintenable, et dans de nombreuses entreprises avec lesquelles je travaille, les systèmes sont à grande échelle, et ce n'est pas si facile. Ce n'est certainement pas le genre de chose que l'on revisite nonchalamment à chaque sprint.
Les ingénieurs doivent vraiment savoir qu'il s'agira d'une voiture avant de pouvoir proposer une architecture adaptée à cette tâche, et ils peuvent en fait choisir de mettre en œuvre cette architecture avec une stratégie de delivery différente de celle conçue pour apprendre rapidement.
Par exemple, ils peuvent finir par construire et tester un ensemble de micro-services (que l'on peut considérer comme les pneus et le moteur de la voiture) et ensuite une plus grande partie de l'expérience front-end plus tard dans la livraison. Nous voulons toujours éviter une livraison big bang, mais encore une fois, c'est aux ingénieurs de décider et il n'est pas nécessaire que la stratégie de delivery soit optimisée pour l'apprentissage - c'est à cela que sert le discovery.
Il y a aussi un deuxième effet important à faire du product discovery comme je le suggère ici. Lorsque les risques sont abordés dans le cadre du discovery et que le travail de delivery nécessaire devient clair, ce travail de delivery progresse beaucoup plus rapidement qu'il ne l'aurait fait sinon.
Vous avez probablement entendu la vieille expression selon laquelle "un problème bien énoncé est un problème à moitié résolu". Lorsque les ingénieurs sont en mesure de jouer avec un prototype créé lors du discovery, de poser des questions et d'identifier les cas d'utilisation manquants, alors si et quand nous décidons de construire une mise en œuvre robuste de cette solution, le travail de delivery peut se dérouler beaucoup plus rapidement, et sans tous les retards et détours coûteux et chronophages.
L'article d'Henrik montre comment obtenir la valeur de l'Agile fondamental - et ce n'est pas une mince affaire, car de nombreuses équipes n'obtiennent pas encore cette valeur. Ce que j'essaie de montrer, c'est comment de solides équipes de produits multifonctionnelles sont allées au-delà du Lean et de l'Agile pour s'attaquer aux risques dès le départ, résoudre des problèmes difficiles pour nos clients et notre entreprise grâce à la collaboration entre le produit, la conception et l'ingénierie, et se concentrer sur les résultats business et pas seulement sur la livraison de fonctionnalités.
Note : Nous remercions Jeff Patton pour ses commentaires avisés sur une version préliminaire de cet article, ainsi que Henrik pour ses nombreuses contributions à notre domaine d'activité.
NdT : cf. traduction de Franck Taillandier, La métaphore du skateboard et de la voiture revisitée.