Bonsoir à tous,
voilà, je suis scrum master pour la première fois et de plus dans un environement SAFe 
.
J’aurais aimé avoir de retours sur comment préparer le team breakout du PI planning d’un point de vue scrum master, comment orienter ou relancer la recherche de dépendances, challenger pour ne pas se contenter d’en faire la liste, …
Merci d’avance pour votre aide 
Vincent
CA fait bien 3 ans maintenant, j’ai oublié ce qu’est le team breakout 
Du coup j’ai posé ta question à Chat GPT.
Je partage ici la réponse.
Je la lis
Puis je réponds à tout si je me souviens de quelque chose 
Bien sûr, je peux vous donner quelques conseils sur la préparation du team breakout du PI (Program Increment) planning en tant que Scrum Master, en gardant à l’esprit vos responsabilités et vos intérêts. Voici quelques étapes et recommandations :
Comprendre les objectifs du PI Planning : Avant le PI Planning, assurez-vous de comprendre les objectifs globaux du Programme Increment, ainsi que les enjeux spécifiques pour votre équipe. Cela vous aidera à orienter vos discussions lors du team breakout.
Identifier les dépendances : Comme vous l’avez mentionné, la gestion des dépendances est cruciale. Lors du team breakout, encouragez les membres de l’équipe à identifier et à noter toutes les dépendances qui existent entre les éléments du backlog. Ne vous contentez pas de les lister, mais essayez de comprendre leur impact sur la planification et la livraison.
Faciliter la communication : En tant que Scrum Master, votre rôle est de faciliter la communication au sein de l’équipe. Encouragez les membres à discuter ouvertement des dépendances et des risques potentiels. Vous pouvez utiliser des techniques de rétrospective pour favoriser cette communication.
Challengez les solutions : Lorsque des dépendances sont identifiées, ne vous contentez pas de les accepter sans réfléchir. Encouragez l’équipe à proposer des solutions pour les résoudre. Soyez un défenseur de la résolution proactive des dépendances plutôt que de simplement les documenter.
Priorisation et révision : Aidez l’équipe à prioriser les dépendances en fonction de leur impact et de leur urgence. Assurez-vous que les dépendances critiques sont traitées en premier. Révisez régulièrement la liste des dépendances pour vous assurer qu’elle est à jour.
Références et ressources : Pour des informations plus détaillées sur la gestion des dépendances en Scrum et l’organisation du PI Planning, je vous recommande de consulter les sources suivantes :
En ce qui concerne la fiabilité des informations, les sources que je vous ai recommandées sont généralement fiables, en particulier le « Scrum Guide », qui est la référence officielle pour Scrum. Cependant, il est toujours recommandé de consulter plusieurs sources et d’adapter les pratiques à votre contexte spécifique. La fiabilité peut varier en fonction de l’application pratique, de la pertinence et de l’actualité des informations. Assurez-vous de rester informé des dernières pratiques et tendances en gestion de projet Agile.
Merci Christophe pour ta reponse, mais je cherche plutôt des petits tips, pour challenger et relancer les équipes, histoires d’aller au fond des choses.
Ok je me souviens un peu.
Ma théorie sur SAFe c’est celle de l’agilité à l’échelle.
C’est une étape pour quand on n’est pas prêt à Scrum ou toute autre cadre où on peut fonctionner avec une équipe à taille raisonnable.
On passe à l’échelle pour faire face à l’impatience de l’organisation.
Donc, on doit en payer le coût.
Ce coût est observable dans l’apparition de dépendances et des rendez-vous supplémentaires de coordination.
Ca ne répond toujours pas à la question mais ca donne le contexte de mon point de vue.
Pendant le PI planning, chaque équipe fait son « planning » dans son coin sur les gros morceaux de l’incrément (il a encore ses sprints planning pour les petits (le stories).
J’ai toujours cherché à vendre le PI comme le moment où on va essayer de retrouver ces dépendances, ces obstacles qui vont apparaitre dans l’autonomie désirée des équipes du train.
Ce n’est surtout pas le moment pour établir un plan. On n’y planifie pas les epic, les features et encore moins les us des n sprints de l’incrément.
On investigue pour dire « vu qu’on est encore dépendant les un des autres, constatons que pour faire ça dans telles équipes, il faudra, du part du manque d’autonomie et d’indépendance, attendre que cette autre équipe ait livré cela »
C’est du pur Gantt/retroplanning.
Et si on veut être agile mais « à l’échelle » on doit essayer d’être le plus drivé par des « possibilités de livrer » en suivant les opportunités, mais sans se voiler la face et accepter qu’on a encore du waterfall.
Le team breakout sert à ce moment d’échange entre les équipes qui déclarent leurs dépendances.
Il faut avancer, acceptons-les, accordons-nous du temps pour « livrer », profitons des inspections pour voir comment s’améliorer, voir comment dé-scaler, revenir à des équipes à taille humaine optimisées pour passer plus de temps à délivrer qu’à se coordonner.
J’adorai marquer les dépendances avec des ficelles
C’était moche, ça dérangeait. Les dépendances, c’est dérangeant. Les montrer, c’est voir, constater ce qu’on va envisager d’améliorer
Sur le Board
Chaque équipe affiche les éléments qu’ils comptent prendre en charge, mais pas « complètement »
Pas complètement veut dire qu’ils vont attendre du travail fait par une autre équipe, ou qu’ils vont délivrer quelque chose qu’une autre équipe doit utiliser pour finir le travail complet.
Selon cela, ils placent une carte sur leur board, et attendent de rencontrer l’autre équipe pour établir les limites de ce que chacune fait.
On va souvent identifier des tâches d’assemblages aussi.
En tant que « sm » (donc dans une des équipes) aider l’équipe à identifier tout ce dont elle a besoin en amont, tout ce qu’elle pense ne pas faire pour l’objectif complet
être prêt à la discussion pendant le team breakout
Le RTE de son côté animera ce team breakout pour que l’échange se fasse
Merci, ca me permet d’y voir plus clair
J’espère qu’il y aura d’autres réponses. La mienne est guidée par mon interprétation de SAFe et d’une expérience dans un contexte pas idéal (et en plein confinement)
Je n’existe pas, je suis un mirage 
un mirage d’opposum ?