"On a arrêté de penser à la maille de l'objectif du sprint pour penser à la maille de chaque problématique." Cela veut simplement dire qu'on traite plusieurs problématiques en parallèle avec des espaces de temps différents. On itère avec une approche incrémentale et on apprend sur chacune des problématiques en parallèle sur des périodes courtes. On fonctionne en flux continu plutôt qu'en sprint, et c'est essentiellement cette nuance qui nous éloigne de Scrum. Ça ne nous empêche bien évidemment pas de prioriser la bonne problématique en continu sans avoir à développer des fonctionnalités inutiles. 😁 S'il fallait mettre un nom sur notre approche, ce serait plus proche du Lean et du NoEstimates que du Scrum, même si on a quelques rituels en commun. => À dispo pour clarifier notre approche, parce que j'ai l'impression qu'il y a quand même quelques malentendus et/ou incompréhension.
Il y a deux erreurs épistémologiques : - présumer que le post de Rudy raconte fidèlement ce qu'il s'est réellement passé - ré-interpréter son expérience sans y avoir été Les vraies raisons ou plutôt dispositions se cachent fort probablement dans ce qui n'a pas été dit.
On croise beaucoup d'idées préconçues sur Scrum ou l'agilité, c'est pas neuf. Souvent les contraintes de la boite, l'existant (pratiques et outils), la prise en route des sujets causent beaucoup de souffrance à l'application du framework. Les deux cumulés donnent une mauvaise image de "Scrum" parce que trop de gens s'y sont mis par effet de mode, sans réellement essayer d'en avoir la mentalité. Ca ne me surprend pas que les gens, maintenant, toujours par effet de mode, trouvent un moyen de s'en détacher (même si pas réellement), Perso, étant dans une orga qui bosse toujours en retard de phase et avec des contraintes lourdes, j'ai essayé de prendre ce qu'on m'a donné et de tirer la mentalité vers l'agilité. On a eu des ratés, on sait qu'on peut mieux faire, mais l'équipe est satisfaite et les retours des utilisateurs et de l'organisation sont globalement positifs, On n'a pas transcendé Scrum, on fait clairement pas mieux que Scrum, on essaie juste d'en avoir la mentalité avec les limitations qu'on a. 1 cm par 1 cm on y arrivera ^^
"Faut-il "transcender" Scrum ?" Est ce que le question est bien poser? Scrum est un cadre, parfois c'est le meilleur cadre, parfois il faut faire différèrent et c'est mieux. Oui chez nous ont fait mieux sans Scrum qu'avec Scrum, ça ne veut pas dire que nous l'avons "transcendé". De toute façon, à partir du moment où on est capable de mesurer l'impact de chaque changement et qu'on comprend pourquoi on les fait il ne devrait pas y avoir de débat.
J'aime l'agilité et l'amélioration continue, mais je deteste scrum. Dire que Scrum c'est bien parce que "c'est pas le vrai Scrum" n'est pas un argument, l'application fait loi. Si toutes les entreprises "appliquent mal scrum" c'est que scrum est mauvais, de facto. Exemple : La rétrospective par exemple est un concept très mauvais. Une vraie équipe agile se remet en question presque quodiennement. Si il y a un problème ennuyeux qu'il faut résoudre car cela empiète sur l'humeur et la productivité de l'équipe, il faut que l'équipe le résolve maintenant, soit en mettant un point officiel dans l'agenda, à la machine à café, 2 devs se mettent sur un pc, ou un dev prend l'initiative de le corriger etc. La rétro poussent certaines personnes à attendre la fin du sprint pour en parler, et peut etre qu'à l'issue de cette rétro on créera un ticket, qui sera peut etre intégré un jour dans un sprint... "mais oui mais bien sur qu'il faut faire ce que tu dis", oui sauf que le concept même de rétro provoque ce genre de problème et beaucoup de gens le comprennent comme ca. La plannification, pitié. Les gens se réunissent pour parler de 4 ou 5 sujets qui sont assez différents les uns des autres. Pour qu'au final on refasse des réunions pendant le sprint pour parler de ces sujets de manière indépendantes et plus précisément. La bonne méthode : ne pas faire de plannification. Généralement, on sait ce qui est important pour le produit et tout le monde a la roadmap globale an tête (même si elle est mouvante). Certains sujets ont besoin de 2, 3, 4 réunions, faisont les. D'autres ont juste besoin d'une phrase, et qu'on laisse les devs faire leur boulot. Laissez les devs faire leur boulot pitié.
Salut @Monsieur_Anderson, Merci pour ton commentaire et ton point de vue tranché sur les événements de Scrum. C'est toujours enrichissant de voir des avis différents sur ce vaste sujet qu'est l'agilité en entreprise. Je comprends bien tes frustrations face aux rétrospectives et aux plannings. Cependant, je pense que la clé réside dans la compréhension et l'adaptation des principes de Scrum plutôt que leur rejet total. Tu parles de l'importance de résoudre les problèmes sur le moment, et je suis totalement d'accord. En fait, une équipe Scrum mature devrait avoir cette capacité de communication fluide et continue, tout en utilisant les événements Scrum comme des moments structurants pour prendre du recul et ajuster le tir. La rétrospective, par exemple, ne remplace pas les discussions quotidiennes mais les complète en offrant un cadre régulier pour une réflexion plus profonde. Pour la planification, ton point de vue sur la flexibilité et l'adaptation des réunions est pertinent. Scrum ne dicte pas le contenu exact de chaque événement, mais plutôt un cadre flexible où les équipes peuvent s'ajuster en fonction de leurs besoins spécifiques. Une roadmap mouvante, comme tu le mentionnes, est essentielle et devrait être intégrée dans ces événements pour que chacun reste aligné sur les priorités. Je serais curieux de connaître des exemples concrets où tu as vu des approches agiles fonctionner sans les événements formels de Scrum. Peut-être que ça pourrait inspirer d'autres viewers de "Scrum Life" ! Au plaisir d'échanger davantage, Robin
Tres bon sujet ! Il est vrai que Scrum est dévalorisé en ce moment et bien souvent soit pour continuer à travailler comme "avant" ou simplement pour dénigrer une méthode de travail qu'ils utilisent au final toujours. Merci pour cet éclairage !
Merci pour ton commentaire, @brucemacfly ! 🙌 Tu as tout à fait raison, la dévalorisation de Scrum est souvent due à une mauvaise compréhension de ses principes fondamentaux ou à une résistance au changement. Il est crucial de rappeler que Scrum n'est pas une simple méthode, mais une approche pour améliorer la collaboration et l'efficacité de l'équipe. 💡 Si Scrum est parfois mal compris, c’est aussi une opportunité pour nous, agiliste, de réexpliquer ses bénéfices et de partager des expériences réussies. D’ailleurs, est-ce qu’il y a des aspects précis de Scrum que toi ou ton équipe trouvez particulièrement sujets à débat ? Cela pourrait nous inspirer pour de futurs sujets à aborder dans nos vidéos ! 🤔 Merci encore pour ton soutien et n'hésite pas à partager tes réflexions. À très vite pour d'autres discussions passionnantes ! Robin 🚀
8 місяців тому
Scrum à la réputation d'être simple..... Mais il se présente comme un cadre LÉGER, pas SIMPLE. Ça n'est pas la même chose. Ça me fait penser à la nuance qu'on trouve avec le motto d'un de mes meilleurs potes 'la simplicité est la sophistication suprême" (de tonton Léo le gaucher)
L'agilité n'a jamais été une référence du Scrum Guide. Certes, que ce soit Sutherland ou Schwaber, les deux font vite allusion dans leur talk à l'agilité, mais les deux piliers structurant Scrum sont la philosophie empirique et la pensée lean. Il est en fait tout à fait possible de faire une compliance Scrum sans être agile, mais est-ce bien le but ? En fait, la mode en est à dépasser Scrum, Kaizen... Ces mêmes feront demain du copier-coller du modèle Spoty sans se rappeler ce fondamental : Scrum by the book est useless, l'agilité se rattache à un contexte, l'écosystème conditionne pour beaucoup, la démarche si elle n'est pas holistique s'effondrera comme un soufflé, transition sans prise en compte des réalités en amont et au sortir est l'assurance d'un échec... Faire du Scrum, de l'agile à mesure de ce que cela nous apporte, se donner les moyens à mesure qu'on veut bien se donner la peine d'envisager le pourquoi avant le comment... L'agilité est comme Scrum, c'est bien, mais si on ne sait pas pourquoi on y va : ne pas y aller est une réduction manifeste d'un muda potentiel...
Finalement est ce que ca n'est pas lorsque l'équipe s'est dit "comment pourrions nous mieux ceci ou plus cela" au lieu de chercher à se conformer a un cadre (mal compris/interpreté) qu'ils sont parti dans la bonne direction ? :) Ce qui etait l'intention initiale mais c'est peut etre le message a faire passer ;)
Salut @benjaminjakmakian6593, Tu as tout à fait raison ! L'essence même des approches agiles, que ce soit Scrum ou Kanban, c'est de s'adapter en permanence pour s'améliorer. Évidemment, suivre un cadre comme Scrum peut donner une direction et des repères essentiels, surtout au début. Mais en fin de compte, l'idée est que les équipes trouvent leur propre chemin en posant justement ces questions : "Comment pourrions-nous mieux ceci ou plus cela ?" C'est en s'appropriant l'esprit agile et en l'adaptant à son contexte que l'on finit par vraiment avancer. Après tout, l'agilité prône l'inspecter et s'adapter, non ? Quel a été le déclic pour toi, ou pour ton équipe, où vous avez vraiment senti que vous preniez votre propre direction tout en restant fidèles aux valeurs agiles ? Robin P.S. Merci pour ton commentaire, ça fait plaisir de lire des réflexions aussi approfondies ! 😊
Merci à toi pour ton commentaire @Reconversion-pro-et-coaching ! 😊 On a vraiment à cœur de démystifier Scrum et de partager toutes les subtilités qui font la différence dans la pratique. Est-ce qu'il y a des sujets ou des aspects particuliers de Scrum ou d'une autre approche agile que tu aimerais qu'on creuse plus en détails dans nos prochaines vidéos ? On est toujours à l'écoute de vos suggestions pour continuer à vous apporter du contenu pertinent et utile. À bientôt dans la prochaine vidéo, Robin 🚀
Peut-être qu'un des changements à apporter au guide serait de donner l'exemple d'un sprint planning avec une décision de l'objectif de sprint, puis de la durée du sprint, et enfin seulement du backlog, un peu comme ça avait été involontairement fait avec le daily. Ca pourrait peut-être réduire les adoptions trop rigides comme on en voit si souvent ?
![Et si Shape Up avait raison de faire des pauses ? [Non]](http://i.ytimg.com/vi/unwBLga6P_E/mqdefault.jpg)
"On a arrêté de penser à la maille de l'objectif du sprint pour penser à la maille de chaque problématique."
Cela veut simplement dire qu'on traite plusieurs problématiques en parallèle avec des espaces de temps différents.
On itère avec une approche incrémentale et on apprend sur chacune des problématiques en parallèle sur des périodes courtes.
On fonctionne en flux continu plutôt qu'en sprint, et c'est essentiellement cette nuance qui nous éloigne de Scrum.
Ça ne nous empêche bien évidemment pas de prioriser la bonne problématique en continu sans avoir à développer des fonctionnalités inutiles. 😁
S'il fallait mettre un nom sur notre approche, ce serait plus proche du Lean et du NoEstimates que du Scrum, même si on a quelques rituels en commun.
=> À dispo pour clarifier notre approche, parce que j'ai l'impression qu'il y a quand même quelques malentendus et/ou incompréhension.
Il y a deux erreurs épistémologiques :
- présumer que le post de Rudy raconte fidèlement ce qu'il s'est réellement passé
- ré-interpréter son expérience sans y avoir été
Les vraies raisons ou plutôt dispositions se cachent fort probablement dans ce qui n'a pas été dit.
On croise beaucoup d'idées préconçues sur Scrum ou l'agilité, c'est pas neuf.
Souvent les contraintes de la boite, l'existant (pratiques et outils), la prise en route des sujets causent beaucoup de souffrance à l'application du framework.
Les deux cumulés donnent une mauvaise image de "Scrum" parce que trop de gens s'y sont mis par effet de mode, sans réellement essayer d'en avoir la mentalité.
Ca ne me surprend pas que les gens, maintenant, toujours par effet de mode, trouvent un moyen de s'en détacher (même si pas réellement),
Perso, étant dans une orga qui bosse toujours en retard de phase et avec des contraintes lourdes, j'ai essayé de prendre ce qu'on m'a donné et de tirer la mentalité vers l'agilité. On a eu des ratés, on sait qu'on peut mieux faire, mais l'équipe est satisfaite et les retours des utilisateurs et de l'organisation sont globalement positifs, On n'a pas transcendé Scrum, on fait clairement pas mieux que Scrum, on essaie juste d'en avoir la mentalité avec les limitations qu'on a.
1 cm par 1 cm on y arrivera ^^
T'en dis quoi toi ? Faut-il "transcender" Scrum ? Quelle est ton expérience ? 👇👇👇
"Faut-il "transcender" Scrum ?"
Est ce que le question est bien poser?
Scrum est un cadre, parfois c'est le meilleur cadre, parfois il faut faire différèrent et c'est mieux.
Oui chez nous ont fait mieux sans Scrum qu'avec Scrum, ça ne veut pas dire que nous l'avons "transcendé".
De toute façon, à partir du moment où on est capable de mesurer l'impact de chaque changement et qu'on comprend pourquoi on les fait il ne devrait pas y avoir de débat.
J'aime l'agilité et l'amélioration continue, mais je deteste scrum. Dire que Scrum c'est bien parce que "c'est pas le vrai Scrum" n'est pas un argument, l'application fait loi. Si toutes les entreprises "appliquent mal scrum" c'est que scrum est mauvais, de facto.
Exemple : La rétrospective par exemple est un concept très mauvais. Une vraie équipe agile se remet en question presque quodiennement. Si il y a un problème ennuyeux qu'il faut résoudre car cela empiète sur l'humeur et la productivité de l'équipe, il faut que l'équipe le résolve maintenant, soit en mettant un point officiel dans l'agenda, à la machine à café, 2 devs se mettent sur un pc, ou un dev prend l'initiative de le corriger etc. La rétro poussent certaines personnes à attendre la fin du sprint pour en parler, et peut etre qu'à l'issue de cette rétro on créera un ticket, qui sera peut etre intégré un jour dans un sprint... "mais oui mais bien sur qu'il faut faire ce que tu dis", oui sauf que le concept même de rétro provoque ce genre de problème et beaucoup de gens le comprennent comme ca.
La plannification, pitié. Les gens se réunissent pour parler de 4 ou 5 sujets qui sont assez différents les uns des autres. Pour qu'au final on refasse des réunions pendant le sprint pour parler de ces sujets de manière indépendantes et plus précisément. La bonne méthode : ne pas faire de plannification. Généralement, on sait ce qui est important pour le produit et tout le monde a la roadmap globale an tête (même si elle est mouvante). Certains sujets ont besoin de 2, 3, 4 réunions, faisont les. D'autres ont juste besoin d'une phrase, et qu'on laisse les devs faire leur boulot. Laissez les devs faire leur boulot pitié.
Salut @Monsieur_Anderson,
Merci pour ton commentaire et ton point de vue tranché sur les événements de Scrum. C'est toujours enrichissant de voir des avis différents sur ce vaste sujet qu'est l'agilité en entreprise.
Je comprends bien tes frustrations face aux rétrospectives et aux plannings. Cependant, je pense que la clé réside dans la compréhension et l'adaptation des principes de Scrum plutôt que leur rejet total.
Tu parles de l'importance de résoudre les problèmes sur le moment, et je suis totalement d'accord. En fait, une équipe Scrum mature devrait avoir cette capacité de communication fluide et continue, tout en utilisant les événements Scrum comme des moments structurants pour prendre du recul et ajuster le tir. La rétrospective, par exemple, ne remplace pas les discussions quotidiennes mais les complète en offrant un cadre régulier pour une réflexion plus profonde.
Pour la planification, ton point de vue sur la flexibilité et l'adaptation des réunions est pertinent. Scrum ne dicte pas le contenu exact de chaque événement, mais plutôt un cadre flexible où les équipes peuvent s'ajuster en fonction de leurs besoins spécifiques. Une roadmap mouvante, comme tu le mentionnes, est essentielle et devrait être intégrée dans ces événements pour que chacun reste aligné sur les priorités.
Je serais curieux de connaître des exemples concrets où tu as vu des approches agiles fonctionner sans les événements formels de Scrum. Peut-être que ça pourrait inspirer d'autres viewers de "Scrum Life" !
Au plaisir d'échanger davantage,
Robin
Tres bon sujet ! Il est vrai que Scrum est dévalorisé en ce moment et bien souvent soit pour continuer à travailler comme "avant" ou simplement pour dénigrer une méthode de travail qu'ils utilisent au final toujours. Merci pour cet éclairage !
Merci pour ton commentaire, @brucemacfly ! 🙌
Tu as tout à fait raison, la dévalorisation de Scrum est souvent due à une mauvaise compréhension de ses principes fondamentaux ou à une résistance au changement. Il est crucial de rappeler que Scrum n'est pas une simple méthode, mais une approche pour améliorer la collaboration et l'efficacité de l'équipe. 💡
Si Scrum est parfois mal compris, c’est aussi une opportunité pour nous, agiliste, de réexpliquer ses bénéfices et de partager des expériences réussies. D’ailleurs, est-ce qu’il y a des aspects précis de Scrum que toi ou ton équipe trouvez particulièrement sujets à débat ? Cela pourrait nous inspirer pour de futurs sujets à aborder dans nos vidéos ! 🤔
Merci encore pour ton soutien et n'hésite pas à partager tes réflexions. À très vite pour d'autres discussions passionnantes !
Robin 🚀
Scrum à la réputation d'être simple..... Mais il se présente comme un cadre LÉGER, pas SIMPLE.
Ça n'est pas la même chose.
Ça me fait penser à la nuance qu'on trouve avec le motto d'un de mes meilleurs potes 'la simplicité est la sophistication suprême" (de tonton Léo le gaucher)
J'ai l'impression qu'il y a des problèmes de régularité sur la luminosité des parties de Constantin. C'est que chez moi ?
L'agilité n'a jamais été une référence du Scrum Guide. Certes, que ce soit Sutherland ou Schwaber, les deux font vite allusion dans leur talk à l'agilité, mais les deux piliers structurant Scrum sont la philosophie empirique et la pensée lean. Il est en fait tout à fait possible de faire une compliance Scrum sans être agile, mais est-ce bien le but ?
En fait, la mode en est à dépasser Scrum, Kaizen... Ces mêmes feront demain du copier-coller du modèle Spoty sans se rappeler ce fondamental : Scrum by the book est useless, l'agilité se rattache à un contexte, l'écosystème conditionne pour beaucoup, la démarche si elle n'est pas holistique s'effondrera comme un soufflé, transition sans prise en compte des réalités en amont et au sortir est l'assurance d'un échec...
Faire du Scrum, de l'agile à mesure de ce que cela nous apporte, se donner les moyens à mesure qu'on veut bien se donner la peine d'envisager le pourquoi avant le comment...
L'agilité est comme Scrum, c'est bien, mais si on ne sait pas pourquoi on y va : ne pas y aller est une réduction manifeste d'un muda potentiel...
Finalement est ce que ca n'est pas lorsque l'équipe s'est dit "comment pourrions nous mieux ceci ou plus cela" au lieu de chercher à se conformer a un cadre (mal compris/interpreté) qu'ils sont parti dans la bonne direction ? :)
Ce qui etait l'intention initiale mais c'est peut etre le message a faire passer ;)
Salut @benjaminjakmakian6593,
Tu as tout à fait raison ! L'essence même des approches agiles, que ce soit Scrum ou Kanban, c'est de s'adapter en permanence pour s'améliorer. Évidemment, suivre un cadre comme Scrum peut donner une direction et des repères essentiels, surtout au début. Mais en fin de compte, l'idée est que les équipes trouvent leur propre chemin en posant justement ces questions : "Comment pourrions-nous mieux ceci ou plus cela ?"
C'est en s'appropriant l'esprit agile et en l'adaptant à son contexte que l'on finit par vraiment avancer. Après tout, l'agilité prône l'inspecter et s'adapter, non ?
Quel a été le déclic pour toi, ou pour ton équipe, où vous avez vraiment senti que vous preniez votre propre direction tout en restant fidèles aux valeurs agiles ?
Robin
P.S. Merci pour ton commentaire, ça fait plaisir de lire des réflexions aussi approfondies ! 😊
Merci à toute l'équipe pour ce travail d'analyse ! c'est parfait d'apporter toutes ces précisions et nuances sur ce qu'est vraiment Scrum.
Merci à toi pour ton commentaire @Reconversion-pro-et-coaching ! 😊 On a vraiment à cœur de démystifier Scrum et de partager toutes les subtilités qui font la différence dans la pratique. Est-ce qu'il y a des sujets ou des aspects particuliers de Scrum ou d'une autre approche agile que tu aimerais qu'on creuse plus en détails dans nos prochaines vidéos ? On est toujours à l'écoute de vos suggestions pour continuer à vous apporter du contenu pertinent et utile.
À bientôt dans la prochaine vidéo,
Robin 🚀
Scrum reste un cadre parmi les nombreux cadres agiles…à chacun d’adopter le cadre qui convient le mieux au contexte
Peut-être qu'un des changements à apporter au guide serait de donner l'exemple d'un sprint planning avec une décision de l'objectif de sprint, puis de la durée du sprint, et enfin seulement du backlog, un peu comme ça avait été involontairement fait avec le daily. Ca pourrait peut-être réduire les adoptions trop rigides comme on en voit si souvent ?
Bravo à l’équipe !
Comme tjs, c’est du contenu de qualité faisant progresser la conscience, les principes, mes valeurs et les pratiques agiles 👍