Quand il n’y a pas d’agilité! Dans mon activité, je rencontre des Product Owners n’arrivant pas à jouer pleinement leur rôle. Pour eux, la solution est figée avant qu’ils prennent en charge le projet, et n’arrivent plus à y mettre de l’agilité. Cela génère de la frustration ou de l’apathie de leur part.
Alors, avec eux, partons à la recherche de l’agilité perdue.
L’adaptation au changement
Retour aux sources, avec le Manifeste Agile, pour rappeler les objectifs que cherchent à atteindre l’agilité :
- Les individus et leurs interactions plus que les processus et les outils
- Des logiciels opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que le suivi d’un plan
Concentrons-nous sur une de ces valeurs, l’adaptation au changement.
Changer la solution, non le besoin
S’adapter au changement d’accord, mais il porte sur quoi ce changement ?
La réponse est simple : sur la solution (puisque l’on parle de logiciel qui fonctionne). L’adaptation au changement peut permettre de converger plus rapidement vers la bonne solution, celle qui répond au besoin des utilisateurs et les satisfait, voire de co-construire la solution avec eux.
Le changement porte sur la solution, non le besoin. Si ce n’est pas le cas, des méthodes telles que le Lean startup seront plus adaptées pour démarrer le projet et valider le besoin également. Rapidement, le Lean startup va s’appuyer sur l’agilité.
Provoquer le changement
Le changement est accueilli positivement dans l’agilité, synonyme de plus de valeur ajoutée perçue par les utilisateurs. Mais il faut aller le chercher, le changement se provoque. C’est pourquoi les méthodes agiles préconisent de mettre dans les mains des utilisateurs la solution, au plus vite, en production ou au cours de démo, même avec une solution partielle. Les retours que font les utilisateurs alimentent alors le changement.
Identifier les leviers d’ajustement
Une fois identifiés ces changements, il faut pouvoir les prendre en compte. L’ampleur potentiel de ces changements fait parfois peur aux sponsors, aux parties prenantes, aux Product Owners eux-mêmes :
Peut-être cela va-t-il remettre en question toute la solution ?
Généralement non ! Et puis si c’est le cas, autant le savoir au plus vite…
Bon d’accord, les freins rencontrés sont souvent plus subtils que cela. Un problème régulièrement évoqué par les Product Owners est que le périmètre est de toute façon déjà figé (ainsi que le nombre de sprints), par des décideurs, marketeurs, ou business owners. Et donc ils n’ont pas de leviers d’ajustement pour prendre en compte d’éventuels changements. A la place d’être Product Owners, ils se voient plutôt comme des Product Managers.
En tout cas, c’est ce qu’ils disent…
A la recherche de l’agilité perdue
Regardons cela de plus près. Où peuvent se cacher les leviers d’ajustement permettant ce changement ? Plus précisément à quelle granularité les chercher ?
Agilité et features
Prenons un projet de covoiturage (toujours le même, je suis d’accord, c’est juste pour être plus concret). Voici son impact mapping. Il permet de définir la vision (objectif, pour qui, pourquoi) et la liste des features qui peuvent faire parties de la solution :
Impact Mapping
Clairement, certaines features sont moins prioritaires que d’autres : « connaître les autres passagers » vs « voir l’évaluation du conducteur ». Certaines sont optionnelles : « envoyer une newsletter pour informer ».
Prenons le cas où le marketing décide d’embarquer dans la prochaine release une liste de features, dont celles citées précédemment.
Dès les premières démos, pas mal de retours impactent le plan de release. Vous êtes Product Owner, que faites-vous pour gérer le changement ? Essayez-vous d’enlever du périmètre les features optionnelles ou moins prioritaires ?
Normalement, le Product owner fait partie de ces discussions avec le marketing ou les Business Owners. Mais justement s’il ne l’est pas, c’est là que les ennuis commencent, et que mon propos, lui aussi, commence.
Il y a peu de chances que le marketing accepte de finalement ne pas faire toutes les features prévues. Elles font parties de la version, elles sont visibles du plan de release, du plan marketing, que sais-je. Vous comprenez qu’il va falloir réaliser toutes les features demandées. Les priorités vous donnent seulement les clés pour faire un plan de release adéquat, mais c’est tout.
Pas d’ajustement possible à ce niveau-là. Le cadre a été fixé, le Product Owner doit faire au mieux à l’intérieur de ce cadre. Les fonctionnalités moins prioritaires en font parties.
A ce stade, il aurait fallu privilégier des versions plus courtes, avec un périmètre restreint, ne prenant pas en compte par exemple telle ou telle feature optionnelle.
L’agilité, à l’échelle des features, se traduit par des releases plus courtes et une roadmap adaptée, qui s’ajuste.
Agilité et user stories
Regardons de plus près une release. Le cadre a été fixé par la roadmap, soit en termes d’objectifs (l’idéal) soit en termes de features. L’objectif du Product Owner est de maximiser la valeur ajoutée créée dans ce cadre-là.
Si les features sont en générales fixées, ce n’est pas le cas des user stories. C’est là que réside la marge de manœuvre la plus importante du Product Owner, qui ne maîtrise pas le cadre issu d’une roadmap. Encore faut-il aller chercher ces user stories. Car le diable se cache dans les détails, dans l’informatique aussi. Il faut aller le débusquer. En ordre de grandeur, une user story ne représente que quelques jours de travail.
Cela demande du travail de découpage de la part du Product Owner ou de l’équipe. Le story mapping est un bon outil pour cela. Reprenons l’exemple du covoiturage pour une des features :
Exemple de story Mapping
Dans cet exemple, on a décomposé la feature « Je veux comparer les prix » en différentes étapes (les tickets verts), et chaque étape en user stories (les tickets jaunes).
Ce que j’ai pu remarquer sur le terrain
Certains Product Owners vont penser que comme la feature « Je veux comparer les prix » est obligatoire pour la version, on doit proposer la solution qui y répond complètement. Alors, ils découpent la feature selon ses grandes étapes : « sélectionner un trajet », « une plage horaire », « voir les propositions de co voiturage », et « comparer les prix » ; puis donnent ces user stories à l’équipe pour un découpage technique.
En s’arrêtant à cette granularité, pas étonnant qu’un Product Owner est l’impression de ne pas avoir de levier d’ajustement pour le changement. C’est sûr qu’aucune de ces étapes n’est optionnelle. Nous n’irons pas en production sans l’une d’elles. Le problème vient du fait qu’ils ne découpent pas suffisamment les user stories.
En reprenant l’exemple, pour chaque étape, nous avons identifié des user stories, certaines indispensables pour répondre à la feature, comme de pouvoir identifier un point de départ et un point d’arrivée ; d’autres optionnelles, comme le fait de trier par type de voiture.
A cette granularité, il est bien plus simple d’identifier le périmètre ajustable de la version. Et ne vous y fiez pas, c’est très puissant, car toutes ces options finissent par coûter cher à une version.
Aller chercher les leviers d’ajustement à la bonne granularité
Mon conseil : aller aussi loin que possible dans le découpage des features en stories, tant que ce découpage a du sens fonctionnel, pour identifier et trier l’optionnel du non optionnel. C’est un travail important, mais nécessaire. De toute façon, quelqu’un de l’équipe le fera. C’est un travail de conception fonctionnelle. Si on délègue cela à l’équipe, la conception sera plutôt technique.
L’astuce pour y arriver, est de lisser ce travail tout au long du projet. Ne pas découper tout le périmètre dans le détail trop tôt, mais attendre le bon moment pour le faire, lorsque la priorité augmente, la certitude qu’on va effectivement la réaliser ou l’imminence de sa réalisation. Car aller dans le détail coûte, il est important de minimiser le coût du changement.
