Bonjour, j’aurai besoin pour aider le PM à créer une roadmap pour le prochain PI ? Quels sont conseils et méthodes/pratiques pouvez-vous me donner pour réaliser cette mission ?
Sans trop connaître ton contexte, je préconiserais de commencer par un arbre des solutions et des opportunités (Opportunity-Solution Tree) de Teresa Torres.
Plus généralement, les méthodes de découverte du besoin (product discovery) sont les plus utiles pour construire une feuille de route.
1 « J'aime »
Hello, alors le premier conseil qui me vient en tête : ne mettez pas de dates 
1 « J'aime »
Je suppose comme hypothèse que tu es dans du SAFe à fond sur le Delivery avec un marché relativement stable.
De mon expérience :
- Si vous avez un contexte de Delivery pur, avec un marché qui est stable voire très stable (ce que j’ai pu vivre avec une boite de plus de 100 ans récemment, donc ça existe encore) : avoir un projet à la fois. Et si c’est pas possible, limiter quand même à un projet à la fois. C’est souvent le soucis numéro 1 des roadmaps Delivery des grands groupes, la gourmandise. Aussi, rendre FACILEMENT visible les dépendances, éviter les paquets de spaghettis comme je vois dans des PI Plannings, quel enfer !
- Pour un contexte avec un marché fluctuent, 100% OST de Teresa Torres comme l’a dit William. Mais faire du SAFe avec du « vrai » discovery, j’ai encore jamais vu malgré mes tentatives de mentorat donc je ne peux pas aider plus. Je l’ai fait en start up, labo d’inno et scale up mais pas pour de plus grandes entreprises.
Bonjour,
Je serai curieuse de creuser davantage votre observation des paquets de spaghettis et comment rendre visible les dépendances.
De mon experience dans une entreprise aussi très gourmande lors de chaque PI planning, mais peut d’énergie est mis sur cette compréhension des dépendances. J’aimerai bien comprendre comment pratico-pratique vous réussissez à éviter l’effet « paquet de spaghetti »?
Dans mon cas précis, la gestion des dépendances se limite à énoncer et lister les dépendances des sujets entre différentes équipes pendant le PI planning. On va parfois détailler de quel type de dépendance il s’agit (dépendance de type solution, développement bloqué, third-party, ou limitation technique). Afficher les dépendances dans un tableau et ça s’arrête la. Les conséquences d’un manque de suivi se retrouve dans des blocker constant dans les mep par exemple.
Sur la gestion des dépendances, je conseillerais de creuser le trio de sujets Team Topologies (topologies d’équipe), Domain-Driven Design (conception pilotée par le domaine métier) et Wardley Mapping (cartographie de Wardley). Il y a une super présentation de leur utilisation conjointe par Suzanne Kaiser : Architecture for Flow.
Julien Topçu aborde le sujet d’une façon similaire dans sa présentation Loi de Conway : lorsque les bonnes pratiques ne suffisent pas.
1 « J'aime »
En pratico pratique ?
Réorganiser les équipes avec comme objectif principal de réduire les dépendances. Et limiter le travail en cours (moins de projets en même temps = moins de dépendances, c’est simplifié mais c’est l’idée)
Cf. exactement ce qu’a dit William sur ce quoi creuser : Wardley Mapping pour visualiser de manière globale notre organisation et la vraie chaine de valeur actuelle, Team Topologies pour réorganiser les équipes et DDD pour liée l’organisation à l’architecture.
Un exemple ici : Architecture for Flow with Wardley Mapping, DDD, and Team Topologies - InfoQ
1 « J'aime »
Un des enjeux est l’alignement des interfaces techniques avec les interfaces organisationnelles : éviter que plusieurs équipes travaillent sur le même produit, et que des équipes travaillent sur plusieurs produits. Il y a donc un enjeu à structurer les produits en cohérence avec les capacités de structuration de l’organisation, et inversement de structurer l’organisation d’une manière cohérente avec la topologie technique recherchée. La réponse ne peut pas être purement managériale, ni purement technique !
Il y a aussi un enjeu à concevoir techniquement les produits d’une manière qui assouplit les contraintes de dépendances entre eux au lieu de les durcir. Pour cela, il faut être attentif à la compatibilité et la rétrocompatibilité des évolutions des composants. L’objectif est de limiter les changements cassants, de bien communiquer autour des ces événements, et de fournir des contournements temporaires qui permettent aux autres équipes de migrer vers la nouvelle version à leur rythme au lieu de subir les impératifs des composants qu’ils utilisent. De la même manière, quand on conçoit un composant qui en utilise d’autres, il est important dans une certaine mesure de découpler son fonctionnement, pour ne pas devoir tout casser à chaque évolution d’une dépendance.
C’est un sujet très vaste et ça dépend beaucoup de quel type de produit on se parle.