Le Framing Agile est une méthode pour lancer un projet en mode « Agile » avec des notions de « Design Thinking ». Dans cet article, nous allons voir la version actualisée de la méthode sans entrer dans les détails.
Ce framework de cadrage de projet se veut être axé « produit » et « idéation » de celui-ci.
Un site totalement dédié à ce nouveau framework est en cours de création ; vous y trouverez toutes les informations détaillées pour ce framework.
Explication de cette méthode
Le Framing Agile démarre en amont de la phase d’exécution comme le présente le petit schéma ci-dessous :
Objectifs du framing agile
Voici les principaux buts que les équipes doivent atteindre en fin de Framing Agile.
Avoir le backlog affiné pour lancer le sprint 1
Il n’est pas rare de voir des équipes commencer des sprint 1 avec des user-stories encore peu matures ; le framing agile a pour but de travailler l’affinage du backlog pour que les équipes démarrent les développements sur des bases solides.
Lors du Framing, le cadre de ce backlog sera également mis en place. Pour cela, l’équipe travaillera sur la Definition of Done et la Definition of Ready. C’est d’ailleurs ce cadre qui permet au Product Owner de proposer un premier sprint complet et de qualité.
Sans ce travail, il est fréquent de voir les équipes prendre 3 sprint voire plus à avoir des user-stories qui répondent à 100% aux besoins des développeurs ; cela fait perdre beaucoup de temps car la fluidité sur la chaîne de développement est imparfaite (allez/retour avec le PO voire les clients nécessaires pour des précisions nécessaires sur le besoin, pas de tests utilisateurs qui laissent des doutes sur le travail réel à faire…).
Avoir le socle technique et les environnements en place
Beaucoup d’équipes techniques (ce qui est encore plus vrai dans les grands groupes) perdent un temps considérable pour avoir un poste de développement, pour obtenir des environnement de recettes de qualité voire installer un outil complémentaire pas conforme aux normes de sécurité de l’entreprise…
Le framing assume ce problème et en fait même un de ses points forts. Les développeurs commenceront les développements quand tous les environnements seront en place afin de ne pas perdre un temps considérable pour tenter des mises en recettes, pour faire des développements instables…
C’est très frustrant pour les équipes d’avoir des premiers sprint où aucune valeur n’est livrée contrairement à ce que l’ensemble de l’équipe imaginait. De plus dans de nombreux cas, le fait que ces installations n’étaient pas totalement assumée peut amener le core management à mettre de la pression sur l’ensemble de l’équipe en cours de projet.
Le framing agile assume que cette phase fait parti du mois de framing accepté par l’ensemble des partis ; il ne sera donc pas mal vu que les équipes techniques rencontrent de grandes difficultés pour avoir un environnement technique stable.
Attention, le mois de framing ne permet pas toujours de régler tout à 100% dans certains grands groupes où la phase des environnements peut-être un véritable casse tête.
Former les équipes aux méthodes agiles (généralement choisi pour la phase d’éxécution)
Le Framing agile permet également de préparer les équipes à la future méthode de gestion de projet lors de la phase de développement. L’équipe choisira la technique désirée et se fera former par un coach agile (par exemple) pour apprendre la méthode de gestion de projet que l’équipe désire mettre en place.
La formation est souvent un peu négligée car on pense que les équipes sauront mettre un bon Scrum en place facilement. Attention de ne pas commettre cette erreur, il n’est pas simple pour des équipes de bien comprendre le cadre des méthodes agiles et surtout les principes fondateurs qui sont la raison de leurs existences ; négliger la formation aura des conséquences sur l’ensemble des développements futurs.
Avoir un produit qui répond réellement aux besoins des utilisateurs
Cette partie est souvent omise dans les projets. Un Product Owner va penser au produit à la place des utilisateurs clés. Nul doute que celui-ci pensera faire de son mieux mais sa vision ne remplacera pas celle des utilisateurs.
Le framing agile impose de challenger le produit (sa vision car aucun développement de fait lors de cette phase) avec les utilisateurs clés, les sponsors et les parties prenantes.
Il est important de bien interviewer ces 3 types de rôles pour éviter certaines dérives :
- l’utilisateur clé va bien exprimer son besoin
- le sponsor va rappeler les contraintes dont budgétaires que l’utilisateur clé ne connait pas
- les parties prenantes vont rappeler certaines obligations (exemple un juriste qui rappellera que cela est interdit)
Avoir un cadre complet avant l’exécution
Dire « go, ils apprendront sur le tas » est une phrase qui s’entend encore dans les coaching agiles ; cependant parfois cela fait du mal aux équipes. Le framing préfère que le cadre se prépare avant de se lancer dans l’exécution.
On peut voir des équipes qui mettent jusqu’à 8 sprints pour livrer de la valeur ; le framing agile n’effacera pas tous les problèmes rencontrés mais permettra de mieux structurer en séparant bien la préparation et l’exécution.
Cela va impliquer d’avoir des Definition of Done/Ready pour les équipes voulant faire du scrum par exemple, en ayant des demandes affinées dès le premier sprint…
Maitriser son budget
Comme le veut l’iron triangle agile, le framing permet de contrôler le coût du projet. En agile, il est tout a fait possible de déterminer le coût du projet et les délais de réalisation ; par contre, le scope du projet sera variable.
Le framing permet de mesurer des dates de releases et de définir le coût de celles-ci (logistique, ressources…). Attention à ne pas commettre cette erreur : l’agile n’interdit pas de deadline… L’agile interdit qu’on fixe un scope et d’en refuser tout changement.
Un framework complet
Voici l’image qui explique l’ensemble du framework dans les grandes lignes.
Le framing est une période de 2 semaines (pour les nouvelles features) et 1 mois pour les nouveaux produits ; pedant celle-ci, l’équipe va construire ensemble la vision du produit puis aller peu à peu vers le détail des réalisations (vision box, personae, customer journey, story mapping….. affinage des user-stories du sprint 1 + socle technique).
J’ai déjà détaillé quelques articles expliquant les ateliers présentés sur l’image ci-dessus :
Vision du projet avec la product vision box
Bien écrire son persona dans un projet agile
Bien comprendre la création d’un story-mapping (avec customer journey)
Estimons avec de l’Extreme Quotation
Faire un planning release en agile
N’hésitez pas à aller sur le site du framing ; celui-ci vous donnera de réelles indications sur l’enchainement à avoir pour réaliser un framing agile de qualité.
Les interviews, base du framing
Lors du framing, il sera nécessaire de réaliser de nombreuses interviews (utilisateurs clés, sponsors et parties prenantes) ; cela permettra de challenger le contenu du produit comme on l’a vu un peu plus haut.
Le framing sera rythmé d’itérations d’une semaine ; elles débuteront par une planification des objectifs de la semaine et qui finiront par une revue et une rétrospective. Le but étant de ne pas appliquer bêtement une méthode mais d’être dans un état d’esprit d’amélioration continue et d’adapter si le contexte l’exige. Chaque matinée exceptée le lundi, l’équipe fera une daily meeting très rapide pour se synchroniser. Les adeptes du Scrum ne seront pas perdus avec cette façon de faire.
Un Decision Committee sera mis en place pour prendre des décisions importantes que l’équipe du framing seule n’a pas le mandat pour le faire ; elle devra également permettre de soulever les obstacles que l’équipe de framing sera en incapacité de gérer. Ce Committee est réalisé par des membres de l’équipe de framing ainsi que les sponsors et les parties prenantes toutes les deux semaines.
Conclusion Framing agile
Si le site du framing agile vient d’ouvrir, n’hésitez pas à le garder sous le coude car il va s’étoffer de nombreux articles dans les prochains jours. Je suis moi même formateur de cette méthode qui apporte beaucoup aux entreprises. N’hésitez pas à me demander si vous avez des questions sur le sujet.
Merci pour cet article de synthèse.
En fonction des contexte projets et produits, j’ajoute à la démarche de framing Agile :
– un atelier de rôles et responsabilité / give & take matrix / delegation grid …
– la stratégie de tests : comment s’organise la recette itérative (testeurs hors ou dans l »équipes ?)
– mise en place d’un matrice de risques pour adresser ceux rapidement de forte occurence et de gravité élevée sur lesquels l’équipe / les équipes « ont prise »
– les facteurs clés de succès du projet/produit (hors triangle de fer)
(exemple : identifier si les utilisateurs, ll’équipe / les équipes, les sponsors sont satisfaits, amélioration du tunnel d’achat d’un site marchand, meilleure qualification de prospects, …)