Alors, pour ou contre la pause entre les sprints ? Qu'en dis-tu ? Quelles sont tes expériences ? 🔍

Nous, on fait la review et la rétro le vendredi matin, et le planning le lundi matin. Ça laisse le vendredi après midi pour faire de la veille techno, des katas ou autres ateliers du genre.

@ScrumLife

2 ай бұрын

Un peu comme ce que je racontais au Player de France Télévisions ! Belle expérience, je suis sûr ! Pas vrai ? -- JP

@ScrumLife

20 күн бұрын

Salut @vincentleroy2490 ! 👋 C'est génial de voir comment vous organisez vos événements et même incluez du temps le vendredi pour la veille techno et les katas. C'est une belle manière de monter en compétences tout en gardant l'équipe soudée ! As-tu remarqué un impact particulier sur la productivité ou la créativité de ton équipe grâce à cette organisation ? Merci pour ton partage et au plaisir d'échanger plus ! 🚀 Robin

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

@ScrumLife

19 күн бұрын

Salut @romaindebrito, Merci pour ton commentaire et ton enthousiasme! 🎉 La team Constantin a définitivement une approche unique pour faciliter la conduite du changement, et je suis ravi que tu l'aies trouvée utile. Ce que tu dis sur l'importance de l'expérimentation et de l'innovation pendant le sprint est tellement vrai. C'est souvent en testant et en ajustant nos pratiques au sein même du sprint que l'on découvre des moyens d'améliorer notre flux de travail et notre collaboration. Peut-être pourrais-tu partager une expérience où l'innovation dans un sprint a vraiment fait la différence pour ton équipe? Je suis sûr que beaucoup de nos abonnés seraient curieux de savoir comment ça s'est passé pour toi! Merci encore pour ton retour et ton engagement. À bientôt sur Scrum Life, 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 🙂

@ScrumLife

Ай бұрын

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

@ScrumLife

18 күн бұрын

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

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

@ScrumLife

19 күн бұрын

Salut @guzul ! Merci pour ton commentaire et pour avoir partagé ton expérience ! C'est toujours passionnant de voir comment chaque contexte unique influence la façon dont les équipes s'organisent. 👏 Effectivement, cette journée "pause" peut sembler déroutante au premier abord. Tu fais bien de vouloir sonder ton équipe lors de la rétro pour comprendre comment cette journée est vécue et utilisée. Les événements Scrum, comme les rétrospectives, offrent souvent un terrain fertile pour ajuster et améliorer nos approches agiles. As-tu déjà des premières impressions sur la façon dont ton équipe perçoit cette journée ? J'ai hâte de connaître les insights que tu récolteras après cette rétro ! À bientôt, Robin #ScrumLife #Agilité #ContinuousImprovement

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

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

@ScrumLife

19 күн бұрын

Salut @melodiepellet4565, Merci pour ton retour détaillé et pour avoir partagé ton expérience avec SAFe ! 🎉 Je suis totalement d'accord avec toi sur l'importance d'adapter les événements pour qu'ils répondent au mieux aux besoins des équipes. Intégrer l'innovation et la formation directement dans les sprints classiques, tout en veillant à maintenir un bon niveau de focus, semble être une approche judicieuse. C'est génial aussi que ton management fasse confiance à l'équipe pour ajuster ses plans en fonction des nécessités. Tu mentionnes l'opinion de Constantin sur le fait de "charger moins les sprints pour garder un rythme soutenable". Ça soulève une excellente question : comment concilier l'envie de livrer fréquemment et la nécessité de laisser de la place pour l'innovation et la formation ? J'aimerais beaucoup connaître ton point de vue sur une autre dimension : as-tu observé une évolution de la satisfaction des équipes avec cette intégration directe de l'innovation et de la formation ? 🤔 Hâte de te lire et encore merci pour ton partage 🙏 Robin 🚀 | Scrum Life

Hello! Super sujet! Moi je suis plutôt comme Constantin, si on doit faire une pause entre chaque sprint, c'est que le sprint est beaucoup trop chargé. Mais par ailleurs, ce que propose JP avec une demi-journée entre retro et planning me semble un bon compromis. De mon côté, j'ai vécu une super expérience: à la faveur des fêtes de fin d'année qui avaient bousculé le rythme de nos sprints, on a fait 1 semaine de pause qu'on a vraiment organisée. On y a calé une conférence, un atelier sur la qualité logicielle, une lecture accompagnée du Scrum Guide, un atelier pour reprendre le process de MeP... bref, tout le monde était bien occupé en vrai. Et tout ça sur le principe de confiance et d'invitation: rien d'obligatoire et personne ne s'est tourné les pouces! Un vrai plus pour tous les équipiers!

@ScrumLife

2 ай бұрын

Super expérience, merci de la partager Cécile. Tu devrais proposer ce REX à des confs :) Est-ce que cette expérience à été bien perçue finalement par les équipes, par leur management ? -- Constantin

@cecilevivant6351

2 ай бұрын

@@ScrumLife il existe le REX... je l'ai déjà fait d'ailleurs... L'équipe était méfiante au départ, quand les équipiers ont compris qu'on ne leur demandait rien. Ils se sont dit que s'ils voulaient ils pouvaient regarder des séries toute la semaine, mais que comme on leur faisait confiance, sans rien tracer, sans faire de daily, ils se devaient de respecter ça. Et ça a fonctionné d'enfer! Le management... il a fallu convaincre en amont de nous laisser tenter l'expérience. On a eu de la chance. Et au final, franc succès! On a fait un REX pour le management, et les équipiers ont vraiment fait des retours positifs. C'était une semaine très productive en termes de cohésion d'équipe, de softs skills, et de remise à plat de certains irritants dans les process. Pour le management, c'était positif aussi, mais pas quantifiable, le ROI est difficilement mesurable. Même s'ils ont bien compris que cela avait été bénéfique.

@ScrumLife

20 күн бұрын

Salut @cecilevivant6351 ! Merci pour ton retour éclairé et enthousiaste 🌟. Ton expérience pendant les fêtes de fin d'année est vraiment inspirante. Mettre en place des événements constructifs et non obligatoires, c'est une magnifique démonstration de confiance et d'autonomie dans l'équipe, bravo à vous ! 👏 Je suis curieux, lequel de ces ateliers ou activités a eu le plus d'impact sur l'équipe selon toi ? Et as-tu des ressources ou astuces à partager pour organiser ce genre de "pause active" ? Ça pourrait être super utile pour d'autres membres de la communauté ! 💡 À bientôt, et continue de partager tes précieuses expériences ! 🚀 #ScrumLife #AgileCommunity #TeamBuilding

@cecilevivant6351

7 күн бұрын

​@@ScrumLifehello! Je pense que l'atelier de remise à plat du process de MEP est celui qui a eu le plus d'impact immédiat. Mais celui de lecture débat du Guide Scrum a été un moment fort de discussions et de cohésion d'équipe. Le plus difficile à été de convaincre le management car c'est une semaine sans production!😊 Il faut donc bien soigner son argumentaire et préparer le bilan à présenter ensuite. Le gros plus de la semaine est que, travaillant pour un grand groupe, nous avons eu la chance de pouvoir faire intervenir une agiliste interne qui fait régulièrement des conférences à l'extérieur, ça a évité de rester en vase clos.

6:33 Le nombre de fois ou j'entends cette phrase dès que l'équipe veut améliorer les choses en proposant des choses évidentes... Et évidemment, on a aussi le droit au "sprint cooldown" imposée par le management pour faire 2 semaines de correction de bugs, la qualité d'un projet qui a 3 ans d'existence qui est déplorable... Toutes ces boites qui font les mêmes erreurs documentées depuis des années, elles ont vraiment de la chance que le business suivent derrière.

@ScrumLife

2 ай бұрын

Merci pour ton commentaire, pourquoi crois-tu que ces entreprises n'arrivent pas à se rendre compte que "ça ne fonctionne pas vraiment" ? On est dans un monde très capitaliste, et pourtant elles s'autorisent à gaspiller du temps et de l'argent à faire sans cesse les mêmes choses qui ne fonctionnent pas. N'est-ce pas paradoxal ? -- Constantin

@Monsieur_Anderson

2 ай бұрын

​@@ScrumLife C'est effectivement paradoxal et cela peut s'expliquer pour plusieurs raisons selon moi. Déjà, ca peut être polémique, mais en France le capitalisme est très limité par le code du travail. Parfois le système d'une entreprise devient un amas de décisions, de managers, de coachs, de chef de projets, de PO, de PM, de proxy PO de Program Managers... qui se sont empilés au lieu de se réorganiser. Ces systèmes digne de l'URSS nécessitent une réorganisation et donc, tristement, des licenciements. Ce qui en France se fait moins facilement que dans d'autres pays, pour le meilleur et pour le pire. L'autre raison c'est que le capitalisme ne juge que par la rentabilité globale du système d'une entreprise. Donc si les 20% des personnes les plus compétentes de la boite la tire vers le haut très brusquement, cela compense l'incompétence d'autres personnes. Exemple : si une entreprise toxique et très directive avec ses développeurs, qui impose des deadlines intenables, fait que certains développeurs travaillent dur par professionnalisme pour contrecarrer les décisions qui n'ont aucun sens... le projet peut quand même marcher. Et ca va inciter tout le management à continuer, la preuve : ca marche ! Aussi, certaines boites ont tellement capitalisé que même en prenant les pires décisions, il faut des années pour que cela commence à se voir. Mais globalement dans ma région, les entreprises qui ont bonne réputation dans la tech sont aussi les entreprises qui font de bons chiffres.

@ScrumLife

20 күн бұрын

Salut @Monsieur_Anderson ! 👋 Oh, tu mets le doigt sur des points si vrais et si frustrants à la fois… 😅 La fameuse résistance au changement dans un environnement où l'innovation est censée être la clé, ça peut vraiment être décourageant. Les "sprint cooldowns" imposés, c'est un classique qui frustre pas mal d'équipes ! 🙈 D'ailleurs, quelles seraient pour toi les actions prioritaires pour améliorer la situation dans ces entreprises ? J'ai l'impression que beaucoup ici rencontrent les mêmes défis, ça pourrait ouvrir une discussion passionnante sur les solutions concrètes à mettre en place. Merci pour ton partage, c'est super enrichissant ! Hâte de te lire ! 🚀🔄 Robin

Totalement d'accord ❤️

@ScrumLife

20 күн бұрын

Salut @NicolasPoitelon ! Merci beaucoup pour ton soutien 🙏! Quel aspect t’a le plus marqué dans cette vidéo ? J'adore échanger avec vous tous sur ces sujets passionnants et ton feedback est super précieux. Hâte de te lire ! 🚀 #AgilitéEnsemble

N'est-il contre-productif de courir à fond pendant les sprints et de faire des pauses entre eux, sachant qu'à force cela peut casser un rythme qui devrait être soutenable, diminuer la valeur créée pendant les sprints et allonger les périodes de repos entre les sprints ?

@ScrumLife

2 ай бұрын

C'est personnellement ce que je pense aussi. Mais je rejoins JP sur le fait que c'est compliqué de dire à quelqu'un de motivé et pris dans la passion de sa création de s'arrêter un peu, d'aller moins vite. Tu ferais comment toi ? -- Constantin

@spip931

2 ай бұрын

@@ScrumLife En effet, ce n'est pas évident. Je ferais comment ? Je lui conseillerais de ralentir pour durer plus longtemps, même s'il doit utiliser le temps restant du sprint pour se former, réécrire son code... Le risque à aller trop vite c'est que la personne fasse un burn-out, se démotive dans le sens où la reconnaissance n'est pas à la hauteur de son engagement, et/ou démissionne pour une autre boite. Ce n'est pas pour rien que le Scrum Guide parle de rythme "soutenable". Selon moi, il n'est pas nécessaire d'aller à fond, quitte à se cramer, pour "prouver" sa concentration, son courage et son engagement (3 des valeurs de Scrum)

@ScrumLife

20 күн бұрын

Salut @spip931, Merci pour ton commentaire super pertinent ! 😊 Effectivement, c'est une question que beaucoup se posent lorsqu'ils découvrent la dynamique des sprints dans Scrum. 🎯 L'idée des sprints n'est pas de courir à fond comme une course de 100 mètres, mais plutôt de trouver un rythme de travail soutenable, comme un marathon. 🏃‍♂️💨 Les pauses entre les sprints, également connues sous le nom de rétrospectives, sont conçues pour aider l'équipe à réfléchir et à s'améliorer continuellement. Cela peut même augmenter la valeur créée à long terme! Et toi, comment vois-tu l'équilibre entre productivité et pauses dans ton contexte ? Hâte de connaître ton avis ! 🚀 À bientôt, Robin

Je l'ai vu cette publication sur LinkedIn

@ScrumLife

2 ай бұрын

Haha ! J'avoue y'en a pas mal de ce type de post "inspirant". -- Constantin

Intéressant comme débat. Je suis pour et contre, donc selon le contexte. Si nous suivent la même philosophie de SAFe framework. On travaille sur des sprints full pour livrer, après on prend une pause pour faire autre choses. Ce qui fait que les sprints sont engagés a 100%, donc il n'y a pas de marge de manoeuvre par ce que tout ce qui est dans le sprint on doit le livrer pour prendre une pause après. Et ce point affecte d'une façon indirecte l'équipe, ou tout personnes commence a se concentrer sur son travail par ce qu'il fait partie de commitment, et la on commence a perdre la collaboration par ce que tout le monde est occupé par son travail. La ou c'est intéressant d'avoir des sprint soutenable pour livrer de la qualité et améliorer la collaboration de l'équipe. Et on aura le temps pour adresse correctement les point d'amélioration. Par contre, ça nous donne pas la possibilité pour travail sur la dette techniques ou d'autres choses qui impact le projet surtout si elle est développe par une autre équipe dans le passé. Et aussi ça donne l'impression que on est dans la roulette de hamster sans fin de parcours. Ou le fait d'avoir une pause pour livrer une autre valeur différente c'est intéressant aussi.

@ScrumLife

2 ай бұрын

"Et aussi ça donne l'impression que on est dans la roulette de hamster sans fin de parcours. Ou le fait d'avoir une pause pour livrer une autre valeur différente c'est intéressant aussi." Merci c'est très intéressant comme remarque. Personnellement je trouve qu'une Sprint Review bien faite, c'est à dire orientée business offre ce moment de réflexion sur la suite et de se permettre de faire autre chose. Ce qui amène sur la dette technique, pour moi un sprint soutenable permet justement, en ne le blindant pas à fond, de laisser le temps à l'équipe d'adresser la dette, l'automatisation, etc. Mais on ne peut faire ça qu'en ayant un focus objectif de sprint/produit, plutôt qu'une liste à dépiler le plus vite possible. Qu'en dis-tu ? -- Constantin

@fouadbenzina3183

2 ай бұрын

Merci Constantin pour ta réponse. Je suis d'accord avec ce que tu as mentionné. Par contre le contexte de projet jeu un rôle la dessus, ex, quand on travaille dans une entreprise de consulting ou le contrat avec le client est de livrer que de la valeur, c'est difficile de faire passer de la dette techniques dans des sprint par ce que pour eu il ne vois pas forcément de la valeur business ( oui c'est possible d'approuver que il y a une valeur derrière au moyen, long terme, mais ça reste un débat a faire pour le gagner). Ce qui rajoute aussi de la complexité c'est quand tu as un contact base sur les story points et souvent on arrive après que tout est en place donc on est bloqué par ça. Par contre si tu dit on fait de SAFe avec un sprint d'innovation tout le monde l'accepte 😅😅.

@ScrumLife

20 күн бұрын

Salut @fouadbenzina3183, Merci pour ton commentaire réfléchi! Tu mets en lumière un débat crucial dans le monde de l'agilité. En effet, la cadence des sprints et la balance entre l'engagement et la collaboration sont des éléments clés. SAFe peut parfois donner cette impression d'une "roulette de hamster", comme tu le dis si bien. La question de la soutenabilité des sprints est essentielle pour maintenir la qualité. Par ailleurs, tu soulignes bien l'importance de s'accorder du temps pour adresser les dettes techniques, souvent laissées en arrière-plan. Je suis curieux, as-tu déjà expérimenté des ajustements ou des variantes au sein d'un framework comme SAFe qui ont permis de trouver un meilleur équilibre entre ces différents aspects? Partage ton expérience, cela pourrait vraiment enrichir la discussion! À bientôt, Robin de Scrum Life 🚀 P.S. Pour ceux qui passent par ici, n'hésitez pas à donner votre avis sur cette question! #Agilité #SAFe #Collaboration #Sprints

c'est tout le problème de Scrum : prioriser la procédure à l'adaptation (donc la moins agile des méthodes agiles) c'est ce que je reproche le plus à cette méthode, car on parle de "framework à suivre" ce qui est le contraire de l'agilité. Le principe de Scrum est très bien : optimiser le processus de développement, mais n'est pas assez flexible, et donc pas assez agile pour s'adapter à des situations particulières. D'où le Lean qui est plus agile. En réalité le Scrum n'est qu'une évolution de la doctrine des années 80, juste améliorée et soutenue avec les critères d'acceptabilité actuelle, Scrum m'a toujours fait pensé à un "travail à la chaine", où Attention au terme "innovation" qui est utilisé à mauvais escient ici, pour indiquer seulement une "amélioration potentielle et probable" 9:08 "que chaque sprint apportent de la valeur... et produit quelque chose" : c'est tout le problème ! on parle de "chaine de valeur" pour "toute les parties prenantes", mais cette "valeur ajoutée" est rarement estimée, et plus rarement appréciée, parfois jugée (ce qui donne de l'espoir quand même) - les "moins values" sont par contre bien plus estimées et appréciées car intégrées au process Scrum (review, retrospective, vélocité etc...) Le problème étant que ma méthode elle-même est très-très peu agile elle-même : très figée (protocolaire) C'est là où SAFe apporter une dimension en plus qui peut apporter une agilité sur les méthodes et l'organisation elle-même Vous l'aurez compris, je ne suis pas pro-scrum, mais plus orienté Lean en choisissant des méthodologies adaptées + vision business (moyen/long terme)

@ScrumLife

2 ай бұрын

Bonjour JfD et merci pour ton commentaire. J'ai quelques questions si tu veux bien : 1/ Quand tu écris "prioriser la procédure à l'adaptation", je ne suis pas sûr de comprendre de quoi tu parles. Tu peux préciser stp ? 2/ Tu écris que Scrum n'est pas assez flexible, peux-tu préciser ce que tu trouve peu flexible dans Scrum au point de ne pas pouvoir s'adapter à des situations particulières ? 3/ "mais cette "valeur ajoutée" est rarement estimée, et plus rarement appréciée, parfois jugée " là dessus je te rejoins souvent, mais justement normalement ça ne devrait pas se passer, et c'est souvent mon combat au quotidien avec mes clients, d'arrêter de ne pas regarder la valeur qu'on espère ou celle qu'on a vraiment générée ou pas. J'espère te lire bientôt, pour m'aider à comprendre ce que tu trouves de protocolaire dans Scrum par exemple. -- Constantin

@JfD_xUp

2 ай бұрын

@@ScrumLife Bonsoir, tout d'abord merci pour le retour, car je comprends que mes propos ne sont pas clairs (c'est toujours plus simple dans notre tête, mais une relecture par autrui est toujours bonne) 1+2 : "prioriser la procédure à l'adaptation" - ce que je voulais dire ici c'est que Scrum nous demander d'appliquer le processus (ou "framework"). Une des valeurs de l'agilité étant "Les individus et les interactions plus que les processus et les outils". Ce qui m'embête avec Scrum c'est la rigueur avec laquelle on doit appliquer le "framework", c'est ce cadre qui est rigide. ex : DSTUM 15min alors que parfois on n'a rien à dire, surtout si (par exemple) les développeurs vont passer 2-3 jours à développer une fonctionnalité : quelle est l'utilité de ce Daily Stand-up Meeting si on parle avec l'équipe dès qu'on perçoit un soucis (et pas attendre le DSTUM pour en parler). autre exemple : la durée fixée des sprints, qui ne peuvent être changés ou écourtés (en théorie), même si tout s'est fini plus vite que prévu, ou s'il manque juste 1-2 journée pour terminer : c'est cette flexibilité qui manque, selon moi, à Scrum, tout comme le fait que les sprints soient toujours fixés sous prétexte que l'équipe s'habitue à cette vitesse (je suis d'accord avec ce principe) mais oublie une chose : la dynamique (comme la "dynamique des fluides"). Parfois ça a du bon de modifier légèrement le rythme, tout en cherchant à garder "l'alchimie" : si on ne change pas de rythme (dans une musique) on s'en lasse, mais il faut toujours que ça reste "harmonieux" (les fameuses "harmoniques musicales") 3 : c'est peut-être en mettant un peu de "stress volontaire et accepté par toute l'équipe" (ce qui peut être challengeant) qu'on peut justement permettre de faire une analyse de la valeur ajoutée : "l'équipe est-elle compétente en cas de stress (ex : pression client, deadline)", comment renforcer les liens entre l'équipe, comment valider la vélocité si on ne teste pas d'autres sprint-lapse? Peut-être que je me trompe (sûrement d'ailleurs), mais j'ai cette impression que Scrum est plutôt rigide : est-ce que cette méthode prend en compte le fait qu'une ou deux personnes peuvent manquer dans l'équipe ? (ex : être malade) elle met bien en valeur la "performance" de l'équipe en place, ce qui est bien, mais je me pose la question de ce qui se passe si on voudrait accélérer et ajouter 1-2 personnes en plus (ex : scale-up, rapid prototyping), ou au contraire ralentir un peu (normalisation, standardisation) Désolé pour cette vision plus orientée Business, mais si ça sort du cadre de Scrum : pourriez-vous alors m'expliquer pourquoi j'ai cette impression qu'il manque une "dimension" (ou peut-être que la solution est serait SAFe - que je maitrise encore moins) une petite question en plus : comment se passe le "transfert de compétences" ? vous créez un sprint spécial "transfert de compétence" / "consolidation des acquis" etc . ? merci en tout cas pour cette échange, sincèrement, j'aime apprendre, mais cherche aussi à comprendre j'ai souvent entendu parlé de Scrum comme une méthode pouvant aussi être utilisée pour la R&D et l'innovation, mais j'ai un peu de mal à apprécier ce point de vue, car la R&D (la vraie, pas le développement logiciel) est difficilement estimable, et pour l'innovation la difficulté est le recueil d'informations pour pouvoir prendre des décisions. Je ne sais pas si Scrum est fait pour moi (ma manière de penser), mais je trouve ça intéressant de voir des personnes passionnées par cette méthodologie. bien à vous

@jocoign

2 ай бұрын

@@JfD_xUp Scrum est beaucoup plus souple que tu ne le perçois. Le daily scrum a une timebox de 15min, il peut se finir en 1min sans aucun soucis. Par contre le fait qu'il dépasse les 15min régulièrement est un signe qu'il y a quelque chose à améliorer au sein de l'équipe. La durée du sprint peut être changée par exemple à la suite d'une rétrospective. Le changer en cours de sprint n'a pas vraiment de sens car ce que tu veux à la fin c'est avoir du feedback et un atelier de travail avec les parties prenantes en sprint review pour ensemble imaginer une suite avec le plus de valeurs possibles. Si tu changes la durée du sprint en cours, tu as toutes les chances que tes parties prenantes ne soient pas disponibles au pied levée et donc tu vas rater cet évènement de sprint review qui est certainement le plus important. Tu parles de stresser un peu le système, la scrum team, why not, elle est sensée s'améliorer en continue avec le support du Scrum Master et comme tout bon sportif tu ne t'améliore, ne dépasse tes limites qu'en ayant par moment un peu de souffrance. Il faut juste que ça reste soutenable dans le temps. Scrum ne l'interdit pas, il précise la redevabilité du Scrum Master qui est d'améliorer l'efficacité. Ca rentre dedans parfaitement. Qu'est ce que tu entends par valider la vélocité ? Il y a des absences non prévues dans l'équipe ? C'est la vie ! Le reste de l'équipe doit faire son max (sans basculer dans un rythme insoutenable) pour tenter d'atteindre l'objectif et peut être qu'ils n'y arriveront pas. Scrum ne dit pas qu'il faut alors virer tout le monde. Par contre en rétrospective il pourra être intéressant que l'équipe réfléchisse à comment devenir plus antifragile, car souvent l'absence d'une personne qui a une répercussion forte sur l'atteinte de l'objectif signale un problème de pluridisciplinarité (l'unique expert de..) ou de communication sur ce qu'un tel fait, à commencer à faire... Si tu veux accélérer ou ralentir sur la production de valeur sur le produit, Scrum ne dit pas que ce n'est pas possible. Le PO est redevable de maximiser la valeur par contre, à lui de voir avec le reste de l'équipe s'il utilise son budget pour plus de monde pour accélérer ou pas.

@JfD_xUp

2 ай бұрын

@@jocoign merci pour ta réponse, ça me rassure un peu (n'ayant jamais travailler en Scrum réellement)

@ScrumLife

20 күн бұрын

@JfD_xUp Merci pour ton commentaire détaillé ! 🙌 Ta critique de Scrum est vraiment enrichissante et soulève des points essentiels. Il est vrai que la rigidité perçue de Scrum peut parfois sembler contradictoire avec l'esprit d'agilité que l'on cherche à insuffler dans les équipes. Cependant, il y a des nuances intéressantes à explorer. Le cadre Scrum, bien que structuré, est conçu pour encourager l'adaptation continue via les rétrospectives et les ajustements constants. La flexibilité peut parfois sembler limitée, mais beaucoup trouvent qu'elle offre un équilibre entre structure et adaptation, notamment pour des équipes cherchant à améliorer leur collaboration et leurs processus. Tu mentionnes SAFe et Lean comme des alternatives potentiellement plus adaptables et visionnaires. Je serais curieux de savoir comment tu les as intégrés dans tes projets et quelles différences notables tu as observées en termes de résultat et de satisfaction des parties prenantes. Pour ce qui est de la "chaîne de valeur" et de l'innovation, c'est une conversation continue que nous avons entre praticiens. Comment évaluer la véritable valeur ajoutée est en effet un challenge constant. Hâte de lire ton retour d'expérience plus en détail ! Quelle a été ta plus grande réussite avec Lean ou SAFe ? À bientôt ! Robin 🚀

Sans

@ScrumLife

2 ай бұрын

Sans quoi ? :) -- Constantin

@ScrumLife

20 күн бұрын

Salut @th3Machin3s ! 👋 Merci pour ton commentaire, mais il semble qu'il manque quelque chose. 🤔 N'hésite pas à développer ta pensée ou poser tes questions, je suis là pour échanger et t'aider sur tout ce qui touche à l'agilité en entreprise ! 🚀 À très bientôt, Robin #ScrumLife #Agilité #Entreprise

ça me rappelle cette vidéo: kzread.info/dash/bejne/X2Gkuqh9qLeTmpM.html ;-)

@ScrumLife

19 күн бұрын

Merci @davidravigneaux4541 pour le partage de cette vidéo ! 🎥 C'est toujours intéressant de voir différents points de vue sur les approches agiles. La diversité des perspectives peut vraiment enrichir nos pratiques. Qu'as-tu pensé de cette autre vidéo ? As-tu trouvé d'autres insights qui pourraient compléter ce qu'on a discuté dans la nôtre ? Hâte de te lire ! Robin