Le cadrage Agile – Agile Tips #1

En tant qu’agiliste, nous sommes régulièrement sollicités pour répondre à diverses problématiques intéressantes que nous allons détailler dans ces différents articles de blog. 

Pour cette première édition, nous vous proposons de parler du cadrage agile. On m’a, à plusieurs reprises, demandé comment il est possible de définir un budget pour un « projet » agile alors que l’agilité recommande une démarche itérative et Lean. Ce qui impliquerait que, lors du cadrage, toutes les spécifications et solutions du produit ne seraient pas encore définies…

Effectivement, la théorie Agile recommande de respecter les engagements de coûts, de délais et de qualité, mais aussi de limiter au maximum le « gâchis » en évitant : 

• De maturer (c’est-à-dire spécifier finement) trop tôt des fonctionnalités que l’équipe n’aura finalement pas le temps de développer 
• De développer des couches techniques qui ne seront finalement pas exploitées 
• De développer des fonctionnalités qui ne sont pas pertinentes ou cohérentes avec le produit final 

Pour ce faire, avant de se lancer dans un nouveau « projet », l’agilité va conseiller de commencer par dépeindre quel serait le produit parfait. Il s’agit d’une « big picture » représentant les fonctionnalités majeures qu’on aimerait voir dans notre produit. Pour vulgariser, et en fonction du framework choisi par l’équipe, on appellera ces fonctionnalités majeures des « Features », des « Capacities », voir dans certains contextes des « Epics », …  Et c’est au fur et à mesure de l’avancée des réalisations que ces fonctionnalités majeures seront spécifiées, planifiées et découpées en expressions de besoins plus petites (comme des User Stories et des tâches). De nouvelles expressions de besoins peuvent d’ailleurs émerger en cours de réalisation, que ce soit pour aligner notre produit aux standards du marché ou par ce qu’on se rend compte que le produit en cours de réalisation ne répond pas complétement aux besoins des utilisateurs. 

On s’aperçoit qu’avec un périmètre variable et non finement spécifié, le cadrage, l’estimation et la budgétisation peuvent s’avérer compliqués.  

C’est à ces fins que Lean propose un ensemble d’outils permettant de cadrer son produit (ou un prochain incrément produit) en plusieurs étapes : 

• Imaginons le produit parfait : ce qu’on aimerait voir idéalement ajouté ou créé dans notre Produit (qu’on appellera pour le moment des hypothèses) 
• Estimons la complexité de réalisation et le coût de chacune des hypothèses imaginées 

• Retenons les hypothèses qui répondent aux mieux aux besoins, tout en prenant en compte la faisabilité 
• Priorisons ces fonctionnalités en prenant en compte le coût, la valeur ajoutée, les dépendances… 

Voyons maintenant quelques outils et techniques usuellement utilisés lors de ces phases de cadrage

 

1) Repenser le besoin pour l’utilisateur et définir une Vision Produit 

 

Dès la phase de cadrage, l’agilité va recommander de ne pas se précipiter vers des solutions, mais de commencer par se concentrer sur les besoins utilisateurs. L’objectif étant de maximiser la valeur ajoutée des nouvelles fonctionnalités : elles doivent toutes répondre à une problématique (nouveau besoin, ou fonctionnalité existante qui ne fonctionne pas bien) rencontrée par les utilisateurs de notre Produit.  

Pour nous aider sur cette première étape, il existe plusieurs outils tels que l’Elevator Pitch (pour résumer ce qu’on veut faire), les Personnas (pour identifier et caricaturer les différents profils d’utilisateurs de notre Produit), …  

Parmi tous ces outils, Lean propose le Lean Canvas, imaginé par Ash Mauria en 2010, qui va aider l’équipe à dessiner une Vision du Produit lors du cadrage. Pour ce faire, il faudra répondre à différents segments qui sont itérativement liés, et qui se répondent les uns les autres : 

• 1. Qui sont nos clients, nos utilisateurs, et surtout nos early adopters : ceux qui ont besoin des fonctionnalités et qui vont les utiliser (ceux qui pourront faire des retours utilisateurs qualitatifs) 
• 2. Quelles sont les problématiques et les obstacles qu’ils rencontrent, quelles sont les éventuelles solutions de contournement 

• 3. Quelle est la proposition de Valeur de notre Produit, quelles fonctionnalités uniques et bénéfices proposons nous à nos utilisateurs 
• 4. Quelles sont les solutions (fonctionnalités, produit ou service) que nous pouvons proposer pour répondre à la proposition de Valeur. Il s’agit pour le moment uniquement d’hypothèses. Plusieurs hypothèses différentes et concurrentes peuvent d’ailleurs être prises pour répondre à un même besoin. Attention, il ne s’agit pas ici de spécification ! 
• 5. Quels canaux utiliser pour entrer en contact et échanger avec nos utilisateurs 
• 6. Comment les solutions que nous venons d’imaginer vont nous aider à gagner de la Valeur et de l’argent, quel est l’impact sur le modèle économique de notre Produit 
• 7. Quels sont les complexités et les couts de fabrication de ces solutions. Il s’agit ici de macro-estimations fournies par des représentants de l’équipe de réalisation. 

• 8. Quels sont les indicateurs à mettre en place et à suivre pour mesurer l’efficacité de ces solutions 
• 9. Et finalement, en quoi notre produit et ces solutions seront incontournables 

Vous avez bsoin d’un modèle de Lean Canva? Utilisez celui Aubay ! (Téléchargement possible)

C’est donc dans lors étapes 6 et 7 que sont définies les estimations. Pour ce faire, il est possible d’utiliser des abaques, mais l’agilité va recommander d’utiliser des outils comme les Poker Plannings ou d’Extreme Quotation qui permettent de fournir des estimations plus fiables, beaucoup plus rapidement, en impliquant les équipes de réalisation. Mais ceci fera l’objet d’un prochain Agile Tips.  

A noter que SAFe propose aussi ses outils et process pour gérer et répartir des budgets entre différentes équipes stables : le Lean Budgets https://www.scaledagileframework.com/lean-budgets/ 

2) Story Mapping pour la définition d’un Plan Produit  

 

Grace au Lean Canvas, vous avez défini des Hypothèses de Solutions qui ont de la valeur. Et on a vu qu’il est même possible d’en définir un coût, et donc de les budgétiser. Il va falloir maintenant les prioriser ! Il serait tentant de les mettre directement dans le Backlog Produit et de les planifier au moment opportun. Mais attention, il va d’abord falloir confirmer ces hypothèses prises, et d’en assurer de la cohérence dans notre produit. Cette fois, c’est l’outil Story-Mapping qui va nous aider. 

Le Story Mapping est un outil permettant de visualiser et de prioriser nos hypothèses. Il s’agit donc d’une matrice de fonctionnalités, qu’on va prioriser sous des étapes chronologiques qui illustrent le parcours ou l’expérience des utilisateurs de nos produits. 

Pour ce faire, il est recommandé que des représentants de chaque clients et/ou métier participent, afin de tous se mettent d’accord sur les priorités en prenant en compte les besoins, urgences et criticités de chacun. 

Lors de cet atelier, il est souhaitable de faire participer des représentants de tous les métiers/clients/utilisateurs impactés par le produit pour que chacun présente et comprenne les besoins, priorités et criticité des autres, et ainsi de se mettre tous d’accord sur les hypothèses à retenir et celles à déprioriser. 

En fin d’atelier de Story Mapping : 

• Les hypothèses seront triées (en prenant en compte leurs Valeur Business, leurs complexités, et leurs pertinences à répondre aux besoins) afin de ne retenir que celles qui deviendront des expressions de besoin 
• Des Releases sont définies en fonction des priorités (on tâchera de prioriser les fonctionnalités qui génèreront le plus de valeurs dans notre produit) 

• On pourra identifier le MVP (minimum viable product : ensemble de fonctionnalités minimales requises pour que notre produit soit cohérent et opérationnel) qui peut être composé de plusieurs Releases. 

C’est ici que vous pourrez réellement estimer et budgétiser votre MVP, puisqu’on aura défini le vrai périmètre attendu en écartant des hypothèses. On notera toutefois qu’il ne s’agit encore que de macro-estimations. Il reste souhaitable de raffiner/maturer finement les fonctionnalités seulement quelques semaines avant ces réalisations, pour prendre en compte les derniers retours utilisateurs et standards de marché. Ces macro-estimations pourront être reprises comme “limite” (quand est-ce qu’on s’arrête dans une démarche d’amélioration continue d’un produit) puisque l’agilité recommande fortement le respect du délai et du budget. 

On pourrait dire que ces deux étapes sont efficaces, mais uniquement dans le cadre d’un nouveau produit, ou de nouvelles fonctionnalités majeures. Il est toutefois possible de décliner ce modèle en ajoutant, entre le Lean Canvas et le Story Mapping, une étape de “cartographie de l’existant”. Cela consiste à redessiner les fonctionnalités majeures du produit, par étapes chronologiques de l’expérience ou du parcours utilisateur, et d’identifier les fonctionnalités qui performent (en se basant sur les besoins et attentes de nos utilisateurs) et celles qui présentent des irritants. Pour chaque irritant, on pourra alors identifier de nouvelles hypothèses d’amélioration de notre Produit, afin qu’il réponde encore plus aux attentes de nos utilisateurs et aux standards du marché.

Conclusion 

 

Nous avons vu qu’en s’inspirant de Lean, il est possible de cadrer un produit sans avoir à le spécifier finement. Cependant, chaque produit est différent ! il existe plusieurs autres outils et méthodes de cadrages qui s’adaptent mieux à des contextes particuliers. C’est pourquoi il est toujours conseillé de se faire accompagner par un agiliste expérimenté qui pourra aider les équipes à identifier et animer leur cadrage pour toujours plus de cohérence et des résultats encore plus fiables.