Sur leur chemin de création de produits à forte valeur, les équipes agiles peuvent se demander comment organiser leurs démonstrations de produit de manière plus efficiente et en dehors de tout dogme ou cadre trop rigide.
La démo est une cérémonie pivot que l’équipe doit maîtriser le plus tôt possible.
Alors, cessez de perdre du temps avec des démos inutiles : c’est un signe évident que vous foncez droit dans le mur.
Arrêtez de demander du feedback sur des éléments qui ne vous intéressent pas, ou pire encore, sur un design que vous jugez déjà « suffisamment bon ».
Arrêtez de justifier le travail accompli ces dernières semaines.
Arrêtez d’attendre de la reconnaissance.
Arrêtez de découvrir pendant la démo ce que vos collègues ont réalisé.
Et surtout, arrêtez de consulter vos e-mails par désintérêt ou en attendant votre tour.
Aucun de ces comportements ne contribuera à rendre votre client, votre équipe ou votre organisation exceptionnels. Revenez aux fondamentaux de l’agilité et (re)commencez à réfléchir à votre parcours agile en vous posant les bonnes questions.
Une nouvelle définition de la démo
Alors que la démonstration n’est qu’une partie de la revue Scrum, elle demeure un moment clé pour recueillir du feedback et vérifier les hypothèses.
Je propose ici une nouvelle définition, complémentaire à Scrum et inspirée du Lean Startup, afin de vous aider à retrouver l’essence de l’agilité.
Les participants valideront régulièrement (ou non) les hypothèses que l’équipe a formulées sur le produit :
« Ce point technique doit fonctionner ainsi »,
« Ce design est assez bon pour nos clients »,
« Cette fonctionnalité correspond à leur besoin réel »,
« Ce niveau de performance est suffisant »,
« Le nouvel incrément de produit fonctionnera. »
Détails des termes utilisés :
- Participants : ceux qui apportent des réponses à vos questions et posent de nouvelles questions pertinentes.
- Régulièrement : dès que c’est pertinent. N’attendez pas la fin du sprint si vous pouvez vérifier une hypothèse avant, avec les bonnes parties prenantes.
- Valider : vous aurez peut-être besoin de plus qu’un écran pour cela. Testez, examinez et adaptez ce qui est pertinent dans votre contexte. Plus la validation se rapproche du produit réel dans le contexte du client, plus elle est qualitative.
- Hypothèses : privilégiez l’apprentissage à la livraison de fonctionnalités. Ne présumez pas de la valeur : formulez des hypothèses à tester, confirmer ou invalider. Soyez guidés par les données.
Enfin, si vous ne connaissez pas encore le Lean Startup, Eric Ries y définit deux types d’hypothèses :
- Hypothèse de croissance : comment mettre le produit sur le marché ?
- Hypothèse de valeur : les clients achèteront-ils réellement cette valeur ?
On aurait pu utiliser le mot feedback, comme le font souvent les coachs agiles et Scrum Masters. Mais j’ai observé que lorsque les équipes demandent du feedback, elles ne sont pas dans une posture d’apprentissage : apprendre des autres, de leurs erreurs, ou des hypothèses erronées. Peut-être est-ce dû à l’éducation scolaire, où l’on apprend à faire « parfaitement ». Le feedback est un moyen, pas un objectif. L’objectif est de vérifier les hypothèses pour avancer. Il existe différentes façons de le faire ; l’une d’elles est d’observer les comportements des clients lorsqu’ils utilisent votre produit.
Une structure pour aider l’équipe à préparer la démo
Désolé les amis, mais le but d’une démo n’est pas de célébrer votre travail.
Les félicitations et applaudissements peuvent être une conséquence naturelle, mais ils ne doivent pas être votre objectif.
Si la reconnaissance du travail est importante pour vous, partagez-le avec l’équipe et inventez une autre cérémonie.
En m’inspirant de l’article de Richard Lawrence, “How to Give a Great Sprint Demo”, voici une adaptation des points essentiels :
- Racontez une histoire.
Ce n’est pas une histoire improvisée 30 minutes avant la démo, mais celle que vous avez préparée avant de commencer le sprint.
Plus elle est préparée en amont, plus la présentation sera fluide et percutante. - Misez sur les hypothèses plutôt que sur une longue liste de critères d’acceptation.
Gardez l’essentiel pour rendre l’histoire claire et centrée sur ce qui compte.
Considérez chaque itération comme la validation d’hypothèses distinctes. - Investissez votre temps selon l’importance des hypothèses à valider.
Plutôt que de “faire la démo trois fois avant” comme on peut le lire souvent, demandez-vous : « Quel est le temps minimal nécessaire pour s’assurer que nous pouvons valider ou invalider les principales hypothèses de ce sprint ? ». - Bannissez la question “Avez-vous des retours ?”
Elle ne génère ni idées ni apprentissage.
Si vous souhaitez recueillir du feedback sur un point précis, soyez spécifique.
Sinon, ne montrez pas votre travail et poursuivez l’exécution de votre plan sans le remettre en question.
Questions pour adapter votre cadre de démo
Il peut être difficile de remettre en question les cadres standards, surtout après de longs efforts pour enfin les appliquer.
Mais voici quelques questions pour bousculer le statu quo :
- Que cherchez-vous à apprendre grâce à la démo que vous avez organisée ?
- Est-ce vraiment orienté client ou business d’inviter de nombreux observateurs passifs ?
- Est-ce orienté client de présenter la démo vous-même plutôt que de laisser les parties prenantes manipuler le produit ?
- Est-ce orienté client de laisser les utilisateurs clés parler à la place des vrais utilisateurs ?
- Est-ce orienté client de limiter la démo aux demandes initiales, sans profiter de leur présence pour mieux comprendre leurs besoins ?
- Apprenez-vous réellement des participants que vous invitez ?
Conclusion
L’hypothèse de cet article est que vous souhaitez véritablement être agile, concevoir d’excellents produits et avoir des équipes épanouies. Alors, commencez-vous à vous détacher des cadres standards ? Cherchez-vous à construire le vôtre ?
J’adorerais lire votre histoire !
En savoir plus sur jerometasse.fr
Abonnez-vous pour recevoir les derniers articles par e-mail.
jerometasse.fr 