J'ai travaillé avec 2 types de compagnies ayant adopté SAFe. Celle qui a mandaté une compagnie externe pour implémenter le framework (sachant que la culture interne ne connaissait ni Agile ni Scrum). Et celle qui a voulu expérimenter Scrum "from scratch" (parce que "tout le monde ne parle que de cela"), puis après quelques années, a pris peur parce que les équipes devenaient trop autonomes et donc exigeantes (ce qui signifie "contester les vraies valeurs établies") et s'est donc dit : "re-structurons donc tout cela mais sans faire fuir les employés d'un coup". Je ne vous cache pas que le résultat est très mitigé. SAFe est un framework où il est très facile de ne plus se poser de questions ("Suis le train, tout ira bien."), noyé dans les meetings récurrents de planification et coordination multi-équipes, démotivant progressivement la grande majorité des membres. Et pour en plus retomber dans les travers de la planification à outrance pour rassurer via de (fausses) métriques, avec une mesure de la performance basée sur la quantité, et... une Roadmap qui est en fait un Gantt caché. Cela plaît à bien des directions parce que... cela leur permet de faire comme avant mais en utilisant les termes Agile et Scrum. Et le problème majeur que je vois est que de nombreux POs, SMs ou encore DEVs ayant été formés à travers ces types d'organisations "SAFe" manquent ensuite de souplesse pour revenir à du Scrum de base (par exemple) : trop mécanisé et ritualisé, et on leur a appris à éviter de trop se questionner. J'ai quand même eu une équipe (PO et SM inclus) qui m'a dit : "Bah quand on commence un projet, on doit s'asseoir pendant plusieurs jours voir semaines en équipe pour créer tous les items du backlog et créer toutes les sous-tâches reliées pour ensuite les estimer en heures. Ainsi, la direction peut savoir combien de temps le projet va prendre". J'ai ouvert une carte, il y avait un titre vague que personne ne comprenait vraiment, et les tâches étaient du style "Investigation, Do It, Review, PO Sign-off". Et le planning se résumait à prendre les items, maximiser la capacité en temps horaire du Sprint backlog, et les dispatcher aux membres de l'équipe. J'ai eu un grand moment de déprime. Oui, bon, j'avoue, je ventile un peu (désolé) :D
Merci beaucoup pour ce partage ! Malheureusement, l'expérience que tu nous partages ne semble pas isolée. Est-ce que tu penses que cette vidéo, et plus largement nos vidéos sur SAFe, aideront à éviter ce type de situation, aideront les personnes à ne pas accepter sans réfléchir ce mode de fonctionnement ? -- JP
Merci pour cette vidéo thématique intéressante. J'ai déjà eu le tour plusieurs fois en tant que Scrum Master, d'observer une pression de la part de PM qui se sont engagés sur des features (sans impératif législatif) auprès de personnes. Ils ont forcés les équipes à prendre des sujets, qui ont pourtant été embarqué selon leur priorisation, malgré le fait que ça ne rentrait pas, sans vouloir en retirer d'autre. Allant même jusqu'à vouloir challenger les estimations à chaque User Story. Les équipiers, PO pensant à tort que le PM a une position hiérarchique supérieure ("il y a la théorie et la pratique" comme ils disent) : ils ont acceptés. Après tout, ce sont eux qui réalisent et qui estiment pouvoir s'engager... Au final, ils n'ont pas pu délivrer ce qui dépassait à la première estimation, ils ont eu beaucoup de pression tout au long du PI, ont zappé l'innovation du Sprint d'Innovation pour qu'on leur disent qu'ils n'étaient pas bon... Au PI Planning d'après, bah ils ont recommencés malgré des Rétrospectives où le sujet fut abordé et les gens d'accord pour ne plus accepter ce genre de choses... Je passe l'épisode où le PM veut engager l'équipe sur des features avant le PI Planning avec un planning Excel alors que cette feature n'est même pas découpée.... Dans mon histoire, il est important de noter que l'ensemble des participants, doivent non seulement avoir fait la formation, mais surtout avoir l'esprit Agile et surtout ceux des couches supérieurs, ainsi que les décideurs auquel le train doit éventuellement rendre des comptes. Autre point débat : Faut-il préparer un PI Planning et si oui à quel niveau ? Pour expliciter ce point, je prend l'exemple d'un nouvel arrivant qui arrive dans l'équipe au PI Planning (c'est en théorie là que ça commence), mais les User Story sont déjà toutes affinées en amont et non réexpliquées en séance. Quid de l'utilité de cette cérémonie qui va durer à peine une demi-journée de planification ?
Merci pour ce partage 🙏 -- on compatit 😑 Dans ton histoire, on a envie d'accuser le PM, mais j'aurais tendance à dire aussi : il est où le RTE ? Il fait quoi ? Quand est-ce qu'il coache le PM pour qu'il ait une attitude qui permette au système de fonctionner ? Tu m'as compris je pense... Très bon point sur l'intégration des nouveaux, difficile de prendre le train en marche pendant le PI Planning. Mais est-ce grave ? Globalement, quand tu es nouveau dans l'équipe, c'est normal de ne pas tout maîtriser et tu te laisses forcément un peu "porter" par le reste de l'équipe dans un premier temps. L'idée étant que lors de son 2e PI Planning, la personne est pleinement intégrée et au courant des sujets. Après, j'imagine que lorsque l'équipe est seule à faire sa planification d'équipe, elle passera pas mal de temps à tout expliquer au nouveau. Qu'en dis-tu ? -- JP
@@ScrumLife Je suis d'accord avec toi, le point avait été plus ou moins pris en charge par le RTE, mais il a fallu du temps pour que le fait qu'on identifie clairement que la personne qui avait besoin d'accompagnement était le PM (la faute peut-être à la hiérarchie anciennement établie). Sur l'intégration, la théorie voudrait que l'on explique durant la planification les story et les fonctionnalités derrière, mais dans la pratique si tout le monde sauf le nouveau connait le contenu des story, il est peu probable que celle ci soit expliquée. En effet, l'équipe aurait (peut-être) l'impression de refaire une séance d'explication qui a déjà eu lieu en amont du PI Planning. On est donc bien sur l'opposé du principe SAFe qui est qu'une équipe choisisse en séance une feature parmi ceux qu'ont présentés les PM, la comprenne et la découpe puis la planifie sur le PI. Là la feature est "pré-affectée" à une équipe, cette équipe l'a déjà découpée et estimés pour moitié avec le PO en amont. Il ne reste donc plus que l'estimation de la moitié des US qui est faite dans le PI Planning, avant que le PO puisse jouer à ranger ces US dans des cases à points :)
Video intéressante. Bravo pour condenser un pavet aussi lourd dans une vidéo aussi courte. Ce qui arrive à l'équipe Panda ne me semble pas trop réaliste. Entre le début du PI et la fin du PI il y a quand meme de nombreux événements qui donne l'occasion à l'équipe de proposer un changement d'objectifs afin de valider la livraison d'une business value supérieur à celle initiatement engagée (committed) pendant le PI. Il y a 4 iterations reviews, 4 itération demos, 4 PO syncs, 1 demo system et autre. Il me semble ici que l'on montre le résultat d'une équipe Panda qui travaille de facon "Autonome et Isolé" plutot que de facon "Autonome et Synchronisé".
Très bien formulé ! Cet outil devrait être une première étape pour démêler les spaghettis existants et progressivement ne plus avoir de spaghettis du tout, rendant donc l'outil obsolète. Est-ce une cause perdue selon toi ? Trop souvent on voit du SAFe qui s'enferme dans SAFe, et c'est notamment ça qui nous dérange 😥 -- JP
J'aimerais dire que non, que ce n'est pas perdu d'avance mais une fois qu'on a investi autant de temps/énergie/argent, quelles sont les chances qu'on veuille dépiler et simplifier ? #biaisdescoûtsirrécupérables
Hello et bravo pour l'acte courageux de parler de SAFe ;). Par ailleurs, je ne suis pas aligné avec votre approche de "Ne pas prédir l'avenir" car si on s'en tient à SAFe, l'alignement se fait à travers les objectifs de PI donc c'est ce sur quoi l'équipe s'engage. Non pas à suivre un plan mais à se focus sur ces objectifs en alignement avec les BO/PM. Evidemment, je vous rejoins sur le nécessité de pouvoir pivoter suivant les opportunités ou les risques vitaux, mais la réaction de votre "méchant bo" arrive en toute fin de PI, et donc quid du changement de priorité de l'équipe en transparence avec ce BO/PM (whatever) ? Problème de confiance ? Insécurité ?
Ah ! Mais oui, c'est récurrent, il y aura toujours une fois suivante 😁 Tu peux peut-être nous dire dans quelle mesure le PI Planning auquel tu as participé la semaine dernière tombait dans les erreurs que l'on cite, ou si au contraire les conseils que l'on donne étaient appliqués ? Et bien sûr, viens au Live pour partager ton expérience ! -- JP
Hello bonne vidéo ! SAFe est un sacré pavé difficile à résumer (et à mettre en place ^^ je suis en plein dedans). Vous n'abordez pas l'ART Sync (ou Scrum of Scrum et PO Sync) qui est un évènement de synchro important à l'issue d'un PI Planning. Il permet de faire un suivi régulier entre chaque itération du Program Increment, des objectifs pris par les équipes du train lors du PI Planning. C'est un peu le daily scrum meeting du train pour suivre les itérations en cours et à venir du Program Increment, sauf que c'est à la fin de chaque itération :) (pour les lecteurs : ART => Agile Release Train)
Salut, oui comme tu le dis SAFe est un énormé pavé et on est forcément obligé de faire des choix, de ne pas parler de tout. Selon toi, quels sont les sujets les plus mal compris / mal mis en place de SAFe qui mériteraient qu'on en parle en premier ? Merci des compléments en tous cas ! Et n'hésite pas à venir au Live pour partager ton expérience avec la communauté ! -- JP
@@ScrumLife C'est dommage car ça laisse penser à un effet tunnel. Les principales difficultés dans SAFe que j'ai pu rencontrer (et que je rencontre !) : 1) Avant de déballer la grosse artillerie, il est nécessaire d'acculturer les équipes au global sur l'Agilité pour avoir les bases, puis d'amener SAFe par itération. 2) Le passage sur SAFe doit se faire à tous les niveaux (du management au dev, et pas seulement que les dev !) 3) Il faut se donner les moyens, car le passage à SAFe est un énorme changement de paradigme et prend du temps. 4) Aligner les équipes sur une vision produit global Je vais peut être en découvrir d'autres ^^
Chaque sujet en son temps. Excellente cette premiere video sur le Pi. Ma derniere experience sur le sujet est assez cocace. J'y reviendrai ds un prochain post
Bonjour et merci pour cette vidéo très instructive. Nous avons vécu la semaine dernière un PI planning et il me semble que nous sommes tombés dans certaines des choses à ne pas faire... Par exemple définir un plan sur les prochains sprints du prochain pi... Par contre à quoi servent les sessions de team breakout ??? Je pense que j'ai pas tout pigé 🤪
Salut ! Idéalement on voudrait une dynamique similaire à ce que l'on voit en Sprint Planning de Scrum : on rentre dans le détail de comment on va s'y prendre de manière à être relativement confiant sur les objectifs que l'on prend ; ce qui ne veut pas dire que le plan en question est immuable, au contraire on le fera évoluer au fil de l'eau (le Daily étant un moment formel pour détecter le besoin de changer le plan). Donc tout détailler n'est pas un problème en soi, notamment si on n'est pas encore très à l'aise avec l'exercice. Mais il faut être conscient du "gâchis" potentiel que cela représente et normalement à terme avoir un engagement plus au "gut feeling" qu'en essayant de lister exhaustivement ce qu'on imagine de faire. Qu'en dis-tu ? -- JP
@@ScrumLife Oui je vois ce que tu veux dire et je te remercie pour ton explication. Concernant le gâchis potentiel dont tu parles, je comprends sauf que dans notre cas le besoin plutôt global aux pods dans le pi est plutôt immuable. Ce qui n'empêchera pas dans l'absolu de rajouter des choses et d'en enlever d'autres bien que la marge de manœuvre soit assez faible.
J'aimerais mieux me faire scier la jambe avec une cuillère à soupe que de faire du Safe et j'admire votre positivisme. Pour moi, le PI planning c'est la mort du Product Owner, qui devient un "Story Owner". Le PI planning c'est tenter de coordonner des équipes entre eux au lieu d'éliminer les dépendances et maximiser l'autonomie. Par contre, ça rassure les décideurs qu'ils contrôlent bien toute cette affaire.
Oh ! Je t'invite à regarder la vidéo qu'on sort la semaine prochaine ; on parlera du sujet d'un Product Owner qui porte le "discovery" et qui s'en retrouve privé suite à un "passage à l'échelle"... On évoquera donc les différentes alternatives pour "passer à l'échelle" sans enlever la dimension "discovery" des équipes ! Je suis d'accord que ce que tu décris, c'est le SAFe que l'on voit. Le but de cette vidéo est de faire changer ça, d'au moins ouvrir les chakras, que les personnes ne se retrouvent pas enfermées dans un SAFe anti-agile. Est-ce que selon toi cette vidéo dans la bonne direction ? -- JP
@@ScrumLife Merci pour cette tentative. Je pense que c'est effectivement une façon positive de voir les choses et que vous allez dans la bonne direction. Malheureusement je crois que les entreprises qui ont entamé un virage Safe sont déjà allé pendant tellement longtemps (ou avec tellement d'efforts) que de changer la direction pour passer à un adaptatif libérateur réelle au lieu d'une apparence de celle-ci est souvent soit peine perdue ou itérer sur la chandelle en espérant que l'ampoule en découle. Ceci dit, lâchez pas! Bien hâte de voir le prochain épisode!
@Nicolas, tu es pas le seul à penser comme ça. Avoir testé SAFe, je me fis qu’on a trouvé l’excellent moyen de tuer l’autonomie d’une équipe et le rôle du product owner. Je n’adhère absolument pas. Mais je n’ai jamais compris pourquoi j’étais la seule Scrum Master chez le client qui ne soit pas d’accord avec l’approche et qui a du mal avec ça. Tu me rassures que je ne suis pas la seule
@@ghenimamezine5627 c'est le dilemme de la consultation : "si tu ne fais pas partie de la solution, il y a beaucoup d'argent à faire en prolongeant les problèmes" Safe c'est une grosse business, les certifications et les implantations dures de processus et avoir plein "d'experts et de certifications à passer" ça rassure tout le monde qui n'aime pas "tracer le chemin soi-même" qui est la nature de l'adaptatif. Et oui par fois même des rôles proactifs comme Scrum Master on besoin d'être consolé et rassuré.
Ce que je ne comprends pas c que vs avez l'air de dire que l'on ne doit pas "suivre le plan" mais encourager le pivotage pour rechercher la valeur. Du coup n'est ce pas une des definitions du PI, c a dire definir ensemble un plan en vue d' atteindre les objectifs? Un peu comme le sprint planning où on s'aligne sur les obectifs à atteindre et on definit un plan pour y arriver. C ds cette optique qu'on pourra d'ailleurs pivoter par la suite si necessaire par rapport à ces objectifs ?
Ou alors, si j'analyse votre message intrinseque peut être que finalement la vraie valeur du PI planning (serait ce la seule selon vous d'ailleurs :)) reside ds le fait que c le lieu par excellence pour resoudre les dependances ( et non pas seulement "gerer" comme vs expliquez tres bien) . Mais là, je vs laisse libre de proposer un nouveau nom aux createurs de SAFe, le "dependency planning"...fini les plans sur la comète...
Découvre les différentes approches d'agilité à l'échelle 👉 ruclips.net/video/A0alM2OovFk/видео.html
J’ai organisé et coordonné 7 PI plannings en tant que RTE.
Un PI planning est essentiel lorsqu’on est dépendants les uns des autres.
J'ai travaillé avec 2 types de compagnies ayant adopté SAFe. Celle qui a mandaté une compagnie externe pour implémenter le framework (sachant que la culture interne ne connaissait ni Agile ni Scrum). Et celle qui a voulu expérimenter Scrum "from scratch" (parce que "tout le monde ne parle que de cela"), puis après quelques années, a pris peur parce que les équipes devenaient trop autonomes et donc exigeantes (ce qui signifie "contester les vraies valeurs établies") et s'est donc dit : "re-structurons donc tout cela mais sans faire fuir les employés d'un coup". Je ne vous cache pas que le résultat est très mitigé.
SAFe est un framework où il est très facile de ne plus se poser de questions ("Suis le train, tout ira bien."), noyé dans les meetings récurrents de planification et coordination multi-équipes, démotivant progressivement la grande majorité des membres. Et pour en plus retomber dans les travers de la planification à outrance pour rassurer via de (fausses) métriques, avec une mesure de la performance basée sur la quantité, et... une Roadmap qui est en fait un Gantt caché. Cela plaît à bien des directions parce que... cela leur permet de faire comme avant mais en utilisant les termes Agile et Scrum.
Et le problème majeur que je vois est que de nombreux POs, SMs ou encore DEVs ayant été formés à travers ces types d'organisations "SAFe" manquent ensuite de souplesse pour revenir à du Scrum de base (par exemple) : trop mécanisé et ritualisé, et on leur a appris à éviter de trop se questionner.
J'ai quand même eu une équipe (PO et SM inclus) qui m'a dit : "Bah quand on commence un projet, on doit s'asseoir pendant plusieurs jours voir semaines en équipe pour créer tous les items du backlog et créer toutes les sous-tâches reliées pour ensuite les estimer en heures. Ainsi, la direction peut savoir combien de temps le projet va prendre". J'ai ouvert une carte, il y avait un titre vague que personne ne comprenait vraiment, et les tâches étaient du style "Investigation, Do It, Review, PO Sign-off". Et le planning se résumait à prendre les items, maximiser la capacité en temps horaire du Sprint backlog, et les dispatcher aux membres de l'équipe. J'ai eu un grand moment de déprime.
Oui, bon, j'avoue, je ventile un peu (désolé) :D
Merci beaucoup pour ce partage !
Malheureusement, l'expérience que tu nous partages ne semble pas isolée.
Est-ce que tu penses que cette vidéo, et plus largement nos vidéos sur SAFe, aideront à éviter ce type de situation, aideront les personnes à ne pas accepter sans réfléchir ce mode de fonctionnement ?
-- JP
Merci pour cette vidéo thématique intéressante.
J'ai déjà eu le tour plusieurs fois en tant que Scrum Master, d'observer une pression de la part de PM qui se sont engagés sur des features (sans impératif législatif) auprès de personnes.
Ils ont forcés les équipes à prendre des sujets, qui ont pourtant été embarqué selon leur priorisation, malgré le fait que ça ne rentrait pas, sans vouloir en retirer d'autre. Allant même jusqu'à vouloir challenger les estimations à chaque User Story.
Les équipiers, PO pensant à tort que le PM a une position hiérarchique supérieure ("il y a la théorie et la pratique" comme ils disent) : ils ont acceptés. Après tout, ce sont eux qui réalisent et qui estiment pouvoir s'engager...
Au final, ils n'ont pas pu délivrer ce qui dépassait à la première estimation, ils ont eu beaucoup de pression tout au long du PI, ont zappé l'innovation du Sprint d'Innovation pour qu'on leur disent qu'ils n'étaient pas bon...
Au PI Planning d'après, bah ils ont recommencés malgré des Rétrospectives où le sujet fut abordé et les gens d'accord pour ne plus accepter ce genre de choses...
Je passe l'épisode où le PM veut engager l'équipe sur des features avant le PI Planning avec un planning Excel alors que cette feature n'est même pas découpée....
Dans mon histoire, il est important de noter que l'ensemble des participants, doivent non seulement avoir fait la formation, mais surtout avoir l'esprit Agile et surtout ceux des couches supérieurs, ainsi que les décideurs auquel le train doit éventuellement rendre des comptes.
Autre point débat : Faut-il préparer un PI Planning et si oui à quel niveau ? Pour expliciter ce point, je prend l'exemple d'un nouvel arrivant qui arrive dans l'équipe au PI Planning (c'est en théorie là que ça commence), mais les User Story sont déjà toutes affinées en amont et non réexpliquées en séance. Quid de l'utilité de cette cérémonie qui va durer à peine une demi-journée de planification ?
Merci pour ce partage 🙏 -- on compatit 😑
Dans ton histoire, on a envie d'accuser le PM, mais j'aurais tendance à dire aussi : il est où le RTE ? Il fait quoi ? Quand est-ce qu'il coache le PM pour qu'il ait une attitude qui permette au système de fonctionner ? Tu m'as compris je pense...
Très bon point sur l'intégration des nouveaux, difficile de prendre le train en marche pendant le PI Planning. Mais est-ce grave ? Globalement, quand tu es nouveau dans l'équipe, c'est normal de ne pas tout maîtriser et tu te laisses forcément un peu "porter" par le reste de l'équipe dans un premier temps. L'idée étant que lors de son 2e PI Planning, la personne est pleinement intégrée et au courant des sujets. Après, j'imagine que lorsque l'équipe est seule à faire sa planification d'équipe, elle passera pas mal de temps à tout expliquer au nouveau. Qu'en dis-tu ?
-- JP
@@ScrumLife
Je suis d'accord avec toi, le point avait été plus ou moins pris en charge par le RTE, mais il a fallu du temps pour que le fait qu'on identifie clairement que la personne qui avait besoin d'accompagnement était le PM (la faute peut-être à la hiérarchie anciennement établie).
Sur l'intégration, la théorie voudrait que l'on explique durant la planification les story et les fonctionnalités derrière, mais dans la pratique si tout le monde sauf le nouveau connait le contenu des story, il est peu probable que celle ci soit expliquée. En effet, l'équipe aurait (peut-être) l'impression de refaire une séance d'explication qui a déjà eu lieu en amont du PI Planning.
On est donc bien sur l'opposé du principe SAFe qui est qu'une équipe choisisse en séance une feature parmi ceux qu'ont présentés les PM, la comprenne et la découpe puis la planifie sur le PI.
Là la feature est "pré-affectée" à une équipe, cette équipe l'a déjà découpée et estimés pour moitié avec le PO en amont.
Il ne reste donc plus que l'estimation de la moitié des US qui est faite dans le PI Planning, avant que le PO puisse jouer à ranger ces US dans des cases à points :)
Video intéressante. Bravo pour condenser un pavet aussi lourd dans une vidéo aussi courte. Ce qui arrive à l'équipe Panda ne me semble pas trop réaliste. Entre le début du PI et la fin du PI il y a quand meme de nombreux événements qui donne l'occasion à l'équipe de proposer un changement d'objectifs afin de valider la livraison d'une business value supérieur à celle initiatement engagée (committed) pendant le PI. Il y a 4 iterations reviews, 4 itération demos, 4 PO syncs, 1 demo system et autre. Il me semble ici que l'on montre le résultat d'une équipe Panda qui travaille de facon "Autonome et Isolé" plutot que de facon "Autonome et Synchronisé".
Merci pour cette présentation claire et positive des bénéfices que peut apporter un PI planning fidèle aux intentions (et "bien fait"©® 😅). J'aime l'idée qu'il s'agisse là aussi, en effet, d'un outil sur lequel s'appuyer mais dont on devrait arriver à se passer par la suite (dès que possible ?) grâce aux améliorations qu'il aura contribué à apporter/déclencher au niveau de l'orga et de la topologie des équipes/du produit 👍
Très bien formulé ! Cet outil devrait être une première étape pour démêler les spaghettis existants et progressivement ne plus avoir de spaghettis du tout, rendant donc l'outil obsolète.
Est-ce une cause perdue selon toi ? Trop souvent on voit du SAFe qui s'enferme dans SAFe, et c'est notamment ça qui nous dérange 😥
-- JP
J'aimerais dire que non, que ce n'est pas perdu d'avance mais une fois qu'on a investi autant de temps/énergie/argent, quelles sont les chances qu'on veuille dépiler et simplifier ? #biaisdescoûtsirrécupérables
Hello et bravo pour l'acte courageux de parler de SAFe ;). Par ailleurs, je ne suis pas aligné avec votre approche de "Ne pas prédir l'avenir" car si on s'en tient à SAFe, l'alignement se fait à travers les objectifs de PI donc c'est ce sur quoi l'équipe s'engage. Non pas à suivre un plan mais à se focus sur ces objectifs en alignement avec les BO/PM. Evidemment, je vous rejoins sur le nécessité de pouvoir pivoter suivant les opportunités ou les risques vitaux, mais la réaction de votre "méchant bo" arrive en toute fin de PI, et donc quid du changement de priorité de l'équipe en transparence avec ce BO/PM (whatever) ? Problème de confiance ? Insécurité ?
La vidéo arrive en retard pour moi, j’ai eu mon premier PI Planning la semaine dernière 😂
Je prends des notes pour le prochain du coup 👍🏼
Ah ! Mais oui, c'est récurrent, il y aura toujours une fois suivante 😁
Tu peux peut-être nous dire dans quelle mesure le PI Planning auquel tu as participé la semaine dernière tombait dans les erreurs que l'on cite, ou si au contraire les conseils que l'on donne étaient appliqués ?
Et bien sûr, viens au Live pour partager ton expérience !
-- JP
Hello bonne vidéo ! SAFe est un sacré pavé difficile à résumer (et à mettre en place ^^ je suis en plein dedans).
Vous n'abordez pas l'ART Sync (ou Scrum of Scrum et PO Sync) qui est un évènement de synchro important à l'issue d'un PI Planning.
Il permet de faire un suivi régulier entre chaque itération du Program Increment, des objectifs pris par les équipes du train lors du PI Planning.
C'est un peu le daily scrum meeting du train pour suivre les itérations en cours et à venir du Program Increment, sauf que c'est à la fin de chaque itération :)
(pour les lecteurs : ART => Agile Release Train)
Salut, oui comme tu le dis SAFe est un énormé pavé et on est forcément obligé de faire des choix, de ne pas parler de tout.
Selon toi, quels sont les sujets les plus mal compris / mal mis en place de SAFe qui mériteraient qu'on en parle en premier ?
Merci des compléments en tous cas ! Et n'hésite pas à venir au Live pour partager ton expérience avec la communauté !
-- JP
@@ScrumLife C'est dommage car ça laisse penser à un effet tunnel.
Les principales difficultés dans SAFe que j'ai pu rencontrer (et que je rencontre !) :
1) Avant de déballer la grosse artillerie, il est nécessaire d'acculturer les équipes au global sur l'Agilité pour avoir les bases, puis d'amener SAFe par itération.
2) Le passage sur SAFe doit se faire à tous les niveaux (du management au dev, et pas seulement que les dev !)
3) Il faut se donner les moyens, car le passage à SAFe est un énorme changement de paradigme et prend du temps.
4) Aligner les équipes sur une vision produit global
Je vais peut être en découvrir d'autres ^^
Chaque sujet en son temps. Excellente cette premiere video sur le Pi. Ma derniere experience sur le sujet est assez cocace. J'y reviendrai ds un prochain post
Bonjour et merci pour cette vidéo très instructive. Nous avons vécu la semaine dernière un PI planning et il me semble que nous sommes tombés dans certaines des choses à ne pas faire... Par exemple définir un plan sur les prochains sprints du prochain pi... Par contre à quoi servent les sessions de team breakout ??? Je pense que j'ai pas tout pigé 🤪
Combien tu avais d’équipe dans ton PI ?
Salut ! Idéalement on voudrait une dynamique similaire à ce que l'on voit en Sprint Planning de Scrum : on rentre dans le détail de comment on va s'y prendre de manière à être relativement confiant sur les objectifs que l'on prend ; ce qui ne veut pas dire que le plan en question est immuable, au contraire on le fera évoluer au fil de l'eau (le Daily étant un moment formel pour détecter le besoin de changer le plan).
Donc tout détailler n'est pas un problème en soi, notamment si on n'est pas encore très à l'aise avec l'exercice. Mais il faut être conscient du "gâchis" potentiel que cela représente et normalement à terme avoir un engagement plus au "gut feeling" qu'en essayant de lister exhaustivement ce qu'on imagine de faire.
Qu'en dis-tu ?
-- JP
@@ScrumLife Oui je vois ce que tu veux dire et je te remercie pour ton explication. Concernant le gâchis potentiel dont tu parles, je comprends sauf que dans notre cas le besoin plutôt global aux pods dans le pi est plutôt immuable. Ce qui n'empêchera pas dans l'absolu de rajouter des choses et d'en enlever d'autres bien que la marge de manœuvre soit assez faible.
J'aimerais mieux me faire scier la jambe avec une cuillère à soupe que de faire du Safe et j'admire votre positivisme. Pour moi, le PI planning c'est la mort du Product Owner, qui devient un "Story Owner". Le PI planning c'est tenter de coordonner des équipes entre eux au lieu d'éliminer les dépendances et maximiser l'autonomie. Par contre, ça rassure les décideurs qu'ils contrôlent bien toute cette affaire.
Oh ! Je t'invite à regarder la vidéo qu'on sort la semaine prochaine ; on parlera du sujet d'un Product Owner qui porte le "discovery" et qui s'en retrouve privé suite à un "passage à l'échelle"... On évoquera donc les différentes alternatives pour "passer à l'échelle" sans enlever la dimension "discovery" des équipes !
Je suis d'accord que ce que tu décris, c'est le SAFe que l'on voit. Le but de cette vidéo est de faire changer ça, d'au moins ouvrir les chakras, que les personnes ne se retrouvent pas enfermées dans un SAFe anti-agile. Est-ce que selon toi cette vidéo dans la bonne direction ?
-- JP
@@ScrumLife Merci pour cette tentative. Je pense que c'est effectivement une façon positive de voir les choses et que vous allez dans la bonne direction. Malheureusement je crois que les entreprises qui ont entamé un virage Safe sont déjà allé pendant tellement longtemps (ou avec tellement d'efforts) que de changer la direction pour passer à un adaptatif libérateur réelle au lieu d'une apparence de celle-ci est souvent soit peine perdue ou itérer sur la chandelle en espérant que l'ampoule en découle. Ceci dit, lâchez pas! Bien hâte de voir le prochain épisode!
@Nicolas, tu es pas le seul à penser comme ça. Avoir testé SAFe, je me fis qu’on a trouvé l’excellent moyen de tuer l’autonomie d’une équipe et le rôle du product owner.
Je n’adhère absolument pas.
Mais je n’ai jamais compris pourquoi j’étais la seule Scrum Master chez le client qui ne soit pas d’accord avec l’approche et qui a du mal avec ça.
Tu me rassures que je ne suis pas la seule
@@ghenimamezine5627 c'est le dilemme de la consultation : "si tu ne fais pas partie de la solution, il y a beaucoup d'argent à faire en prolongeant les problèmes" Safe c'est une grosse business, les certifications et les implantations dures de processus et avoir plein "d'experts et de certifications à passer" ça rassure tout le monde qui n'aime pas "tracer le chemin soi-même" qui est la nature de l'adaptatif. Et oui par fois même des rôles proactifs comme Scrum Master on besoin d'être consolé et rassuré.
En mode Safe multitrain et en plus dans une équipe transverse à tous, ba on fait tout ce qu’il ne faut pas faire 😂
Ce que je ne comprends pas c que vs avez l'air de dire que l'on ne doit pas "suivre le plan" mais encourager le pivotage pour rechercher la valeur. Du coup n'est ce pas une des definitions du PI, c a dire definir ensemble un plan en vue d' atteindre les objectifs? Un peu comme le sprint planning où on s'aligne sur les obectifs à atteindre et on definit un plan pour y arriver. C ds cette optique qu'on pourra d'ailleurs pivoter par la suite si necessaire par rapport à ces objectifs ?
Ou alors, si j'analyse votre message intrinseque peut être que finalement la vraie valeur du PI planning (serait ce la seule selon vous d'ailleurs :)) reside ds le fait que c le lieu par excellence pour resoudre les dependances ( et non pas seulement "gerer" comme vs expliquez tres bien) . Mais là, je vs laisse libre de proposer un nouveau nom aux createurs de SAFe, le "dependency planning"...fini les plans sur la comète...
Malheureusement c’est très courant. On a tendance à oublier le mot valeur juste pour rester dans la case et respecter à la lettre le PI
SAFe est une plaie.
Ouch ! Ca sent le passif lourd avec SAFe.
Pourrais-tu nous en dire plus ? Quelles ont été tes expériences ?
-- JP