1h = 40 US / features chiffrées. Merci JP. Ca donne de la visibilité aux dev sur le futur du projet et ça va nous permettre de communiquer sur une estimation du calendrier de nos futurs sprints. L'atelier est très bon enfant j'ai adoré l'animer.
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 ✌️
Super idée, faut que j'essaye ça! mon exp de poker planning c'est qu'on met environ 3h pour estimer un backlog avec une petite équipe de 2, c'est long ^^
Content que cette technique se soit développée ! En Nouvelle Zélande, ils avaient un autre atelier pour le même cas. Ils donnaient une story au premier développeur qui la place sur le tableau. Le deuxième développeur a le choix entre prendre une nouvelle story, ou déplacer une story sur la table et expliquer son point de vue. De mon expérience : effet similaire, un peu plus lent, avec plus d'échanges structurés et moins de self organisation. SI vous l'essayez, je suis intéressé par vos retours...
Bonjour ! De mon côté on ne pratique pas ce type d'atelier...Nous nous rapprochons d'un sprint planning classique, et ce, lors de nos "missions de cadrage" dont la finalité est l'émission d'une propale. Pour cela, contrainte du distanciel... Solution trouvée => Lors du cadrage, généralement 2j (pour les sujets "standards" passés avec les représentants du métier, on dégrossit le sujet et on rédige les niveaux "epics" et features (parfois US sur certains sujets si suffisamment petits mais ce n'est pas notre objectif...). On les liste dans un tableau. Pour l'estimation => Présentation des epics et features par le PO, puis passage en revue par l'équipe des epics et features avec estimations mises en face. On arrive à faire l'exercice en environ 02h00, le niveau de granularité étant je pense plus fin que celui que vous prenez en exemple, et on part parfois "trop" dans la technique et les considérations fonctionnelles existentielles... Cette approche d'effort de recette est-elle vraiment suffisamment "fine" pour avoir une estimation pas trop éloignée de la réalité ? (moins de 30% de delta) Un exemple => Partage sur les réseaux sociaux : Le client sera-t-il prêt à faire des compromis fonctionnels ? Si on se dit que sur cette fonctionnalité le client a de fortes chances de ne pas vouloir revenir dessus, alors autant le prendre en compte directement et l'affiner un peu plus pour diminuer le risque d'écart non ? Désolé du pavé et merci quoi qu'il en soit pour vos vidéos ! =D
Bonjour ! Merci pour ce partage. Quel est le niveau de description minimal et acceptable pour présenter une US lors d'un Extrem Quotation ? juste une User Story ? pas de critères d'acceptation ? Pas de détails complémentaires ?
D'expérience on en met le moins possible et les personnes posent des questions pendant l'atelier pour éclaircir. Le but c'est d'aller à l'essentiel, et de n'avoir que les conversations nécessaires. Donc on n'interdit pas d'avoir ces éléments mais on ne les met pas sur la carte dont la présentation se veut la plus succincte possible 😉 C'est avant tout un grand moment d'échange, mais animer de manière à être super efficace ! Comptes-tu essayer d'utiliser cet atelier prochainement ? -- JP
@@ScrumLife Merci pour ta réponse ! 4 ans après avoir posté la vidéo. C'est une idée qu'on a avec le scrum master de l'équipe pour préparer les PI Planning auxquels nous assistons. J'envisage de l'utiliser d'ici 1 ou 2 PI Planning, le temps de creuser l'idée et de faire mouche auprès de l'équipe :D étant donné que nous ne sommes pas habitués à ce type de pratique, j'ajouterais bien une règle pour écrire les questions en suspens sur ce type d'atelier. Une colonne "Café" aussi pour qu'un équipier puisse dire "Je ne suis pas capable d'estimer cet item de backlog". Qu'en penses-tu ?
L'atelier a l'air vraiment extra ! Je pense l'essayer prochainement. Petite question : dans une équipe avec des BAs, ceux-ci participent-ils à l'estimation ?
J'ai envie de te répondre "bien sûr !" mais pour être sûr je vais plutôt te poser une autre question : quel est le rôle des BA dans ton équipe ? Pour reprendre le référentiel Scrum : - Le "Product Owner" et le "Scrum Master" ne participent pas à l'estimation sauf s'ils sont aussi des "Developers" de la "Scrum Team" - Tous les "Developers" participent à l'estimation Finalement, l'atelier ne change rien, c'est comme avec le Poker Planning et les autres estimations agiles : ua-cam.com/video/NZxcqei5qIE/v-deo.html Attention, je parle de là de l'action d'estimer et non pas de participer à l'atelier. On veut bien sûr que le Product Owner soit présent à l'atelier même s'il n'estime pas. -- JP
Une question : Les estimations reflètent la complexité des tests ok. Comment fais-tu pour faire le lien avec les estimations de complexité "classiques" d'implémentation par planning poker ?
Je le connaissais sous le nom d"Estimations magiques" (vu en formation chez Agilbee). J'avoue tout de même avoir quelques doutes. Cela me paraît top afin de permettre les échanges, de faire connaissance avec le produit après je m'intérrroge surtout sur la qualité des estimations. A tester.
Aucun soucis, il s'agit d'un échange :-) Par défaut, une estimation est fausse. Je crains juste qu'elle ne soit archi fausse. Ceci dit il est vrai que les erreurs liées à celles-ci se lissent sur le temps... Comme je le disais, c'est à tester et après tout être Agile c'est avoir le goût des nouvelles expériences.
Pour mieux te répondre, peux-tu expliciter ce que tu entends par "estimation SWAG" ? Une recherche rapide m'indique quelque chose d'assez différent... Merci d'avance ! -- JP
@@ScrumLife Le SWAG est, sous VersionOne, une estimation rapide qu'on a l'habitude de faire, mais rarement, pour donner une valeur brute d'effort afin de prioriser des features de même importance selon les product manager. Ainsi après cette estimation rapide, certaines features sont mises en avant et d'autres déclassées. L'estimation SWAG est vraiment très très rapide et grossière, c'est pour cela que je trouve que cela se rapproche de l'extreme quotation.
Une grosse limite à cette pratique souvent sous-estimée : plus un produit avance, plus il avance lentement. Ce qui prend 2h à dev à ce moment de vie de produit prendra certainement 2-3j 6 mois plus tard car il y aura eu entre temps plus de fonctionnalités et d'interactions à gérer (sans parler de la spec qui changera également). Pour ca que cet atelier est complétmeent obsolète et dangereux sur une échelle de temps supérieure à 1 mois. (On se rapproche là d'ailleurs d'un sacro saint principe de Kanban : tout ce stock d'US chiffrée périme très vite en temre de spec, scope et de tous les élements qui servent à la chiffrer, il faut absolument le minimiser).
En effet ! L'information donnée est valable à l'instant T. C'est donc tout l'intérêt de minimiser le temps passé, d'où cet atelier. Mais oui cela ne doit pas occulter la pertinence limitée des estimations. Merci pour ce complément ! -- JP
Franchement je vois pas l'intérêt d'estimer l'intégralité d'un PB. Pour moi les macro estimer numériquement n'a pas de réel intérêt si c'est pour les placer sur une valeur absolue lambda liée à la façon dont on recette ou tout autre moyen. Estimer n'a surtout d'intérêt que si on les places de manière relatives les unes par rapport aux autres. Est ce que A est plus/autant/moins complexe que B... Et pour moi encore l'intérêt d'une user story c'est d'avoir une conversation donc si on ne peut pas avoir un minimum de discussion sur ce qui est attendu je ne vois pas bien en quoi ça a de l'intérêt... jouer à pile ou face la valeur à attribuer...
En fait, ca pose la question de "pourquoi on estime ?". AMHA, l'estimation en planning poker est avant tout un outil de conversation et d'alignement. Peut importe que la Dev Team mette 3 ou 21, l'important c'est que l'équipe soit alignée sur une estimation, à travers une conversation. Bref, la valeur de la carte est sans importance. En Extreme Quotation / Magic Estimate, l'important c'est de donner un ordre de grandeur à la louche au PO sans gaspiller de temps. C'est quand même intéressant pour lui de savoir si son idée de produit risque d'occuper la Dev Team plutôt sur 3 mois ou sur 10 mois. Côté REX, j'ai vu des estimations en EQ d'une précision incroyable, car avec la lois des grands nombres, à l'occasion des séances de raffinage suivantes, un item à 5 passe à 8, un autre item à 13 passe à 8... et l'un dans l'autre, ça s'équilibre super bien. L'équipe à laquelle je pense avait estimé 300 points et livré 303 points 6 mois plus tard.
Bonjour Elsa, (juste pour le débat :D ) Après un achat sur internet, qui n'a pas, pour premier réflèxe, d'aller voir la date de livraison ? N'est-ce pas énervant de commander (tjs sur internet) un lave-vaisselle (ou autre) et de voir un transporteur vous dire "Je vous livre Samedi entre 08:30 et 18:00 ?" Vous faites-quoi dans ce cas là ? Soit vous gâchez votre Samedi en le passant à la fenêtre pour guetter le transporteur soit vous tentez une négo pour un passage "planifié et personnalisé" => en tant que client, vous mettez la pression sur votre fournisseur ! Dans la vraie vie, il y a (malheureusement) toujours des contraintes temporelles ! L'idée de ne pas faire d'estimation est séduisante ... mais cela n'existe pas tout simplement parceque les clients en ont ! (un salon, une démo, un lancement ...). Scrum répond à cette problèmatique, non pas en gommant cette contrainte mais en l'acceptant et en changeant l'angle du traitement. Au lieu de dire : "on a une contrainte temporelle, il faut donc faire vite", Scrum dit "on a une contrainte temporelle, il faut donc faire mieux (au sens "valeur apportée") ". Bref, on a toujours besoin d'un planning (oui "besoin" ! ... pas forcément pour l'équipe de dev ... mais au moins, pour rassurer le client/management). Comment soulager, sans prendre trop de temps sur la production de valeur, un management ou un client qui demande une roadmap, une date de mise en production ou qui stresse en l'absence de planning ? La seule façon, pour le Scrum Master, c'est, (si j'ose employer des termes ITIL :b) 1. traiter l'incident en lui en donnant un planning (et comment ne pas passer trop de temps à sa confection ? ... en utilisant l'ExtremQuotation) et ; 2. traiter le problème en faisant de la pédagogie. Franck PS : Courage aux équipes Agiles prises en étau entre le bon sens du mindset Agile et la réalité du monde d'aujourd'hui.
Et du coup en répondant à ce type de demande pressante par ce type d'atelier qui aura une fiabilité relative je pense. Le Scrum Master ne se tire-t-il pas une balle dans le pied plutôt que de faire de "l'éducation"?
Bonjour Elsa, Dans un sens, oui, tu as raison sur 2 points : 1. sur la fiabilité relative et 2. "il se tire une balle dans le pied" s'il ne fait pas "d'éducation". Donner la roadmap et ne pas expliquer que ce n'est pas fiable, pas " utile" pour les devs et pourquoi, c'est comme faire un serious game sans faire de debriefing pour remettre le jeu dans lea réalité. Il n'est pas question ici, de systématiquement produire une roadmap mais de pouvoir en créer une quand elle est "nécessaire" sans dépenser trop d'efforts. L'idée de donner une roadmap à un client/manager est de le dé-stresser et de le remettre en état d'écoute. Il est ansi plus à même d'entendre, plus ouvert à nos arguments contre les planifications excessives et lointaines. :) Passe un bon Dimanche. Franck
Merci pour cette clarification du paradoxe "besoin d'estimations (pour le client) alors que ça n'aide en rien la Dev Team". "équipes Agiles prises en étau entre le bon sens du mindset Agile et la réalité" => Oui, c'est le cas de la majorité. On "fait de l'Agile", on "fait du Scrum" dans une organisation encore très command & control et waterfall.
Découvrez toute la communauté Scrum Life ! 👉 sl.run/sDBBFo
1h = 40 US / features chiffrées. Merci JP. Ca donne de la visibilité aux dev sur le futur du projet et ça va nous permettre de communiquer sur une estimation du calendrier de nos futurs sprints. L'atelier est très bon enfant j'ai adoré l'animer.
Super et génial ! Merci du retour.
Je suis ému devant autant de pragmatisme, belle leçon )
Avec plaisir ! Vas-tu utiliser cet atelier ?
-- JP
A essayer prochainement ! Merci @ScrumLife
Salut Yoann,
Merci beaucoup pour ton commentaire ! 🚀 On est ravis de savoir que la vidéo t'a donné envie d'essayer ces techniques. C'est un premier pas crucial vers une organisation plus agile ! 😉
N'hésite surtout pas à revenir nous dire comment ça s'est passé pour toi et ton équipe. As-tu déjà pensé à quel événement ou type de backlog tu pourrais tester ces améliorations en premier ? 😊
À très bientôt sur Scrum Life !
Robin ✌️
Super idée, faut que j'essaye ça!
mon exp de poker planning c'est qu'on met environ 3h pour estimer un backlog avec une petite équipe de 2, c'est long ^^
Content que cette technique se soit développée !
En Nouvelle Zélande, ils avaient un autre atelier pour le même cas. Ils donnaient une story au premier développeur qui la place sur le tableau. Le deuxième développeur a le choix entre prendre une nouvelle story, ou déplacer une story sur la table et expliquer son point de vue.
De mon expérience : effet similaire, un peu plus lent, avec plus d'échanges structurés et moins de self organisation.
SI vous l'essayez, je suis intéressé par vos retours...
Je te donne un retour lundi :D
Bonjour !
De mon côté on ne pratique pas ce type d'atelier...Nous nous rapprochons d'un sprint planning classique, et ce, lors de nos "missions de cadrage" dont la finalité est l'émission d'une propale.
Pour cela, contrainte du distanciel...
Solution trouvée => Lors du cadrage, généralement 2j (pour les sujets "standards" passés avec les représentants du métier, on dégrossit le sujet et on rédige les niveaux "epics" et features (parfois US sur certains sujets si suffisamment petits mais ce n'est pas notre objectif...).
On les liste dans un tableau. Pour l'estimation => Présentation des epics et features par le PO, puis passage en revue par l'équipe des epics et features avec estimations mises en face.
On arrive à faire l'exercice en environ 02h00, le niveau de granularité étant je pense plus fin que celui que vous prenez en exemple, et on part parfois "trop" dans la technique et les considérations fonctionnelles existentielles... Cette approche d'effort de recette est-elle vraiment suffisamment "fine" pour avoir une estimation pas trop éloignée de la réalité ? (moins de 30% de delta)
Un exemple => Partage sur les réseaux sociaux : Le client sera-t-il prêt à faire des compromis fonctionnels ? Si on se dit que sur cette fonctionnalité le client a de fortes chances de ne pas vouloir revenir dessus, alors autant le prendre en compte directement et l'affiner un peu plus pour diminuer le risque d'écart non ?
Désolé du pavé et merci quoi qu'il en soit pour vos vidéos ! =D
Merci pour ce partage. Je connaissais pas et ça va économiser beaucoup de temps à mon PO et dev team.
Bonjour !
Merci pour ce partage. Quel est le niveau de description minimal et acceptable pour présenter une US lors d'un Extrem Quotation ? juste une User Story ? pas de critères d'acceptation ? Pas de détails complémentaires ?
D'expérience on en met le moins possible et les personnes posent des questions pendant l'atelier pour éclaircir. Le but c'est d'aller à l'essentiel, et de n'avoir que les conversations nécessaires.
Donc on n'interdit pas d'avoir ces éléments mais on ne les met pas sur la carte dont la présentation se veut la plus succincte possible 😉
C'est avant tout un grand moment d'échange, mais animer de manière à être super efficace !
Comptes-tu essayer d'utiliser cet atelier prochainement ?
-- JP
@@ScrumLife Merci pour ta réponse ! 4 ans après avoir posté la vidéo.
C'est une idée qu'on a avec le scrum master de l'équipe pour préparer les PI Planning auxquels nous assistons.
J'envisage de l'utiliser d'ici 1 ou 2 PI Planning, le temps de creuser l'idée et de faire mouche auprès de l'équipe :D
étant donné que nous ne sommes pas habitués à ce type de pratique, j'ajouterais bien une règle pour écrire les questions en suspens sur ce type d'atelier. Une colonne "Café" aussi pour qu'un équipier puisse dire "Je ne suis pas capable d'estimer cet item de backlog". Qu'en penses-tu ?
quel est la rapport entre point d'effort et jours/homme ?
L'atelier a l'air vraiment extra ! Je pense l'essayer prochainement. Petite question : dans une équipe avec des BAs, ceux-ci participent-ils à l'estimation ?
J'ai envie de te répondre "bien sûr !" mais pour être sûr je vais plutôt te poser une autre question : quel est le rôle des BA dans ton équipe ?
Pour reprendre le référentiel Scrum :
- Le "Product Owner" et le "Scrum Master" ne participent pas à l'estimation sauf s'ils sont aussi des "Developers" de la "Scrum Team"
- Tous les "Developers" participent à l'estimation
Finalement, l'atelier ne change rien, c'est comme avec le Poker Planning et les autres estimations agiles : ua-cam.com/video/NZxcqei5qIE/v-deo.html
Attention, je parle de là de l'action d'estimer et non pas de participer à l'atelier. On veut bien sûr que le Product Owner soit présent à l'atelier même s'il n'estime pas.
-- JP
tellement kiffant
Une question : Les estimations reflètent la complexité des tests ok. Comment fais-tu pour faire le lien avec les estimations de complexité "classiques" d'implémentation par planning poker ?
Je le connaissais sous le nom d"Estimations magiques" (vu en formation chez Agilbee). J'avoue tout de même avoir quelques doutes. Cela me paraît top afin de permettre les échanges, de faire connaissance avec le produit après je m'intérrroge surtout sur la qualité des estimations. A tester.
Aucun soucis, il s'agit d'un échange :-) Par défaut, une estimation est fausse. Je crains juste qu'elle ne soit archi fausse. Ceci dit il est vrai que les erreurs liées à celles-ci se lissent sur le temps... Comme je le disais, c'est à tester et après tout être Agile c'est avoir le goût des nouvelles expériences.
Moi je dirais plutôt que par défaut une estimation est juste alors qu'un chiffrage peut être faux :-)
Merci
Puis-je avoir ton avis des différences entre estimation SWAG et Extreme Quotation ?
Pour mieux te répondre, peux-tu expliciter ce que tu entends par "estimation SWAG" ? Une recherche rapide m'indique quelque chose d'assez différent... Merci d'avance !
-- JP
@@ScrumLife Le SWAG est, sous VersionOne, une estimation rapide qu'on a l'habitude de faire, mais rarement, pour donner une valeur brute d'effort afin de prioriser des features de même importance selon les product manager. Ainsi après cette estimation rapide, certaines features sont mises en avant et d'autres déclassées. L'estimation SWAG est vraiment très très rapide et grossière, c'est pour cela que je trouve que cela se rapproche de l'extreme quotation.
Une grosse limite à cette pratique souvent sous-estimée : plus un produit avance, plus il avance lentement. Ce qui prend 2h à dev à ce moment de vie de produit prendra certainement 2-3j 6 mois plus tard car il y aura eu entre temps plus de fonctionnalités et d'interactions à gérer (sans parler de la spec qui changera également). Pour ca que cet atelier est complétmeent obsolète et dangereux sur une échelle de temps supérieure à 1 mois. (On se rapproche là d'ailleurs d'un sacro saint principe de Kanban : tout ce stock d'US chiffrée périme très vite en temre de spec, scope et de tous les élements qui servent à la chiffrer, il faut absolument le minimiser).
En effet ! L'information donnée est valable à l'instant T. C'est donc tout l'intérêt de minimiser le temps passé, d'où cet atelier. Mais oui cela ne doit pas occulter la pertinence limitée des estimations.
Merci pour ce complément !
-- JP
S'il y a quelque chose à retenir de cet épisode: "c'est très bien d'être flou" ;)
Franchement je vois pas l'intérêt d'estimer l'intégralité d'un PB. Pour moi les macro estimer numériquement n'a pas de réel intérêt si c'est pour les placer sur une valeur absolue lambda liée à la façon dont on recette ou tout autre moyen. Estimer n'a surtout d'intérêt que si on les places de manière relatives les unes par rapport aux autres. Est ce que A est plus/autant/moins complexe que B... Et pour moi encore l'intérêt d'une user story c'est d'avoir une conversation donc si on ne peut pas avoir un minimum de discussion sur ce qui est attendu je ne vois pas bien en quoi ça a de l'intérêt... jouer à pile ou face la valeur à attribuer...
En fait, ca pose la question de "pourquoi on estime ?". AMHA, l'estimation en planning poker est avant tout un outil de conversation et d'alignement. Peut importe que la Dev Team mette 3 ou 21, l'important c'est que l'équipe soit alignée sur une estimation, à travers une conversation. Bref, la valeur de la carte est sans importance. En Extreme Quotation / Magic Estimate, l'important c'est de donner un ordre de grandeur à la louche au PO sans gaspiller de temps. C'est quand même intéressant pour lui de savoir si son idée de produit risque d'occuper la Dev Team plutôt sur 3 mois ou sur 10 mois. Côté REX, j'ai vu des estimations en EQ d'une précision incroyable, car avec la lois des grands nombres, à l'occasion des séances de raffinage suivantes, un item à 5 passe à 8, un autre item à 13 passe à 8... et l'un dans l'autre, ça s'équilibre super bien. L'équipe à laquelle je pense avait estimé 300 points et livré 303 points 6 mois plus tard.
Bonjour Elsa,
(juste pour le débat :D )
Après un achat sur internet, qui n'a pas, pour premier réflèxe, d'aller voir la date de livraison ?
N'est-ce pas énervant de commander (tjs sur internet) un lave-vaisselle (ou autre) et de voir un transporteur vous dire "Je vous livre Samedi entre 08:30 et 18:00 ?"
Vous faites-quoi dans ce cas là ?
Soit vous gâchez votre Samedi en le passant à la fenêtre pour guetter le transporteur soit vous tentez une négo pour un passage "planifié et personnalisé" => en tant que client, vous mettez la pression sur votre fournisseur !
Dans la vraie vie, il y a (malheureusement) toujours des contraintes temporelles !
L'idée de ne pas faire d'estimation est séduisante ... mais cela n'existe pas tout simplement parceque les clients en ont ! (un salon, une démo, un lancement ...).
Scrum répond à cette problèmatique, non pas en gommant cette contrainte mais en l'acceptant et en changeant l'angle du traitement.
Au lieu de dire : "on a une contrainte temporelle, il faut donc faire vite", Scrum dit "on a une contrainte temporelle, il faut donc faire mieux (au sens "valeur apportée") ".
Bref, on a toujours besoin d'un planning (oui "besoin" ! ... pas forcément pour l'équipe de dev ... mais au moins, pour rassurer le client/management).
Comment soulager, sans prendre trop de temps sur la production de valeur, un management ou un client qui demande une roadmap, une date de mise en production ou qui stresse en l'absence de planning ?
La seule façon, pour le Scrum Master, c'est, (si j'ose employer des termes ITIL :b)
1. traiter l'incident en lui en donnant un planning (et comment ne pas passer trop de temps à sa confection ? ... en utilisant l'ExtremQuotation) et ;
2. traiter le problème en faisant de la pédagogie.
Franck
PS : Courage aux équipes Agiles prises en étau entre le bon sens du mindset Agile et la réalité du monde d'aujourd'hui.
Et du coup en répondant à ce type de demande pressante par ce type d'atelier qui aura une fiabilité relative je pense. Le Scrum Master ne se tire-t-il pas une balle dans le pied plutôt que de faire de "l'éducation"?
Bonjour Elsa,
Dans un sens, oui, tu as raison sur 2 points : 1. sur la fiabilité relative et 2. "il se tire une balle dans le pied" s'il ne fait pas "d'éducation".
Donner la roadmap et ne pas expliquer que ce n'est pas fiable, pas " utile" pour les devs et pourquoi, c'est comme faire un serious game sans faire de debriefing pour remettre le jeu dans lea réalité.
Il n'est pas question ici, de systématiquement produire une roadmap mais de pouvoir en créer une quand elle est "nécessaire" sans dépenser trop d'efforts.
L'idée de donner une roadmap à un client/manager est de le dé-stresser et de le remettre en état d'écoute. Il est ansi plus à même d'entendre, plus ouvert à nos arguments contre les planifications excessives et lointaines. :)
Passe un bon Dimanche.
Franck
Merci pour cette clarification du paradoxe "besoin d'estimations (pour le client) alors que ça n'aide en rien la Dev Team".
"équipes Agiles prises en étau entre le bon sens du mindset Agile et la réalité"
=> Oui, c'est le cas de la majorité. On "fait de l'Agile", on "fait du Scrum" dans une organisation encore très command & control et waterfall.