Bienvenue sur LA série qui raconte avec humour et toujours dans le concret tout ce qui touche à Scrum et à l'Agilité. No bullshit garanti !
🚀 Accède sans attendre à notre formation gratuite : scrumlife.tv/formationgratuite 🎓 Va plus loin avec notre formation "Deviens meilleur(e) Leader Agile" ➡️ scrumlife.tv/leaderagile
Tu veux soutenir la chaîne ? Porte nos couleurs ! Voici la boutique : scrumlife.tv/shop
À très bientôt ! N'hésite pas à échanger, commenter, suggérer ou poser des questions ! Tu peux aussi nous contacter sur les réseaux sociaux : ➡️ LinkedIn : www.linkedin.com/school/scrumlife/ ➡️ Twitter : twitter.com/scrumlifetv ➡️ Facebook : facebook.com/scrumlife
Scrum Life est aussi un organisme de formation, pour en savoir plus : ➡️ scrumlife.tv
La loi de Little sert, par l'analyse du flux au travers des 5 conditions d'application de cette loi orientée débit, à trouver ce qui rend instable le processus. (Tx entrée/ sortie different, âge du wip non constant, wip qui fluctue, éléments qui entrent mais ne sortent pas du processus). L'équation n'est vrai que quand toutes les conditions sont remplies. Ce qui est très rarement le cas dans le contexte de management de produit, où la variabilité est très présente. Attention également, c'est une relation de moyenne. Une limite de wip ne doit pas être une moyenne mais un optimum que l'équipe doit chercher à maintenir constamment. Fixer des limites d'encours sur la base de calculs théoriques, risque de ne pas correspondre à la capacité de travail réelle ou à la dynamique de collaboration de l'équipe. Établir des limites optimales de wip passe par un processus empirique et d'amélioration continue. La loi de Little éclaire sur le fait qu'une diminution ou augmentation du wip aura un effet sur le débit et/ou le temps de cycle mais ne permet pas de prédire qu'elle sera cet effet. Bref, à mon sens il n'y a aucune réponse bonne dans ce qui est proposé. Une bonne réponse serait : "Elle aide l'équipe produit ou Scrum à comprendre la relation entre les 3 paramètres et à stabiliser son processus"
Merci pour cette précision, effectivement ici on se concentre vraiment sur la certif et de leur façon de poser les questions et les réponses possible. Dés la rentrée, on rentrera plus en profondeur sur Kanban !!! Voici le message qu'on rajoute sous les vidéos : ⚠ Dans cette série, nous n'entrons pas trop sur le fond, le but étant vraiment de s'entraîner à passer les certifications, nous allons rapidement au but en te montrant comment, en quelques secondes, tu peux réfléchir et trouver la meilleure réponse à la question. Dans ce type de certification, "meilleure réponse" ne voulant pas forcément dire la réponse parfaite, précise et exacte, mais plutôt celle que l'organisme derrière la certification attends. Abonne-toi à la chaine car par contre, nous allons approfondir Kanban dès la fin de l'été ! -- Constantin
⚠ Dans cette série, nous n'entrons pas trop sur le fond, le but étant vraiment de s'entraîner à passer les certifications, nous allons rapidement au but en te montrant comment, en quelques secondes, tu peux réfléchir et trouver la meilleure réponse à la question. Dans ce type de certification, "meilleure réponse" ne voulant pas forcément dire la réponse parfaite, précise et exacte, mais plutôt celle que l'organisme derrière la certification attends. Abonne-toi à la chaine car par contre, nous allons approfondir Kanban dès la fin de l'été ! Alors ? Tu connaissais la loi de Little ? Dis-nous en commentaire si tu es d'accord ou si tu as une autre opinion ! 👇
Super ! J'aimerais beaucoup une vidéo sur le fameux "scrumban" pour une équipe support qui traite beaucoup de sujets de run au fil de l'eau par exemple :-) je trouve que c'est plutôt bien adapté mais j'aimerais beaucoup vos avis ! Merci ❤
J'ai vécu cela complétement chez Engie Solutions ! Grande manque de transparence et de confiance, plus de manipulation, les rituels complétement ridicules, par exemple le daily en mode reportage pour se flicer et se justifier entre équipe... et ils se croient Agile !
Merci pour cette vidéo très instructive ! Cependant, j'aurais besoin de plus de précisions sur la manière d'identifier les goulots d'étranglement sur le diagramme et comment les interpréter efficacement. Pourriez-vous, s'il vous plaît, détailler davantage cette partie ? Merci beaucoup pour votre aide !
"Un goulet d'étranglement est l'endroit où la quantite d'éléments prêt à être tirés est supérieure à la capacité de tirage. Une contrainte est le goulet d'étranglement ayant la capacité la plus faible dans l'ensemble du système." Voir sur un CFD qu'une ligne s'épaissit, ne signifie pas forcément qu'on est sur un cas de goulot d'étranglement. Le CFD seul ne suffit pas à le dire. En Kanban, on devrait être en flux tiré avec des règles explicites de contrôle de WIP. Cependant, l'épaississement dans un CFD peut signifier que l'équipe ou certains membres tirent plus qu'il ne faudrait (potentiellement ils ne respectent pas les règles du contrôle d'encours). Il n'y a pas plus d'éléments que ce qu'il est possible de tirer dans l'étape suivante, il y a juste un mauvais contrôle de l'encours, une mauvaise collaboration dans l'équipe. Le WIP augmente a cet endroit mais les éléments ne respectent pas les conditions de tirage pour avancer donc ils ne peuvent etre tirés. C'est malheureusement choses très courantes... et ce que je vois avec cette mauvaise compréhension ce sont des managers qui vont s'empresser d'ajouter des compétences sur ce point, a priori d'étranglement alors qu'il n'y a pas vraiment besoin. Ceci faisant ils sous optimisent davantage le flux et ils accentuent du silotage dans l'équipe. Une meilleure approche est d'arriver à éduquer les personnes qui ne respectent pas la DoW, afin qu'au lieu de tirer de nouveaux éléments ils aident à faire traverser un élément dans le flux, qu'ils collaborent en équipe pour mieux contrôler leur encours.
J'ai l'habitude de dire que l'utilisation de Scrum ne va pas de soi, par contre kanban est valable tout le temps. Et kanban avec Scrum augmente clairement scrum, par exemple, l'âge des items en cours pour les daily c'est clairement une augmentation de la qualité du daily, à tous les coups
L'IA c'est juste un outils qui va faire des recherches google à ta place. Si tu es remplacé par un outil aussi bidon c'est que tu n'as pas une grande valeur.
⚠ Dans cette série, nous n'entrons pas trop sur le fond, le but étant vraiment de s'entraîner à passer les certifications, nous allons rapidement au but en te montrant comment, en quelques secondes, tu peux réfléchir et trouver la meilleure réponse à la question. Dans ce type de certification, "meilleure réponse" ne voulant pas forcément dire la réponse parfaite, précise et exacte, mais plutôt celle que l'organisme derrière la certification attends. Abonne-toi à la chaine car par contre, nous allons approfondir Kanban dès la fin de l'été ! Alors ? Que penses-tu des réponses ? Dis-nous en commentaire si tu es d'accord ou si tu as une autre opinion !
Merci Sylvain ! Je suis ravi que les conseils de Maarten t'aient été utiles.Si tu as des questions ou des sujets que tu aimerais qu'on aborde, n'hésite pas à les partager ! 🚀 Robin
⚠ Dans cette série, nous n'entrons pas trop sur le fond, le but étant vraiment de s'entraîner à passer les certifications, nous allons rapidement au but en te montrant comment, en quelques secondes, tu peux réfléchir et trouver la meilleure réponse à la question. Dans ce type de certification, "meilleure réponse" ne voulant pas forcément dire la réponse parfaite, précise et exacte, mais plutôt celle que l'organisme derrière la certification attends. Abonne-toi à la chaine car par contre, nous allons approfondir Kanban dès la fin de l'été ! Que penses-tu des réponses ? Dis-nous en commentaire si tu es d'accord ou si tu as une autre opinion ! 👇
J'ai tellement l'impression de vivre la même chose en ce moment et cette impression d'être nul ça me rassure de voir qu'avec ton expérience tu as vécu la même chose. j'ai également un projet dont j'ai créé l'architecture qui n'est peut être au final pas le mieux et une deadline qui approche avec des énormes journées sans vraiment avancer le problème est : comment faire quand la deadline approche, que tu doit avancer tout en sachant que ce que tu fais n'est pas le mieux mais qu'il faille se former au TDD ou autres design pattern ? Egalement, comment appliquer ce type de logique sur du graphisme, ce qui me prend le plus de temps à chaque fois c'est la logique graphique comme si je sélectionne tel item de ma combobox alors ce bouton est enabled mais sauf si c'est tel item et une case a cocher etc... ? Merci pour ce retour personnel
Salut @son1powa ! Je comprends parfaitement ta situation, c'est vraiment frustrant de se sentir coincé entre les enjeux business et la nécessité d'apprendre de nouvelles techniques. D'abord, respire un grand coup et rappelle-toi que tu n'es pas seul, beaucoup passent par là. Quelques idées : Tu peux envisager de décomposer ton apprentissage en petites sessions quotidiennes, même 15 minutes par jour sur le TDD ou les design patterns peuvent faire une grande différence sur le long terme. Courage, et n'oublie pas, chaque petit progrès est une victoire ! 💪 Si tu as d'autres questions, je suis là pour t'aider. 🚀 Merci pour ton retour et à bientôt ! Robin
En ce qui concerne la dette technique, il y a 2 risques à gérer et à mettre dans la balance face à la valeur et au ROI du produit quand on est PO et qu'on veut prioriser : le risque élevé de bug/anomalie/dysfonctionnement comme vous l'avez mentionné et aussi l'AUGMENTATION DU TEMPS DE CYCLE et du TEMPS DE TRAVERSEE (vrai en particulier sur un projet légacy, pas sur un green field, les 6 premiers mois). Parce que plus la dette technique augmente, plus le code spagetti, impossible à déméler et mal conçu, grossi et se répend à toute la codebase, et plus il faudra du temps pour le faire évoluer, le corriger et tout simplement le comprendre pour gérer ses dépendances et intégrer y d'autres (nouvelles) parties de code. Ce n'est qu'une question de coût : est-ce que ça coute moins cher de le laisser en l'état même si chaque développement plus ou moins lié prend beaucoup plus de temps et ralenti tout le monde, ou bien est-ce que le moins cher c'est de donner un coup de pied dans la fourmilière et de le refaire/refactorer ? Et c'est à l'équipe (autonome et responsable !^^) d'évaluer chacune des solutions de prendre cette décision comme vous dites pour le mieux dans un climat de confiance .... parce que plus le temps passe et plus le temps de cycle augmente (c'est exponnentiel, le temps double au bout d'une année !). Plus on le refait tôt, moins c'est cher et moins le coût pèse sur les prochaines itérations. Voila comment un PO digne de ce nom doit le gérer .... et le défendre pour son équipe.
Salut @fbuiphuong61 ! Tu as parfaitement résumé le dilemme auquel sont confrontés les Product Owners lorsqu'ils doivent jongler avec la dette technique. D'ailleurs as-tu vu notre vidéo sur le cout du délai ? Si "non", je pense qu'elle te plaira et que tu te reconnaitras dedans ! L'importance d'une équipe autonome et responsable ne peut être sous-estimée. Comme tu le dis, il faut évaluer les coûts à court et long terme et décider si un refactoring est la meilleure solution. La transparence et la confiance au sein de l'équipe sont essentielles pour prendre ces décisions critiques. Merci pour ton analyse approfondie, c'est exactement ce genre de réflexion qui permet de mieux comprendre les enjeux d'un bon Product Owner. À bientôt et n'hésite pas à partager d'autres réflexions ou questions ! 🚀 Robin
J'aime beaucoup vos vidéos, je suis globalement d'accord avec la majorité de ce que vous dites. Sauf que dans la définition de l'agilité comme dans tout le reste de la vidéo, vous ne mentionnez jamais la terminologie "AMELIORATION CONTINUE" ... alors que c'est quand même le vrai objectif final de l'agilité ! Pourquoi on itère en récupérant du feed back à chaque fois, c'est pour s'améliorer de façon empirique : on améliore ainsi les process de chaques équipes, le dev, la code base, les compétences, on trouve une solution à la majorité des problématiques, les comportements s'améliorent aussi ... et le graal vers lequel on converge tous ... on améliore le produit pour optimiser sa valeur pour les utilisateurs et son ROI pour l'entreprise ! C'est quand même dingue d'expliquer un concept sans jamais le nommer littéralement !^^
Merci pour ce commentaire. Pour être pointilleux, je ne pense pas que l’objectif final de l’agilité soit l’amélioration continue. L’objectif est de faire le bon produit. L’amélioration continue reste indispensable, mais c’est un outil, pas une fin en soi. Qu’en dis-tu ? - Constantin
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 !
J'ai envie de nuancer ton avis dans lequel je me retrouve assez... On a ce qu'on regroupe généralement sous le terme des "flow metrics" : lead time/cycle time, débit (throughput), WIP et l'âge/WIA (Work Item Age). Pour bien utiliser ces 4 métriques il est essentiel d'être conscient que les 2 premières sont des _lagging indicators_, des indicateurs tardifs, alors que les 2 dernières sont des _leading indicators_, des indicateurs précoces. Cela veut dire que cycle time et débit sont très intéressants pour faire du pilotage à plus haut niveau (juger de la performance du système, planification de release, amélioration continue type rétrospective...) alors que le WIP et le WIA sont ce que l'équipe va utiliser au quotidien pour lever les problèmes et ajuster dynamiquement sa manière de travailler et ainsi influencer le lead time/cycle time/débit avant de constater, après coup, qu'ils sont mauvais. Donc clairement, oui, au quotidien, le CFD n'est pas utile ! Sa vocation est plus dans une logique d'introspection et de projection, mais ce n'est pas ce que l'on va regarder en Daily par exemple. Un bon board affiche clairement le nombre d'éléments en cours (WIP) ainsi que le temps passés par les éléments dans le système (WIA) ! Est-ce que cela correspond à ton expérience ? -- JP
@@ScrumLife Je suis en phase sur les leading et lagging, tout à fait ! Le seul truc, c'est la complexité de construire un bon CFD (la data) et de le lire (la compréhension). C'est du boulot, c'est surtout ça mon point... Et de toute façon si tu gères ton âge et ton WIP tu améliores ton cycle time et ton débit forcément, même si ça peut être de la data pour faire bouger le leadership, je suis d'accord ! ;)
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.
Totalement ! Et quelque chose me dit que la loi de Little sera évoqué dans le cadre de cette série de l'été 😉 Est-ce que tu arrives facilement à convaincre des équipes et leur parties prenantes de l'importance de limiter le travail en cours ? On constate continuellement que cela reste contre-intuitif... 😣 -- JP
Limiter le travail en cours est contre intuitif puisqu'à côté de cela l'entreprise sera certainement à demander à produire plus. Les personnes pensent donc naturellement qu'ajouter plus de choses en cours permettra de répondre positivement à l'attente des boss de l'entreprise. Pour éviter cela, je préfère parler de contrôle de l'encours et ne pas amener l'équipe (sauf si elle le souhaite bien évidemment) à poser une ou des limites de WIP. Contrôler l'encours se passera notamment autour de l'âge des éléments. En évitant que les éléments vieillissent au delà d'un âge convenu en équipe et qui fait sens pour les parties prenantes, l'équipe limitera plus naturellement son encours. Les limites de wip pourront venir ensuite pour optimiser encore davantage le flux.
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é 👍🙏
@@ScrumLife Le truc avec les metrics (quelles qu'elles soient), (peut-être à approfondir dans une prochaine vidéo) c'est toujours : - A quoi ça sert ? - Lesquelles on met en place ? Autrement dit, pourquoi celle-ci plutôt qu'une autre ? - Qui va les utiliser ? Généralement c'est le scrum master, encore que ... - Qui les alimente (en données) ? - Quelles données, justement, alimentent telle ou telle metric ? - Quand/pourquoi on met en place telle ou telle metric ? - Pour quelle durée ? Est-ce que c'est en permanence ou est-ce que c'est ponctuel (le temps d'identifier un/des problème(s) et de le(s) résoudre) ? (Dernière question, et non des moindre) Peut-on s'en passer ? J'en doute fortement car ça permet souvent de mettre en exergue un/des problème(s) sous un angle différent et quelle équipe n'a pas (eu) de problème ?! Ici, cette vidéo répond à un certain nombre de ces questions, donc oui, ça allait, merci @ScrumLife JP 🙏😉
⚠ Dans cette série, nous n'entrons pas trop sur le fond, le but étant vraiment de s'entraîner à passer les certifications, nous allons rapidement au but en te montrant comment, en quelques secondes, tu peux réfléchir et trouver la meilleure réponse à la question. Dans ce type de certification, "meilleure réponse" ne voulant pas forcément dire la réponse parfaite, précise et exacte, mais plutôt celle que l'organisme derrière la certification attends. Abonne-toi à la chaine car par contre, nous allons approfondir Kanban dès la fin 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 ?
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 ?
Salut ! Ce qu'il faut faire c'est de préparer les vacances en faisant monter en compétences, dès que possible, le reste de l'équipe pour qu'elle soit capable de se débrouiller sans cette personne. J'imagine que cela semble difficile à faire dans ton contexte ! Avez-vous déjà essayé ? -- JP
29 дней назад
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
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 ?
29 дней назад
Pour moi, c'est effectivement "un exemple", mais tous les types de dépendances sont concernés. IMHO Il ne faut jamais oublier que les dépendances font partie du "prix à payer" pour l'impatience d'une organisation qui n'arrive pas à accepter la vélocité d'une équipe autonome et auto-organisée. Il n'y a pas que les dépendances, il y a aussi le cout de la surcouche d'organisation, de synchronisation, d'alignement, .... Dans l'exemple présenté, ça parle de la dépendance entre équipe. Mais dans la solution "ambassadeur" ( 6:02 ) on ne parle pas de dépendance entre "équipes" qui livrent, mais entre une équipe qui livre et une personne (ou un groupe) de soutien. Ca c'est pour une organisation qui cherche à "rationaliser" une (ou des compétences spécifiques). Dans le mécanisme décrit par Constantin, j'aime souligner la notion de responsabilité pour alimenter la discussion : l'équipe est responsable du livrable, des choix technologiques et méthodologiques, de sa qualité, de son respect de la DOD, .... Tout le reste n'est que "partage de connaissance" et contraintes. Un externe/ambassadeur/soutient/consultant ne travaille pas pour cette responsabilité, il prémâche le travail, il guide, il sous-traite…, tout ce qu'on veut, mais il n'a aucune responsabilité sur ce qui est livré. Le gaspillage vient de la gourmandise.
29 дней назад
à réécouter la vidéo, l'ambassadeur vient d'une autre équipe. Donc ca induit un autre effet, "le cout de sa disponibilité" : Quand il est ambassadeur, il n'est pas force de travail sur sa propre équipe. Une manière de "cadrer" le temps consacré au partage de compétences, c'est d'avoir des COP régulières. Les cop ont la force de faire monter en compétence plusieurs équipes. Celui qui est "ambassadeur" dans la vidéo, rejoint tous les membres des autres équipes devant monter en compétence sur le sujet. Chacun explique son cas puis "ensemble" et sous le feedback de l'ambassadeur (l'exprert, le partageur de connaissance, ...) la cop réponds à chacun des besoins/problématiques présentés. Cette manière est une forme de rationalisation de la formule ambassadeur, et donc, a aussi ses défauts. L'idéal se trouve sans doute avec un dosage des différentes formules. Il est aussi possible de planifier des moments de "pair programmming" entre un membre de l'équipe et l'expérimenté externe Mais attention...planifier => avant le Sprint planning pour qu'il puisse se faire en connaissance de la bande passante restante. Mais dans tous les cas .... Seule l'équipe a la responsabilité de ce qui est livré.
29 дней назад
"Tout le reste n'est que "partage de connaissance" et contraintes." J'ai envie de revenir sur le terme "contrainte" En effet, la "contrainte", est une règle qui restreint la possibilité d'autonomie d'une équipe en vue d'un intérêt commun de l'organisation. C'est à utiliser judicieusement. Le travail de l'organisation est d'avoir le moins de contraintes possible pour garantir un maximum d'autonomie et reduire le risque de contraintes contradictoire. EXEMPLE : "Tous les développements doivent se faire obligatoirement en COBOL, et le code doit être en espagnol" Parfois, on a des règles comme ça qui tombent, on ne sait pas d'où. Parfois, elles ont du sens pour tous, parfois juste au niveau transversal et incompris, ou mal vécu au niveau local, ... Ce sont aussi des "dépendances". On est plus dans la dépendance entre composants/sous étape de livraison. Mais une dépendance à des "décisions"
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 🙂
L'argument de la roadmap à tenir semble fallacieux ! S'il faut faire une pause pour vraiment terminer les choses hors sprint, d'un point de vue calendaire cela revient exactement au même que d'intégrer ce temps dans le sprint. Et bien sûr, tenir la roadmap en se cramant, ce n'est pas vraiment tenir la roadmap ! Belle posture que tu as pris, bravo 👏 Merci infiniment pour ce partage 🙏 -- JP
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 !
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 🙌🙌
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 ! 😉
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".
Merci Sam pour ton commentaire. Bien que je sois d'accord avec toi, il ne faut pas se voiler la face, quand dans une entreprise les 3, 5, 7 couches de management ont tous pour objectif la rentabilité, le message à leur passer, à mon avis, est que cette rentabilité peut être atteinte mieux et plus rapidement on diversifiant les équipes, en traitant bien les gens et en leur donnant les moyens de faire leur travail correctement. Peu d'entreprises ont pour but que leurs employé(e)s s'épanouissent. Et celles qui ont ce but, n'ont pas besoin de ce message car c'est déjà dans leur ADN généralement. Sinon, pour parler à ces entreprises qui n'ont pas encore conscience de ça, tu préconises quelle approche pour les intéresser ? -- Constantin
@@ScrumLife Je parlais simplement de ce que cette grille de lecture m'évoquait, je n'invalide pas le fait que ce soit une composante du système pour autant. Ma réponse à ta question est : le problème est beaucoup plus complexe que ça. Tu proposes d'améliorer la qualité de vie de chacun en allant taper à la porte des managers. C'est louable, ça marchera certainement, et c'est surement souhaitable également. Là où mon problème commence, c'est que ça n'offres pas une autre grille de lecture mais simplement un argument de plus au leur : l'inclusivité aide la production, et est donc une composante positive du capitalisme, et valide de fait le système en place, justifiant tous leurs autres choix. Ce que je "dénonce" par là, c'est le côté bien trop apolitique de la communauté qui sous couvert de pragmatisme oublie le côté éminemment politique et sociale du boulot de SM.
Ah je comprends mieux. J'avais eu une discussion avec une personne en mettup un jour : l'agilité est de gauche ou de droite ? Ca rejoint un peu ce que tu décris je pense. Est-ce qu'on le fait pour valider le système, ou pour le changer ? Ai-je bien compris ? -- Constantin
@@ScrumLife Je ne vais pas refaire le match ici, on en a déjà longuement parlé sur le forum. Mais pour répondre à ta question, l'agilité est foncièrement de droite au départ. Ça n'empêche absolument pas une réappropriation, mais c'est un fait.
@@NiokSam J'arrive après la bataille mais : - Oui, effectivement, je module mon discours pour qu'il soit entendable dans des entreprises capitalistes. Donc je parle de soussous et de performance. - Je suis déçue que juste l'éthique ne fasse pas bouger les gens. - J'ai pas eut le temps de dire dans l'interview ou le live que notre implication dans le travail est qu'une toute toute petite partie, elle est nécessaire mais pas suffisante. Et je serai ravie de continuer à en discuter si tu as envie :)
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 :)
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.
