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