Value Stream Mapping

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/VmR1gZ

[@celinejanssens7817]

Merci ScrumLife pour cet outil. Je vais de ce pas aller creuser l'outil. Ca m'a l'air super puissant

[@ScrumLife]

Super ! N'hésite pas à revenir nous dire ce que ça a donné :)

[@Bouanabile]

merci beaucoup. c'est un peu plus claire dans ma tête . très intéressant

[@ScrumLife]

Super ! Est-ce que tu vas utiliser l'outil ? -- JP

[@thierrycagnin4406]

Vidéo très claire, et c'est une bonne idée d'avoir présenté les icônes et la posture du facilitateur.

[@ScrumLife]

Merci Thierry, as-tu déjà fait cet atelier ? Penses-tu le faire ? -- Const

[@vincentlaffitte800]

👍 OK pour plus de vidéos dans ce style, plus orientées coaching agile que scrum master.

[@VincentJOBARD]

Merci @scrumlife pour cette vidéo (que j’ai raté il y a 3 mois). Super initiation de cet outils. Conseillerais-tu à un nouveau Scrum Master d’une équipe d’en organiser un assez rapidement après son arrivée pour anticiper les futurs points de bloquage ? Cordialement

[@ScrumLife]

Pas forcément, ça me semblerait une attitude trop "oh là là vous bossez n'importe comment, attendez on va faire un atelier pour remettre à plat tout ça". On amènerait l'atelier pour l'une ou l'autre de ces raisons : - soit il y a un problème, on ne connait pas forcément la solution mais on est conscient qu'il y a un problème et on veut le résoudre (on est trop lent, on gagne pas assez d'argent, mauvaise satisfaction client...) - ou alors l'équipe pas à Kanban et l'atelier est un excellent moyen de modéliser le processus actuel

[@VincentJOBARD]

@@ScrumLife Je voyais plus ça comme une occasion d'accélerer l'onboarding. Genre "OK les gars, je viens d'arriver, j'aimerais connaitre le fonctionnement de l'équipe et des process d'entreprise, pour rapidement savoir comment vous aider". Commencer à identifier des points de bloquages dans le process d'entreprise et en profiter pour commence aussi à faire connaissance avec les équipes où des points sont bloquants. Généralement c'est ce que je fais, j'essai de comprendre où y'a des points de bloquage en arrivant sur un projet, puis je vais me présenter aux équipes en liens, si possible physiquement pour apprendre à les connaitre, et discuter avec pour comprendre et voir comment on peut trouver une solution assez rapidement qui soit satisfaisante pour tout le monde (J'aime pas la "résolution par mail", trop impersonnelle et peu efficace). Je ne connaissais pas VSM mais comme je déteste les trucs qui bloquent pour rien, ça peut m'aider :)

[@ScrumLife]

@Vincent JOBARD je comprend mieux ce que tu veux dire, et je vois la pertinence de la proposition. Néanmoins utiliser le VSM dans ce cas de figure me semblerait trop abrupt. N'oublions pas qu'un véritable VSM -- pas un bidon comme celui de la vidéo -- prendrait une demie-journée à être défini par tout un ensemble de personnes accompagnés par un coach aguerri. Une énorme dépense d'énergie et de temps. À son arrivée, le Scrum Master préférera sûrement observer plutôt que rendre immédiatement la situation explicite. Qu'en dis-tu ? -- JP

[@VincentJOBARD]

@@ScrumLife ah oui effectivement c'est très lourd.... Donc éventuellement un VSM simplifié comme celui de ta vidéo en atelier d'une demi heure pour prendre un peu le pouls et accentuer l'onboarding, ça peut peut-être le faire

[@vincentjarrossay8667]

Vidéo très simple et intéressante ! Il y a quelques années, on parlait de BPM (Business Process Modeling) pour modéliser des processus métiers et j'ai l'impression que cela est un peu passé de mode au profit d'approches Lean qui se veulent plus modernes. Mais n'y a-t-il pas des racines communes ? Certes l'outil VSM a probablement plus une finalité qui est plus dans l'identification des "gaspillages" mais ne ferait-on pas quand même un peu du neuf avec du vieux ? En tout cas, bravo pour cette vidéo qui est très claire !

[@ScrumLife]

Salut Vincent, oui probablement ! Encore plus à la mode, on parle maintenant beaucoup de "Event Storming" et j'y vois là beaucoup de parallèles avec le VSM, avec un angle un peu différent forcément. Peu importe l'outil utilisé à vrai dire, dès lors qu'il permet de visualiser les problèmes et de réfléchir en groupe. Tu as expérimenté le BPM toi-même ? -- JP

[@rocketeer3708]

Bravo ! C'est clair et précis.

[@yait-jebli4013]

Bravo ! Merci c'est très clair

[@Safpanda]

Woah ! Intéressant cet outil, merci !

[@TheTippex66]

Est-ce que l'on peut dire qu'au final, c'est une combinaison d'un diagramme de GANTT avec un diagramme de séquence/activité, présenté de manière plus visuelle ? On a ici une approche assez théorique (même si elle est tout de même accompagnée de mises en situation), mais peut-être peut-on avoir des retours d'expérience ? de quelqu'un qui l'a mis en pratique et comment cela l'a aidé lui-même ou le client accompagné ? La vidéo reste tout de même très intéressante pour une première approche et donne envie d'aller plus loin !

[@davidpaquet3855]

Moi aussi je suis daccord pour avoir plus de cas concrets. Pour notre part en ce moment nous voulons modeliser un process pour trouver comment le diminuer. Alors si vous voulez je pourrai le partager dans quelques mois. Nempeche quavoir des exemples varies nous aiderait.

[@davidpaquet3855]

Moi jai une question qui peut sembler bete mais peut on faire un process de type flowchart et appliquer les memes procedes de calcul dattente ? A mon sens le vsm permet de voir un process high level et apres le flowchart permettrait de decortiquer davantage. Mais peut etre que le flowchart est trop stricte et ne permet pas detre plus lean ?

[@ScrumLife]

Salut, l'idée est intéressante. Je pense qu'elle fonctionnerait, il faudrait par contre définir la notation pour indiquer les différents temps. Tiens-nous au courant de ce que ça donne si tu essaies ! -- JP

[@fredericdehin402]

A votre avis; Serait-il plus judicieux de commencer par un VSM high level (au niveau produit : idée - livraison) ou partir d'un niveau équipe scrum avec les différentes étapes durant 1 sprint (design, DB, access rights, code, doc, tests, livraison) ?

[@pierre-andregaudard9183]

Attention, dans le lean VSM, le temps de travail est en bas et le temps d'attente est en haut (sur la ligne de temps)

[@ScrumLife]

Merci pour la précision.

[@chaosgandalf]

Bonjour, Est-ce que rajouter des métriques automatiques au traitement rendrait l'atelier plus facile ? type "temps moyen de validation par mail", "temps de présence en attente". Cela permettrait d'avoir une valeur moyenne objective plutot que des retours approximatifs et ressentis des acteurs de l'ateliers (et cela enlèverait une possible volonté d'opacité). Il faudrait juste valider que la mesure faite est suffisante : exemple : si 1 fois sur 2, la validation est téléphonique, la mesure du temps de réponse par mail uniquement n'est pas bonne). Cela enlèverait aussi une charge mentale aux acteurs dans cet atelier qui semble assez intense.

[@darvishali1663]

Je comprends bien la puissance de l'outil mais tel qu'il est décrit, l'adaptation me semble plus simple dans le cadre d'une gestion de projet classique (cycle en V). Il peut y avoir quelques difficultés en le superposant avec la philosophie de Scrum guide

[@julienmontenoise7935]

La philosophie Scrum permet justement d'optimiser une partie du process "classique" tel qu'il est décrit dans la vidéo et c'est effectivement le but recherché! C'est là où les mondes Agile et Lean se rejoignent. Effectivement si l'équipe est très mature en agilité et complètement cross fonctionnelle, il y a fort à parier que le nombre d'étapes sera (très) réduit. Il est néanmoins probable qu'il reste 1 ou plusieurs étapes en amont (sur la partie triage et découverte des idées des clients) et en aval (sur la partie déploiement) de cette équipe. Il peut être intéressant d'identifier ces étapes et se demander s'il existe des solutions pour fluidifier encore plus le process (par ex: discovery par l'équipe, déploiement continu, cf l'article de John Cutler: amplitude.com/blog/journey-to-product-teams-infographic )

[@ScrumLife]

Attention à la parenthèse de fin qui casse l'URL : amplitude.com/blog/journey-to-product-teams-infographic

[@inckhaled]

Brilliant , no question like subscribe Merci

les Scrum life ne sont plus numérotés ?

[@ScrumLife]

Et non ! On a conclu que ça n'apportait pas grand chose. Par contre ça ajoute des contraintes pour ne pas se tromper...

[@joesrs4744]

C'est null , 23 min du blabla Meme les informations faux

[@davidpaquet3855]

N est stupide que la stupidité