Scrum Life - Lean, Agile, Kanban
Scrum Life - Lean, Agile, Kanban
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
Пікірлер
Vous connaissez les "job stories"? J'en entends de plus en plus parler.
Salut @TiffannyDoll! Merci pour ta question super pertinente ! Les "Job Stories" sont effectivement un outil très intéressant dans l’univers agile, surtout en complément des User Stories. Plutôt que de se concentrer sur "qui" et "quoi", les Job Stories focus sur le « job to be done » donc se concentrent à comprendre "pourquoi" une tâche est effectuée, ce qui peut offrir une perspective plus riche pour adapter les solutions aux vrais besoins des utilisateurs. As-tu déjà eu l'occasion de les utiliser dans ton équipe ? Si oui, comment cela s'est passé ? Si non, je te recommande de les essayer, cela pourrait apporter une belle valeur ajoutée à ton processus ! Hâte de te lire 😊 - Robin
@@ScrumLife Bonjour Robin, je ne connaissais pas avant de tomber sur une vidéo de "Mountain Goat Software". Du coup, je vais essayer dès semaine prochaine et voir la réaction des membres de l'équipe. @ suivre donc. Excellent weekend
@@TiffannyDollparlais tu de cet article : www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories ? Bon week-end à toi ! Robin
@@COACHAGILE oui c'est cet article et il y a aussi une vidéo sur la chaîne youtube. @ suivre donc.
Grosse arnaque dss entreprises de la tech qui ne servent à rien, pour faire bosser les devs encore plus.
Salut @angeliris3598 ! Je comprends tout à fait ta frustration. Il est vrai que certaines entreprises de la tech peuvent parfois mal appliquer les principes agiles. C'est là que l'expertise et la compréhension de l'agilité entrent en jeu pour faire en sorte que ces approches soient vraiment bénéfiques pour tout le monde, y compris les développeurs. En réalité, bien appliqué, Scrum et les autres approches agiles améliorent non seulement l'efficacité mais aussi la satisfaction des équipes. L'objectif est d'encourager la collaboration, de promouvoir l'amélioration continue et de livrer de la valeur réelle aux utilisateurs finaux. As-tu déjà travaillé dans une entreprise qui applique bien ces principes ? Partage ton expérience, ça pourrait ouvrir un débat intéressant ! À bientôt, Robin
Je n’est pas étudié la loi Little mais par déduction, je dirais elle permet de déterminer le wip optimal pour équilibrer le débit et le temps de cycle
Salut @Abdelkarim-ou3hw, Tu as tout à fait raison ! La loi de Little est une véritable pépite pour comprendre et optimiser le flux de travail dans un système. On l'utilise souvent en Kanban pour trouver cet équilibre précieux entre le WIP (Work In Progress), le débit et le temps de cycle. Si tu veux approfondir, ça ferait un excellent sujet pour une future vidéo, non ? Alors, dis-moi, voudrais-tu qu'on explore davantage cette loi dans le contexte des approches agiles, ou as-tu d'autres points ou questions spécifiques en tête ? Hâte de te lire ! Robin 🚀
Dans le cas où on voit que des nouvelles priorités peuvent arriver pendant une itération ou que de bugs peuvent subvenir pourquoi ne pas "prévoir l imprévue" sous la forme d une user story ?
Bonjour @mokamo1798 ! C'est une excellente question, et c'est un sujet qui revient souvent ! Quand on parle de "prévoir l’imprévu", il y a différentes écoles de pensée. Certains préconisent, en effet, de laisser un peu de marge dans le sprint pour gérer les urgences et les imprévus. Par exemple, certaines équipes choisissent de ne pas remplir totalement leur capacité de sprint pour pouvoir absorber les imprévus sans compromettre les engagements pris. Par contre, formaliser cette marge sous la forme d'une user story pourrait te poser problème. Une user story, de par sa nature, doit être suffisamment claire, précise et testable. Prévoir l'incertitude sous forme de user story pourrait rendre cette dernière floue et difficile à prioriser et à mesurer. À la place, pourquoi ne pas expérimenter avec une "buffer zone" dédiée aux imprévus ? En réservant un certain pourcentage du sprint pour les bugs et les nouvelles priorités, sans les formaliser, tu gardes une certaine flexibilité. Après, tout dépend de ton équipe et de son contexte. L'important est de garder des lignes de communication ouvertes et d'ajuster les pratiques selon le retour d’expérience. Et toi, comment ton équipe gère ce genre d’imprévus actuellement ? - Robin P.S.: Si tu as d'autres questions ou souhaites partager ton expérience, n'hésite pas à le faire ici ! 😊
@@ScrumLife Super merci beaucoup pour ces précisions ☺
A essayer prochainement ! Merci @ScrumLife
Salut Yoann, Merci beaucoup pour ton commentaire ! 🚀 On est ravis de savoir que la vidéo t'a donné envie d'essayer ces techniques. C'est un premier pas crucial vers une organisation plus agile ! 😉 N'hésite surtout pas à revenir nous dire comment ça s'est passé pour toi et ton équipe. As-tu déjà pensé à quel événement ou type de backlog tu pourrais tester ces améliorations en premier ? 😊 À très bientôt sur Scrum Life ! Robin ✌️
Bonjour Est ce que vous pouvez aborder ce sujet dans une autre vidéo pour mise à jour si il y’a des nouveautés Merci beaucoup
Bonjour @abdelfattahmosaddaq3504, Merci pour ta suggestion ! C'est une excellente idée de revisiter ce sujet pour voir s'il y a des nouveautés. Je prends note et je vais en discuter avec l'équipe. Reste à l'écoute, des mises à jour pourraient arriver bientôt ! N'hésite pas si tu as d'autres sujets en tête ou des questions spécifiques. On adore échanger avec la communauté 🙂 Robin 🚀
Le backlog c'est pas de la faute à jira c'est du scrum ! Essayez de faire du scrum sans JIRA, on va bien rigoler...
Salut k4nful. Personnellement, j'accompagne les équipes sans Jira. Même quand elles l'utilisent, en général les équipes s'en éloignent pour le quotidien et on automatise un max la remontée d'information dans Jira pour qu'on ait pas à y aller justement. Qu'est-ce que tu verrais de difficile dans Scrum sans Jira ? -- Constantin
Salut @k4nful, Merci pour ton commentaire ! Tu soulèves un point intéressant. 🧐 Le backlog est effectivement un élément clé de Scrum, mais il ne dépend pas d’un outil spécifique comme JIRA. Ce qui compte, c’est la bonne gestion du backlog par l’équipe Scrum. Je suis curieux : quelles alternatives as-tu déjà essayées pour la gestion du backlog, et comment ça s’est passé ? Crois-tu que JIRA est indispensable à votre succès agile, ou peut-il y avoir d'autres outils qui peuvent mieux s’adapter à certaines équipes ? Hâte de lire ta réponse ! 🙌 Robin
Cela aide beaucoup mais comme on ne peut rien promettre, comme bien indiqué dans la vidéo , on ne peut pas dire systématiquement, mais c'est vrai que c'est préférable à la livraison de gros lot de fonctionnalités. Livrer de petits incréments favorise largement le feedback et c'est exactement ce que l'on veut
Salut @lutaseb, Merci pour ton commentaire très pertinent ! 🌟 Tu as tout à fait raison, livrer de petits incréments est fondamental pour favoriser un feedback rapide et itératif. Cela permet non seulement de s'assurer que nous sommes sur la bonne voie, mais aussi d'apporter des ajustements en cours de route et d'adapter le produit aux besoins réels des utilisateurs. Quel a été l'impact le plus significatif que tu as constaté en appliquant cette approche dans ton équipe ou ton organisation ? Hâte de te lire ! 🚀 Robin
Tenue en haleine jusqu'à la réponse, j'ai bien failli croire que mon raisonnement n'était pas le bon ! Toujours faire attention aux mots choisi dans la formulation de la question !
Pareil, j'ai failli me faire avoir
Merci pour ton commentaire, @aurorechailloux ! 😊 Eh oui, en agilité, chaque mot compte ! C'est impressionnant de voir à quel point une simple formulation peut orienter nos réflexions et nos décisions. Ton raisonnement était bon, et c'est là toute la magie de l'agilité : apprendre et s'améliorer continuellement. As-tu déjà eu l'occasion d'expérimenter cette prise de conscience dans tes événements Scrum ou dans une approche Kanban ? J'aimerais bien connaitre ton expérience là-dessus. - Robin
J'ai rien compris
Connais tu Scrum ou le lean ? Robin
On travaille en agile. De ce que j'ai compris vous réunissez le scrum Master et le po en lean. Mais pour moi même si la tâche est agrégé ça va rien changer. Le lean est un projet sur du plus long terme et le scrum projet à court terme avec itération
@jeujeux6810 en fait tu retrouves beaucoup de lean dans Scrum. Par exemple sur le fait de limiter le gaspillage (limiter le travail à refaire en prenant le feed-back, les événements Scrum et leurs outcome souhaités etc). Robin
🔥 Quel est ton avis ? Penses-tu que réduire systématiquement la taille des tâches rend une équipe plus efficace ? Dis-nous tout en commentaire et partage ton expérience avec la communauté ! 👇👇
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
Salut @jocoign, Merci pour ton commentaire très détaillé et instructif ! Tu as tout à fait raison de souligner les nuances et les conditions d'application de la loi de Little. C'est précisément cette complexité qui rend l’approche empirique et l'amélioration continue si essentielles en agilité. En effet, dans un contexte où la variabilité est omniprésente, les modèles théoriques peuvent perdre un peu de leur pertinence pratique, et c'est là que l'inspection et l'adaptation prennent tout leur sens. Aussi, ton point sur la limite de WIP (Work In Progress) est crucial : ce n'est pas une moyenne mais un optimum qu'on cherche à atteindre pour maintenir une flow efficiente. Ta formulation de la "bonne réponse" est très éclairante : "Elle aide l'équipe produit ou Scrum à comprendre la relation entre les 3 paramètres et à stabiliser son processus." Cela apporte une vision claire sur la manière dont la théorie peut informer la pratique, sans prétendre être une solution universelle. Je te remercie encore pour ta contribution et pour enrichir la discussion. N'hésite pas à partager d'autres insights ou exemples pratiques que tu aurais pu rencontrer dans ton expérience. Qu'en pensent les autres membres de notre communauté ? Avez-vous des expériences ou des questions à partager sur l'application de la loi de Little ? Robin #ScrumLife #Agilité #ProductManagement #Kanban #LoiDeLittle
⚠ 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 ❤
Salut @annethiebold8871 ! Merci pour ton super retour, ça fait plaisir ! 😊 Ah, le Scrumban ! C’est vrai que c’est une approche fascinante, particulièrement utile pour les équipes support comme la tienne, qui ont des sujets de run à gérer. L’idée d’une vidéo sur le Scrumban est excellente et pourrait apporter pas mal de clarté sur comment optimiser le flux de travail tout en conservant la souplesse nécessaire pour répondre aux imprévus. Pour te donner un petit aperçu rapide : le Scrumban combine la structure de Scrum avec la flexibilité du Kanban. C'est souvent parfait pour les environnements où les tâches doivent être traitées de manière continue. Cela te permet d’adapter et de stabiliser le flux de travail tout en gardant un œil sur les priorités et les urgences. Je note cette suggestion et je vais en parler avec l’équipe pour voir comment on peut traiter ce sujet dans nos prochaines vidéos. En attendant, est-ce que tu as des exemples spécifiques ou des défis particuliers avec lesquels tu souhaiterais qu’on t’aide ? Encore merci pour ta contribution et ton enthousiasme. On adore quand la communauté participe comme ça ! À bientôt sur Scrum Life ! 🚀 - Robin P.S. : À tous ceux qui sont intéressés par le Scrumban, n'hésitez pas à ajouter vos questions ou idées ici 👇
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 !
Salut @monirehsanaei6252, Merci pour ton partage, c'est vraiment important de mettre en lumière ces expériences. Malheureusement, ce que tu décris chez Engie Solutions n’est pas une situation rare dans les entreprises qui cherchent à adopter l'agilité sans en comprendre les valeurs fondamentales. La transparence et la confiance sont des piliers essentiels de toute approche agile, et sans eux, des événements comme le Daily Scrum peuvent rapidement devenir contre-productifs. As-tu eu l'occasion de discuter de ces dérives avec ton équipe ou tenté d'introduire des pratiques pour améliorer la situation ? Parfois, même de petites initiatives peuvent faire une grande différence. Hâte de lire ton retour ! A bientôt, Robin 🚀 #ScrumLife #Agilité #Transparence
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.
Merci Rochdi pour ton commentaire et ta question pertinente ! 🍀 Je suis ravi que la vidéo t'ait été utile. Identifier les goulots d'étranglement sur un diagramme de flux, c'est crucial pour améliorer l'efficacité de ton équipe. Voici quelques astuces pour t'aider : 1. **Observe les colonnes de ton tableau Kanban** : Les colonnes où les cartes s'accumulent rapidement indiquent souvent des goulots d'étranglement. 2. **Analyse le temps de cycle** : Regarde où le temps de cycle est le plus long. Les étapes qui prennent plus de temps peuvent révéler des blocages. 3. **Écoute ton équipe** : Parfois, les membres de l'équipe peuvent te signaler des obstacles auxquels ils font face régulièrement. Pour interpréter ces goulots efficacement : 1. **Discute avec l'équipe** : Organisez une rétrospective pour explorer les causes et trouver des solutions ensemble. 2. **Priorise les solutions** : Une fois les blocages identifiés, priorise les démarches pour les résoudre en fonction de leur impact. 3. **Mesure les améliorations** : Après avoir mis en place des actions correctives, mesure l'impact pour ajuster si nécessaire. N'hésite pas à partager ici tes expériences ou d'autres questions ! On est là pour apprendre ensemble. 😊 Courage et agilité, Robin 🚀
@@ScrumLife merci beaucoup Robin!
B et D
Merci pour ton commentaire, @rochdiliverpool ! Je suis curieux de savoir ce que tu penses des événements Scrum comme la revue de sprint ou la rétrospective. Quelle expérience as-tu eu avec ces éléments dans tes équipes ? À bientôt ! Robin de Scrum Life
C et D?
Je ne vois plus le commentaire...
J'avais bien répondu B :)
Salut @rochdiliverpool ! Bravo pour ta réponse ! 😊 Je vois que tu maîtrises bien le sujet. La question sur les rôles dans Scrum peut parfois paraître simple, mais elle renferme beaucoup de subtilités. Selon toi, quel est le plus grand défi que rencontre le Scrum Master dans une équipe ? Hâte d'avoir ton avis ! À bientôt, Robin
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
Pas faux ! J’adore aussi le workitem age ! Ça permet aussi d’améliorer son lead Time … bref tout est lié
Salut @lutaseb, Merci pour ton commentaire et pour partager ton avis ! C’est super intéressant de voir comment tu envisages l’utilisation combinée de Scrum et Kanban pour optimiser les pratiques agiles. 😊 Je suis totalement d'accord que Kanban ajoute une couche de transparence et de fluidité qui peut vraiment enrichir les événements Scrum. L'âge des items en cours est un excellent indicateur pour aider les équipes à se concentrer sur la finalisation des tâches et à améliorer leur flux de travail. Je me demande, as-tu d'autres astuces ou pratiques Kanban que tu trouves particulièrement efficaces pour compléter Scrum ? Ça m'intéresserait de savoir comment d'autres équipes tirent le meilleur parti de cette synergie. Hâte de te lire et d'échanger davantage là-dessus ! - Robin
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.
Salut @arthur7446, Merci pour ton commentaire. Je comprends ta perspective sur l'IA, mais je pense que c'est important de voir comment elle peut enrichir et non remplacer les compétences humaines. Par exemple, dans le cadre de Scrum et des approches agiles, l'IA peut aider à analyser des données complexes rapidement, permettant ainsi aux Scrum Masters et Product Owners de prendre des décisions plus éclairées. Penses-tu que l'IA pourrait jouer un rôle bénéfique dans la facilitation des événements Scrum comme les Sprint Reviews ou les Retrospectives? Cela pourrait ouvrir un débat intéressant! À bientôt. Robin
Toujours aussi près du terrain ! Grand merci , je vais voir la vidéo tout de suite :)
Salut @AmorAGUILERA-u8y ! Merci pour ton enthousiasme, ça fait plaisir de lire des retours comme ça ! 😀 On essaie toujours de rester au plus près des réalités du terrain parce qu'on sait que c'est là que ça se joue vraiment. Dis-moi, y a-t-il un aspect spécifique de l'agilité ou une situation concrète que tu aimerais voir davantage explorée dans nos futures vidéos ? Ça pourrait nous donner des idées pour les prochains sujets ! À bientôt sur Scrum Life ! - 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é ! Alors ? Que penses-tu des réponses ? Dis-nous en commentaire si tu es d'accord ou si tu as une autre opinion !
Yes réponses correctes pour moi
Salut @adlane5911 ! Merci pour ton retour ! 🎉 Ça fait toujours plaisir de voir que nos contenus t’aident à approfondir tes connaissances en agilité. 👏 As-tu déjà mis en pratique ces concepts dans ton équipe ? Je serais curieux de savoir comment ça se passe pour toi ! Scrumment vôtre, Robin 🔄💡
Super sujet Maïlis, en effet je serais ravie d'y aller plus loin avec ce sujet. Merci beaucoup !
Stop starting, start finishing...
Salut @garancera, Merci pour ton commentaire incisif et pertinent ! Tu soulèves un point fondamental de l'approche Lean. Se concentrer sur la finition des tâches avant d'en commencer de nouvelles est effectivement une règle d’or pour maximiser la valeur et réduire le gaspillage. À ce sujet, comment intègres-tu cette philosophie dans tes propres projets ou dans ton équipe ? As-tu observé des résultats concrets ? Je serais curieux de lire ton retour d'expérience ! Robin 🚀 #ScrumLife #Agilité #LeanThinking
Il est urgent de modifier le bruit de feutre surligneur - c’est une véritable agression pour les tympans - merci 😘🙏🏻
Oui, il est bien trop fort sur celle-ci, désolé :/ -- Constantin
Salut Alain, Merci pour ton retour précieux ! 😊🙏🏻 Je comprends tout à fait, le son peut parfois être un peu perturbant. J'apprécie que tu prennes le temps de nous le signaler, c'est grâce à des retours comme le tien qu'on peut améliorer la qualité de nos vidéos. Peux-tu me dire si ce bruit t'a particulièrement gêné à un moment précis de la vidéo ? On va essayer d'ajuster ça pour que l'expérience soit plus agréable pour tout le monde. Encore merci pour ton soutien et ta vigilance, c'est ce genre de feedback qui fait avancer les choses ! 💪🏻 À bientôt sur Scrum Life ! Robin
Très intéressant d'avoir vos retours ainsi que celui de Marteen, it all makes sense !
Merci pour ton commentaire @SylvainCalmels ! Ça fait plaisir de voir que notre échange avec Marteen t’a parlé. 😊 As-tu déjà eu l’occasion de tester certaines des approches dont nous avons discuté dans ton propre contexte de travail ? Je serais curieux de savoir lesquelles t’ont marqué le plus et pourquoi. Partager tes expériences pourrait en inspirer d'autres dans la communauté ! À bientôt, Robin 🚀
Super format 😂. Merci beaucoup
Merci @MrStefanica pour ton enthousiasme ! 😄 Ravi que le format te plaise. Pour continuer à améliorer notre contenu, y a-t-il un sujet agile que tu aimerais voir abordé dans une prochaine vidéo ? Tes idées sont les bienvenues ! - Robin de Scrum Life
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
Salut @son1powa, Merci pour ton commentaire sincère et introspectif. Tu n'es pas seul, et c'est justement l'une des forces de l'agilité : partager nos défis et apprendre ensemble. Quand des deadlines approchent et que tu ressens le besoin de te former pour améliorer ta pratique (comme le TDD ou les design patterns), c'est souvent un signe que l'amélioration continue est nécessaire. Voici quelques pistes : 1. **Timeboxing et Incremental Learning** : Peut-être peux-tu allouer un court créneau quotidien pour te former tout en avançant sur ton projet. Pas besoin de tout apprendre d'un coup ! Par exemple, 30 minutes de TDD chaque matin avant de commencer ta journée de code. 2. **Choisir ses batailles** : Il est parfois stratégique de "faire au mieux" plutôt que de "faire parfait". Respecter une deadline peut aussi nécessiter quelques compromis pragmatiques. On peut toujours itérer et améliorer dans un sprint futur. Pour ton problème de logique graphique, peut-être devrais-tu explorer ces options : - **Automatiser les tests UI** avec des outils comme Selenium pour valider rapidement les interactions. - **Design Systems** : Avoir un guide de design préétabli pourrait te faire gagner énormément de temps en standardisant les composants. Moins de réinvention, plus de réutilisation. Ton commentaire me donne à penser que nombreuses sont les personnes confrontées aux mêmes défis. Qu'en pensez-vous la communauté Scrum Life ? Des idées ou des conseils à partager ? Merci encore pour ton ouverture, et n'oublie pas, chaque pas compte ! 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
Salut @fbuiphuong61, Merci pour ton commentaire très détaillé et pertinent ! 🙌 Tu as parfaitement mis le doigt sur une problématique cruciale en gestion de produit : la dette technique. Tu soulignes bien l'impact de cette dette non seulement sur la qualité du produit, mais aussi sur les temps de cycle et de traversée, des éléments souvent sous-estimés. Effectivement, comme tu le dis, la dette technique peut devenir coûteuse à long terme si elle n'est pas gérée proactivement. En tant que PO, il est vital d'évaluer constamment cet équilibre entre valeur immédiate et coûts à long terme. La clé, c'est de maintenir ce dialogue de confiance avec l'équipe pour prendre des décisions éclairées ensemble. C'est aussi une question de transparence et de priorisation intelligente dans le backlog. Quelle stratégie préconises-tu généralement dans ces cas-là ? Prioriser des refactorisations itératives ou planifier des sprints dédiés à la réduction de la dette technique ? À bientôt, et au plaisir de lire ta réponse ! Robin 🚀
@@ScrumLife "Prioriser des refactorisations itératives ou planifier des sprints dédiés à la réduction de la dette technique ?" C'est l'équipe responsable et autonome, auto organisée en un mot, qui choisit la mise en oeuvre au cas par cas comme il lui convient le mieux ie comme elle sera la plus efficace et productive. Le PO ne choisit pas ou que très rarement entre les options de mise en oeuvre possibles, il donne les contraintes et les priorités, la vision qui oriente les choix, mais c'est l'équipe qui reste maitre des choix de sa propre organisation et des choix techniques. Ces points peuvent d'ailleurs évoluer : c'est itératif et aussi sujet à amélioration continue !^^ Et le PO adapte ou refait ses stories, ses spec, ses sprints, son backlog .... il est aussi agile le PO !^^
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
Salut @fbuiphuong61, Je te remercie pour ton commentaire super pertinent ! Tu mets le doigt sur un point crucial : l’amélioration continue est effectivement au cœur de l’agilité. Tu as tout à fait raison, notre approche consiste à itérer, recueillir du feedback, et ajuster en conséquence pour constamment s'améliorer. Peut-être que dans cette vidéo spécifique, j'ai davantage mis l'accent sur d'autres aspects de l'agilité, tels que la collaboration, la flexibilité, ou l’adaptation au changement. Mais tu fais bien de souligner l’amélioration continue, car elle est le moteur qui nous permet de gagner en qualité et en efficacité. Je suis ravi de voir que tu es aussi passionné par le sujet et que tu as une compréhension si fine de ces concepts. Pour toi, quelle pratique agile incarne le mieux cette notion d'amélioration continue ? J’aimerais beaucoup connaître ton avis ! Merci encore pour ton retour et à très vite sur Scrum Life ! Robin
@@ScrumLife : oui l'objectif final est bien le bon produit mais ça ne change pas, c'est toujours vrai, c'était aussi le cas en waterfall et c'est vrai avec n'imorte quelle méthodologie, framework ou absence de framework ... c'est une vérité absolue en soit (enfin j'espère !^^) . Le propre de l'agilité, ce qui fait sa particularité puisque c'est le sujet ici, c'est l'amélioration continue, concept inexistant dans les autres frameworks et anciennes méthodologies, qui conduit à tout ce que vous mentionnez très justement en terme de feed back, d'itération ... la différence est là.
Dans ce cas, plus que l’amélioration continue, je parlerai d’empirisme incarné dans Scrum par la transparence, l’inspection et l’adaptation. Robin
@@ScrumLife Oui c'est exactement l'idée, merci, et ça n'est pas dans la vidéo non plus. Et l'empirisme c'est du lean et c'est aussi l'EBM de scrum, et la transparence, l'inspection et l'adaptation, c'est la théorie du scrum guide, basé sur la roue de Deming (Shewhart cycle). C'est dommage de ne pas mentionner toute cette terminologie dans une vidéo sur la définition de l'agilité, même sans l'expliquer (c'est le sujet de vos autres vidéos plus détaillées d'expliquer chacune de ces notions). D'ailleurs, il n'y a pas grand chose sur l'EBM qui mériterait à être plus connu et reconnu, car c'est le début des feed backs plus formalisés.
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 ! ;)
Salut Benjamin, Je comprends parfaitement ton point de vue, et c’est un débat que j’entends souvent dans la communauté agile. 💬 Le Cumulative Flow Diagram (CFD) peut effectivement sembler complexe et parfois peu révélateur de la réalité de certaines équipes. Cependant, le CFD peut avoir une grande valeur si utilisé correctement, notamment pour visualiser les goulets d'étranglement et les tendances à long terme. Mais tu as raison, les notions de cycle time, WIP (Work In Progress) à l'instant T et l'âge des items peuvent offrir des insights plus directs et actionnables pour une prise de décision rapide. 📊 C’est comme avec n’importe quel outil agile : il faut savoir quand et comment l’utiliser, et surtout, adapter les pratiques à la maturité et aux besoins spécifiques de l’équipe. Peut-être que combiner plusieurs approches, comme tu le suggères avec l'âge des items et le cycle time, serait une piste à explorer pour maximiser les bénéfices ? 🤔 Qu'en pensent les autres ? Avez-vous eu des expériences similaires avec le CFD ou d'autres outils ? Merci pour ton commentaire inspirant, Benjamin ! 🚀 - Robin PS : As-tu essayé de mélanger plusieurs visualisations pour voir si cela répondait mieux à tes attentes ? #ScrumLife #Agilité #Kanban #CFD
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
@@ScrumLife 🤣🤣
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.
Salut @lutaseb, Merci pour ton commentaire ! 🎉 Tu as tout à fait raison, la loi de Little est un excellent cadre théorique pour comprendre pourquoi limiter le travail en cours (WIP) peut avoir un impact significatif sur la réduction du cycle time. En effet, plus le nombre de tâches en cours augmente, plus la durée moyenne pour les terminer s'allonge - ce qui ne fait qu'accroître la frustration et diminuer la productivité de l'équipe. Avez-vous déjà mis en place des limites de WIP dans vos propres équipes ? Comment cela a-t-il marché pour vous ? J'adore entendre des retours d'expérience concrets sur ce sujet ! À très vite, Robin 🌟 #ScrumLife #Agilité #LeanThinking
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é 👍🙏
Ah ah, bravo ! 🙌 J'espère que la rapide explication du CFD était claire 😬 Ca allait ? Dis-moi ! -- JP
@@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 🙏😉
Salut @spip931, Bravo à toi ! 🎉 Découvrir et réussir d'emblée, c'est déjà un bel exploit ! J'espère que notre contenu te permet de mieux comprendre ces subtilités de l'agilité et d'en tirer des bénéfices dans ton quotidien. 🧠✨ Et oui, de chouettes défis t'attendent la semaine prochaine ! 😉 Alors, prêt à continuer cette aventure agile avec nous et à découvrir davantage sur Scrum et Kanban ? Si tu as des questions ou des sujets que tu aimerais qu'on aborde, n'hésite surtout pas à les partager ! Merci pour tes encouragements et ta fidélité à #ScrumLife. On est là pour t'aider à exceller et grandir dans les approches agiles ! À bientôt pour la suite de cette série de l'été ! 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é ! 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 ?
Merci pour ton commentaire @ScrumLife ! 🙌 Tu as parfaitement compris l'objectif de cette série. Pas de blabla inutile, on va droit au but pour t'aider à décrocher ces certifications importantes. C'est super que tu mentionnes qu'on va approfondir Kanban bientôt - reste bien abonné, ça va être du lourd ! 🔥 Alors, dis-moi, comment ça se passe de ton côté avec le diagramme de flux cumulé (CFD) ? Est-ce que c'est un outil que tu utilises souvent pour suivre l'évolution de tes tâches ? J'aimerais bien avoir ton retour d'expérience ! Abonne-toi et active la cloche 🔔 pour ne rien manquer des prochaines vidéos ! Robin 🚀 #ScrumLife #Agilité #Kanban
Ça c’est du vrai coaching 🙌🏽🙌🏽 J’espère que scrum life prend des notes .. #PDCA #Emprism dans le coaching #Kata
Si la question c'est est-ce qu'on invitera à nouveau Emilie, on espère bien que oui ! 😁 -- JP
@@ScrumLife en tout cas, moi, c'est volontiers que je viens papoter avec vous et vos abonnée·s 🤗
Merci pour ton commentaire enthousiaste, @b.a9891 ! 🙌🏽 Je suis ravi que tu trouves nos conseils et nos pratiques de coaching inspirants. L’approche PDCA et le Kata sont effectivement des outils puissants pour améliorer en continu et structurer nos avancées. Scrum Life s'appuie beaucoup sur ces cycles d'amélioration pour fournir un contenu toujours plus pertinent. Dis-moi, dans quel contexte appliques-tu le Kata ? Partages-tu une anecdote ou un succès que tu as eu grâce à cette approche ? À bientôt dans les commentaires, Robin #Agilité #ScrumLife #CoachingAgile
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
Salut @amirablaiech3538, C'est une excellente question et une situation que beaucoup d'équipes rencontrent. Dans l'approche agile et plus spécifiquement dans Scrum, l'objectif est d'éviter que les connaissances soient concentrées entre les mains de quelques individus. Cela signifie que dès le départ, il est crucial de favoriser le partage de compétences au sein de l'équipe. On peut utiliser des techniques comme la revue de code en binôme (pair programming) ou des sessions de partage de connaissances pour démocratiser les savoirs critiques. Maintenant, si tu te retrouves déjà dans cette situation où quelqu'un d'indispensable part en vacances, il y a quelques étapes à suivre : 1. **Identifier les tâches critiques** : Avant que la personne ne parte, assure-toi de bien identifier lesquelles de ses tâches sont critiques. 2. **Documentation** : Demande à la personne de documenter ses procédures de travail de manière exhaustive. Une bonne documentation peut sauver la mise quand il y a une absence imprévue. 3. **Formation croisée** : Si possible, organise des sessions de formation rapide pour que plusieurs membres de l'équipe acquièrent ces compétences de base avant le départ de la personne. 4. **Communication** : Il est vital de communiquer de manière transparente avec toutes les parties prenantes pour mettre en place un plan de contingence. Et toi, as-tu déjà essayé certaines de ces approches dans ton équipe ? Comment cela s'est passé ? À bientôt, Robin
Je ne suis plus RTE depuis 2020 donc je n'ai 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
Dans les premières versions de SAFe la philosophie était plus (pour moi) de visualiser pour voir le plus vite possible les impacts en cas de problème. Qu’en penses tu ? Robin
Génial de voir de nouvelles têtes
👍 Super ! C'est toujours un plaisir d'apporter de nouvelles perspectives et idées avec l'ensemble de l'équipe. Quels autres sujets aimerais-tu qu'on aborde avec les nouveaux intervenants ? 🚀 Robin 🦅
Le cœur du Lean c'est de mettre ses collaborateurs dans les meilleures conditions pour être performants
Salut @ahmedb6898 ! Merci pour ton commentaire perspicace ! Tu soulignes un aspect crucial du Lean : l'importance de créer un environnement optimal pour que chacun puisse donner le meilleur de lui-même. Cela me rappelle une citation d'Edward Deming : "Ce n’est pas les gens qu’il faut blâmer, mais le système." Et toi, comment veilles-tu à mettre tes collaborateurs dans les meilleures conditions au sein de ton équipe ? Partage-nous ton expérience, ça enrichira la discussion 😊 Robin de Scrum Life 🚀
@@ScrumLife Selon moi, l'un des facteurs est de mettre à l'aise tout le monde sur le droit à l'erreur. Un droit à l'erreur éclairé qui implique d'apprendre de ses erreurs afin de ne pas les répéter. Nous sommes des êtres d'erreurs 😁. Nous faisons des erreurs depuis notre naissance et grâce à cela nous apprenons. L'entreprise, l'organisation, tout groupe, tout individu peut embrasser une démarche d'amélioration continue où l'erreur est une opportunité pour s'améliorer à tous les niveaux et pour se challenger. A cela, on peut aussi ajouter la lutte contre le perfectionnisme mais ça c'est une autre histoire 😁
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 ?
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.
à 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é.
"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"
Salut @slashy206, Merci pour ton commentaire et d'avoir pris le temps de partager tes réflexions ! Tu pointes un sujet essentiel et c'est précisément ce genre d'échange qui enrichit notre communauté. Tu as raison, la dépendance front-end / back-end est une réalité que beaucoup rencontrent, et j'aurais peut-être dû m'attarder plus sur ce point. Dans certains contextes, la mise en place d'un modèle d'équipes cross-fonctionnelles peut aider à réduire ces dépendances. As-tu déjà essayé cette approche ? Et toi, comment tu gères ces dépendances dans ton travail ? Partage tes expériences, ça pourrait vraiment profiter à tout le monde ici ! Robin
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 ...
Salut @yarazakaria7994, Merci d'avoir partagé ton point de vue si honnêtement ! Ta réflexion est vraiment précieuse et porte sur des sujets essentiels. Je suis d'accord avec toi sur le fait qu'accompagner les personnes pour qu'elles trouvent leur valeur au-delà d'un diplôme ou d'une certification est crucial. C'est effectivement une des clés pour renforcer leur confiance et casser les biais. En tant que femme dans le secteur informatique, ton témoignage est particulièrement pertinent. Il met en lumière la complexité des préjugés et des stéréotypes, ainsi que l'importance d'un accompagnement bienveillant et non stigmatisant. Nous avons tous un rôle à jouer pour valoriser les expériences et les capacités de chacun, au-delà des cases que la société voudrait nous faire cocher. Cela peut parfois être un équilibre délicat à trouver, entre mettre en avant des différences et éviter de renforcer certains stéréotypes. Continuons cette conversation : Comment vois-tu concrètement l'accompagnement dont tu parles ? Hâte de te lire, Robin
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
Salut @bayahamidi6343, Merci pour ton message et pour ta fidélité à notre chaîne ! Deux visionnages, c’est dire que l’agilité te tient vraiment à cœur 😊 Tu soulèves un point crucial : la gestion de la charge de travail dans des environnements contraignants comme le domaine médical. Effectivement, il est vital de ne pas surcharger les sprints afin de maintenir une cadence soutenable pour l'équipe, surtout quand des éléments non négociables comme la documentation et les tests doivent être intégrés. Je trouve que tu as très bien expliqué à ton équipe la nécessité de laisser un pourcentage de capacité pour les imprévus et que le Sprint Planning est leur moment pour effectuer cette planification intelligente. Ta clarification sur la roadmap vs. le scope montre une bonne compréhension de ce qu’est une approche agile pragmatique. Une question pour toi : as-tu déjà expérimenté la mise en place de "sprints de stabilisation" ou des moments de "slack" pour gérer ce genre de contraintes ? Ça pourrait être une pratique intéressante à explorer pour équilibrer la charge de travail. Continue comme ça et n’hésite pas à partager d’autres retours d’expérience. Ton expertise enrichit notre communauté ! À bientôt pour de nouvelles aventures agiles 👋, Robin
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 !
Salut @user-xd6vg2sc6w ! Merci pour ton commentaire. On constate effectivement des différences culturelles et économiques entre pays quand il s'agit de reconnaître et de valoriser les approches agiles, notamment Scrum. La France a encore du chemin à parcourir, mais je suis convaincu que les mentalités évoluent. À mon avis, c'est aussi à nous, praticiens de l'agilité, de démontrer la valeur ajoutée de ces approches dans les entreprises françaises. As-tu des exemples concrets de la manière dont Scrum est intégré dans les entreprises à Singapour ? Ça pourrait être super intéressant pour la communauté ici ! Au plaisir d'échanger avec toi, Robin
@@ScrumLife OUI ! Tant que les projets se passent entre singapouriens , ça passe SI les gains financiers sont assurés et immédiats. Par contre , dès que l'on intègre des locaux avec des expatriés aux niveaux d'éducation et d'expériences différents , ça bloque . C'est l'industrie de l'armement qui privilégie cette méthode à contrario de la finance et du transport maritime. Cordialement.
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 !
Merci pour ton commentaire, @ScrumLife ! Oui, j'ai eu l'occasion de tester plusieurs approches similaires dans différents contextes d'entreprise. Une approche agile m'a particulièrement marqué : la mise en place de Kanban dans une équipe de développeurs travaillant sur un projet complexe et changeant. Les avantages ont été nombreux, notamment une meilleure gestion du flux de travail et une plus grande transparence pour toute l'équipe. L'un de mes principaux conseils serait de commencer par une sensibilisation à l'outil et de l'adapter aux besoins spécifiques de ton équipe. Prendre le temps de bien définir les critères de "Done" et d'identifier les goulets d'étranglement dès le départ est aussi crucial. Et toi, as-tu déjà expérimenté une autre approche agile dans ton équipe ? Comment ça s'est passé ? Hâte de lire ton retour ! 🚀 Robin
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 ?
Bonjour @MdGalag1098, Merci pour ton commentaire et ta question très pertinente ! 😊 Je vois que tu es déjà bien engagé dans la réflexion sur les approches agiles. En réalité, l'agilité, et plus spécifiquement Scrum, peut être extrêmement bénéfique non seulement dans les phases d'exploration et d'idéation, mais aussi durant la phase de build classique. Pourquoi ? Même lorsque tu connais ton Produit et que tu as une roadmap, la flexibilité et l'inspection continue offertes par les événements Scrum (comme les revues et les rétrospectives) permettent d'adapter le plan en fonction des retours utilisateurs et des découvertes faites en cours de route. La capacité d’ajustement est donc un atout inestimable, peu importe la phase du projet. As-tu déjà eu l'occasion d'implémenter une approche agile dans une phase de build plus traditionnelle ? J'adorerais connaître ton retour d'expérience ! À très vite, Robin 🚀 P.S. : Si cette approche t'intéresse davantage, n'hésite pas à parcourir nos autres vidéos qui explorent en détail chaque événement Scrum.
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 😉
Merci @gwendallemoulec9179 pour ton retour ! 😃 C’est super de voir que le contenu de Maïlis t'a plu. Est-ce qu'il y a un aspect particulier des événements Scrum ou des approches agiles que tu aimerais qu'on approfondisse dans une prochaine vidéo ? On est toujours à l'écoute de notre communauté ! À très vite sur Scrum Life ! Robin