Hello à tous toutes !
J’interviens dans une grosse entreprise IT où la principale difficulté que je rencontre est l’adhérence forte des équipes de DEV à l’écosystème global de l’entreprise.
Des conditions d’acceptance validées ? Ah non, il faut faire une recette transverse avec les systèmes amont et aval et que chacun valide avant d’envisager une livraison
Cibler la meilleure valeur produit en faisant de l’itératif mais s’inscrire dans des road maps à 6 ou 12 mois qui elles ciblent des fonctionnalités précises.
A l’arrivée, un cycle en V qui habille le lotissement de ses fonctionnalités d’habits scrum (sprints, rituels, …) avec un PO qui recouvre peu ou prou le rôle de chef de projet.
Le pire, c’est que la méthode est devenue le cache sexe idéal … « on fait de l’itératif, on peut changer d’avis ». C’est assez démoralisant …
Je ne vois pas de question dans ton message, donc voilà ce que cela m’inspire.
« There is no silver bullet »
Toutes les entreprises ne peuvent être et avoir des comportements collaboratifs, avec une pensée système. C’est une dure réalité. Plus c’est gros, plus c’est lourd !
A ça, existe les 3 réponses à la peur : Se battre, Fuir, ou Paralysé.
Soit je me bats contre des moulins à vent, et avec un assez gros bazooka, sur un coup de chance ça peut marcher.
Soit je fuis et je cherche un endroit qui correspond plus à nos valeurs et croyances.
Soit je suis paralysé devant tout cela et je perds en motivation.
De mon côté, j’ai totalement accepté que beaucoup d’entreprises continueront leur manière de fonctionner. Le système a pris le dessus. Je choisis mes missions et part si je ne peux plus me battre (dans le sens mettre en place des actions positives pour le système).
Salut @Norbert, merci beaucoup pour ce partage !
On va faire une vidéo où on répond à ces questions 
Sur ce thème, ce vieux Scrum Life pourrait apporter un ensemble d’éléments pour avancer.
Même si c’est très incomplet, qu’en pensez-vous ? "C'est hors de notre contrôle !" - Scrum Life 15 - YouTube
Bonjour ! Oui, cette vidéo est un bon point de départ.
Le sujet des OPs est pertinent car dans l’organisation où j’interviens ils ne sont pas hiérarchiquement rattachés à la même entité que les DEVs. Objectifs individuels non alignés, etc … ça peut créer des irritants.
Mais ce n’est pas forcément là que c’est le plus difficile.
C’est plutôt l’alignement des besoins et des différents PO de l’écosystème qui est difficile à obtenir.
Le PO A se préoccupe de sortir SES features, le PO B les siennes , le PO C …
Par contre, A ne se préoccupe de savoir si ses features ont des répercussions / adhérences avec celles de B ou C…
« Ah oui mais c’est compliqué les équipes Scrum sont autonomes » « B ne m’a pas dit que je devais prendre en charge ses contraintes » « Je suis Product Owner, pourquoi dois-je gérer des éléments sur lesquels je n’ai pas la main » …
J’ai mis en place des points entre PO, entre TechLeads … pour faire circuler l’info au mieux. Ca se parle, mais ça créé de l’insatisfaction '« encore une réunion où j’ai rien à faire » « On fait des points mais là je découvre encore que … »
J’ai le sentiment que c’est vraiment compliqué de faire du real scrum dans ces gros écosystemes … à fortiori quand ils sont hétérogènes et hérités d’un passé lointain (culturellement autant que techniquement).
Je reconnais un peu un contexte que j’ai connu dans ce que tu décris.
J’avais envie de partager une expérience dont nous avions beaucoup appris selon moi.
Il me semble que ce qui nous avait le plus rapproché (une équipe Scrum unique (dans tous les sens du terme 
) et ceux qu’on pourrait appeler des PPO, pour simplifier) c’est de gérer une urgence, imprévue et subie par tous où tout le monde avait donc le même objectif, la même problématique à résoudre et n’avait pas le choix car tant que cela n’était pas réglé on ne pouvait adresser aucun autre sujet ! J’avais veillé à focus sur l’objectif sans faire de ‹ chasse à la sorcière ›, nous avions le soutien d’un bon état d’esprit hiérarchique (focus également sur l’objectif). On avait plannifié des points de synchro journaliers, partagé les même difficultés, on était tous tourné vers un objectif commun, on s’est entraidé… on n’avait jamais autant collaboré. J’ai l’impression que ça nous avait fait gagner pas mal de stop dans la collab, la confiance etc. On avait ancré ce qui avait marché avec une rétro et évidemment on avait pris des actions pour s’améliorer tous ensemble.
Collaborer, être agile dans le type de contexte que tu décris, c’est un réel challenge chaque jour je trouve, l’impression qu’on se bat contre une organisation, plutôt que de conjuguer nos efforts, parfois l’impression de David contre Goliath… Je pense que ces contextes sont des machines à casser des SM, des PO, des Dev et de l’humain en général, par manque de compréhension, de courage, de volonté de l’organisation et/ou des acteurs, si on n’y prend pas garde et si on est trop peu réalistes sur la situation et les possibilités.
Ça prend du temps, beaucoup parfois, pour que les choses évoluent.
Garder un rythme tenable dans l’équipe est primordial et même avec un bon soutien hiérarchique/sponsor, le poids de l’organisation, des habitudes peut parfois être oppressant. L’impression aussi de déplacer ce poids sur d’autres épaules alors qu’avec des objectifs communs, on pourrait répartir ce poids (et plus utopiquement ne plus avoir ce poids mais franchement je n’y crois pas dans de gros groupes, par contre je ne demande qu’à ce qu’on me fasse mentir ! Ouep jsuis du genre à avoir de l’espoir).
Et je garde bien mes distances pour ne pas subir cela dans un contexte SAFe (…à l’échelle en général ?!
), pour moi ça ressemble à l’enfer, le combo parfait pour burn out 
mais pareil je ne demande qu’à l’observer et le ressentir par mes propres pores. Par contre j’irai bien vivre une aventure à l’échelle dans une orga qui a vraiment fait sa transfo, ça doit être quelque chose ! Bref, le problème, c’est pas le framework ou la méthode, c’est pas non plus l’organisation, c’est quand le combo n’est pas adapté (comme dans un couple finalement, nan ?)
Je pourrai en dire tellement de choses et ça commence à se voir (et à se savoir 
)… j’ai tendance à m’étendre 
Je vais donc juste ajouter que dans un contexte non scalé, le PO, quand il est un réel membre de l’équipe et qu’il n’a pas tout le pouvoir qu’il devrait, est, je pense, un des rôles qui ‹ trinque › le plus (notamment face aux ‹ PPO › qui défendent leurs projets, leurs objectifs, souvent multiples… et à ce SM qui veut toujours du temps que personne ne veut donner). Protégeons nos PO ! (Cri du cœur d’un SM)
Merci Sophie pour ce partage qui vient du fond du coeur… ça permet aussi de constater que l’on est pas un extra terrestre et que d’autres partagent des situations comparables…
Une des difficultés auxquelles je suis confronté, c’est celle des « arbitrages ».
Arbitrages techniques pour l’essentiel … l’équipe de Dev A propose la solution A, l’équipe B propose une solution B … chacun voyant les avantages de l’une ou l’autre pour son périmètre.
Et au final, c’est l’architecte global qui arbitre, parce que contrainte budgétaire, parce que, parce que …
Bref, frustration des Dev, frustration du PO à qui on donne des limites … et un SM qui se débat entre tout ceci
Sans apporter de réponse.
Intuitivement je fais le lien avec Team Topologies et le principe de Conway.
D’après mon expérience, le code d’une application devrait être modifiée par une seule équipe.
Quand plusieurs équipes sont responsables de la même application alors les décisions d’architectures impact toutes les équipes, et donc aucune décision impactentes ne peut être prises en autonomie.
L’autonomie d’une équipe dépend directement de ses responsabilités. Mais quand ces responsabilités sont partagées alors cette autonomie est ébranlée.
Génial ! Vous avez tapé dans le mille à tous les moments de la vidéo.
Pas de solution miracle, les conseils sont pertinents. A nous de les mettre en œuvre. Il y a du taff !
Je nuancerais juste sur un point : si vous partez sur une approche (tout à fait louable) de « faire plutôt que demander », n’oubliez quand même pas de vous couvrir en prévoyant un plan B au cas où. L’égo d’un dirigeant peut très vite amener à ce qu’une démarche qui était pertinente, preuve à l’appui, soit discréditée par simple ressentiment.