Arrêtez de faire le tour de vos tickets

La démo commence dans six minutes. Quelqu'un cherche un compte de test. Quelqu'un d'autre demande quel environnement a la dernière version. La personne qui présente a ouvert Jira et filtré pour Terminé, ce qui semble maintenant être l'ordre du jour. Il y a quatorze tickets, trois présentateurs différents et aucune réponse évidente à la question qu'une partie prenante est sur le point de poser : « Qu'est-ce que nos utilisateurs peuvent faire maintenant qu'ils ne pouvaient pas faire avant? »

C'est ainsi qu'un bon travail d'ingénierie se retrouve dans une mauvaise démo. Un développeur explique une implémentation complexe, parcourt un nouvel écran et passe la parole à la personne suivante. Tout le monde a travaillé fort. Tout le monde est poli. À la fin, l'auditoire sait que des choses ont été complétées, mais doit peut-être encore faire le travail de comprendre pourquoi elles importent.

Une meilleure préparation commence plus tôt que la vérification du partage d'écran. Cela signifie relier le travail complété à un problème que les gens reconnaissent, montrer ce qui a changé et faire de la place pour une réponse utile. Une répétition plus longue de la liste de tickets ne vous y mènera pas.

Commencer par le changement que quelqu'un peut reconnaître

Un titre de ticket a du sens pour les personnes qui ont passé deux semaines à en discuter. Les parties prenantes n'ont peut-être pas ce contexte. « Ajouter un point de terminaison d'approbation en lot » leur dit ce que l'équipe a construit. Cela n'explique pas la journée de qui était difficile, quelle partie est maintenant différente ou ce qui reste non résolu.

Imaginez une équipe qui construit un outil d'achat pour les gestionnaires de département. L'ancienne démo commence par un numéro de ticket, mentionne le nouveau point de terminaison et montre une case à cocher de sélection. Le présentateur approuve trois demandes. Ça fonctionne. « Des questions? » est accueilli par le genre de silence qui fait que les gens vérifient s'ils sont encore en sourdine.

Le même travail pourrait être présenté différemment : « Un gestionnaire qui révise un lot de demandes de routine doit actuellement ouvrir et approuver chacune séparément. Nous avons ajouté une façon d'approuver les demandes admissibles ensemble. Je vais montrer ce parcours, puis ce qui se passe quand une demande nécessite une révision individuelle. Nous aimerions votre aide pour vérifier si les règles d'admissibilité correspondent à votre façon réelle de travailler. »

Maintenant, les clics ont un but. L'auditoire peut inspecter le comportement par rapport à une situation qu'il comprend. Quelqu'un pourrait souligner que les demandes d'un nouveau fournisseur nécessitent toujours une vérification séparée. C'est une découverte utile, même si elle rend la démo moins soignée.

L'équipe devrait aussi être précise quant à ses preuves. Montrer une action en lot qui fonctionne établit que la capacité existe. Cela n'établit pas combien de temps les gestionnaires économiseront, s'ils l'utiliseront ou si les approbations s'amélioreront. Ce sont des choses à investiguer après l'utilisation. « Nous nous attendons à ce que cela réduise les étapes répétitives » est une explication honnête de l'intention. « Nous avons rendu les gestionnaires plus productifs » nécessite des preuves que la démo seule ne peut fournir.

Le travail technique mérite la même clarté

Cette approche ne devrait pas transformer une révision en concours de beauté pour les fonctionnalités visibles. Un sprint passé à améliorer la récupération, la sécurité ou la maintenabilité peut avoir énormément d'importance. Personne n'a besoin d'inventer un nouveau bouton pour le justifier.

Pour un changement de récupération, montrez le scénario d'échec, comment le système répond maintenant et ce que le test démontre. Pour une mise à niveau de dépendance, expliquez quel risque elle adresse et comment la compatibilité a été vérifiée. Reliez le travail d'ingénierie à la conséquence qu'il vise à changer, en utilisant les preuves disponibles et en étant clair sur leurs limites.

Se préparer pour une conversation

Sachez qui écoute. Un auditoire d'affaires peut avoir besoin de l'impact sur un flux de travail et de la décision qu'il permet. Un auditoire technique peut avoir besoin d'inspecter les choix d'implémentation et les compromis. Avec les deux dans la salle, commencez par pourquoi le changement importe, puis fournissez la profondeur nécessaire pour l'examiner.

Si vous n'avez que dix minutes, décidez quelle valeur d'affaires l'auditoire a le plus besoin de comprendre. Dans l'exemple d'achat, cela pourrait signifier montrer le parcours d'approbation en lot et vérifier les règles d'exception, plutôt que de faire le tour de chaque ticket complété. Choisissez ce qui aide les gens à prendre une décision utile. Gardez l'objectif de sprint en vue, y compris où le résultat est insuffisant; une démo plus courte ne devrait pas cacher un résultat gênant.

Pour chaque élément, l'équipe devrait être capable d'expliquer le problème, le comportement changé et les preuves derrière ses affirmations. Ensuite, demandez quelle réponse serait utile. Vérifiez-vous une hypothèse sur un flux de travail? Choisissez-vous entre deux prochaines étapes? Testez-vous si une limitation est acceptable? Une question spécifique donne aux gens une façon d'entrer dans la discussion que « Des commentaires? » offre rarement.

La préparation pratique importe toujours. Confirmez ce qui respecte la définition de terminé, ce qui est déployé où et ce qui peut réellement être démontré. Configurez des données représentatives et vérifiez le parcours que vous prévoyez montrer. Laissez du temps aux gens pour interrompre. En Scrum, la démonstration n'est qu'une partie de la revue de sprint, où l'équipe et les parties prenantes inspectent le résultat et déterminent quoi faire ensuite. Elle devrait soutenir cette collaboration, pas consommer tout l'événement.

Comment Flow aide

Les notes de démo de Simyl Flow peuvent être ajustées pour un auditoire d'affaires, technique ou mixte. En plus de suggérer des éléments complétés dignes de démo, ses notes relient le travail à la valeur d'affaires et fournissent des points de discussion, des questions anticipées des parties prenantes et des réponses suggérées. L'équipe a un point de départ pour expliquer pourquoi un changement importe et se préparer pour la conversation qu'il peut susciter. Dans l'exemple d'achat, cela pourrait signifier se préparer pour des questions sur les exceptions, avec des réponses vérifiées par rapport au comportement réel.

Quand l'ordre du jour est comprimé, les notes incluent aussi un bref « Si le temps manque, soulignez : », rassemblant les points de valeur d'affaires des éléments du présentateur. L'équipe décide toujours de l'ordre et des priorités, vérifie ce qui est prêt à démontrer et vérifie les affirmations. Flow aide à garder l'explication concentrée; l'équipe reste responsable de ce qu'elle dit.

Le temps de préparation s'additionne à travers l'équipe. À titre d'exemple illustratif, si Flow économise à quatre développeurs quinze minutes chacun avant une démo, cela retourne une heure-équipe. À un coût chargé supposé de 75 $ US de l'heure, c'est 75 $ US de capacité, plus que le prix mensuel Growth de 49 $ US par équipe. Une démo peut couvrir le mois sur ces hypothèses, et la préparation de démo n'est qu'une des cérémonies que Flow soutient. C'est du temps disponible pour d'autre travail, pas une économie garantie ou de l'argent retiré de la masse salariale. Sauter la préparation a aussi un coût : cela laisse tout le monde dans la réunion à démêler ce qui aurait dû être expliqué au préalable.

La conversation a aussi besoin d'un endroit où aller après. Flow peut transformer les commentaires de démo en cartes de rétro et actions, aidant l'équipe à porter l'apprentissage dans son travail d'amélioration. Les commentaires produit devraient aussi informer les décisions pertinentes du carnet de produit. Une demande pour une règle de fournisseur manquante et un problème récurrent avec les environnements de démo nécessitent un suivi différent, même quand les deux proviennent de la même révision. Convenez qui prendra chaque suivi en charge et quand l'équipe vérifiera ce qui s'est passé.

Avant la prochaine démo, regardez le premier élément que vous prévoyez montrer. Quelqu'un à l'extérieur de l'équipe peut-il comprendre qui cela aide, ce qui a changé et ce que vous devez encore apprendre? Sinon, continuez à préparer l'explication, pas à ajouter plus de tickets. Donnez aux gens assez pour questionner, pas juste assez pour applaudir. Ensuite, utilisez ce que vous entendez pour décider ce qui se passe ensuite.