Le cycle de vie d'un produit
Un pattern fractal basé sur l'approche scientifique
On peut suivre une approche agile de bout en bout en commençant par explorer le produit avec du Lean Startup avant de l’exploiter avec Scrum.
Je me suis longtemps intéressé au cycle de vie des logiciels. Pas particulièrement le cycle en V, qui n’existe pas, mais les différentes approches qui vont du séquentiel à l’itératif.
C’était du temps où j’étais consultant en génie logiciel et aussi prof pour des étudiants en développement de logiciel.
Le chapitre 2 de mon livre Scrum revient sur ces notions de cycle en montrant comment le développement itératif transforme la façon de faire.
Mais sur le terrain, on rencontre parfois des mélanges hasardeux, comme le cycle en VRUM.
Une question qui revient depuis que je suis dans l’agilité, c’est :
qu’y a t-il avant le premier sprint ?
Après, c’est facile, on fait des sprints. Mais avant ? Bien sûr, ça dépend.
Deux phases pour le développement d’un produit
Dans l’édition 5 de Scrum, j’ai ajouté le paragraphe 2.2.4 Approche scientifique à deux phases pour donner un élément de réponse.
Voici un extrait de ce § :
Les scientifiques savent attaquer l’incertitude dans des problèmes complexes avec une approche qui consiste à faire une hypothèse, à l’expérimenter, puis à observer le résultat pour décider d’accepter ou rejeter l’hypothèse.
Par rapport à une simple approche itérative qui sollicite le feedback et l’accepte ou pas selon un jugement subjectif, la méthode scientifique base son acceptation sur des mesures. Si on utilise cette approche pour le développement d’une fonction d’un produit, l’observation suite à l’expérimentation permet soit de s’assurer de sa valeur et de continuer, ou d’apprendre qu’elle n’en n’a pas.
Le Lean Startup a popularisé cette notion d’apprentissage validé, avec l’idée de faire des cycles courts pour apprendre sur un nouveau produit. On entend parler à tout va de MVP (Minimum Viable Product), terme mal choisi car il ne s’agit pas d’avoir un produit, même minimal, à la fin d’un cycle, mais simplement un résultat qui permet de valider des hypothèses, et donc d’apprendre.
Si l’hypothèse n’est pas validée, le produit évolue pour passer à une autre fonction- nalité. On dit que le produit pivote.
Pour un produit, l’obtention d’un MVP correspond à la fin de la phase d’exploration et au début de la phase d’exploitation.
Dans la vie d’un produit, le Lean Startup a sa place dans la phase d’exploration, et Scrum dans la phase d’exploitation.
D’où ce schéma :
Quelques commentaires
- les phases d’exploration et d’exploitation sont reprises de Lean Entreprise, Humble & co
- la justification de deux phases distinctes y est clairement décrite, notamment parce que l’équipe qui explore n’a pas vocation à continuer ensuite pour l’exploitation
- la fin de la phase Lean Startup, c’est le MVP validé avec le Product/market fit (on a donc fait potentiellement plusieurs MVP avant).
La notion de MVP est abondamment utilisée de nos jours, avec parfois un positionnement bien différent comme dans le livre L’approche Lean pour la transformation digitale d’Yves Caseau choisi pour le prochain klub de lecture Agile Toulouse.
Avec l’agilité radicale
Pendant la phase d’exploration (et même après), on expérimente vite pour apprendre sur le produit, en validant auprès des utilisateurs qu’on a bien compris leur problème, puis que notre solution leur convient. Le Lean Startup est très orienté vers l’aspect économique, avec la validation qui porte sur le fait qu’ils sont prêts à acheter. L’agilité radicale ajoute des composantes sociale et économique écologique aux hypothèses qui sont expérimentées.
En phase d’exploitation, on va continuer à expérimenter pour apprendre et commencer à procurer régulièrement de la valeur. L’agilité radicale amène un système de valeurs qui ne se réduit à la valeur économique.
Le pattern deux phases est fractal
En écrivant le chapitre 2 de Scrum édition 5, je ne pensais pas considérer ces deux phases comme un pattern. Mais une fois dans le chapitre 6, j’ai trouvé qu’il pouvait s’appliquer de manière fractale :
Dans le chapitre 2, nous avions évoqué une approche en deux phases (explorer puis exploiter) pour un produit, tout à fait similaire: l’idée générale est de diminuer les risques et d’évaluer des options dans une première phase, et de réaliser dans une seconde.
Le pattern à deux phases est fractal : il est aussi applicable à la vie de la story, et à celle de la fonctionnalité.
Fractal, cela signifie que les mêmes concepts s’appliquent à différents niveaux.
J’ai résumé le principe fractal dans un tableau qui figure page 89 du livre, que j’ai revu pour l’occasion :
| Vie du produit | Vie de la fonctionnalité | Vie de la story | |
|---|---|---|---|
| Phase 1 | Explorer | Tester hypothèse | Affiner |
| Jalon | MVP validé | Hypothèse validée | Prête |
| Phase 2 | Exploiter | Développer dans une saison | Réaliser dans un sprint |
| Fin | Retrait produit | Mise en service (finie) | Finie |
Articles en relation
- les cycles de vie Scrum et OpenUp
- le cycle en V n’existe pas
- la présentation Scrum, mon scrotum dans laquelle figure le cycle en VRUM
- la définition de fini multi-niveaux
- la vie d’une feature
- features et stories
À noter que mon vocabulaire a changé depuis l’écriture de ces articles : je ne dis plus release mais saison, je ne dis plus feature mais fonctionnalité.