Le Modèle Produit et l'Agile
Auteur : Marty Cagan
Source : The Product Model and Agile
Date : 28/01/2025
Traducteur : Fabrice Aimetti
Date : 10/02/2025
Crédit : Chloé Renault
Traduction :
L'une des questions que l'on me pose, sous diverses formes, est la suivante : quelle est la relation entre Agile et le Product Operating Model (modèle opérationnel produit) ?
S'agit-il de la même chose ? Le modèle produit est-il simplement une évolution de l'Agile ? L'un est-il une composante de l'autre ? Ou, pour les plus cyniques, le modèle produit est-il simplement la prochaine certification pour les coachs Agile ?
À un certain niveau, il s'agit d'une question très simple. L'Agile est simplement l'une des trois principales dimensions (en) du modèle produit. Je développerai un peu plus loin chacune de ces trois dimensions, mais l'une d'entre elles concerne la manière dont une équipe produit construit, teste et déploie son logiciel.
Mais cette réponse est trop simpliste et masque plusieurs concepts importants.
Pour comprendre les nuances, il est important de clarifier quelques points :
Premièrement, le modèle produit n'est pas nouveau ; il existe depuis plus de 20 ans. Je n'ai donc jamais prétendu que le modèle produit était "la prochaine grande nouveauté", car je pense que ce n'est pas vrai.
Les entreprises produits performantes suivent le modèle produit depuis des décennies, mais la plupart des entreprises dans le monde n'ont été exposées que récemment à ce modèle, ce qui explique pourquoi tant de gens le considèrent comme nouveau.
Deuxièmement, et je sais que cela en irrite plus d'un, il existe aujourd'hui des définitions très différentes de ce que signifie "Agile". Certains considèrent SAFe comme Agile. Si c'est ce que vous considérez comme Agile, alors je dirais que l'Agile ne joue aucun rôle dans le modèle produit, puisque SAFe est pratiquement l'antithèse du modèle produit (en).
Cette différence est souvent qualifiée aujourd'hui de "faux Agile" par rapport au "vrai Agile". Et pour être clair, si vous utilisez XP, ou Kanban, ou Scrum, ou même aucune des cérémonies Agile, mais que vous faites du déploiement continu de manière cohérente, alors au moins en ce qui me concerne, vous faites du "vrai Agile".
Troisièmement, nous devrions séparer les principes de l'Agile (tels que définis dans le Manifeste Agile) des divers processus, principalement de gestion de projet, qui ont été mis en place autour de ces principes (par exemple Scrum, Kanban, XP).[1]
Je pense que la plupart des gens reconnaîtraient que les principes Agile sont en effet utiles et pertinents, et ce sont ces principes qui ont d'abord attiré beaucoup d'entre nous vers l'Agile. Cela dit, ces principes se rapportent principalement à la construction, au test et au déploiement de logiciels, et non à la question de savoir ce qu'il faut construire.[2]
Enfin, il est également important de souligner qu'il existe un principe Agile qui peut être suffisant pour un travail logiciel sur mesure ou en sous-traitance, mais qui ne l'est pas pour un travail sur un produit commercial. Il s'agit du principe selon lequel "un logiciel opérationnel est la principale mesure d'avancement".
Les entreprises ayant recours à un modèle produit savent qu'un "logiciel opérationnel" n'est qu'un livrable, et que le plus grand défi consiste à s'assurer que ce que nous construisons résout le problème sous-jacent et atteint les résultats nécessaires, également connus sous le nom d'"impacts" (outcomes).
Ces quatre mises en garde importantes étant faites, nous pouvons revenir à la question initiale.
Le modèle produit aborde trois dimensions majeures : comment décider des problèmes à résoudre (stratégie produit ~ product strategy (en)), comment résoudre ces problèmes (découverte produit ~ product discovery (en)), et comment construire, tester et déployer vos solutions (réalisation produit ~ product delivery (en)).
Le véritable Agile peut certainement contribuer à cette troisième dimension.
Mais cela soulève la question de savoir si et comment les coachs Agile peuvent aider une organisation à se transformer vers le modèle produit ?
Certains coachs Agile ont une solide expérience de la stratégie produit ou de la découverte produit, ou des deux, et ces personnes peuvent être des coachs produit (en) d'une valeur exceptionnelle.
Mais la plupart des coachs Agile ont axé leur carrière sur les activités d'ingénierie et de construction, ce qui est bien entendu une bonne chose. Dans les cas où les coachs Agile ont une expérience pratique et pertinente du travail difficile que représente le passage au déploiement continu, la mise en place de l'instrumentation, de la télémétrie et de la surveillance nécessaires, et la mise en place d'une infrastructure de déploiement pour prendre en charge des éléments tels que les tests A/B, ces coachs Agile (également connus sous le nom de "Delivery Coaches" (en)) peuvent être très utiles pour la transformation.
Mais si vous avez un coach Agile qui n'a pas d'expérience pertinente en matière de stratégie produit, de découverte produit ou de réalisation produit, il est probable qu'il se concentre plutôt sur le processus spécifique que vous appliquez, ce qui est nettement moins important lorsque l'on passe au modèle produit (voir le premier principe du modèle produit : les Principes plutôt que les Processus (en)).
C'est pourquoi, même si nous passons une grande partie de notre temps à encourager les équipes produit à passer au modèle produit, nous ne préconisons ni ne reconnaissons aucune des nombreuses certifications. Les certifications peuvent s'appliquer à des processus formels, mais nous recherchons plutôt l'expérience pertinente que l'on trouve dans les entreprises ayant adopté le modèle produit (en).
Merci à Josh Kerievsky pour ses commentaires sur la version initiale de cet article.
Notes
[1] C'est pourquoi j'ai été déçu, mais pas surpris, de voir le mariage de l'Agile Alliance et du Project Management Institute (PMI).
[2] Certains agilistes affirment que l'on peut utiliser l'approche Agile pour déterminer ce qu'il faut construire, simplement en construisant et en voyant si le produit fait ce que l'on veut. Bien que cela soit en partie vrai, ce serait la manière la plus lente et la plus coûteuse de découvrir un produit, sans parler d'abuser de vos pauvres clients. Il s'agit en fait du modèle "prêt - tirez - visez".