Davide Casari, co-fondateur d’AgileItalia, est venu nous parler d’une des tendances 2022 dans le domaine Agile : le Refactoring Life Cycle.

Vous avez un produit en déclin sur le marché ? Voici comment sortir d’une situation de crise, grâce à ce modèle, très utile pour tout le monde.

J’ai été agréablement surpris la première fois que quelqu’un a mis sous mes yeux, à l’université, le graphique qui reflète le cycle de vie d’un produit. J’avais peut-être 19/20 ans et je me suis dit que la personne qui a publié ce graphique très intelligent, avait certainement bien réfléchi et étudié la question avant.

Pratiquement, ce graphique prédit l’avenir. Un avenir où à la fin, aussi bon que vous soyez et aussi fort que vous croyiez en votre idée, vous perdez toujours. Mais que se passe-t-il si nous décidons « maintenant » que nous ne voulons pas accepter la phase finale, celle du déclin ?

Dans le secteur Agile, on parle beaucoup de la façon de fabriquer un produit mais jamais de la raison pour laquelle il finit par décliner. Comment trouver une solution de contournement à ce destin tragique ?

Commençons par essayer de comprendre ensemble si la phase de déclin d’un produit est due au marché, qui un jour décrète la fin du produit ou si nous l’infligeons nous-même, lentement et au fil du temps et la vivons jusqu’à la mort effective du produit lui-même.

Refactoring Life Cycle

Dans cet article nous réorganisons les idées sur la phase de Refactoring d’un produit, c’est-à-dire que nous partons d’un produit qui existe déjà sur le marché, qui entre dans sa phase de déclin et nous cherchons la bonne méthode pour éviter cette fin tragique.

Prenons un exemple simple connu de la plupart des gens : le Nokia Lumia était réputé pour la qualité de Nokia, c’était un produit en faillite, qui a décliné et est mort. Pourquoi ? Est-ce à cause du produit ? du marché ? ou des personnes impliquées dans le développement du produit ?

Commençons par nous détacher complètement du concept de vente, puisque le concept lié aux ventes déforme la réflexion sur les problèmes réels. Je voudrais vous rappeler que l’un des principes fondamentaux de la méthodologie Lean Production est de prendre des décisions à long terme, au détriment des gains à court terme.

Pourquoi est-ce que je dis ça ? Il faut se détacher de la notion de vente car toutes les décisions que nous prenons doivent avoir un souffle qui puisse nous faire penser, dans une  phase de «hauts revenus », à une stratégie pour faire face au marché lorsque le produit entre dans sa phase de déclin.

Pour ce faire, la stratégie doit au moins être abordée en suivant ce que nous avons défini comme le Refactoring Life Cycle. Analysons en détail ce que doivent être les phases de refactoring d’un produit pour être prêt à affronter l’inévitable phase de déclin :

Phase d’indifférence

La première est la phase d’indifférence, ou la soi-disant zone de confort.

Notre produit génère des revenus quelle que soit la période de l’année : il n’y a pas d’équipe dédiée car c’est maintenant un produit mature qui prospère, sans trop de problèmes. Aucun espace n’est laissé aux membres de l’équipe pour travailler dessus et s’il y a problème quelqu’un intervient à la volée et fixe le problème « comme ça vient » car « tant que ça marche on continue ». Il n’y a pas de vision future du produit.

Au bout d’un certain temps, arrive le moment du choc. C’est le moment où nous ne pouvons plus prétendre que nous ne nous soucions pas de certains événements. Ce moment peut être, selon le point de vue, à la fois un choc positif (changement technologique) ou négatif (l’arrivée d’un concurrent sur le marché) mais dans les deux cas, il oblige l’organisation à changer.

Phase de panique

La deuxième phase est celle où l’entreprise panique, c’est-à-dire que vous réalisez que vous devez mettre la main sur le produit mais à ce stade, personne ne veut le faire car personne n’a les connaissances techniques du domaine. Un bouc émissaire est sans cesse recherché et chacun reproche aux managers des autres de ne pas s’en être souciés avant. Ceux-ci à leur tour se plaignent du manque de budget, de ressources qui devaient être consacrées à d’autres projets et d’un « sponsor de niveau C » efficace, qui ferait avancer l’importance du produit.

La phase de panique, cependant, doit nécessairement prendre fin à un moment donné, soit parce que tout le monde a démissionné et quitté l’entreprise, soit parce que le moment de la prise de conscience arrive. A ce moment, il y a une réelle prise de conscience, vous réalisez qu’il faut arrêter d’avoir peur et cherchez à comprendre si cela a du sens d’essayer de sauver le produit et si oui, vous retroussez vos manches pour revoir/améliorer le produit. Toutes les personnes dédiées à l’équipe doivent « assumer la responsabilité » du travail qu’elles auront à effectuer.

Attention ! L’agilité est souvent utilisée uniquement pour la gestion du travail, compromettant l’état d’esprit Agile qui est à la base de la méthodologie. Si vous travaillez de manière mécanique, en ne respectant que les techniques et pratiques, vous êtes face à une gestion du travail simple et vous prenez la part la moins importante de l’état d’esprit Agile. L’autonomie et la responsabilisation des équipes est l’une des pierres angulaires d’Agile et chacun au sein de l’équipe doit essayer d’atteindre l’objectif commun.

Phase d’action

Le moment est venu de passer à l’action, l’entreprise s’organise pour atteindre l’objectif. Le sponsor produit (C-Level) entre en jeu, rassemble le ou les managers qui doivent s’occuper de constituer l’équipe de travail et donne le budget par département/domaine de travail.

À ce stade, nous entrons au cœur de la méthodologie de travail Agile : les techniques et pratiques que beaucoup connaissent et qui nous ont toujours permis de démarrer de la meilleure façon pour la conception et le développement du produit, continuent maintenant de nous aider dans la phase de Refactoring .

Grâce à Inception et Envisioning, l’équipe s’implique dans ce qui doit être fait, elle est sensibilisée et impliquée dans la réflexion sur l’idée du futur produit. L’ensemble des pratiques telles que Value Stream MAP, User Story Mapping, Stakeholders Map, Risk Analysis et l’évaluation des KPI permettent à l’équipe de procéder avec plus de confiance dans la révision des valeurs qui caractériseront le produit sur le marché.
Ensuite, vous entrez enfin dans la partie de la courbe qui vous plaît, celle des profits : tout fonctionne, le marché est de votre côté, vous livrez en continu des fonctionnalités en fonction de ce que demandent vos parties prenantes.

Moment du dilemme

Puis vient le moment du dilemme ou il faut se demander : voulez-vous rester concentrés sur le produit ou revenir à une vision de projet ?

Les deux points de vue s’opposent :

• La vision produit permet d’avoir une équipe dédiée qui suit et comprend parfaitement le marché et est prête à affronter les évolutions technologiques puisqu’elle est totalement concentrée sur le produit.
• La vision projet, en revanche, permet de boucler un cycle et au bout d’un certain temps, l’équipe se disperse, les membres retournent à leurs occupations initiales et l’équipe se formera de nouveau lors des prochains moments de choc.

Bien sûr, la logique nous amène à penser que si nous suivons une vision projet, nous reviendrons sûrement tôt ou tard à la phase d’indifférence, en relançant le « Product Refactoring Life Cycle » et en fonction du comportement de l’équipe, cela peut ou non redevenir un produit à succès.
Les possibilités de business au sein d’une organisation sont tellement variées que ce modèle ne permet pas de dire quelle est la bonne méthode pour gérer le Refactoring Life Cycle.

En avoir conscience et avoir un modèle à suivre pour se préparer à affronter la phase de déclin, proposé par Raymond Vernon (auteur de Product Life Cycle Stages), nous permet d’être plus précis dans les décisions que nous devons prendre lorsque nous pensons à l’avenir de nos produits sur le marché. Et vous ? Quelle vision choisiriez-vous ?

Davide Casari

Co-fondateur d’AgileForItaly, AgileItalia et AgileExperienceConference, Davide Csari est également Product Owner au sein du groupe Cerved.