Comment éviter l'effet démo ?

Comment contrer l’effet démo ?

Les équipes qui travaillent en agilité ont maintenant l’habitude de présenter le fruit de leur labeur pendant le Sprint Review. Mais comment sont-elles arrivées à un stade où elles ne craignent plus le fameux effet démo ? Nous allons vous proposer quelques pistes.

Tout d’abord qu’est-ce que l’effet démo ?

Ce sont tous les irritants, bugs techniques ou d’environnements, bases de données vidées, serveurs hors service, etc… qui ne sont pas prévus et qui empêchent d’atteindre l’objectif du rituel en donnant bien souvent des sueurs froides à l’équipe de développement face aux parties prenantes. Attention, cependant, l’effet démo n’est pas uniquement lié à la technique, on peut aussi le rencontrer suite à un manque de préparation de l’équipe par exemple.

Maintenant que nous connaissons la cause de nos peurs, nous pouvons nous employer à les contrer. Répondons d’abord à nos craintes sur les soucis techniques. Les effets démo dus à des « problèmes » techniques peuvent avoir beaucoup de sources différentes, une base de données purgée pendant la nuit, des données modifiées par une autre équipe, des serveurs hors services, etc…

Voici quelques astuces pour les éviter :

• Créez une capture vidéo de chaque User Story que vous voulez démontrer le jour J. Si vous ne pouvez pas montrer les nouvelles fonctionnalités à cause d’un souci technique, cela sera toujours mieux que de ne rien montrer aux personnes présentes, et vus pourrez ensemble commenter les nouvelles features de l’application.
• Préparez les environnements de démonstration la veille au plus tard, et assurez-vous qu’ils soient encore fonctionnels le matin du rituel. Faites un tour rapide de l’application pour être sûr que les jeux de données sont toujours conformes à la préparation.
• Imposez-vous un processus de stabilisation de sprint évitant les commits de dernière minute. En effet, on a tous entendu au sein d’une équipe de développement : “il me reste juste ce bout de code et ensuite on va pouvoir la passer en done, je le fais ce matin juste avant la démo”.
• Même si cette astuce tombe sous le sens, ne montrez que ce qui est fini (DOD -> Definition Of Done) : on connaît tous l’excitation et la fierté de vouloir montrer son travail accompli même si pas totalement terminé et la frustration que cela peut engendrer de ne pas pouvoir montrer une User Story qui vous a pris des jours et des jours de travail.

Comme pour les examens, plus on se prépare à les passer, plus on a de chance que cela se passe comme prévu. La préparation du Sprint Review est importante et il ne faut laisser aucune place au hasard.

Voici quelques astuces qui vous permettront de préparer au mieux la démonstration :

• L’équipe écrit le scénario de démonstration. Celui-ci va comporter l’ordre de passage des US et de ceux qui les présentent. Il doit être partagé à toute l’équipe pour que celle-ci sache à tout instant où nous nous trouvons dans la démonstration et ne pas perdre le fil. Dans ce cadre, un certain nombre de techniques existent pour ne pas avoir à construire le filage du sprint review en fin de sprint (pouvant bien souvent être chronophage) notamment avec la mise en place d’un story board qui peut être ajouté dans le DOD Definition Of Done.

• Faites une répétition à blanc de la démonstration entre tous les développeurs. Cela permet de remonter les parties où il est nécessaire d’avoir plus d’explications, de changer l’ordre de passage des US pour avoir une démo plus fluide, etc…Lors de cette répétition, notez dans une partie « jeu de données » les données nécessaires pour avoir une démonstration avec les données qui sont au plus proche de la réalité. Ainsi, vous ne perdrez pas de temps pendant la démonstration pour arriver au use case souhaité (le copier-coller sera votre meilleur ami pour remplir les formulaires ou certains champs nécessitant des inputs bien spécifiques). N’hésitez pas à créer plusieurs jeux de données pour les user stories car les parties prenantes voudront essayer le produit et réutiliser des données similaires.


• Enregistrez le temps que vous prend cette préparation et essayez de l’améliorer de sprint en sprint, pour ne pas perdre de temps sur les tâches du sprint


• Avec un peu d’entraînement, cette préparation permet à toute l’équipe de se synchroniser en moins d’une heure pour un sprint de 3 semaines et arriver avec une démo fiable et fluide.

Bien sûr, le Sprint Review abordera d’autres points que juste la démonstration, mais c’est tout de même l’axe central de ce rituel et surtout le point de départ pour la récolte des feedbacks utilisateurs. Une mauvaise démo, entraînera irrémédiablement de mauvais feedbacks (pas seulement négatifs, mais aussi de mauvaise qualité) et il sera plus difficile de rentrer dans le cercle vertueux de l’amélioration continue.

Gardez bien en tête que le sprint review est un moment clef, notamment du cycle d’itération SCRUM, car il présente le fruit et la qualité de votre travail auprès des parties prenantes.

De plus, le sprint review donne bien souvent la tendance sur le sérieux avec lequel est mené le projet : évitez donc au maximum cet effet démo…