Faire son framing agile sans penser Waterfall !

Il est essentiel quand nous enclenchons un framing agile, de ne pas penser Waterfall. Cet article va vous expliquer la démarche à entreprendre pour bien réaliser son framing agile.

Ne pas penser Waterfall !

Le Framing Agile a pour but de lancer un produit en utilisant des concepts 100% agile. Bien que le canvas indique des étapes numérotés, il ne faut pas les voir comme un classique Waterfall ; c’est tout a fait le contraire.

Objectifs du framing agile

Ce framework vous propose un enchainement logique d’ateliers qui vont amener les participants à pouvoir atteindre 8 objectifs précis. Les objectifs à atteindre sont ceux-ci :

1. Avoir une bonne vision du produit (et la partager)
2. Préparer un backlog d’itération affiné de la première itération
3. Préparer le socle technique, la stratégie devops et les environnements
4. Former les équipes au mindset et méthodes agiles utilisées en phase de réalisation
5. Définition de la gouvernance
6. S’assurer que le budget et ressources prévues sont adaptés
7. Capacité de prendre une décision de Go / No go à tout moment
8. Avoir formalisé le cadre de la phase de réalisation

Le premier atelier pour travailler la vision du produit est le Product Vision Board ; il deviendra un increment dès la fin de l’atelier. Cependant, la partie centrale présentant les interviews indispensables pour challenger l’ensemble de la vision créée, pourra amener cet incrément à évoluer. En effet, un atelier terminé n’amène pas à un increment parfait ; et le framing agile recommande à 100% de revenir sur un increment s’il doit être amélioré.

Le framing agile, 100% manifeste agile

Rappelons-nous des 4 valeurs citées par le manifeste agile :

Avec le framing agile, nous cherchons à avoir des logiciels opérationnels. Pour cela, il est essentiel d’accepter de revoir notre vision si elle ne correspond pas à 100% à celle de nos utilisateurs. Les équipes ne devront donc pas suivre un plan sans réfléchir ; elles devront accepter l’adaptation au changement venant des interviews réalisées.

Si une interview venait à démontrer que la vision de l’équipe n’est pas parfaite, celle-ci n’hésitera pas à revenir à l’étape 2 puis à l’étape 3 pour retravailler les incréments réalisés même si elle en est à l’étape 4. C’est d’ailleurs l’une des plus grandes forces du framing agile : proposer des ateliers simples et des rendus modulables évitant toute documentation exhaustive. Le client sait mieux que nous ce qu’il attend, nous ne devons pas nous substituer à lui.

Vous comprendrez aisément l’importance de la collaboration avec les clients dans ce framework qui se dit « de lancement de produits » et non « de lancement de projets ».

Faire le framing agile en mode waterfall en pensant un increment finalisé lorsque l’étape est franchit amènera à perdre une grande partie de l’efficacité du framing agile.

Pensons produit et ne pensons plus projet !

Le Framing agile est un framework complet qui peut lui même être challengé. Si il est très adapté à l’ensemble des produits, il peut être adapté si nécessaire. Si par exemple, vous travaillez un produit qui est une interface de monitoring basée sur un grand nombre de données (comportant qu’un seul écran remplit de graphiques différents), il ne sera peut-être pas intéressant de travailler des customer journey ; dans ce cadre, l’utilisation d’un impact mapping serait plus efficace.

Le plus important n’est pas d’effectuer chaque étape de façon waterfall mais d’avoir un enchainement logique d’ateliers amenant la vision à se clarifier jusqu’à aller vers la constitution d’un premier backlog non détaillé. En pensant produit, nous accepterons que chaque interview (utilisateurs clés, parties prenantes, sponsors) peut amener à revenir à plusieurs reprises sur les précédents ateliers avec pour objectif d’affiner les incréments réalisés.

Attention à la partie technique du framing agile

Bien que le framing agile  propose en étape 5′ de travailler sur une analyse technique, la stratégie craftsmanship et le socle technique à mettre en place, rien n’impose de le faire à 100% lors du framing agile. Ne regardez pas ces incréments comme des choses qui doivent être validées à 100% pour passer à l’étape suivante.

L’objectif de cette étape est d’amener les équipes techniques à se poser les bonnes questions. Mais si dans un grand nombre de cas, ces incréments seront réalisables, le contexte ne le sera pas toujours.

Si l’équipe entrevoit de travailler dans un langage de développement avec un framework précis pour répondre aux besoins des utilisateurs, ils pourront entrevoir de mettre en place ce socle technique qui sera indispensable pour réaliser les première user-stories. Cela n’interdira pas à l’équipe d’améliorer celui lors de la phase de réalisation ; surtout si cela amènera à une meilleure excellence technique.

Exemple d’un travail à ne pas faire

Cependant, si un moteur de recherche est envisagé dans le produit mais qu’il ne semble pas être prioritaire, l’équipe ne commencera pas le travail dessus même si il répondre à un petit lot de user-stories à l’avenir ; voici quelques raisons de ne pas le faire lors du framing agile :

• les feedbacks sur les premières fonctionnalités peuvent amener le client à penser que le moteur de recherche n’est pas nécessaire ; la valeur qu’apporterait celui-ci serait donc plus basse.
• d’ici une priorisation haute de cette fonctionnalité, les user-stories peuvent amener à de nouvelles fonctionnalités innovantes. Ces changements pourraient amener une solution à devenir obsolète… Et le travail réalisé sur ce premier moteur de recherche pourrait partir à la poubelle et à rendre tout ce travail inutile ; en effet, l’équipe technique aurait pu profiter de ce temps pour travailler sur d’autres parties très utiles.

Bien que cela n’est pas si simple car ça exige un changement de mentalité pour les équipes techniques qui découvrent réellement un univers agile, il est essentiel de ne faire que ce qui est sûr d’amener à offrir de la valeur au client.

D’ailleurs le framing agile conseille fortement de ne pas créer tout son modèle de données lors de cette phase de préparation. Cela compliquera considérablement les changements futurs nécessaires pour s’adapter au changement venant d’un affinage de backlog et des feedbacks.

Conclusion : faire son framing agile sans penser Waterfall !

Vous l’aurez compris, en se refusant de faire le framing agile en mode waterfall, vous arriverez à créer votre produit avec un vrai mindset agile et le produit final qui sera réalisé aura de plus grandes chances d’être de grande qualité pour les utilisateurs et clients.