Відео

J'ai utilisé plein de fois le CFD, sur beaucoup de missions. Depuis, je le trouve... Bien peu utile. Surtout, à part les agilistes et limite les statisticiens, ce n'est pas compréhensible facilement... Et il est difficile d'avoir de la data simple pour l'utiliser. Bref, parfois ça me prend trop de temps pour très peu de bénéfices. Un peu comme dans Lean from the Trenches, j'ai la même conclusion : avoir les cycle time, le WIP à l'instant T et l'âge c'est bien plus intéressant que le CFD ! Et surtout pour moi il ne montre pas la mesure la plus intéressante de Kanban : l'âge !

il est tres interessant pour illustrer la loi de little et l 'importance de limiter le travail en cours. On peut facilement voir, que plus il y a de quantité de travail moyenne en cours (traits verticaux), plus le cycle time moyen aura tendance à s'allonger (trait horizontal)...d'ou l'importance des WIP limit/limitation du travail en cours.

Je ne connaissais pas, mais j'avais bon. Ouf !! 😜 J'espère avoir bon aussi la semaine prochaine 😉 En tout cas #ScrumLife, merci pour cette série de l'été 👍🙏

Et toi ?! Tu as trouvé directement les bonnes réponses ? Est-ce que tu utilises au quotidien le diagramme de flux cumulé ou CFD dans tes équipes ?

Ça c’est du vrai coaching 🙌🏽🙌🏽 J’espère que scrum life prend des notes .. #PDCA #Emprism dans le coaching #Kata

J'ai une question. J'ai pas compris ce qu'il faut faire dans le cas où une personne indispensable prend vacance et que ses compétences et que personnes dans l'équipe ne sais faire alors comment faire ?

Je ne suis plus RTE depuis 2020 donc je n'est pas suivi les évolutions mais je suis étonné de ce que j'entends parce que pour moi dès le départ c'est la seule utilité d'afficher les dépendances c'est de chercher à les faire disparaître

Génial de voir de nouvelles têtes

Le cœur du Lean c'est de mettre ses collaborateurs dans les meilleures conditions pour être performants

Hum, ça partait bien ! On site les dépendances entre équipes Métier, UX/UI, dev... Et puis on donne des réponses très orientées pour les dépendances entre équipes techniques : inner source et ambassadeur. Dommage ! Ca ne permet même pas de résoudre le problème n°1 de dépendance entre équipe tech que j'ai vu partout : la dépendance de l'équipe front-end sur l'équipe backend.. Ou alors j'ai loupé un truc ?

J'espère que je ne vais pas me faire déchirer pour mon opinion >.> mais la voilà : Je commence par l'exemple : Si je reprends l'exemple du niveau du diplôme bac+5 : Au lieu de demander les gens de faire attention à ça, (peut-être ils en sont fières aussi et ils ont besoin de le partager? peut-être ça serait inspirant pour d'autres?), pourquoi ne pas accompagner les gens qui ne se sentent pas bien avec ce sujet, pour qu'ils trouvent leur valeur au delà d'un diplôme ou une certification quelconque ; pour qu'ils trouvent le moyen aussi de valoriser leurs expériences et capacités ? Je suis convaincue que le plus puissant qu'on peut faire, c'est accompagner les personnes avec ces difficultés pour qu'elles mêmes soient en confiance et bien avec qui et comment elles sont. Les accompagner pour comprendre leurs droits, à assumer et assurer leur légitimité malgré les biais et les discriminations qu'elles ont vécues/en train de subir. A mon sens, c'est cette confiance qui cassera les biais et qui fera preuve qu'ils ne sont pas la vérité. Je suis une femme, étrangère et dans le secteur informatique. Je sais que je suis en minorité, je sais qu'il y a des stéréotypes, des préjugés, d'inconsidération parfois, etc... Et c'est dommage, mais je trouve qu'en mettant l'accent sur mes différences, on me victimise, et en voulant faire bien, on incarne encore plus les biais mais différemment : les gens ont encore plus de confusion et de préjugés de ce qu'on peut ou ne peut pas dire. En conséquence, même les personnes qui sont bienveillantes, et pas du tout racistes/sexistes/etc...., elles doivent avoir cette pression de faire gaffe à ce qu'elles disent et comment et qu'est-ce que ça pourrait signifier, et du coup elles sont encore moins à l'aise autour de nous. Ou bien, le contraire, j'ai vu du concrètement on s'en fou, mais on a des bons indicateurs RSE, tout ça tout ça, et là je me sens juste valorisée pour les cases que je coche, ce qui est très dévalorisant ...

Super vidéo, je l'ai regardé 2 fois, la 1ère à sa sortie et la deuxième aujourd'hui, car à la dernière rétro, l'équipe a demandé à faire une pause, le sprint les a épuisé car le travail ne s'est pas déroulé comme ils l'avaient supposé au départ, et donc ils ont tout donné jusqu'à la dernière minute de peur de ne rien avoir à montrer à la sprint review. Par ailleurs, nous sommes dans le domaine médical, beaucoup de contraintes réglementaires qui nécessitent beaucoup de documentation de la part de l'équipe, et donc à la rétro une partie de l'équipe a demandé une pause inter-sprint pour faire la documentation et les tests, et là je leur ai expliqué qu'on ne devait pas charger nos sprints à 100%, qu' fallait de toute manière laisser 25% à 30% du sprint déjà pour les imprévus, autre chose, et que le sprint planning est leur moment et qu'ils sont maîtres de "charger" le sprint de manière à ce que ce soit atteignable et que ça rejoigne la DoD, qui contient au passage la doc. On m'a répondu que cela risquerait de compromettre la road map qui est ambitieuse, je leur expliqué que la roadmap est basée sur des objectifs, et que le scompe lui est négociable, et qu'en tant que PO j'assume cette négociation. Donc, je suis d'accord avec Constantin de ne pas charger le sprint et que tout est question d'organisation, pour ne pas se griller. Bien sûr, cela est plus facile à dire qu'à faire, mais à essayer 🙂

Le problème de la FRANCE , c'est que même qualifié SCRUM , les employeurs ignorent cette formation ou font mine de l'ignorer. Leur réponse est : vous serez payé ... au SMIG ... Par contre , nous à SINGAPORE , c'est quasi obligatoire de l'avoir afin de devenir cadre. Nuance !

Est-ce que tu as déjà essayé ce genre d’approche ? Qu’est-ce que ça a donné ? Partage-nous tes conseils et retours d’expérience !

Donc c’est une méthode adaptée aux phases d’exploration et idéation et non pas au build classique où on connait déjà son Produit et sa roadmap. C’est cela ?

C'est trop cool de voir Maïlis sur Scrum Life 🤩C'est clair, c'est engageant, c'est pragmatique. Merci beaucoup Maïlis pour ton engagement au quotidien 💜 Et merci @ScrumLife de l'avoir invitée 🙌🙌

Merci Maïlis 😉

Pour être plus sérieux, c'est en effet un sujet très important. Merci pour ces explications et cette prise de conscience Scrum Life et Maïlis !

Maïlis! Maïlis! une autre video!

Super vidéo ! C’est vrai que tous ces petits biais nuisent forcément à la cohésion de l’équipe et qu’il est difficile de tordre le cou aux mauvaises habitudes. Je vous remercie par avance pour la prochaine vidéo ! 😉

Qu'est ce que ca fait plaisir de voir Maïlis dans cette vidéo !!!

Je vais dire en préambule : Merci beaucoup pour la vidéo. Elle fait du bien, d'autant plus vu le climat actuel... Personnellement, j'atténuerais un peu le côté "petit pas" parce que le cadre est aussi important que l'amélioration continue (kaikaku/kaizen) et l'un ne va pas sans l'autre, au moins pour donner un horizon (je lâche un gros mot mais il est important) politique. Ceci étant dit, et je ne vous jette pas la pierre, mais ça me gonfle qu'on mette toujours le mot "performance" en avant dans ce genre de discussion. Rationaliser, dans le cadre capitaliste, des relations humaines en faisant de la capacité de production une valeur cardinale, c'est un peu marcher sur la tête. En gros, "soyons inclusif·ve·s parce qu'on produira mieux" est devenu, dans le discours commun, aussi et voir même plus important que "soyons inclusif·ve·s parce qu'on vaux mieux que des crétin·es sexistes, racistes et validistes".

Intervention très intéressante. Un grand merci pour nous avoir éclairé sur ces sujets de diversité et d'inclusion. Nous sommes tous biaisés (saleté de cerveau ! ) et en avoir conscience est déjà un bon départ sur le chemin de l'amélioration :) J'espère avoir le plaisir de profiter d'autres vidéos sur le sujet :)

Merci Maïlis pour cette vidéo, ça fait plaisir de te voir dans Scrum Life 😊 Idée de sujet de vidéo : inclure les profils neuroatypiques...

Je suis sensibilisé au sujet dans ma vie familiale mais avoir une piqûre de rappel dans le monde pro, ça fait beaucoup réfléchir. Merci pour la vidéo et +1 pour une autre.

👏👏👏

Superbe intervention, merci Maïlis ! Hâte d'en voir davantage :)

Merci pour le partage. Maïlis, une autre vidéo ! :)

J'avais vu "le lit" dans la vignette au lieu de "l'IT" 😂🤣

Je vais devoir arrêter d’écouter ScrumLife pendant un temps… pour diversifier mes sources ! 😂

Réponds à Maïlis : comment fais-tu ta veille ? Et quel est son niveau de diversité ?

Comment gères-tu tes parties prenantes ? Dis-nous en commentaire !

Je suis de la team Constantin !! Mais effectivement ça peut être une approche de conduite de changement pour aider à comprendre qu'on peut faire mieux ! En tout cas l'expérimentation / innovation doit pouvoir se faire dans le sprint pour ma part ;) Merci pour la vidéo

L'agilité se repose sur l'humilité des collaborateurs. Avouer qu'on ne sait pas n'est pas facile quand on est un décideur. Oser dire "Essayons, l'avenir nous le dira", "apprenons".. C'est très difficile quand on est dans un système, où on doit justifier ses choix avant d'avoir obtenu les résultats. C'est difficile de mettre en place un système qui s'adapte et avance dans l'inconnu. C'est plus facile de prévoir, et de fataliser (chercher un coupable) face à l'imprévu. L'agile c'est mettre de l'huile dans la machine à pivoter.

Il faut leur parler de choses qu'ils connaissent mais j'ai quand même découvert un élément bloquant dans la discussion avec "le haut" de l'organisation. Sans chercher à utiliser le terme avec eux, l'acceptation du monde VUCA est importante (voire indispensable ?) .... Et ca n'est pas si évident que cela. Avant d'essayer de proposer l'agilité, il faut le besoin. A quoi ca sert d'être Agile alors que pendant des décennies, on a fonctionné sans ?

I recommend building relationships even before starting to find the problem. Without building your social capital and trust with the team members and stakeholders, you will find it very difficult to find the REAL problem or the challenge. You need to learn and understand how people interact and work together. You need to know the goal in order to know the problem. The real problem is a limitation to reach the goal. I would go even deeper and understand the self-interest of people and not only their problems and create the solutions that when they ask "What's in it for me?" they find something valuable for them. Those are good insights, but it could be even better.

L'agilité, l'art de s'adapter... Aux autres

Penses-tu que nos conseils vont t'aider ? Quels autres conseils aurais-tu à partager ? On te rappelle le lien de la vidéo spécifiquement à destination des directeurs et manager : scrumlife.tv/exec

ça me rappelle cette vidéo: ua-cam.com/video/--pXFDxT-j0/v-deo.html ;-)

Très bonne question ( et vidéo). De mon côté, on utilise SAFe depuis presque 7 ans et plus on avance dans le temps et moins le sprint IP est un sprint de "pause", mais plutôt un sprint classique ( avec une partie refinement plus importante ~ 30 % de notre temps). La partie formation et innovation se fait dans nos sprints classiques, elle est planifiée et priorisée par le PO et les PM au besoin. Pour moi, le sprint de "pause" faisait perdre aux équipes le focus, ce qui est beaucoup moins le cas quand on intègre l'innovation dans les sprints classiques. De plus, il y a moins de frustration car on peut aller au bout de notre idée sans devoir attendre le prochain sprint IP pour reprendre le projet, la formation ou autre. Si l'équipe souhaite une "pause" ou un temps de veille techno dans ses sprints, elle peut très bien en discuter en retro et adapter leur planification en fonction ( on a de la chance d'avoir un management qui nous fait entièrement confiance ). Je serai du coup plutôt de l'avis de Constantin, de charger moins les sprints pour garder un rythme soutenable et avoir du temps pour faire le de veille techno ou de l'innovation.

Alors c’est un super questionnement. J’ai changé de contexte et je gère notamment des équipes qui fonctionnent avec 1 journée « pause » entre 2 sprints. J’avoue que cela m’a perturbé comme le mentionne Constantin, d’avoir ce trou entre 2 sprints. Pour les équipes c’est à priori un temps nécessaire (auto formation, poc, tests de techno). Dans les expériences précédentes je le matérialisais avec les équipes dans des sujets du backlog. La je suis tenté d’intégrer cette journée dans le sprint un peu comme le sprint I&P de SAFe… mais avant je vais aller sonder mon équipe lors d’une rétro entre autre sur cette journée et voir réellement comment ils la vivent, l’utilisent officiellement et… officieusement 😁

tellement une bonne idée une solution "no framework" , tellement inefficient de faire du scrum ou du safe imposé alors que ça ***** tlm

Vous êtes géniaux ❤ J’ai testé l’exercice cette semaine, résultat: une révélation 🤩🥳

Salut Scrum Life Je reconnais tout à fait notre projet quand vous évoquez les équipes qui cherchent à remplir les sprints : toutes les équipes du projet font comme ça. J'en suis conscient, mais le problème c'est que je ne vois pas comment faire autrement. Comment réunir toute l'équipe autour d'un même objectif? Si l'objectif est la livraison d'une feature en prod, alors les devs ne pourront pas tous démarrer en même temps, car les tâches ne sont pas toute parallélisables. Il faut d'abord un développeur sur la conception, puis disons 2 sur les devs (quand on a la chance d'avoir des développements parallélisables, c'est pas toujours le cas), puis un sur le déploiement et tests en environnement de qualif, et pour finirun sur la MEP. Vu comme ça, on voit mal comment s'en sortir avec une équipe qui est focus sur un seul objectif. Donc au lieu de ça, on prend plutôt plusieurs features en //, et au cours d'un sprint, certains développeurs seront sur la conception de la feature A, d'autres sur le dev de la feature B, etc. Le PO choisit de 1 à 3 objectifs, correspondant aux différentes features travaillées dans le sprint. Alors, question pour vous: comment vous feriez à ma place pour avoir toute l'équipe focus sur un même objectif?

Totalement d'accord ❤️

La question se pose des pauses entre les sprints quand les équipes ne sont pas 100% dédié. Dans mon entreprise ou le cycle en V règne en maître, les équipes sont partagées entre différents projets. Du coup quand j'ai mis en place un équipe (sur un projet) en mode agile, entre 2 sprints, on fait une pause pour pouvoir réaliser les cérémonies (refinement, sprint planning, rétro et review).