Return to site

Comment préparer ses démos de fin de sprint ?

Et pourquoi est-ce nécessaire de les préparer ?

· Amélioration continu,Scrum

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é du Sprint en l'illustrant, et ce idéalement par des scénarios de la vraie vie des utilisateurs.

Ce qui semble facile lorsque l'on développe des applis Web ou mobiles, mais qui l'est un peu moins dès lors que l'on travaille sur des applis de gestions, et d'autant lorsqu'elles fonctionnent principalement via des appels ou envois de données métiers et très peu d'écrans utilisateurs.

Dans ce cas, il arrive souvent que parmi les parties prenantes, certaines personnes ne connaissent pas le vocabulaire de tous les composants de l’application. Ou encore que les termes, "batch", "web services" ou "IHM" perdent rapidement des utilisateurs métiers. Travaillant sur un référentiel de données commerciales qui envoie et appelle des données au CRM, ainsi qu'aux SI de devis et de facturation par exemple, c'est exactement mon cas.

Ne cherchez pas pour autant à cacher les détails techniques, car vos utilisateurs sont souvent curieux d'en apprendre plus. En revanche, posez-vous la question suivante : "comment puis-je imager ce concept technique avec 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.

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. Ou n'hésitez pas à préciser derrière un concept technique introduit : "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. Pour ma part, le PO est chargé de l'introduction afin de rappeler les objectifs qui étaient attendus dans le sprint. Puis la main est passée au DEV qui a choisi d'animer la démonstration.J'ai donc un seul démonstrateur. Evitez les "Bonjour, je suis Pierre, développeur et je vais commencer la démo en vous présentant la carte 3228 et la carte 4536 et je passerai ensuite la main à Marc qui vous présentera la carte 4536 et la carte 7658" ! Votre auditoire se moque des numéros de cartes et ne veut pas de perte de temps de transition entre les pseakers. Il veut que ce soit fluide, percutant et que ça raconte une histoire. Or en multipliant, les speakers, vous entretenez une pésentation indépendante des cartes au lieu de chercher une logique de présentation de l'ensemble des cartes réalisées et donc un "storytelling" associé qui donne du sens ou une forme de projection utilisateur.
  • Assurez-vous que tout le monde voit les manipulations du démonstrateur et l’entend : mouvement de souris lents et bonne connexion audio avec les équipes métiers délocalisées. Je rappel toujours de se mettre en "mute" pour minimiser les désagréments de bruits de fonds
  • Énoncez l’histoire avant de dérouler le scénario permet à l’auditoire de comprendre.
  • Gardez conscience de votre rythme et du temps passé
  • 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...". Le AVANT / APRÈS marche toujours très bien dans les démos

Checklist des points de préparation pré-démo

Mes cérémonies de Sprint se déroulent le jeudi. Nous sommes sur des sprints de 3 semaines. Sachant que le DEV qui réalise la démo s'est porté volontaire en début de sprint. DEV = développeur réalisant 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 : Le backlog de sprint est consulté. Les scénarios démontrables sont envisagés
  • DEV+SM : Une première organisation fonctionnellement logique des scénarios est posée
  • DEV+SM  : Le tableau des US démontrées au sein des différents scénarios est complété en parallèle
  • SM : une proposition est faite au PO en envoyant le tableau par mail
Exemple de tableau :
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, et de proposer un point d'amélioration continue en terme d'engagement et d'interaction des personnes métiers et/ou du client lors de la démo en reprenant les feedback des démos précédentes
  • 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. Listing des 3-4 principaux scénarios dans la notification de rappel de l'évènement envoyé par mail la veille en fin d'aprèm

  • DEV : les scénarios sont joués pour détecter d'éventuelles incompatibilités ou des US non statuées à "terminé"

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
  • Si certains tests sont négatifs, les cartes jiras du tableau sont supprimées
  • 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
  • Éventuellement, tour de table que chacun se présente en une phrase (prénom + relation avec le projet RefCOM. Au delà de 15 personnes présentes, invitez chacun à donner son prénom et le nom de son SI lors de chaque prise de parole, et surtout lorsque les personnes sont principalement connectées en audio à distance
  • 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 a des remarques, suggestions, questions au cours du déroulé et suite au déroulé. Les inviter à se projeter et à remonter leurs retours d'expérience.
  • Conclure en rappelant la date de la prochaine démo et éventuellement les prochaines fonctionnalités à développer 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'un import de données en masse...." les raisons sont souvent nombreuses pour justifier l’absence de matière concrète à présenter en démo.

Et 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...

Post démo et amélioration continue

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" afin de le documenter et de m'en inspirer lors des futures préparations de démo.

Jouer avec l'amélioration continue en vous donnant à chaque nouvelle démo un challenge ou petit jeu basé sur un point d'amélioration continue à 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 administrateur des ventes du territoire Y,  je vais importer des portefeuilles en masses afin de préparer ma nouvelle année commmerciale, je sélectionne le menu Z pour importer mon fichier préparé la veille avec mon équipe commerciale..."
  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, ils 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 de gestion 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. On l'a fait récemment pour leur demander un support dans le cadre d'une ré-écriture des messages d'erreurs. Bien sur, rappelez leur l'intérêt du feedback pour vous, comment c'est un moyen pour eux de voir des évolutions le plus rapidement possibles en les mentionnant en démo afin que le PO en prenne note pour les prioriser dans un prochain Sprint.

Des remarques, suggestions, postez vos commentaires que l'on approfondisse ensemble le sujet...

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly