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
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".
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".
