Nous allons voir dans cet article comment lancer un projet en mode agile avec la technique de plus en plus populaire appelée le framing. Nous allons voir ensemble comment procéder.
Sachez que le framing a évolué par rapport à cet article. N’hésitez pas à consulter l’ensemble des articles liés au framing agile :
Rappel : adaptez la méthode si besoin
Je ne le rappellerai jamais assez, mais n’hésitez pas à adapter la méthode selon vos besoins. Nulle méthode n’est parfaite même si des méthodes comme celles-ci fonctionnent plutôt pas mal.
La méthode proposée ici est adaptée aux produits de type application (app web, logiciel…).
Voici le déroulement d’un framing
Avant de regarder en détail chaque partie, voici le déroulé d’un framing de projet agile dans les grandes lignes :
Nous allons réaliser le framing en 5 étapes successives qui vont permettre d’aller de la vision au backlog du produit. Nous verrons chacune de ces étapes en détail à la suite de cet article.
0/ Préparation du framing
Pour commencer un framing, il faut se mettre dans les meilleures conditions possibles. Trouvez une salle assez grande, des tableaux blancs ainsi qu’un lot de post’it complet de différentes tailles et couleurs.
Nous allons beaucoup utiliser les murs pour réaliser un framing très visuel.
Je vous conseille fortement de prévoir vos interviews qui se réaliseront tout au long du framing que vous allez lancer ; il est parfois difficile de faire venir certaines personnes dans les jours qui suivent. N’attendez pas pour avoir déjà des dates d’interviews avant même le lancement de ce framing.
Sachant que nous sommes dans un monde Agile, nous voulons vraiment bénéficier au maximum des utilisateurs clés et des stackholders pour avoir un produit le plus proche possible du besoin final.
Les interviews peuvent se faire entre la phase 3 et la phase 4 pour qu’elles soient optimales. Le fait d’utiliser des post’it et des tableaux blancs permet de pouvoir changer nos différents éléments facilement en cas de besoin : il n’est pas rare de se tromper sur certains points en début de framing.
Comme on peut le voir dans certaines méthodes comme le Design Sprint, nous allons mettre un Agile Catalyst (ou un Scrum Master sénior) dans l’équipe de ce framing pour forcer l’équipe à avoir une bonne dynamique. Il est difficile pour les équipes de garder une bonne dynamique tout au long du framing sans avoir quelqu’un pour leur donner cette impulsion.
Article : Qu’est-ce ce rôle d’Agile Catalyst ?
Pour lancer un framing, je vous conseille au minimum d’avoir le Product Owner du projet, l’Agile Catalyst (voire le futur Scrum Master), un tech lead et un UX/UI. Ajoutez des personnes si votre contexte l’impose ; le but principal est d’avoir l’ensemble des personnes pour que l’équipe soit capable de résoudre l’ensemble des potentiels problèmes qu’elle rencontrera lors du framing (principalement dans les grands groupes).
Le framing est une période difficile et fatigante ; il est essentiel d’avoir des journées courtes coupées de pauses. Voici un exemple de rythme soutenable pour un framing :
9h : démarrage de la journée
10h30 – 11h00 : pause matin
12h30 : repas
13h30 : démarrage de l’après-midi
15h00 – 15h30 : pause de l’après midi
17h : fin de la journée
1/ Product Vision Board (ou Box)
Pour démarrer un produit, il est important de commencer par avoir une bonne vision du produit qu’on désire réaliser. Pour cela, il existe deux exercices intéressants (il ne faudra en choisir qu’un) :
- Le Product Vision Box
- Le Product Vision Board
Si le premier est plus sympa à faire (plus ludique), il est vrai que le deuxième est beaucoup plus simple à partager aux équipes ou à numériser.
Le Product Vision Box est une représentation de la vision du projet sous forme d’une boite de céréale (cet aspect 3D rend difficile le partage numérique). Voici un lien pour mieux comprendre ce qu’est ce Product Vision Box :
Article : Vision du projet avec la Product Vision Box
Le Product Vision Board est une vision mise totalement à plat facilement partageable. Voici à quoi ressemble ce board :
Vous allez donc remplir ce board en équipe afin de remplir les 5 cadres nécessaires pour avoir une bonne vision générale du produit. N’oubliez pas que vous partagerez cette vision avec d’autres futurs membres de l’équipe d’où l’importance de faire sérieusement cet exercice.
Vous allez définir les groupes utilisateurs cibles soient les personae de votre produit. Cependant, vous ne détaillerez pas leur fonction à cette étape du framing.
Vous allez ensuite définir les besoins auxquels devra répondre votre produit : si vous avez l’impression qu’il n’y aura pas assez de lignes, synthétisez pour que ça rentre dans la case sans pour autant écrire trop petit. Comment allez-vous créer de la valeur pour vos personae cibles ?
Vous allez également définir dans « product », les 3 à 5 fonctionnalités clés de votre produit. N’oubliez pas que nous travaillons la vision globale du produit, donc nous allons volontairement omettre les petites fonctionnalités afin de ne pas complexifier la vision du produit qu’il faudra par ailleurs défendre plus tard.
Vous définirez les valeurs du produit qu’elles soient financières, qu’elles soient au niveau de la connaissance… Cette base nous permettra d’ailleurs de créer nos futurs KPI parfois exigés par certaines entreprises.
Maintenant que tout ça est fait, vous devriez pouvoir remplir la case du haut en offrant une vision générale et synthétique du produit que vous voulez créer.
2, 3 et 4/ Définir les personas, customer journey et story mapping
Cette partie est très importante car elle permet d’aller de la vision au détail de la vision. Ayant fait un article complet sur le sujet, je vous proposer d’aller le lire directement en suivant le lien ci-dessous :
Article : Bien comprendre la création d’un story-mapping
A partir de ce story-mapping, il pourra être intéressant de prendre l’ensemble des stories écrites pour les estimer brièvement afin d’imaginer un point d’atterrissage envisageable. Pour cela, proposez à l’ensemble de l’équipe de réaliser ensemble un Extrême Quotation de 40 minutes :
Article : Estimons avec de l’Extreme Quotation
Le tech lead proposera un premier sprint qui sera réalisable selon lui par un développeur (voire deux développeurs : 1 front et 1 back) en considérant que le socle applicatif soit déjà réalisé ; le nombre de point d’effort total des user-stories sélectionnées par le tech lead sera une référence pour calculer le nombre de sprint (2 semaines par exemple) nécessaires pour la réalisation du produit comme il est défini lors de ce framing.
Le lead tech aidera l’équipe à définir l’équipe technique idéale à avoir pour bien réaliser le projet.
Attention, si vous travaillez bien en mode agile, n’oubliez pas que le scope changera grâce aux feedbacks continuels des utilisateurs clés donc la date d’atterrissage sera à titre indicatif.
A partir de là, si vous avez besoin de justifier un budget, calculez le coût de chaque ressource qui sera nécessaire pour réaliser le nombre de sprint que vous pensiez ensemble être possible pour aller au bout de la réalisation du produit. La date d’atterrissage peut devenir une « dead line » si bien sûr on accepte que le scope puisse changer au fur et à mesure du temps (être agile pour faire simple).
Exemple :
- L’équipe a défini un total de point d’effort des stories de 300 lors de l’extrême quotation
- Le tech lead a définit un premier sprint réalisable de 50 avec un dev front et un dev back (qui sera lui même).
- L’équipe décide de proposer une équipe de 4 développeurs pour l’exécution du projet soit 50 * 2 points d’effort (100 par sprint) réalisables par sprint
- Le projet durera 3 sprints + 1 sprint 0 donc nous pouvons imaginer une date d’atterrissage 2 mois après le démarrage de l’exécution du projet.
- Si besoin en budget, il suffira de calculer le coût journalier soit par exemple 3600 euros et le multiplier par le nombre de jour pour obtenir le budget nécessaire pour la création du produit : 144.000 euros.
N’oubliez pas que la phase de framing a également un coût à calculer si le budget est indispensable pour les équipes dirigeantes.
Attention : On peut considérer la mise en place du socle technique (le dit sprint 0) lors du framing si l’équipe n’attend pas de go/no go pour lancer l’exécution du projet. Dans ce cas, il ne sera pas nécessaire de calculer le coût du sprint 0 dans l’exécution du projet.
5/ Création de notre backlog
Le Story-Mapping est très utile ; il permet de créer très facilement le backlog de notre produit (ou du moins les premiers sprint). Les équipes en sortie de framing pourront sans soucis lancer l’exécution du projet selon les conditions que nous verrons après.
Voici un article qui parle des user-stories : Comment bien créer ses user-stories ?
Annexe/ Un Go, No Go de fin de framing ?
C’est très important de bien comprendre que le framing peut permettre de valider ou d’invalider un projet dans certaines entreprises. Si c’est le cas, n’hésitez pas à réaliser une réunion de Go/No Go avec les personnes ayant le pouvoir de décision afin de s’assurer que tout correspond bien aux attentes.
En cas de Go, no go
Entre le framing et l’exécution, il faudra alors embaucher l’ensemble des développeurs et l’équipe ne sera complète qu’au mieux au bout de deux semaines.
Le Lead Tech pourra alors amorcer seul le Sprint 0, le temps que l’équipe soit au complet. Dans ce cadre, n’oubliez pas d’enlever le coût des développeurs au sprint 0 prévu lors de la budgétisation du produit (si nécessaire dans votre contexte).
Si vous n’avez pas de Go, no Go
Logiquement dans dans ce cas, l’équipe lancera les recherches de profils dès que la définition des besoins de staffing est terminé. L’équipe entrera alors en exécution si possible dès la sortie de la phase de framing.
Conclusion Framing
Je n’ai peut-être pas tout évoqué dans cet article. Cependant il y a déjà pas mal d’information sur le bon déroulement d’un framing. En cas de question, n’hésitez pas à me demander, j’améliorais l’article selon vos différentes questions.
4 Rétroliens / Pings