Super vidéo comme toujours. :) Pour Scrum, on a la mauvaise pratique avec du ScrumBut. Pour SAFe, c'est la même chose à l'échelle. Je partage l'opinion en ajoutant un truc : quand on multiplie le nombre d'interlocuteurs en les cloisonant à un rôle, c'est compliqué de chercher l'amélioration continue. Quand le système n'est pas simple et qu'il repose sur des éléments trop rigides, comment se l'approprier à l'échelle humaine et l'améliorer ? L'Agile à l'échelle si on peut s'en passer, c'est mieux. Il faut peut-être revenir à ce qu'on attend de tels frameworks et rechercher des solutions plus simples.
Pour moi, la réponse est claire : si vous êtes en SAFe, alors allez *jusqu'au bout* du framework et en particulier exigez bien le "Inspect & Adapt" meeting qui doit avoir lieu à la fin de chaque PI et avec une partie rétrospective. Utilisez ce moment pour challenger en profondeur vos manières de travailler et pas juste pour corriger des problèmes d'exécution -- que vous pouvez certainement adresser à un autre moment. Utilisez ce moment pour résoudre les problèmes qui méritent une intervention collective de tout le train. Qu'en penses-tu ? -- JP
Complètement d'accord que le pb vient des personnes qui "achètent" le framework et non le framework lui-même. Mais la cible commerciale prioritaire (mais certes pas unique) de SAFe, c'est justement des personnes/organisations qui partent du niveau 0 de compréhension de l'Agilité et qui sont réfractaires à l'empirisme, à l'auto-organisation et à la "bottom-up intelligence" (sinon ils s'intéresseraient à des frameworks volontairement moins structurés). Alors ?
Peut-être une vidéo pour lancer la discussion, mais je ne comprends pas pourquoi tu as choisi de prendre le problème sous l'angle "bien ou pas bien ?"... Chacun est libre de choisir sa méthode, mais il aurait été sans doute plus intéressant d'établir si SaFe est un framework compatible avec le Manifeste pour le développement agile de logiciel... Et en l’occurrence, non ! Et la démonstration de cet état de fait ouvre la porte à une analyse un peu plus poussée de pourquoi la mise en place de SaFe est un échec... Voire montrer que ce framework porte lui-même ses propres paradoxes qui le rendent inutilisable. Un prochain épisode peut-être ?
Salut Jean-Pierre, très bon épisode puisque je suis en train de vivre exactement ça en ce moment dans ma boîte 😅 (gros mastodonte). On nous demande à tous les collaborateurs de passer une certification SAFE, on a ainsi le droit à 2 jours de formation suivi de la certif. Ce qui est drôle c'est que pour la plupart des collaborateurs je pense, beaucoup ne connaissent ni l'agilité ni scrum 🙄. Ça me semble pourtant nécessaire pour comprendre SAFE qu'en penses tu?
Je n'ai pas de réponse absolue, mais si on est médisant on pourrait dire que c'est le conflit d'intérêt avec le business des certifications.
5 лет назад+1
Je connais encore mal SAFe mais tout est dans la première citation. C'est une boîte à outils. Et elle ne peut rien faire pour ceux qui enfoncent des vis avec un marteau
Tout à fait, et avant de prendre un outil dans la boîte, c'est mieux de se poser la question de savoir ce qu'on attends de cette outil et si c'est le mieux adapté. Et on hésite pas à créer nos propres outils ou aller voir dans la boîte du voisin si y'a pas un meilleur outils pour notre problème :)
Idéalement oui on ferait un épisode sur chaque je pense, à voir. Par contre objectivement SAFe occupe une telle place (en volume) que s'il ne fallait en parler que d'un c'est de SAFe. C'est comme Scrum : ce serait top de parler par exemple d'XP mais en termes de volume il fallait bien commencer par Scrum.
@@ScrumLife SAFe LeSS Nexus... plutôt que penser en épisode pourquoi ne pas penser en playlist de plusieurs épisodes et découper? Bon j'ai peut être mal cherché mais je ne suis pas encore tombé sur ce que je cherche : une présentation assez complète de tout ça :) En tout cas je suis avec intérêt votre chaine depuis un moment. C est la meilleure chaine francophone que j ai trouvé jusqu ici! Vous avez un Discord a tout hasard?
Le vrai problème est la résistance au changement, la transparence fait peur. J'ai une super expérience de 3 ans dans une value stream internationale. SAFe est un très très bon framework. je regrette seulement que l'on soit obligé de passer par les certifications...
Le retour de l'éternel problème des certifications... Sans vouloir remettre en question le framework, s'il est question de certifier les gens pour qu'ils soient aptent à le mettre en place, pourquoi pas, mais dans ce cas les certifications devraient être données par un unique organisme (histoire d'éviter ce qui s'est fait avec scrum et les fameuses "certifications agile"). Certifier qu'une personne est apte à mettre en place un cadre de travail, OK. Mais de là à certifier que tous les protagonistes auront le bon mindset, c'est hautement risqué. Et c'est justement là que se pose le problème des grosses organisations: comment envisager le risque financier d'une telle transformation ? Du coup, j'ai une question très simple: est-il réellement plus simple de gérer un budget plutôt que de l'humain ?
Le framework safe apporte une visibilité aux donneurs d’ordres ce qui est un parallélisme avec les méthodes séquentielles rassurantes. Les ressources techniques... sont mobilisées, mais les mentalités, routines anciennes à changer ne changent pas, ou marginalement, au final, on livre une solution fonctionnelle, à laquelle manque cruellement la magie, la fluidité de la créativité spontanée des petites équipes...
Le gros intérêt de SAFe, c'est l'alignement des tous les acteurs sur la stratégie d'entreprise, et sa diffusion à tout les acteurs, le sens. Et son plus gros problème, c'est que les grosses boites sous le contrôle des achats reproduisent leurs conneries à l'échelle : du scrum au forfait pour toutes les équipes ! Pourtant il y a tout un laïus sur le sujet sur le site SAFe.
Comment expliquez-vous l'écart entre la "théorie" de SAFe où on retrouve bien de bonnes choses, et la mise en pratique ? À quel moment perd-t-on le "sens" du framework ?
Découvrez toute la communauté Scrum Life ! 👉 sl.run/ydr1un
Merci pour tous ces retours d'experiences. Bravo pour ce partage 😊
Si tu veux plus de contenu sur Safe… reste connecté, une analyse fine de la version 6.0 arrivera peut être bientôt ;) Robin
"Waw maintenant on livre en 4 mois au lieu d'un an" super, on livre n'importe quoi 2 fois plus vite... ^^
J'ai mis un pouce bleu même si du coup c'est 3 fois plus vite et pas 2 ;p
Merci pour ta latitude :-p
Super vidéo comme toujours. :)
Pour Scrum, on a la mauvaise pratique avec du ScrumBut. Pour SAFe, c'est la même chose à l'échelle.
Je partage l'opinion en ajoutant un truc : quand on multiplie le nombre d'interlocuteurs en les cloisonant à un rôle, c'est compliqué de chercher l'amélioration continue. Quand le système n'est pas simple et qu'il repose sur des éléments trop rigides, comment se l'approprier à l'échelle humaine et l'améliorer ?
L'Agile à l'échelle si on peut s'en passer, c'est mieux. Il faut peut-être revenir à ce qu'on attend de tels frameworks et rechercher des solutions plus simples.
Pour moi, la réponse est claire : si vous êtes en SAFe, alors allez *jusqu'au bout* du framework et en particulier exigez bien le "Inspect & Adapt" meeting qui doit avoir lieu à la fin de chaque PI et avec une partie rétrospective. Utilisez ce moment pour challenger en profondeur vos manières de travailler et pas juste pour corriger des problèmes d'exécution -- que vous pouvez certainement adresser à un autre moment. Utilisez ce moment pour résoudre les problèmes qui méritent une intervention collective de tout le train.
Qu'en penses-tu ?
-- JP
Complètement d'accord que le pb vient des personnes qui "achètent" le framework et non le framework lui-même. Mais la cible commerciale prioritaire (mais certes pas unique) de SAFe, c'est justement des personnes/organisations qui partent du niveau 0 de compréhension de l'Agilité et qui sont réfractaires à l'empirisme, à l'auto-organisation et à la "bottom-up intelligence" (sinon ils s'intéresseraient à des frameworks volontairement moins structurés). Alors ?
Excellente analyse ! Bravo et merci :)
Merci ! Pratiques-tu SAFe toi-même ? Quelle est ton expérience ?
Peut-être une vidéo pour lancer la discussion, mais je ne comprends pas pourquoi tu as choisi de prendre le problème sous l'angle "bien ou pas bien ?"... Chacun est libre de choisir sa méthode, mais il aurait été sans doute plus intéressant d'établir si SaFe est un framework compatible avec le Manifeste pour le développement agile de logiciel... Et en l’occurrence, non ! Et la démonstration de cet état de fait ouvre la porte à une analyse un peu plus poussée de pourquoi la mise en place de SaFe est un échec... Voire montrer que ce framework porte lui-même ses propres paradoxes qui le rendent inutilisable. Un prochain épisode peut-être ?
Salut Jean-Pierre, très bon épisode puisque je suis en train de vivre exactement ça en ce moment dans ma boîte 😅 (gros mastodonte).
On nous demande à tous les collaborateurs de passer une certification SAFE, on a ainsi le droit à 2 jours de formation suivi de la certif. Ce qui est drôle c'est que pour la plupart des collaborateurs je pense, beaucoup ne connaissent ni l'agilité ni scrum 🙄. Ça me semble pourtant nécessaire pour comprendre SAFE qu'en penses tu?
Je n'ai pas de réponse absolue, mais si on est médisant on pourrait dire que c'est le conflit d'intérêt avec le business des certifications.
Je connais encore mal SAFe mais tout est dans la première citation.
C'est une boîte à outils.
Et elle ne peut rien faire pour ceux qui enfoncent des vis avec un marteau
Tout à fait, et avant de prendre un outil dans la boîte, c'est mieux de se poser la question de savoir ce qu'on attends de cette outil et si c'est le mieux adapté. Et on hésite pas à créer nos propres outils ou aller voir dans la boîte du voisin si y'a pas un meilleur outils pour notre problème :)
Ça aurait été pas mal de présenter un peu safe au début!
En effet, avec le recul c'est une évidence... Je crois qu'on n'a pas le choix : il faudra faire un épisode dédié à la présentation de SAFe.
@@ScrumLife Avec LeSS ou Nexus ou autre en miroir alors ?
Idéalement oui on ferait un épisode sur chaque je pense, à voir. Par contre objectivement SAFe occupe une telle place (en volume) que s'il ne fallait en parler que d'un c'est de SAFe.
C'est comme Scrum : ce serait top de parler par exemple d'XP mais en termes de volume il fallait bien commencer par Scrum.
@@ScrumLife Howi ! Un épisode sur chaque scaling framework, puis un qui les compare :)
@@ScrumLife SAFe LeSS Nexus... plutôt que penser en épisode pourquoi ne pas penser en playlist de plusieurs épisodes et découper? Bon j'ai peut être mal cherché mais je ne suis pas encore tombé sur ce que je cherche : une présentation assez complète de tout ça :) En tout cas je suis avec intérêt votre chaine depuis un moment. C est la meilleure chaine francophone que j ai trouvé jusqu ici! Vous avez un Discord a tout hasard?
Le vrai problème est la résistance au changement, la transparence fait peur. J'ai une super expérience de 3 ans dans une value stream internationale. SAFe est un très très bon framework. je regrette seulement que l'on soit obligé de passer par les certifications...
Le retour de l'éternel problème des certifications... Sans vouloir remettre en question le framework, s'il est question de certifier les gens pour qu'ils soient aptent à le mettre en place, pourquoi pas, mais dans ce cas les certifications devraient être données par un unique organisme (histoire d'éviter ce qui s'est fait avec scrum et les fameuses "certifications agile").
Certifier qu'une personne est apte à mettre en place un cadre de travail, OK. Mais de là à certifier que tous les protagonistes auront le bon mindset, c'est hautement risqué. Et c'est justement là que se pose le problème des grosses organisations: comment envisager le risque financier d'une telle transformation ?
Du coup, j'ai une question très simple: est-il réellement plus simple de gérer un budget plutôt que de l'humain ?
Le framework safe apporte une visibilité aux donneurs d’ordres ce qui est un parallélisme avec les méthodes séquentielles rassurantes. Les ressources techniques... sont mobilisées, mais les mentalités, routines anciennes à changer ne changent pas, ou marginalement, au final, on livre une solution fonctionnelle, à laquelle manque cruellement la magie, la fluidité de la créativité spontanée des petites équipes...
Le gros intérêt de SAFe, c'est l'alignement des tous les acteurs sur la stratégie d'entreprise, et sa diffusion à tout les acteurs, le sens. Et son plus gros problème, c'est que les grosses boites sous le contrôle des achats reproduisent leurs conneries à l'échelle : du scrum au forfait pour toutes les équipes ! Pourtant il y a tout un laïus sur le sujet sur le site SAFe.
Comment expliquez-vous l'écart entre la "théorie" de SAFe où on retrouve bien de bonnes choses, et la mise en pratique ? À quel moment perd-t-on le "sens" du framework ?