Merci pour ton commentaire, @matthieusaunier4519 ! Heureux que la vidéo t'ait plu 😊. Si tu as des questions précises sur les pratiques agiles ou Scrum, n'hésite pas à les poser ici. C'est toujours enrichissant d'échanger avec la communauté et de creuser des sujets qui vous intéressent. À ton avis, quel aspect de l'agilité en entreprise mérite plus d'attention dans nos futures vidéos ? Au plaisir d'échanger 😊 - Robin
SAFE n'est il pas là pour permettre aux strates organisationnelles qui ont toujours eu le contrôle de reprendre la main? En tous les cas dans les grands groupe en sens bien que beaucoup de gens se sont senti rassuré par cette reprise d'un fonctionnement top top-down. Je dis ça je dis rien...
Pensez vous qu'il soit opportun de faire cohabiter plusieurs framework dans une même entreprise? Par exemple du SAFE pour le développement embarqué et du scrum pour la partie Cloud ?
Oui, bien sûr : c'est même à chaque équipe d'affiner son cadre de travail pour l'adapter au mieux à son contexte. Attention tout de même à SAFe qui a la prétention de cadrer le fonctionnement de toute l'entreprise. Si deux équipes doivent collaborer sur le même produit, il est certainement mieux de soit les intégrer dans le même train SAFe, soit de ne pas utiliser SAFe pour les deux équipes et d'utiliser d'autres moyens pour cadrer leur collaboration. Si les deux équipes n'ont presque rien à voir ensemble, ou du moins ont une "API" claire, on peut essayer de les considérer comme des équipes pleinement indépendantes ce qui amènera à plus d'agilité. -- JP
@@ScrumLife SAFe dit qu'il y a un équilibre à trouver entre l'architecture intentionnelle (specific guidelines) produit par les architectes pour assurer la performance, l'utilisabilité de la solution à long terme. Et le design émergent des équipes qui étend et améliore l'architecture pour supporter le delivery des features..
Un contresens d'école ou buzz à clic ? Hello, en parlant d'agilité si on parle de souplesse au sens premier (lool ...), effectivement le Framework SAFe peut paraître manquer de souplesse (il y a des rôles et des cérémonies définis ....) car il doit apporter un cadre "Agile" pour de grandes organisations ... et orienter les efforts de l'organisation en réponse à des enjeux communs ... en vue de délivrer la valeur attendue par l'organisation. Maintenant si on parle plus sérieusement d'agilité telle que défini dans le Manifeste Agile (et non pas la version Larousse ou autre ...) le framework Safe est en pleine cohérence avec le Manifeste, on pourrait certes lui reprocher un moindre alignement sur l'adaptation au changement mais il s'agit d'une nécessaire adaptation dans le cadre d'une mise à l'échelle quelque soit le framework "à l'échelle". A l'échelle il est nécessaire que les équipes prennent des engagements entre elles et sur plusieurs sprints. Alors oui, en permettant d'allouer ses investissements sur ce qui apporte le plus de valeur à l'entreprise, SAFe fait preuve d'adaptabilité, de souplesse ... euh pardon d'Agilité ...
Chacun voit midi à sa porte, et l'adéquation qui l'arrange entre SaFe et le manifeste pour le développement Agile de logiciels. Mais ceux qui ont déjà eu l'occasion d'expérimenter vraiment l'Agilité savent ce que représentent les valeurs et les principes du manifeste. Et SaFe est très loin d'y satisfaire, en premier lieu à cause de sa structure en strates. Mais encore une fois, chacun est libre d'interpréter les choses comme il le souhaite, c'est juste dommage de prendre le parti de la provocation comme vous le faîtes. Je vous souhaite de tout cœur de trouver les clés de compréhension qui vous manquent manifestement.
Houla houla !!!! SAFe serait Lean ?? J'vais me mettre en colère hein !! :p Bon, étant au travail je ne vais pas m'étendre. Mais un PI c'est 5 sprints de deux semaines (enfin d'après les recommandations), soit un stock de 10 semaines de production !! Rien que ça c'est déjà pas super Lean. Et puis bon, la place donnée au client dans le poster est beaucoup trop ridicule pour une démarche Lean qui le placerait devant tout. Je ne parle pas non plus de la place donnée à l'amélioration continue pour laquelle le Lean utilise à outrance le PDCA prônant l'expérimentation. Comment expérimenter quoi que ce soit dans un cadre aussi fermé et qui apporte déjà tant de "solutions" ? Bref, bravo pour cette vidéo (j'ai quand même mis un pouce bleu) car l'analyse est tout à fait pertinente. Mais désolé je ne pouvais pas laisser passer cette phrase sans rien dire :p
@@ScrumLife ça dépend pour qui :) Pour le service commercial de vente de certification, je pense que c'est une très bonne chose. Pour les entreprises qui pensent pouvoir bénéficier de la performance du Lean en achetant ces certifs, j'en suis moins sûr. :)
Yoann Lheudé je suis tout à fait d’accord avec toi, et c’est justement ce que je reproche à S@fe : être une boîte à outils nous dédouanant de penser par nous même notre travail. Tout problème a sa solution dans S@fe et on le voit très bien dans tes propos. Sauf que le Lean, ce n’est pas de simples outils à appliquer. Le Lean, c’est d’abord et avant tout une manière de penser son travail. Comment créer davantage de valeur pour le client ? Comment mettre chacun en capacité de créer de la qualité ? Comment créer un flux continu de valeur tiré par la demande du client ? Comment permettre à chacun de contribuer à l'amélioration des produits et des processus tous les jours ? Bref, il y a des outils dans le Lean bien entendu, mais ils ne sont là que pour soutenir une démarche bien plus efficace. S@fe n’est lui qu’un set d’outil à appliquer. Vous avez un problème? S@fe a la solution, inutile de chercher par vous-même ;-) Après je respecte tout à fait les idées de chacun hein, je n’expose que mon humble avis :-)
Yoann ça m'intéresse tout ce que tu racontes, je t'ai envoyé une invitation LinkedIn pour qu'on en discute en privé ! Sinon si tu es plutôt Twitter mes DM sont ouverts. Ou alors écris-moi directement à jp@scrumlife.tv (spoiler : on cherche des gens qui ont un avis positif sur SAFe) -- JP
Bel échange ! SAFe est basé sur Lean non sur Agile donc la question est quelques peu biaisé :-) Encore une fois tout dépend de l'implémentation et surtout de comment les personnes accueillent ces changements et comment elles sont accompagnées dans cette transformation.
En effet SAFe est basé avant tout sur du Lean, mais le manifeste agile apparait aussi dans la documentation. Certaines personnes fusionnent même les deux mouvements pour l'appeler Lean-Agile. De ton côté, quelles différences fais-tu entre les deux ?
Intéressantes approches ! Cependant, en réaction, I&A constitue la rétro de la couche programme et Portfolio. Et l'exploratoire qu'une équipe fait en stretch objective (ou en PI Objective) alimente le collectif SA-SE-PM et donc le solution intent... Et on oublie que ce qui porte SAFe c'est le value chain (avec lequel on construit le train) et je vois beaucoup d'organisations qui implémentent le modèle un peu à l'envers. Et bien souvent c'est là que ça bloque...
Bonjour et merci pour ces compléments d'information très intéressant. Tu as l'air calé sur le sujet et favorable à SAFe, serais-tu dispo pour en échanger ? Je pense t'avoir envoyé une invitation LinkedIn, mais j'ai toujours pu me tromper de profil auquel cas n'hésite pas à faire le premier pas ! -- JP
L'identification de la value chain convient principalement à la démarche DevOps et de manière générale, aux démarches d'industrialisation. Même si Agilité et DevOps se marient bien, les deux démarches ne doivent pas être confondues. Mais vous touchez le cœur du problème : le souhait d'industrialiser les cadres agiles, ce qui aliène l'Agilité. Quant à considérer l'I&A comme une rétrospective, je ne peux que donner mon ressenti : c'est pour moi une imposture sans nom puisqu'en aucun cas elle ne permet une inspection collective et centrée autour de valeurs partagées, comme on le ferait en Scrum. Mais encore une fois, personne ne possède l'ultime vérité et SaFe jouant sur les ambiguïtés, chacun peut même y trouver des idées intéressantes, moi le premier. Merci en tout cas pour la réaction !
Découvrez toute la communauté Scrum Life ! 👉 sl.run/JSgKWW
Encore une discussion très intéressante. Merci pour vos lumières 😊
Merci pour ton commentaire, @matthieusaunier4519 ! Heureux que la vidéo t'ait plu 😊. Si tu as des questions précises sur les pratiques agiles ou Scrum, n'hésite pas à les poser ici. C'est toujours enrichissant d'échanger avec la communauté et de creuser des sujets qui vous intéressent.
À ton avis, quel aspect de l'agilité en entreprise mérite plus d'attention dans nos futures vidéos ?
Au plaisir d'échanger 😊
- Robin
SAFE n'est il pas là pour permettre aux strates organisationnelles qui ont toujours eu le contrôle de reprendre la main? En tous les cas dans les grands groupe en sens bien que beaucoup de gens se sont senti rassuré par cette reprise d'un fonctionnement top top-down. Je dis ça je dis rien...
Pensez vous qu'il soit opportun de faire cohabiter plusieurs framework dans une même entreprise? Par exemple du SAFE pour le développement embarqué et du scrum pour la partie Cloud ?
Oui, bien sûr : c'est même à chaque équipe d'affiner son cadre de travail pour l'adapter au mieux à son contexte.
Attention tout de même à SAFe qui a la prétention de cadrer le fonctionnement de toute l'entreprise. Si deux équipes doivent collaborer sur le même produit, il est certainement mieux de soit les intégrer dans le même train SAFe, soit de ne pas utiliser SAFe pour les deux équipes et d'utiliser d'autres moyens pour cadrer leur collaboration.
Si les deux équipes n'ont presque rien à voir ensemble, ou du moins ont une "API" claire, on peut essayer de les considérer comme des équipes pleinement indépendantes ce qui amènera à plus d'agilité.
-- JP
@@ScrumLife Merci beaucoup
Alister Cockburn appelle cela du Dead Scrum et Jihn Gweriness Water-Scrum-Fall... soyez sérieux les gars! WTF is wrong au Pays des Lumières???
L architecture émerge dans la solution intent .
Pourriez-vous nous en dire plus ?
@@ScrumLife SAFe dit qu'il y a un équilibre à trouver entre l'architecture intentionnelle (specific guidelines) produit par les architectes pour assurer la performance, l'utilisabilité de la solution à long terme. Et le design émergent des équipes qui étend et améliore l'architecture pour supporter le delivery des features..
Un contresens d'école ou buzz à clic ?
Hello, en parlant d'agilité si on parle de souplesse au sens premier (lool ...), effectivement le Framework SAFe peut paraître manquer de souplesse (il y a des rôles et des cérémonies définis ....) car il doit apporter un cadre "Agile" pour de grandes organisations ... et orienter les efforts de l'organisation en réponse à des enjeux communs ... en vue de délivrer la valeur attendue par l'organisation. Maintenant si on parle plus sérieusement d'agilité telle que défini dans le Manifeste Agile (et non pas la version Larousse ou autre ...) le framework Safe est en pleine cohérence avec le Manifeste, on pourrait certes lui reprocher un moindre alignement sur l'adaptation au changement mais il s'agit d'une nécessaire adaptation dans le cadre d'une mise à l'échelle quelque soit le framework "à l'échelle". A l'échelle il est nécessaire que les équipes prennent des engagements entre elles et sur plusieurs sprints. Alors oui, en permettant d'allouer ses investissements sur ce qui apporte le plus de valeur à l'entreprise, SAFe fait preuve d'adaptabilité, de souplesse ... euh pardon d'Agilité ...
Chacun voit midi à sa porte, et l'adéquation qui l'arrange entre SaFe et le manifeste pour le développement Agile de logiciels. Mais ceux qui ont déjà eu l'occasion d'expérimenter vraiment l'Agilité savent ce que représentent les valeurs et les principes du manifeste. Et SaFe est très loin d'y satisfaire, en premier lieu à cause de sa structure en strates. Mais encore une fois, chacun est libre d'interpréter les choses comme il le souhaite, c'est juste dommage de prendre le parti de la provocation comme vous le faîtes. Je vous souhaite de tout cœur de trouver les clés de compréhension qui vous manquent manifestement.
Houla houla !!!! SAFe serait Lean ?? J'vais me mettre en colère hein !! :p
Bon, étant au travail je ne vais pas m'étendre. Mais un PI c'est 5 sprints de deux semaines (enfin d'après les recommandations), soit un stock de 10 semaines de production !! Rien que ça c'est déjà pas super Lean.
Et puis bon, la place donnée au client dans le poster est beaucoup trop ridicule pour une démarche Lean qui le placerait devant tout. Je ne parle pas non plus de la place donnée à l'amélioration continue pour laquelle le Lean utilise à outrance le PDCA prônant l'expérimentation. Comment expérimenter quoi que ce soit dans un cadre aussi fermé et qui apporte déjà tant de "solutions" ?
Bref, bravo pour cette vidéo (j'ai quand même mis un pouce bleu) car l'analyse est tout à fait pertinente. Mais désolé je ne pouvais pas laisser passer cette phrase sans rien dire :p
Serais-tu en train de dire que l'aspect Lean de SAFe est aussi une imposture ?
@@ScrumLife ça dépend pour qui :)
Pour le service commercial de vente de certification, je pense que c'est une très bonne chose.
Pour les entreprises qui pensent pouvoir bénéficier de la performance du Lean en achetant ces certifs, j'en suis moins sûr. :)
Yoann Lheudé je suis tout à fait d’accord avec toi, et c’est justement ce que je reproche à S@fe : être une boîte à outils nous dédouanant de penser par nous même notre travail.
Tout problème a sa solution dans S@fe et on le voit très bien dans tes propos.
Sauf que le Lean, ce n’est pas de simples outils à appliquer. Le Lean, c’est d’abord et avant tout une manière de penser son travail. Comment créer davantage de valeur pour le client ? Comment mettre chacun en capacité de créer de la qualité ? Comment créer un flux continu de valeur tiré par la demande du client ? Comment permettre à chacun de contribuer à l'amélioration des produits et des processus tous les jours ?
Bref, il y a des outils dans le Lean bien entendu, mais ils ne sont là que pour soutenir une démarche bien plus efficace. S@fe n’est lui qu’un set d’outil à appliquer. Vous avez un problème? S@fe a la solution, inutile de chercher par vous-même ;-)
Après je respecte tout à fait les idées de chacun hein, je n’expose que mon humble avis :-)
Yoann ça m'intéresse tout ce que tu racontes, je t'ai envoyé une invitation LinkedIn pour qu'on en discute en privé ! Sinon si tu es plutôt Twitter mes DM sont ouverts. Ou alors écris-moi directement à jp@scrumlife.tv (spoiler : on cherche des gens qui ont un avis positif sur SAFe) -- JP
Bel échange !
SAFe est basé sur Lean non sur Agile donc la question est quelques peu biaisé :-)
Encore une fois tout dépend de l'implémentation et surtout de comment les personnes accueillent ces changements et comment elles sont accompagnées dans cette transformation.
En effet SAFe est basé avant tout sur du Lean, mais le manifeste agile apparait aussi dans la documentation. Certaines personnes fusionnent même les deux mouvements pour l'appeler Lean-Agile. De ton côté, quelles différences fais-tu entre les deux ?
Une image vaut mille mots il parait :-)
Pas de moi certes mais cela me parle parfaitement!
twitter.com/henrikkniberg/status/1180109277349994496?s=21
Je vois 2 littéraires qui discutent et se plaisent à s'écouter parler. La question reste sans réponse.
Intéressantes approches ! Cependant, en réaction, I&A constitue la rétro de la couche programme et Portfolio. Et l'exploratoire qu'une équipe fait en stretch objective (ou en PI Objective) alimente le collectif SA-SE-PM et donc le solution intent... Et on oublie que ce qui porte SAFe c'est le value chain (avec lequel on construit le train) et je vois beaucoup d'organisations qui implémentent le modèle un peu à l'envers. Et bien souvent c'est là que ça bloque...
Bonjour et merci pour ces compléments d'information très intéressant. Tu as l'air calé sur le sujet et favorable à SAFe, serais-tu dispo pour en échanger ? Je pense t'avoir envoyé une invitation LinkedIn, mais j'ai toujours pu me tromper de profil auquel cas n'hésite pas à faire le premier pas ! -- JP
L'identification de la value chain convient principalement à la démarche DevOps et de manière générale, aux démarches d'industrialisation. Même si Agilité et DevOps se marient bien, les deux démarches ne doivent pas être confondues. Mais vous touchez le cœur du problème : le souhait d'industrialiser les cadres agiles, ce qui aliène l'Agilité.
Quant à considérer l'I&A comme une rétrospective, je ne peux que donner mon ressenti : c'est pour moi une imposture sans nom puisqu'en aucun cas elle ne permet une inspection collective et centrée autour de valeurs partagées, comme on le ferait en Scrum. Mais encore une fois, personne ne possède l'ultime vérité et SaFe jouant sur les ambiguïtés, chacun peut même y trouver des idées intéressantes, moi le premier. Merci en tout cas pour la réaction !
Il ne faut pas confondre agileté, et agilité. Rien à voir.
Merci pour votre intervention vous m'avez refait ma soirée ! 😂
agileté = facilité à se mouvoir. Rien à voir avec Agilité. C'est un contresens.
Un contresens d'école ou buzz à clic ?