Un exercice de communication avant tout...

La démonstration de fin de sprint, ou "Review" pour le terme Scrum anglais est un exercice de communication.
L'enjeu est de réussir à démontrer le réalisé de l'itération ou sprint en l'illustrant, et ce, par des scénarios de la vraie vie des utilisateurs. Les démos semblent plus faciles lorsque l'on développe des applis web ou mobiles front, que lorsque l'on travaille sur des applis de gestions, admin et back office. La démo est souvent associée à des interfaces utilisateurs. Et j'entends souvent lorsque j'arrive sur un nouveau projet : "nous n'avons rien à démontrer", sous entendu, nous n'avons pas d'interface utilisateur à démontrer. Je réponds en reprenant le terme "Review" en anglais pour expliquer qu'une démo est une revue de l'itération qui vient de se dérouler et que l'on peut toujours trouver à démontrer ce que l'on vient de réaliser, quand bien même c'est purement technique et qu'il n'y a pas d'interface utilisateur. Seulement, pour y parvenir il est nécessaire de préparer ses démos ou revues.

Ne cherchez pas pour autant à cacher les détails techniques. Ayez en tête que vos utilisateurs sont curieux d'en apprendre plus, de comprendre comment vous fonctionnez. Une démo un peu trop technique pour certains utilisateurs sera mieux que pas de démo du tout en fin d'itération.

L'utilisateur peut toujours poser des questions, se renseigner, faire de la veille et ainsi retirer des éléments de cette démo.
Ceci dit, lorsque vous êtes amenés à préparer une démo principalement technique, posez-vous la question suivante : comment puis-je imager ce concept technique en utilisant une sémantique "grand public"? ou employez le terme technique, mais en l'expliquant simplement en une phrase derrière.

Pensez aux médecins et ce que ça donnerait s'ils employaient uniquement des termes médicaux dans une conversation, ou aux botanistes s'ils n'employaient que des termes latins !
Les problématiques sont souvent liées à la sémantique utilisée, ainsi qu'aux métaphores ou images employées pour simplifier le concept.

Donc ne cherchez pas à dissimuler la technique à tout prix, mais pas besoin non plus de s'y attarder.

Si vous avez en face de vous des utilisateurs qui veulent en savoir plus, faites leur confiance, ils poseront des questions.

Et n'hésitez pas à préciser derrière un concept technique que vous venez d'introduire : "pour ceux que ça intéresse, je vous propose de prendre 5min à la fin pour aller plus loin".

Quelques conseils relatifs à toute présentation en public :

• Limitez le nombre de démonstrateurs à un à la fois. Pour ma part, le Product Owner est chargé de l'introduction. Il rappelle le contexte et le ou les objectifs métiers qui étaient attendus dans l'itération. Puis la main est passée au Développeur qui a choisi d'animer la démonstration. J'ai donc un seul démonstrateur. Évitez à tout pris les démos multi-speakers du type "Bonjour, je suis Pierre, développeur et je vais commencer la démo en vous présentant la carte 328 et la carte 436 et je passerai ensuite la main à Marc qui vous présentera la carte 453 et la carte 765" ! Votre auditoire se moque des numéros de cartes et ne veut pas de perte de temps de transition entre les speakers. Votre auditoire veut que ce soit fluide, percutant et que ça raconte une histoire. Or en multipliant, les speakers, vous entretenez une présentation indépendante des cartes réalisées au lieu de chercher une logique de présentation de l'ensemble des cartes réalisées et donc un "storytelling" qui donne du sens et qui permet aux utilisateurs présents de se projeter dans des scénarios d'utilisation.
• Assurez-vous que tout le monde voit les manipulations du démonstrateur et l’entend. Faites des  mouvements de souris lents. Ayez une bonne connexion audio avec les équipes métiers délocalisées. et parler prêt de votre micro si c'est un micro partagé entre plusieurs personnes.
• Minimisez les bruits extérieurs. Je rappelle toujours aux personnes connectées de couper le son lorsqu'elles ne s'expriment pas pour minimiser les désagréments liés aux  bruits de fond.
• Contextualisez. Énoncez l’histoire avant de dérouler le scénario permet à l’auditoire de comprendre.
• Gardez conscience de votre rythme et du temps passé. Vous ne voulez pas qu'une démo dure plus d'une heure et c'est d'autant plus vrai que vous avez des personnes à distance.
• Le AVANT / APRÈS marche toujours très bien dans les démos. Engagez l'auditoire en lui donnant des indicateurs dans le temps : "avant, les actions étaient les suivantes"... "à présent, il est possible pour l’utilisateur d'utiliser...".
• Impliquez vos utilisateurs tout au long de la démo en leur demandant régulièrement s'ils ont des remarques, des questions, des retours d'expérience à partager. Une démo réussie est une démo qui a fait réagir les utilisateurs métiers, qui les a amené à se poser des questions, à se demander si ce qui a été développé répond bien à leur besoin. Vous voulez éviter les démos qui se déroulent sans interaction avec le "mortel" : des questions ? à la toute fin. Faites réagir votre auditoire. C'est l'indicateur numéro 1 d'une démo réussie. Les réactions de son public.

Mes cérémonies de Sprint se déroulent le jeudi. Nous sommes sur des sprints de 2 semaines. Le DEV qui réalise la démo s'est porté volontaire en début de sprint.
DEV = développeur s'exprimant principalement lors de la démo / SM = Scrum Master / PO = Product Owner
Voici les 3 étapes de préparation à la démo les semaines de cérémonies :
J-2 - le mardi : Préparation du contenu à présenter

• DEVS ensemble : Le backlog de sprint est consulté. Les scénarios démontrables sont envisagés idéallement à partir des cas de tests écrits au préalable dans le descriptif des user stories.
• DEV+SM : Une première organisation fonctionnellement logique des scénarios est posée

J-1 - le mercredi : Les scénarios sont ajustés

• DEV+SM+PO : un point de préparation de la démo se tient avec l'intention de valider l'ordonnancement des scénarios, de préparer l'introduction métier. Je profite également de cette préparation pour s'accorder sur un point d'amélioration en terme d'engagement et d'interaction des personnes métiers  lors de la démo en reprenant un fichier de feedback listés et capitalisé à partir de toutes les précédentes démos. 
• DEVTEAM : Les déploiements sont terminés à 15h la veille pour assurer un environnement de démo stable le lendemain matin

• PO : Le métier et/ou client et utilisateurs sont avisés des scénarios qui seront démontrés via une notification de rappel de la démo. Listez les 3-4 principaux scénarios dans la notification de rappel de l'évènement envoyé par mail la veille en fin d'après-midi pour engager vos métier à venir assister à la démo.

• DEV : les scénarios sont joués pour détecter d'éventuelles incompatibilités ou des US non statuées à "terminé", ainsi qu'utiliser des jeux de données qui ont du sens pour vos métiers. Vous voulez éviter les "toto" et les "lorem ipsum". Employez des jeux de données qui se rapprochent le plus possible de la réalité des utilisateurs si vous voulez les faire réagir.

Puis, itérativement :

• Le niveau de détail des scénarios est adapté
• Les scénarios sont répétés et enchainés sur l'environnement sur lequel aura lieu la démo
• Le PC nécessaire pour la démo est préparé paramétré avec les environnements et outils de communication nécessaires lors de la démo

J - "Jouez ! "
Le déroulé de la démo est le suivant :

• Intro par le PO pour reprendre les enjeux métiers qui étaient attendus et synthétiser ce qui a été développé d'un point de vue métier
• Passage de relais au développeur réalisant la démo
• Déroulé des scénarios préparés à partir des cartes réalisées au cours du sprint, et ce en remettant dans le contexte afin que ça parle à tout le monde
• Démontrer en détaillant les actions réalisées au fil de l'eau et en comparant ce qu'il y avait avant et ce qu'il y a à présent afin de capter l'intérêt des utilisateurs
• Demander s'il y des remarques, suggestions, questions au cours du déroulé et suite au déroulé.  Invitez vos utilisateurs à se projeter et à remonter leurs retours d'expérience. N'oubliez pas qu'une bonne démo est une démo avec un maximum de retours utilisateurs.
• Conclure en rappelant la date de la prochaine démo et éventuellement les fonctionnalités à développer dans la prochaine itération et la prochaine mise en production.

Le point de préparation permet de s'aligner sur qui est présenté au métier, ainsi que de dépasser le sentiment de ne pas avoir grand chose à montrer au métier (quand c'est le cas). "Mise en place d'un nouveau « socle technique », "montée en compétences d'un nouveau dev, modification de web services, création d'imports de données, migration...." les raisons sont souvent nombreuses pour justifier l’absence de matière concrète à présenter en démo.

Les applications de gestion requièrent parfois moins d’interaction avec l’utilisateur, rendant l’exercice de démonstration de scénarios plus "challengeant"... Dépassez ce challenge !

Voyez comment vous tourner vers une présentation simplifiée de certains aspects techniques, de rendre visible le fonctionnement du back office de l'appli, de poser à vos utilisateurs un contexte via un scénario d'utilisation pour qu'ils puissent se projeter...

A la fin de la chaque démo, lorsque tout le monde a raccroché, et qu'il ne reste plus que l'équipe projet présente, je garde 5min de feedback pour lister "ce qui était bien" et "ce qui aurait pu être mieux". Je documente les points relevés afin de m'en inspirer lors des futures préparations de démo. Je note également le nombre de personnes présentes à la démo, ainsi que les interactions qui se sont passées. Qui a posé une question et qu'elle était la question. Je reviens ainsi sur les points listés lors des préparations de démos pour m'assurer d'être dans une démarche d'amélioration continue d'une démonstration à l'autre.

Je peux également noter les demandes d'évolution soulevées en support au PO pour m'assurer post démo que l'on est bien en phase avec ce qui a été demandé et permettre ainsi au PO de ne pas stresser en situation fac à un client exigeant par exemple.

Jouez avec l'amélioration continue en vous donnant à chaque nouvelle démo un challenge ou petit jeu basé sur un point d'amélioration à dépasser et attribuez-vous des points à la clé.

Les 5 principaux points d'amélioration selon mon expérience :

1. Invitez le DEV à se mettre dans la peau d'un utilisateur en nommant "je suis un vendeur dans un bureau de poste du centre historique de Montpellier,  je vais ouvrir dans le CRM ma fiche client pro avec qui j'ai RDV dans 5min, je sélectionne dans le menu le devis d'offre de renvoi de courrier pour être prêt à lancer la contractualisation..."
2. Préférez : "des remarques, suggestions ?" tout au long de la démo à "des questions ?" à la fin. Vous maximiserez grandement vos chances d'interactions avec vos utilisateurs
3. Préparez bien vos jeux de données afin de démontrer vos scénarios avec des données iso prod qui parlent vraiment à vos utilisateurs. Le cas échéants, vos utilisaturs déconnecteront plus facilement. Si vous utilisez de vraies données métiers, ils auront des éléments de comparaisons à partir desquels rebondir ou poser des questions et vous apprendront bien plus de choses en termes de règles métier par exemple.
4. Dans le cas ou l'un de vos scénarios ne fonctionne pas comme attendu, don't panic, c'est l'effet démo !  Expliquez pourquoi ça ne fonctionne pas en toute transparence pour ne pas laisser l'utilisateur dans le doute d'une anomalie, surtout si c'est un développement à affiner ou un jeu de données à adapter.
5. N'hésitez pas à solliciter vos utilisateurs pour les impliquer dans le développement de l'outil lui même. Je l'ai fait récemment lors d'une démo pour leur demander un support dans le cadre d'une ré-écriture de messages d'erreurs. Je leur ai expliqué que les meilleures personnes pour écrire les messages d'erreur, c'était eux car ce sont les utilisateurs de l'application. Et que c'était un moyen de gagner du temps par la suite dans leur utilisation de l'application au quotidien.
6. Bien sur, rappelez à vos utilisateurs l'intérêt du feedback pour vous, et expliquez-leur comment c'est un moyen pour eux de voir des évolutions le plus rapidement possible en les mentionnant en démo afin que le product-owner en prenne note pour les prioriser dans une prochaine itération.