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 qui, à mon avis, explique parfaitement comment les équipes techniques 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 techniques" 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 techniques", je décris une équipe composée uniquement d'ingénieurs, ou 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 techniques, 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 soulignerai 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.
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 de la 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 de quelques mois à quelques jours.
J'essaie également de faire ressortir un autre point du modèle conceptuel de discovery/delivery que vous pouvez voir dans le graphique 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.
