Ne fais pas ça en Sprint Review !

[@ScrumLife]

Une question, un doute, quelque chose à ajouter ? Ajoute-le en commentaire ! ⌨👇 Nous en échangerons lors du 🔴Live jeudi : sl.run/8X7s1p

[@garancera]

Le gros problème sur la valeur, c'est justement que souvent ce sujet est implicité devenant comme secondaire avec une centralisation sur le produit. Ainsi tous les commentaires se fondent sur la marge (qui diverge bien plus facilement de l'attendu) sans s'arrêter sur les impacts générés par le sprint. La favorisation des reviews productive passe souvent par une transformation de la démo par un passage à la main du client qui prend place face au produit et appréhende ce dernier comme un utilisateur final. Après est-ce que la review est suffisante pour saisir tous les use cases ? souvent non, c'est là toute la place de l'environnement de test, mais là encore il s'agit de prévenir ce truc qui survient : on fait la review = c'est en test merci bon j'ai pas que ça à faire, je vous ferai des retours, bonne journée... Bref souvent ouvrir le sujet de la review passe par une question du renforcement de l'implication de toutes les parties autour du produit...

[@ScrumLife]

Très bien résumé Garance ! As-tu un conseil à partager pour renforcer l'implication des parties prenantes ? -- JP

[@garancera]

@@ScrumLife Renforcer l'implication des parties prenantes et recentrer le produit sur sa valeur pourrait être à lui seul l'objet d'un mandat clair de scrum master. De la même manière qu'il n'est pas de produit type, ou d'équipe type, il n'est pas de partie prenante type, comprendre les motivateur d'une personne est souvent la tâche la plus difficile non tant dans un diagnostic de premier plan mais dans l'engagement de déclencheurs à l'action en vue de. L'humain n'est pas qu'un être rationnel, c'est à la fois parfois si désespérant mais c'est tout ce qui est passionnant quand on veut s'intéresser à cette question vaste...

[@christallon7856]

Vidéo très utile et intéressante, qui va me servir 🙂 merci 👍

[@ScrumLife]

Top ! Comment vas-tu t'en servir, justement ? -- JP

[@eirianlegoux]

On va tout casser t'inquiète ! 🤣 En phase sur le contenu de la review. Et pour revenir sur l'épisode précédent : review ou pas review sur un "projet" géré en Scrum dont le sujet est un chantier technique (même si on en convient, impact utilisateur il y a ) ?

[@nicolasrenard8997]

Bonne question ! Pour ma part, j'ai tendance à dire "review courte" mais sans démo. Histoire de montrer aux parties prenantes, que l'on avancé sur un sujet, même s'il est très/trop technique.

[@ScrumLife]

Vu que l'enjeu c'est de parler *valeur* une discussion autour des impacts aura sûrement plus d'utilité qu'une démo technique. Donc même s'il n'y a pas de démo, on présente les sujets, on les contextualise, on rappelle pourquoi on les fait, on dit où on en est et ce qu'on a découvert. Attention, pas de démo ne veut pas dire qu'on ne montre pas de résultat. On pourrait par exemple montrer que l'intégration continue met maintenant 12 minutes au lieu de 2 heures à s'exécuter. Tout comme, dans le cas d'un produit grand public, montrer la synthèse de résultats de tests utilisateurs aura sûrement plus de valeur qu'une démo du produit aux parties prenantes -- du moins dans une logique de pilotage produit. Qu'en pensez-vous ? -- JP

[@eirianlegoux]

En phase !

[@nicolasrenard8997]

Merci pour ce retour ! 😇

[@jayce5734]

Sur une review technique, peut-être que le casting diffère. Permettant d'avoir un publique en lien avec cette partie technique (Architecte, DBA, ...) attention à bien vulgariser les termes et simplifier l'explication en présence de personne néophytes sur un sujet.

[@vanneckkenne9159]

👏👏👏

[@ScrumLife]

Merci ! Quel passage ou conseil retiens-tu tout particulièrement de cette vidéo ? -- JP

Avec ses torts et défauts j'avais une technique, en tant que SM j'avais créé des "cartes" papiers style "canevas" mais en format A6, de couleurs différentes et "champs" à remplir... pour chaque type de carte : Story/Epic | Bug | Question | Feedback|emotion | meeting | peur/risque . Et je demandais à tous les participants de remplir les champs obligatoires. (auteur/description) Ça, c'était pour tempérer les réponses et débats, forcer de poser son idée…, et ne perdre aucune idée. Si quelqu'un voulait prendre la parole, je lui demandais de commencer par l'écrit.

[@ScrumLife]

Intéressant ! Demander de l'engagement pour porter une idée ou un feedback, et pas juste le shooter sans se soucier des conséquences. Qu'est-ce que tu as réussi à provoquer avec cette approche ? -- JP

@@ScrumLife oui 1°Moins de "celui qui parle le mieux/le plus/fort/percutant a forcément raison" 2° on a capté l'idée brute , on peut la traiter en temps voulu 3° les idées sont structurées par les différents canevas et exerce l'audience à y réfléchir 4° ça ne brise pas la spontanéité, car le non verbal reste présent et les gens ne sont pas bâillonnés

J'invite les gens à essayer l'expérience, mais sans chercher ces mini templates que je n'ai pas publié ;) Mais bien en créant, en équipe, ces canevas sur feuille A6 avec les couleurs pour dessiner le cadre Et créer en équipe les champs "Quelle info on veut capturer ?". - Prévoir des champs à préremplir avant la session "date" "code projet" - penser plus large que la revue de sprint (par exemple la fiche 'besoin d'un meeting" est super efficace quand une dans un meeting une discussion dérive hors de l'objectif du meeting présent" ca capture l'essence du besoin d'en discuter, tout en clôturant la discussion )

[@nicolasponcet8626]

​@ Ta proposition est très intéressante. J'ai été un peu perturbé par l'approche de la vidéo qui semble proposer que l'on ne parle pas des bugs, etc car ce n'est pas directement lié à la valeur ... L'incrément de produit est là pour tenter d'ajouter de la valeur, rapidement, et doit donc être potentiellement livrable en Production. Le niveau de qualité attendu est par exemple 'contraint' par la DoD. Selon le niveau de qualité attendu, livrer avec des typos, des boutons de couleurs différentes selon les écrans, etc peut détruire une certaine valeur du produit, une qualité perçue par les clients. Si la DoR/DoD donne des directives sur ces points, il faut les relever en Sprint Review (sans forcément rentrer dans le détail de chaque écran, pièce fabriquée, etc). On attend des PP de signaler ces dégradations qui signifient que non, ce n'est pas DONE, pas livrable en l'état car en inadéquation avec le niveau d'exigence de qualité (par forcément justement quelque chose de parfait) sur lesquelles PP et équipes Scrum se sont accordés. Ainsi, du style 'Boite à idée' que l'on peut revoir en Retro ou en Sprint Planning est une bonne idée. On ne passe pas sous silence les défauts, on peut voir rapidement par topics où sont les axes d'améliorations, et on ne passe ainsi pas la moitié de la Review sur les détails. Ainsi, il devrait en effet être possible en fin de Sprint Review de faire une revue rapide des 'tickets' et de conclure quelle chose comme : "OK, nous allons prendre en compte les remarques et en première lecture, nous comprenons qu'il faut apporter plus d'attention aux textes, ou à l'UX, etc" => As-tu aussi des fiches pour les 'bons points' relevés par les PP ?

@@nicolasponcet8626 quand on me parle de bug, je repense toujours à la vidéo Scrum Life "Pilotage Projet : BUG ou FEATURE ?" avec Frédéric Leguedois et cette définition (ou cette réponse à la question ) la seule différence entre les deux c'est qui va payer ;)

[@sophiebukowski6802]

Tssssssss tsssss, non mais là vous allez trop loin dans le n'importe quoi 🐍! (les vrais savent 😂) Que diriez-vous à celle / celui qui réagit en disant : "ah mais tu vois, la recette fonctionnelle c'est pas pendant le sprint, c'est après la review !" Genre, le feedback sur la couleur du bouton ou la typo, ça fait partie la recette fonctionnelle ou genre, c'est pas pour l'équipe Scrum (ou plutôt pas pour les dev, parce que dire que c'est pour le PO, là, la p'tite dame ou le p'tit monsieur va être d'accord, c'est bien le PO qui doit valider tout après tout 😁). Ce qui semble revenir souvent comme doléance de la part d'une PP c'est qu'elle doit "se 'contenter' d'une solution partielle parce qu'"on est en agile alors hein, alors c'est ça le problème, on fait pas un produit fini d'un coup". Comment la satisfaire, comment répondriez vous à une PP qui veut un produit fini qui couvre tout ces processus et qui râle en review "tfacon ya que des p'tits bouts de solutions imparfaites" et qui a le sentiment de perdre son temps à faire du feedback (du bon et du mauvais, mais qui s'attache au mauvais).

[@ScrumLife]

Salut Sophie ! 🐍😉 Pour le premier cas de figure, je dirais que les personnes qui font cette "recette fonctionnelle" doivent juste râler en disant que ce n'est pas possible de trouver tous ces problèmes. Alors attention : il y a problème (dans le sens "c'est pas comme on a dit") et découverte (dans le sens "maintenant que je le vois bouger je me dis que"). Pour les problèmes, ce n'est pas acceptable et l'équipe devrait travailler collectivement à réduire ça. Un conseil : Example Mapping 😋 Pour le cas de la partie prenante gênée de construire le produit incrémentalement, il faudrait lui montrer plutôt le temps gagner avec ce qu'on a découvert tôt. Mais bien entendu... Cela suppose qu'on ait *effectivement* découvert des choses tôt. Si en réalité on déroule un cycle en V déguisé en agilité, ma foi, la partie prenante aura raison : arrêtons la mascarade et assumons qu'on fait du cycle en V. Qu'en penses-tu ? -- JP

[@isotope222]

@@ScrumLife Totalement d'accord sur les différentes parties. La confusion entre cycle en V découpé et agilité n'est pas toujours facile à identifier pour des SM et PO peu expérimenté. C'est un piège dans lequel il est facile de tomber.

[@jayce5734]

J'emmènerais cette PP faire un atelier Artistes & Spécifieurs :D