Un récent billet de Pablo Pernot (Pourquoi une “user story” technique est un aveu d’échec) a soulevé quelques débats dans la communauté agile.
J’ai l’impression que la discussion est partie (un peu vite, c’est l’effet twitter) sur de mauvaises bases et que c’est pour ça que personne n’est d’accord. En fait plusieurs personnes ont raison mais elles ne parlent pas de la même chose.
En très simplifié(1), Pablo explique qu’une User Story doit avoir une valeur business et qu’une story de refactoring ne peut pas avoir de sens pour l’utilisateur final. Le refactoring devrait intervenir tout au long de la vie du produit et, lorsqu’il devient assez lourd pour justifier de bloquer une part importante du temps du sprint pour figurer au backlog, c’est un constat d’échec.
“La technique pour la technique n’a jamais de valeur” : je suis d’accord (c’est un bon début pour une conversation). C’est ensuite que nos points de vue divergent.
Là où je suis moins d’accord c’est que le refactoring, surtout un refactoring lourd n’est que rarement de la “technique pour la technique”, ou alors là il faut effectivement changer un truc dans l’équipe. Dans ce que j’ai pu voir c’est souvent un besoin de l’équipe de restructurer en profondeur une architecture qui est arrivée en bout de course ou de prendre en compte une évolution technique. L’an dernier, à Agile France, nous avions par exemple une passionnante session présentée par Emmanuel Hugonnet (J2EE m’a tuer) sur la difficulté d’une équipe confrontée à un produit qui s’est construit sur quinze ans de couches techniques aujourd’hui totalement obsolètes.
Donc oui le développement doit être piloté par la valeur business mais non il ne doit pas être restreint aux seules User Story fonctionnelles.
Je crois d’ailleurs qu’il y a un glissement de vocabulaire qui introduit de la confusion. “User Story” ça veut bien dire “histoire utilisateur”, pas “contrainte technique”. Sauf que Scrum ne parle originellement pas de “User Stories” mais de “Backlog Items”. Pour ce que j’en sais c’est Mike Cohn qui a rapporté dans Scrum ce concept dérivé d’XP mais il faut lui redonner sa juste place (j’ai un background XP, bien avant de découvrir Scrum): l’idée c’était de contrer la tendance naturelle des utilisateurs, et des équipes, à sauter directement du besoin à la solution technique. La User Story a comme principe fondateur de reposer le problème en terme de services rendus : qu’est-ce que l’utilisateur va pouvoir faire grâce au logiciel, pour quels bénéfices. C’est donc super pertinent d’utiliser la structure User Story pour l’expression des besoins utilisateurs. Mais la valeur business ne se limite pas à la satisfaction des utilisateurs.
Le rôle du PO n’est pas de satisfaire les utilisateurs. Il est de maximiser le retour sur investissement du produit. La différence, pour moi, se situe à deux niveaux : la prise en compte de l’ensemble des parties prenantes au projet, d’une part, et la prise en compte du long terme d’autre part. Je vais faire une parenthèse hors sujet pour expliquer mon point de vue.
J’ai engagé ma boite dans une démarche de RSE (Responsabilité Sociale et Environnementale) qui doit se traduire par une labellisation Lucie. Cette démarche a un coût direct et aucun bénéfice immédiat. Pourtant je suis convaincu que le ROI sera positif et rapide car je prends en compte la valeur immatérielle de cet investissement qui valorisera l’entreprise à moyen terme. La valeur financière d’une entreprise (je pique l’explication à Alan Fustec, grand Gourou du sujet) c’est sa capacité future à générer des cashflows positifs (plus la trésorerie disponible). Au delà de gagner de l’argent tout de suite la valeur de ma boite repose donc aussi sur sa capacité à avoir, demain, une offre pertinente sur un marché porteur, des clients sains et fidèles, des collaborateurs motivés, compétents et loyaux, des fournisseurs fiables et engagés … toutes ses choses qui ne se construisent que dans un temps long et en respectant ses partenaires aujourd’hui pour pouvoir compter sur eux demain.
(fin de la parenthèse)
Pour un produit logiciel c’est pareil. La valeur doit prendre en compte la capacité à continuer à monter en charge et à innover demain. Donc, si l’architecture initiale (qui était pertinente initialement) devient inadaptée compte-tenu de l’évolution du produit, ou tout simplement de sa montée en charge, il faut absolument pourvoir considérer la valeur business du refactoring, même si pas un seul utilisateur ne comprend ce que ça signifie ou ne serait prêt à payer un centime pour ça. Ici ce n’est pas le besoin utilisateur court terme que l’on sert, c’est le besoin futur.
Pour résumer je dirai que le PO doit, dans ses arbitrages, prendre en compte non seulement la production de valeur à court terme, c’est à dire la livraison de plus de service, plus de qualité, plus de performance, à ses parties prenantes mais il doit aussi veiller au juste investissement dans les sujets de demain. Et comme l’outil du PO c’est le backlog, il doit pouvoir intégrer dans son backlog des “items” non fonctionnels.
C’est, je crois, également le propos de Philippe Kruchten (What color is your backlog, très bon résumé sur InfoQ) repris par Claude Aubry dans son tweet.
Du coup, j’ai envie de dire qu’on peut choisir entre deux approches : soit on unifie le vocabulaire, en parlant de “backlog items” (retour aux sources) ou en élargissant la notion de “user” pour y inclure l’utilisateur final mais aussi l’équipe de développement, l’équipe d’exploitation, dans certain cas les installateurs, distributeurs et techniciens de maintenance ou de support…
Soit on distingue, en effet, plusieurs types de “stories”. J’ai envie de proposer “Team Story” en complément de “User Story” même sis pour ma part, je m’en tiens plutôt à la première solution (Backlog Item).
En conclusion, je rajouterai encore à la confusion (j’aime bien, c’est mon coté rebelle).
Dans le jeu que nous avons développé avec Pierrick Revol (Objectif Mars (2)) nous mettons justement ce sujet en évidence : l’équipe ne peut pas consacrer 100% de sa capacité à produire des fonctions utilisateurs sinon elle est rapidement incapable de produire. Mais il n’y a pas que la dette technique qui s’accumule et la ralentit. Il y a aussi la dette de compétence et la dette de motivation. Le backlog de sprint doit donc comprendre une part de dépilement du Backlog produit + une part d’investissements pour demain (R&D, Lab, Formation, Archi, Investigations fonctionnelles, …) et une part de mou (du buffer pour les imprévus).
Sans marges, c’est la fatigue qui s’installe. Sans formation continue (tant sur le plan technique qu’en termes de connaissance fonctionnelle) les talents s’érodent avec chaque rotation de l’équipe. Sans renouvellement technique, sans challenge, sans célébration, sans fun, c’est la motivation qui s’érode.
Je crois que c’est aussi le rôle d’un bon PO d’intégrer tout ça pour construire un “rythme soutenable”. C’est pour ça que c’est un rôle clé dans Scrum.
(1) Le mieux c’est quand même que vous alliez lire l’article de Pablo avant !
(2) Pub ! Objectif Mars v2 “La revanche du sprint planning !” sera présentée au ScrumDay le 11 avril
