La lecture des annonces de postes de développeurs ne ment pas : l’agilité est devenue un must. Les cérémonies, du stand-up meeting au poker planning, ponctuent le quotidien des startups et de plus en plus d’organisations de R&D s’y sont mises. Pour autant, l’agilité ne suffit pas à résoudre l’équation de l’efficacité du R&D. Parfois, c’est même un cache-misère stratégique !

L’agilité prétend répondre à plusieurs besoins, dont en particulier :

• La prise en compte, dès le début et au fur et à mesure, des retours utilisateurs, afin de s’assurer que ce qui est développé va bien convenir aux utilisateurs in fine ;
• Une auto-organisation efficace du développement au quotidien avec une meilleure coopération entre développeurs et gens de produit (Product Owners) ;
• Une visibilité tôt dans le projet (pas d’effet tunnel), orientée valeur.

Pour les développeurs, elle a permis de sortir de l’enfer des estimations non tenues, de la maîtrise à tout prix des délais.

En effet, classiquement, et pour faire simple, les variables d’ajustement d’un projet sont le temps, les ressources, la qualité, et le contenu. Et lorsqu’un projet ne se déroule pas comme prévu, pour réussir à tenir des délais, on peut bien rêver d’utiliser plus de ressources, mais l’impact sur les coûts est important et l’inertie trop forte : délais de recrutement, d’acculturation au projet, etc. ce qui rend cette piste difficile. D’autant qu’ajouter plus de ressources, sur un temps comprimé en tout cas, n’aboutit pas forcément à plus de résultat, comme l’indique le mythe du mois-homme, très bien re-décrit ici dans sa version moderne. Comme il est également difficile d’envisager de diminuer le contenu, c’est en général la qualité qui fait les frais en premier, les développeurs négligeant les tests et la pureté du code pour aller vite. Et à la fin, malgré ces efforts, le plus souvent, le contenu finit tout de même par être diminué et les délais sont dépassés également ! Bref, tout le monde est mécontent.

Avec les méthodes agiles, on adresse au fur et à mesure cette problématique, par des itérations qui permettent d’atteindre progressivement tout ou partie des objectifs finaux, ce qui permet d’éviter « l’effet tunnel ». En particulier, on définit un sous-ensemble acceptable (MVP) de la cible de contenu, en s’assurant d’avoir la capacité de l’atteindre en cours de route, ce qui laisse de la latitude pour gérer le compromis contenu/délais sans dégrader la qualité.

Bref, cette agilité est, à juste titre, parée de biens des vertus, à condition toutefois d’être pratiquée intelligemment. Car il arrive souvent qu’elle soit juste brandie comme une potion magique, et dans ces cas, évidemment, elle n’apporte pas les miracles escomptés.

Mais même lorsqu’elle est bien implémentée, l’agilité de suffit pas. Au cours des nombreux audits d’éditeurs de logiciel que j’ai pu faire, j’ai souvent constaté deux défauts importants que l’agilité n’avait pas résolus :

• Le manque de focus sur la valeur de ce qui est développé et les conditions de la réalité de cette valeur, vendue et déployée chez les clients ;
• La difficulté à piloter macroscopiquement l’activité de R&D. Le symptôme en est le backlog fourre-tout qui grossit indéfiniment. Dans ces cas, la définition ce que l’on fait est prise au fil d’itérations de court terme, sans évaluation globale (sans possibilité par exemple de « go / no go » basé sur une évaluation globale des coûts et des besoins à moyen-long terme).

Ces deux manques sont, en somme, les signes d’un manque plus général : celui d’un Product Management qui gère efficacement la Stratégie Produits tout autant que les détails du contenu produit au fil de l’eau.

Pourquoi développe-t-on ? Quelles ressources mobiliser, quelles fonctionnalités cibler, dans quel ordre, voilà des questions que tout comité de direction se pose. Pour que l’activité R&D d’un éditeur s’inscrive dans un plan de développement d’entreprise, il est nécessaire d’articuler un Product Management qui soit à la croisée du R&D, du Marketing, du Commerce, du Support et de la Stratégie.

Dans les organisations orientées projet, comme par exemple dans les ESN, les directions informatiques de sociétés, etc., pas besoin de marketing, pas d’étude de la concurrence, pas de stratégie, et l’application développée est généralement pour une seule société. Ainsi, il suffit de récolter les retours utilisateurs pour alimenter un backlog, le prioriser pour décider de l’activité de l’équipe de développement. C’est ce que préconisent en général les formateurs agiles. Un Product Owner, ambassadeur des utilisateurs au sein du développement agile suffit à prioriser les besoins.

Mais chez les éditeurs B2B, c’est différent et notablement plus complexe : les retours utilisateurs sont bien sûr récoltés et remontés, mais ils viennent en concurrence avec des retours des ventes, du support, avec des inputs du marketing, et de la stratégie. C’est pourquoi, on a besoin d’un Product Management fort qui sache orchestrer un contenu produit en réponse à des besoins de natures différentes, d’origines différentes, et de niveaux différents.

La question de savoir comment on peut associer les clients à la définition des produits, comment articuler un fonctionnement efficace entre Product Manager, Business Owner, Product Owners et clients ne sera pas débattue ici. Mais il il est évident que le rôle de ces différentes fonctions doit être pensé et que leur organisation n’est pas simple.

Si la définition de la stratégie Business revient à l’équipe de direction, voire au CEO de l’entreprise, la déclinaison de cette stratégie en une stratégie produit (i.e. le plan de marche produit sur plusieurs années, aussi appelé la roadmap produit) requiert un travail permanent du Product Management. Les positions stratégiques, telles que définies se traduisent naturellement pour le produit en versions majeures. En effet, la vie d’un produit s’articule naturellement en une succession de versions, des versions dont on peut parler, dont on peut faire la publicité.

Si les features sortent de façon non planifiable au gré de versions quotidiennes, résultant d’un process de sélection par priorisation du backlog, comme c’est enseigné dans certaines formations à l’Agilité où l’on préconise non seulement une intégration continue, mais aussi des livraisons continues (Continuous Delivery), et même un déploiement continu, …, alors le produit n’est plus gérable à la vente. Le plus souvent, les clients non plus ne veulent pas de ce processus continu, en tout cas pas pour les grands changements, car ils ont aussi le besoin de qualifier les nouvelles versions, parfois en mobilisant des utilisateurs testeurs, et ils doivent, le cas échéant, mettre à jour de la documentation, des manuels ou des vidéos de formation, accompagner le changement… Et puis ils veulent souvent connaître à l’avance le contenu des futures versions, afin de vérifier s’il va dans le sens de leurs besoins stratégiques. Ajoutons que l’éditeur a besoin de marketer ses produits, i.e. communiquer sur leurs features principales, pour faire parler de lui et ainsi augmenter sa notoriété et son référencement. C’est un des leviers de développement du business.

Bref, il est nécessaire d’élaborer et de maintenir une vue de haut niveau du contenu du produit et de ce qui en fait sa valeur, en agrégeant ces contenus au rythme de versions (entre 1 et 4 par an, suivant les cas, et notamment en fonction du secteur, de la maturité du logiciel, …

Cette vue prospective de sortie de versions, avec un contenu planifié macroscopiquement, est ce que l’on appelle une roadmap stratégique.

Dans une vision roadmap, les besoins sont vus de haut, ils sont macroscopiques. Les features (fonctionnalités en français) qui y répondent sont présentées également de façon macroscopique. La fenêtre de temps de la roadmap est généralement entre 1 an et 3 ans suivant le contexte. Il y aurait beaucoup à dire aussi sur la récolte et l’analyse des besoins, guidés par la valeur, et sur la place de cette valeur tout au long du process, mais ce sera le sujet d’un autre article. Retenons juste ici que la valeur générée par le produit est l’arbitre idéal des choix produit.

Pour résumer, le contenu du produit se décide donc macroscopiquement en amont, se formalise dans une roadmap qui scande les développements de features stratégiques au rythme de versions en réponse à des besoins stratégiques.

Dans ce qui précède nous avons parlé d’une vision, d’une stratégie, d’une roadmap à un instant t figé. Mais dans la réalité, au fur et à mesure du temps, tout bouge, tout change, donc la vision doit changer, et la stratégie aussi.

Le pilotage stratégique du produit consiste donc à faire évoluer la vision produit et la stratégie produit en tenant compte des changements.

Parmi les éléments à prendre en compte pour mettre à jour la roadmap, notons :

• La variation de la capacité du développement
• L’évolution des technologies
• De nouvelles possibilités de partenariat
• L’évolution de la concurrence
• Des retours clients et prospects
• Des retours des vendeurs
• Des évolutions de la stratégie business
• …

Typiquement, une roadmap doit être revue et modifiée tous les 3 mois environ.

Et c’est une responsabilité du Product Management.

Mais comment, me direz-vous, s’articule un processus d’élaboration de la roadmap avec un processus de développement agile ? Et ce processus est-il lui-même agile ?

Les deux fonctionnements sont complémentaires et peuvent parfaitement se superposer.

En effet, on peut tout à fait considérer que chaque version ou itération est un projet nouveau sur quelques semaines ou quelques mois, et que son développement peut se faire en suivant une méthode agile.

Ainsi, en début de période (soit environ tous les trois ou six mois, selon la cadence adaptée au business), on définit un objectif :

• minimal (sorte de MVP pour la version),
• et maximal (qui va permettre de circonscrire le contenu).

Il est très important, avant de dérouler les sprints pour la nouvelle macro-itération, de réinitialiser le backlog à partir du backlog précédent et du contenu maximal désiré pour la version, …

Au niveau macroscopique, comme indiqué plus haut, on revoit la roadmap en continu en fonction des changements stratégiques survenus, et on la republie tous les 3 mois.

La méthode de développement des macro-itérations est agile. Mais l’agilité peut également, et doit, à notre sens, gouverner le processus de gestion des macro-itérations au travers de la constitution de la roadmap et du pilotage stratégique, qui relèvent du domaine du product management.

Sans entrer dans les détails, qui pourront faire l’objet d’un article dédié, retenons qu’un plan stratégique doit évoluer au fur et à mesure du temps et que de ce fait, la roadmap également. La valeur peut servir de fil rouge et d’arbitre dans ce processus, ce qui implique une gestion rigoureuse de la valeur par le Product management. J’entends valeur au sens de la valeur de ce qui est apporté aux clients et utilisé, de ce qui peut être constaté chez les clients en termes de bénéfices, de résolution de peines des clients, de ROI… mais aussi, de valeur pour l’éditeur lui-même.

Difficile également de ne pas évoquer également le besoin de planification des ressources, à la fois sur le moyen terme, mais aussi sur le court terme pour ce qui concerne la gestion budgétaire du contenu des versions. Ce sujet pourra avantageusement faire l’objet d’une publication ultérieure.

A une époque où tout le monde parle d’agilité, où les formations à l’agile sont légion, l’édition de logiciels s’inscrit bien entendu depuis des années dans cette tendance réclamée par tous, à commencer par les développeurs. Mais l’éditeur doit aussi piloter son activité de façon stratégique, dans une vision de moyen/long terme. La complexité des inputs (marché, stratégie business, innovation, retour clients, retours vendeurs et partenaires, …) et leur possible différence de niveau et de nature militent, à notre sens, pour la mise en place d’une agilité à deux niveaux, qui nécessite une activité de Product Management forte et efficace.

Le Product Management doit orchestrer un contenu produit en réponse à des besoins de natures différentes, d’origines différentes, et de niveaux différents. Cela passe par la mise en place d’une roadmap stratégique qui planifie macroscopiquement le contenu du produit en agrégeant les besoins au rythme des versions en réponse aux besoins stratégiques.

Le Pilotage Stratégique est crucial pour faire évoluer la vision produit et la stratégie produit en tenant compte des changements et éléments tels que la variation de la capacité du développement, l’évolution des technologies, de nouvelles possibilités de partenariat, l’évolution de la concurrence, des retours clients et prospects, des retours des vendeurs, et des évolutions de la stratégie business. La mise à jour régulière de la roadmap est une responsabilité clé du Product Management.

Mais comment s’articule un processus d’élaboration de la roadmap avec un processus de développement agile ? Les deux fonctionnements sont complémentaires et peuvent parfaitement se superposer. Il est important de définir un objectif minimal et maximal en début de chaque période pour chaque version ou itération, qui peut être développée en suivant une méthode agile. La valeur peut servir de fil rouge et d’arbitre dans ce processus.

Parmi les sujets adjacents, j’en ai mentionné quelques-uns qui mériteraient un article spécifique. Par exemple : la gestion budgétaire du contenu produits, l’articulation des rôles pour la définition des produits, la gestion produits par la valeur…

On renvoie également le lecteur à des articles sur les méthodes agiles, et en particulier sur SAFe, dont il trouvera un article introductif ici :

https://www.softfluent.fr/blog/safe-scaled-agile-framework-agilite/