Un Daily au top !!! DSM / Daily Scrum Meeting / Daily Standup Meeting

[@ScrumLife]

Que vas-tu essayer pour améliorer tes Daily ? Dis-le nous en commentaire ! 👇

[@Cancrelat_et_Freluquet]

Cela fait quelques semaines que je fais du 'walking board' afin de sortir des sempiternelles 3 questions qui avaient fini par endormir l'équipe plus qu'autre chose...Et bien c'est très efficace et beaucoup plus dynamique ! Merci pour le tuyau !

[@ScrumLife]

Salut @Cancrelat_et_Freluquet, Super content d’apprendre que le 'walking board' a apporté un coup de boost à ton équipe ! 🎉🚶‍♂️ Parfois, il suffit de changer un détail pour voir une grande différence, n'est-ce pas ? Qu'est-ce qui a été le plus surprenant pour toi avec cette approche ? 🎯 Hâte d'en savoir plus ! Robin

[@ericfontaine8260]

Parcourir le board, c'est ce que nous faisons avec mon équipe, en mode Kanban : on commence par examiner les colonnes les plus à droite, puis on remonte le flux de travail. Les objectifs sont de pouvoir tirer le flux quand c'est possible, de privilégier de terminer un travail déjà commencé plutôt que d'entamer une nouvelle tâche, et enfin d'avoir un board à jour en fin de daily. Le PO est présent pour ses compétences produit et ses tests, comme il peut aussi répondre à certaines questions, ça met de l'huile dans les rouages. Le 15 min, je n'aime pas quand ça dépasse parce qu'après où est la limite ? Savoir que ça ne prendra pas plus que le time box motive l'assiduité des dev (et c'est vrai pour tous les événements d'ailleurs). Lorsqu'une discussion intéressante a lieu en fin de daily, comme ça nous est arrivé hier, j'interviens juste pour dire "Le daily est terminé, mais vous pouvez continuer". Comme ça, ceux qui ne se sentent pas concernés peuvent quitter le groupe et ne se sentent pas coincés inutilement.

[@ScrumLife]

Merci Eric, tu as tout à fait raison pour la lecture de droite à gauche du board on aurait dû le rajouter, on en avait parlé dans une autre vidéo mais cela aurait eu sa place ici ! Merci pour cet ajout :) -- Constantin

[@elisef4095]

Une pratique que je trouve très intéressante lorsqu'on fait un "walk the board" : lire le board de droite à gauche, ça permet de se mettre dans une dynamique où on cherche vraiment à maximiser ce qui est terminé, en regardant ce qui n'est pas loin de l'être, au lieu d'être tenté de se dire tout de suite "qu'est-ce qu'on commence ?"

[@ScrumLife]

Oui, tout à fait ! C'est ce que vous faites dans ton équipe actuelle ? -- JP

[@sophiebukowski6802]

😻 On va continuer à adapter notre daily à nos besoins, tous ces conseils me rassure et me conforte dans la direction que nous avions prise avec notre daily de 30mn accepté par l'ensemble de l'équipe et notre routine adaptée à notre contexte.

[@ScrumLife]

Expérimentez !!! Mis à part la durée de 30 minutes, à quoi ressemble votre Daily ? Quelle est votre routine de Daily ? -- JP

[@aurelien2448]

Merci pour les conseils ! Autant je comprends que le PO fasse du test, autant celà reste une faible partie du vaste monde de la QA. Que le PO manipule le produit 1000 fois oui, mais celà ne remplacera jamais l'expertise d'un QA lead. Une vrai mine d'infos vos vidéos, merci à toute l'équipe !

[@ScrumLife]

Bien d'accord ! Merci, est-ce que tu as une vidéo préférée ? -- JP

[@louis_korczowski]

Une tuerie ce nombre d'idées géniales ! Je pense qu'il va falloir qu'on essaye le WALK THE BOARD !

[@ScrumLife]

Raconte-nous ce que ça donne ! Comment les attitudes et dynamiques ont-elles changé dans l'équipe ? -- JP

05:13 Dépassez quand il faut On en a un peu parlé dans le LIVE. les 15 minutes devraient suffire pour faire ce à quoi le Daily sert. Si on a besoin de plus de temps, même pour une discussion riche, le truc c'est pas de tuer cette discussion riche mais de se demander (après coup) "pour quoi elle arrive là ?" * Est-ce que le standup est là pour rattrapper le manque d'analyse ou de disponibilité d'un des membres de l'équipe ? * Est-ce que la question est posée pour qu'on tranche sous la pression du chrono pour éviter d'avoir une discussion soignée sur le point ? * Est-ce que l'équipe cause hors daily ? Est-ce qu'on peut le faire juste après (pas d'autre meeting collé derrière) * Est-ce que toutes les personnes requises sont là ? * Est-ce que tout le monde à sa place dans CETTE discussion ? * Est-ce que l'outil, les documents sont là pour cette discu supplémentaires ? (whiteboard, miro, .. ) * Est-ce que seuls les membres de l'équipe prennent la parole ? * Est-ce que l'équipe a une taille d'équipe Scrum ? ....

[@ScrumLife]

Merci Christophe pour cet extrait des éléments du Live ! -- JP

[@celinejanssens7817]

Top cette video.... je vois souvent des DSM trop "static" et en mode robot ou personne ne s'écoute vraiment ! Je proposerai un ROTI dès le prochain Daily histoire de voir ce qu'en retire les participants. Et peut-etre meme que je demanderai au PO de ne plus venir :) ... histoire que ce DSM ne soit plus un compte rendu au PO mais VRAIMENT utile pour les équipes donc je prévois de proposer : 1) Utiliser le board pour le DSM 2) et terminer le DSM par la question "Tout le monde sait ce qu'il doit faire ?"

[@ScrumLife]

Carrément ! Tu étais là au Live ? On avait donné des astuces supplémentaires ! -- JP

[@quietpanda6083]

Super vidéo, merci à toute l'équipe ! J'ai l'habitude de faire les 3 questions en Scrum et le walk the board en Kanban. Je vais bousculer un peu les habitudes dès demain...

[@ScrumLife]

Carrément ! Tester, expérimenter des choses différentes c'est le plus important 💪 Tu nous raconteras ce que ça donne ? -- JP

[@sandrineviez8861]

Sans hésiter je vais tester le vote de confiance.

[@ScrumLife]

👍👍👍👌 Tu nous raconteras ce que ça donne ? Et vas-tu essayer de tracer une courbe du vote de confiance chaque jour, ou bien uniquement le vote ? À bientôt ! -- JP

[@xavilav8257]

Le vote de confiance au Daily ? Bonne idée, à tester et donc proposer à notre prochaine Retrospective. Pour info le Daily est de 15min chez nous il peut déborder sans problème car en fait nous avons un slot supplémentaire de 15min juste après le Daily pour y traiter les EXTRAS comme par exemple apporter de l'aide si un dev le demande ou prendre le temps de réponde à une question. Cela peut nous éviter de casser la dynamique quand on fait le "Walk" et de prendre le temps de répondre après les 15min. Sinon, parfois, on laisse faire si l'échange est intéressant mais on tient le timing 15/30min max au total sans se forcer.

[@ScrumLife]

Intéressant ! Merci beaucoup du partage. Depuis combien de temps avez-vous mis en place cette manière de faire ? -- JP

[@laurenttrompette6477]

Actuellement on regarde aussi tous les matins le résultats des tests auto de la veille pour identifier les éventuelles régressions. On a identifier aussi avec du color coding les US faisant parti du Sprint Goal pour un meilleur visuel (oui pas toujours en tete de liste). Sinon, j'aime bien aussi faire un double passage... le premier suivi du board avec qui a fait quoi et quels obstacles, chacun parle à son tour. Puis en fonction des soucis rencontrés, demandes d'aide, urgences... au second passage chacun dit sur quoi il va travailler ou aider... Sinon, depuis que le télétravail s'impose, en effet, c'est assez frustranjt de couper à 15 minutes donc on ne le fait pas. Il faut par contre faire en sorte que ça ne devienne pas une discussion sans fins.

[@ScrumLife]

Intéressant ! Merci du partage 🤗 Est-ce que vous expérimentez régulièrement avec votre manière d'animer votre Daily ? -- JP

[@antoninmorin4564]

Le DSM n'a pour but que de mettre la pression et de checker par la peur si on a fourni suffisamment de travail

[@ScrumLife]

Salut Antonin, je te trouve très péremptoire :) Je suppose que tu veux dire par là que "là où tu es, Le DSM n'a pour but que de mettre la pression et de checker par la peur si on a fourni suffisamment de travail". Car je ne crois pas que 1/ ça soit le but et 2/ comme ça que ça se passe dans les équipes que j'ai pu accompagner :) Peux-tu nous décrire comment ça se passe de ton côté généralement ? -- Constantin

[@TVorace]

J'ai d'autant plus l'impression que mon équipe ne fait pas de l'agile quand je vois ce genre de vidéo et que je compare avec mes précédents projets. Il me faudrait un bingo du "pseudo agile". Pas d'objectif (ou "faire tout ce qui a été embarqué"), équipe de 15 devs, l'équipe est bilocalisée et la moitié ne voit pas le board, on construit en mode "plan de charge" (donc pas de montée en compétences mais une hyperspécialisation), le client ne voit pas les US mais juste les features haut niveau, le SM prend des notes sur son cahier en faisant l'appel, le SM saute son tour de parole pour être le dernier à présenter sa journée, l'équipe technique (dev) en SCRUM est séparée de l'équipe système (archi) qui a laissé tomber Kanban pour... aucune méthodo, le PO embarque ses US dans le sprint avant la planif... et le backlog review... et que les devs présentent leurs US techniques. C'est presque "apprendre à reconnaître un cycle en V déguisé en agile"

[@TVorace]

On pourrait ajouter : le SM ne regarde pas la dette technique (SonarQube) ni la stabilité (builds Jenkins)

[@TVorace]

Dans une récente vidéo, il était suggéré de regarder une vidéo de ScrumLife en équipe et de s'en servir pour créer un temps d'équipe. Je crois qu'il est urgent que je pousse le sujet pour faire prendre conscience de l'écart entre théorie et pratique

[@ttehir]

Merci pour cette vidéo, ça me donne des idées pour améliorer notre daily! Notamment la visibilité de l'objectif, le walk the board et le vote de confiance. J'aurais une question pour la communauté car je ne suis pas sûr de voir comment je pourrai proposer ça dans notre équipe. Surtout le walk the board en fait. On travaille dans un contexte startup où on développe plusieurs produits avec une petite équipe. Donc chaque développeur bosse sur plusieurs projets avec un board chacun. Si on fait un daily par projet, on y passe la matinée avec beaucoup de temps morts donc on fait un format avec tout le monde sur le classique ce que j'ai fait hier/vais faire aujourd'hui/points bloquants, et s'il y a des choses à discuter, les personnes concernées se retrouvent après le daily. Le problème c'est qu'on manque de visibilité sur l'avancement retranscrit sur les boards avec cette approche. Vous auriez des suggestions pour nous améliorer ?

[@ScrumLife]

Salut ! Il faut rester cohérent et logique. Si chacun travaille sur ses propres sujets et son propre baord, "Walk the board" ne va que moyennement marcher... Mais pourquoi pas essayer, certes on parle à tour de rôle, mais on se focalise sur le board de chacun à tour de rôle. Le but c'est de forcer le système à avoir des boards lisibles ! Qu'en penses-tu ? -- JP

[@AmorimVitor]

Bonjour, je suis dans le même cas de figure (plusieurs projets et une petite équipe). On a réuni tous les projets sur un seul board On utilise les Epic pour faire la distinctions entre les projets (sur Jira cela affiche des couleurs différentes qui facilitent la lisibilité) Les versions permettent aussi de suivre l'avancement d'un projet (ou plutôt un incrément de ce projet). En espérant vous aider.

[@casualgamer--7dsgrandcross607]

L’idée de traquer le niveau de confiance dans le burndown chart est intéressant ; ce que je propose c’est de traquer la « moyenne d’humeur » de l’équipe... le détail étant noté (traqué) et qui peut servir à la rétrospective, la moyenne est assez amusante à (se la) représenter 😁

[@ScrumLife]

En corrélant l’humeur à la confiance dans l’atteinte de l’objectif ça peut montrer des choses intéressantes en effet :-) Attention tout de même à ne pas avoir trop d’indicateurs au bout d’un moment ! ;-) - Constantin

[@cleytonsilva6879]

Hallo où est ce que je peux telechager ce doc (DOCUMENT A TÉLÉCHARGER)?

[@ScrumLife]

Salut ! Il faut s'inscrire à notre formation gratuite : scrumlife.tv/formationgratuite Dis-nous si tu utilises le document et ce que tu en penses ! -- JP

[@srk0106]

Bonjour, étant un Scrum Mastee en alternance, j’aimerai avoir quelques conseils pour mieux comprendre mon rôle et mettre en place l’agilité afin de bien réussir cette année et cette expérience en tant que Scrum Master Merci!

[@277YOYO]

Quel est ton LinkedIn/mail ? Je veux bien t'aider

[@ScrumLife]

Salut, est-ce que cette vidéo t'aiderait ? 👉 kzbin.info/www/bejne/mabalHmvqd1-g7s Je te laisse regarder et revenir vers nous ! -- JP

[@ScrumLife]

Sympa @Yohann ! Vivre le réseau et l'entraide 💪 -- JP

[@srk0106]

@@ScrumLife Merci je regarderai !

[@jpfroud]

Je ne suis pas a l’aise avec le fait de dire que dépasser la timebox n’est pas si grave. Pour moi ça met en danger l’appropriation de la valeur « focus » de scrum. Chaque événement a sa timebox pour justement pousser les équipe à rester focus sur l’objectif de l’événement. Un des objectifs du daily c’est justement identifier avec qui je vais résoudre telle ou telle difficulté, pas le faire pendant le daily donc la timebox a vraiment un sens

[@ScrumLife]

Merci Jean-Pierre. Je suis assez aligné avec toi, ce que nous avons voulu exprimer là c’est que quand ça arrive, il ne faudrait pas couper une discussion constructive juste « parce que scrum dit 15 min ». Par contre il faut effectivement se demander comment, par la suite, ne plus dépasser. Qu’en dis-tu ? - Constantin

[@jpfroud]

Oui on est d’accord

[@zebelge2000]

​@@jpfroud Oui, cette partie là m'a également fait réagir :-) Je suis aligné avec vos visions, et je vais apporter la mienne: je pense qu'il faut aussi prendre en compte la maturité de l'équipe dans la mise en place de Scrum (Shu Ha Ri...) : au tout départ (Shu), il me semble important de marquer l'importance du time boxing. L'idée, lors de cette phase, n'est évidement pas de clore la discussion totalement mais de signaler le dépassement et de proposer, si c'est pertinent, 1) de finir le daily d'abord , et 2) de lancer ce sujet immédiatement à la suite (en général, dans la même réunion) avec la possibilité pour chacun d'y participer ou pas. Par la suite (dans la phase Ri) l'équipe sera normalement capable de s'approprier le daily et de le gérer de la façon dont ils le souhaitent en connaissance de causes (et de conséquences :) ). Avec le travail à distance généralisé, j'ai noté l'émergence d'un autre besoin dans le daily: il n'y a plus beaucoup de moments d'échanges techniques (souvent jugés "peu importants", mais "juste un petit truc, tu ferais comment, toi, pour...") entre les membres de l'équipe et ils profitent souvent de ce point régulier pour ces échanges pour lesquels ils n'estiment pas utile de déranger via un appel ou un message instantané. Donc le "post daily" est souvent consacré à ces échanges, et donc le créneau du "daily" est rallongé, mais pas forcément la partie "daily" en elle-même...