On est censé. Oui. :-) Kanban va forcer dans le sens où quand tu es bloqué par la wip limit, ça te pousse à aller aider à débloquer le système plutôt que de continuer à le surcharger. Je ne dit pas que scrum ne veut pas ça. Juste scrum ne dit pas forcément comment faire autre que : on travail tous le même objectif. Kanban va plus loin dans la description de la pratique qui nous y pousse. C’est complémentaire. - Constantin

Merci Constantin@@ScrumLife pour ces explications. C'est plus clair maintenant 😉

Salut @blarouche1 ! Merci pour ton retour enthousiaste, ça fait super plaisir à lire ! 🎉 C'est génial que le livre "Comment créer des leaders" t'inspire à ce point. Ça prouve bien qu'il n'y a pas d'âge pour revoir nos pratiques et évoluer. J'adore que tu veuilles mettre en place certaines réflexions avec ton chef d’équipe, ça peut vraiment transformer votre dynamique en équipe. Est-ce qu'il y a des concepts spécifiques du livre qui te parlent particulièrement et que tu aimerais partager ou explorer davantage ? Je suis sûr que d'autres abonnés pourraient aussi en bénéficier ! Hâte de te lire ! 🙌 Robin

@ScrumLife ça confirme qu'une pratique que j'utilisais depuis longtemps N'était pas si folle. Je dis souvent que je n'ai pas de réponses. Mais des questions pour trouver leur réponse. Quelque part, j'applique un peu l'idée "Leader-Leader" en leur donnant la responsabilité de trouver la solution ensemble. Avec l'expérience, j'ai souvent de réponses bien avant qu'ils ont fini de me présenter leur problème. Mais, j'ai aussi remarqué (ok, appris) que la meilleure solution. Elle vient toujours des personnes qui soumettent le problème. Apprendre, et encore apprendre que la solution doit émerger de l'équipe et des membres n'est pas toujours facile. Mais, une voie à exploiter pour améliorer la performance de tout le monde, même la sienne. Le point que je cherche améliorer dans mes équipes, la bonne communication des problèmes. Pas juste, dire, j'ai un problème. Mais, on a trouvé un problème et voici les pistes de solutions ! OK, je ne travaille pas dans un sous-marin nucléaire et je ne suis pas le capitaine non plus. Mais, la personne qui cherche à influer un changement. J'ai souvent pris "Lampe de poche" (ref : livre "Comment créer des leaders”) pour faire le tour sous-marin. Bien sûr, j'ai vue des défauts, dire comment les corriger est facile. Mais apprendre aux gens à voir et prévenir ces défauts est encore meilleur. Jouez au capitaine, fonctionne un certain temps, pas infiniment ! Donc, oui, je vous recommande chaudement de lire le livre "Comment créer des leaders”. Le concept qui va encore plus influencer ma pratique (d'empêcheur de tourner en rond ;-)) sera ne plus être simplement le capitaine. Mais, un membre d'équipe à part entière. Le seconde, est la responsabilité et l'engagement, doit partager par tous ! P.S. "Ça prouve bien qu'il n'y a pas d'âge pour revoir nos pratiques et évoluer." Je ne suis pas vieux, juste modèle avec quelques pièces beaucoup de Kilomètres aux compteurs. Ne t'inquiète pas, je ne l'ai pas pris personnel, je rigole. Les ordinateurs (IBM 8088/8086 et VAX-VMS) et les technologies (Pascal, XP (eXtrem Programming) 😀, que j'ai fait mes premières armes en informatique, sont presque toutes au musée depuis longtemps. Bruno Larouche

Salut @kaledks2722 ! Merci pour ton commentaire et ta question super pertinente. 😃 Je comprends ce que tu ressens, les concepts de lagging indicators et leading indicators peuvent sembler absents du guide Kanban pour les équipes Scrum. Pourtant, ils sont essentiels pour une évaluation précise et proactive de nos processus. Le guide Scrum et le guide Kanban se concentrent souvent davantage sur les pratiques et les rôles, laissant parfois ces indicateurs en arrière-plan. Mais comprendre et utiliser ces indicateurs peut vraiment faire la différence dans l’amélioration continue de ton équipe. Les leading indicators te permettent de prédire les résultats et d'agir en amont, tandis que les lagging indicators t'aident à mesurer la performance passée. Si tu galères à monter seul en compétence, n’hésite pas à rejoindre des communautés agiles, suivre des formations complémentaires ou même poser tes questions ici. Je suis sûr que d'autres viewers auront des conseils à partager ! Quel aspect de l'agilité aimerais-tu approfondir encore plus ? Dis-le moi en commentaire et j'essaierai de faire une vidéo dessus ! À bientôt, Robin 🧠 #ScrumLife #Kanban #Agilité

Salut @blarouche1, Merci beaucoup pour ton retour ! 🌟 Je suis ravi de savoir que ma vidéo t'aide dans ton parcours vers la certification. C'est vrai que Scrum avec Kanban peut sembler complexe au début, mais avec un peu de pratique et une bonne compréhension des principes agiles, tu verras que tout devient plus fluide. En parlant de certifications, as-tu déjà expérimenté certains des événements Scrum dans ton équipe actuelle ? Comment cela se passe pour toi ? N'hésite pas à partager ton expérience, ça pourrait aider d'autres personnes dans la même situation. Encore merci pour ton commentaire et bon courage pour la suite de ta formation ! Robin 🚀 P.S. Si tu as des questions spécifiques ou des sujets que tu aimerais voir abordés dans une future vidéo, fais-le-moi savoir !

Merci @Abdelkarim-ou3hw pour ton retour positif, ça fait vraiment plaisir ! 🎉 Content de savoir que la vidéo t'a été utile et que tu as apprécié notre manière d'aborder le sujet. Y a-t-il un aspect particulier de l'agilité ou de Scrum que tu aimerais qu'on développe plus en détail dans une prochaine vidéo ? Ton avis compte beaucoup pour nous ! À bientôt, Robin 🔄

Salut @jocoign ! 🖐️ Merci pour ton retour éclairé. Tu mets le doigt sur des points essentiels en Kanban. En effet, il s'agit d'optimiser le flux de valeur plus que simplement le flux de travail. Ton analyse sur la réduction des coûts de transaction et leur impact sur le Cycle Time est particulièrement pertinente. C'est exactement ce genre de réflexions qui permet d'affiner notre compréhension et notre pratique des approches agiles. Je comprends aussi tes réserves concernant la formulation de la réponse A. En agilité, rien n'est gravé dans le marbre, et l'avons bien compris, la valeur ne peut être confirmée qu'après livraison et feedback utilisateur. Ton alternative de "faire entrer dans le flux les éléments qui semblent avoir le plus de ROI à l'instant t" reflète mieux cette anticipation de l'incertitude naturelle de nos environnements. Les suggestions que tu proposes enrichissent effectivement la réflexion autour de la priorisation en Kanban. C'est tout cet aspect itératif et empirique qui fait la beauté de cette approche. Si tu avais des exemples concrets où cette stratégie t'a permis de rapidement valider (ou invalider) un pari d'investissement, ce serait fantastique de les partager avec nous ! J'ai hâte de te lire. Agilement, Robin #ScrumLife 🚀

@@ScrumLife désolé du délai de réponse :) je n'étais pas focus sur ça :D J'ai fait l'expérience plusieurs fois de choses que je relate : - en amenant un groupe de personnes en mode coordination (PO qui amenait des éléments à un UX qui ensuite rapportait cela à un BA, puis dev etc...) à basculer en mode collaboration atelier 4 amigos PO, UX, BA, Dev pour parler ensemble et trouver une solution ensemble, permettant de supprimer pas mal de coûts de transaction - autre exemple avec un groupe d'UX designer qui bossait en chambre en amont d'une wannabe scrum team pendant plusieurs semaines et qui amenait des solutions qui ne restaient plus qu'à coder, enfin selon eux, mais qui dans les fait nécessité de nombreuses heures de discussion pour notamment comprendre. En amenant une approche dual track disco/delivery nous avons pu réduire le coût de transaction - en convaincant les Scrum team que j'accompagne qu'affiner des tonnes d'US alors que leur flux ne permettaient d'en dépiler que 3, 4 voire 5 fois moins, était un énorme gaspillage, une perte de focus et un coût de changement de contexte qu'ils allaient payer plusieurs fois etc... Je relate pas de mal de choses que j'ai pu vivre en lien avec le sujet, dans un article que j'ai publié initialement sur mon site en plusieurs parties et que récemment org topologies à republier : www.orgtopologies.com/post/fran%C3%A7ais-org-topologies-strat%C3%A9gie-kanban-pour-augmenter-son-agilit%C3%A9-business

Merci beaucoup pour ton retour enthousiaste, @SophieCARON-CROIX ! 😊 Je suis ravi que tu trouves le contenu accessible et utile. Si tu as des questions spécifiques sur l'agilité ou si tu veux qu'on aborde un sujet particulier dans nos prochaines vidéos, n'hésite surtout pas à le dire ! Quelle est la plus grande difficulté que tu rencontres dans l’adoption des approches agiles ? - Robin de Scrum Life 🧩

@@ScrumLife Je suis en train de regarder petit à petit les vidéos, donc avant de demander à aborder un sujet particulier, je vais déjà regarder ce que vous avez fait et, si j'ai des questions, je reviendrai vers vous ! Merci beaucoup en tout cas !

Merci Abdelkarim pour ton retour élogieux ! 🙏 C’est une très belle définition que tu partages là. En effet, savoir ajuster sa direction en fonction des points de situation et des ressources disponibles est un aspect fondamental de l’agilité. 🚀 D'ailleurs, quelle approche agile préfères-tu intégrer dans ton travail : Scrum, Kanban ou une autre ? C’est toujours enrichissant de connaître les expériences et perspectives des autres pratiquants. Au plaisir de te lire et merci encore pour ton engagement ! 😊 Robin

Merci @eirianlegoux pour ta précision et ta citation tirée du livre ! 🤓 Effectivement, la distinction entre les Enabling Teams et les Communautés de Pratique (CoP) est essentielle pour bien comprendre leurs rôles respectifs dans l'organisation agile. Les Enabling Teams agissent comme des catalyseurs, concentrant leurs efforts sur un petit nombre d'équipes pour les aider à surmonter des obstacles spécifiques et développer leurs compétences. C'est un peu comme un commando agile en intervention ! 💪 De l'autre côté, les CoP jouent un rôle plus transversal en diffusant les meilleures pratiques et les connaissances à travers l'ensemble de l'organisation. Leur effet est plus vaste et global. 🌍 Merci encore pour ton apport enrichissant à la discussion ! Si tu as d'autres questions ou réflexions, n'hésite pas à partager. Qu'est-ce que tu penses des effets à long terme de ces deux approches sur la culture d'entreprise ? À bientôt, Robin 🚀 #ScrumLife

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.

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

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 🚀

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 ☺

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 @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 🚀

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

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

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

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

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 👇

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

"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!

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

Je ne vois plus le commentaire...

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

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

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

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

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 🔄💡

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

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

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 🚀

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

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

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 !^^

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 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

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