Après 4 ans en tant que Product Owner sur 3 produits composés en moyenne de 5 personnes dans une grande DSI IT, intégrés dans différents trains SAFe, je me suis prêtée à une interview : je vous partage les points clés !
Quelques définitions utiles :
Product Owner (PO) : Le pilote du produit, qui donne la vision et priorise.
Train Scaled Agile Framework (SAFe) : Un regroupement d’équipes Agiles travaillant ensemble avec des objectifs communs dans un cadre Agile.
Release Train Engineer (RTE) : Le facilitateur et coordinateur du train SAFe pour assurer une livraison efficace et alignée avec la valeur.
Agile : Approche de gestion de projet basée sur l'adaptabilité, la collaboration et l'amélioration continue à travers des cycles courts et itératifs.
Scrum : Framework Agile qui repose sur des cycles courts et itératifs, avec une équipe auto-organisée, des rôles définis et des événements structurés.
PI Planning : Événement clé du framework SAFe où toutes les équipes d’un Agile Release Train se réunissent pendant deux jours pour aligner leurs objectifs, planifier les incréments et synchroniser leurs dépendances.
Comment as-tu découvert SAFe et par qui cela t’a-t-il été introduit ?
Sur mon premier produit, l’équipe était déjà en place lorsque je suis arrivée. La Product Owner de l’époque m’a présenté de manière très sommaire le fonctionnement de Scrum et de SAFe, qu’elle n’appréciait pas vraiment. J’ai ensuite approfondi mes connaissances par moi-même, ce qui m’a permis de constater une cohérence entre la théorie et la pratique. Cette compréhension m’a été particulièrement utile par la suite pour mon produit, qui avait de fortes dépendances, lorsque je suis devenue Product Owner.
As-tu rencontré des freins à ton intégration dans une organisation SAFe ? Si oui, à quels moments et pourquoi ?
Au départ, certaines équipes ne voyaient pas l’intérêt de SAFe. Elles préféraient éviter d’être sollicitées et n’adhéraient pas au principe du vote de confiance. J’ai donc voulu me faire ma propre opinion : pourquoi SAFe a-t-il été mis en place ?
J’ai eu la chance d’intégrer un train très accueillant. L'implication, l'écoute et la disponibilité du RTE m'ont permis de m’intégrer facilement au train et de percevoir les bienfaits de ce modèle d'organisation.
Qu’est-ce qui t’a été le plus utile dans SAFe, en premier ?
Lorsque l’on prend un nouveau poste avec un périmètre inédit, SAFe joue un rôle d’accélérateur et de facilitateur.
La gestion des dépendances a été un vrai atout, apportant une meilleure visibilité aux équipes, à la direction et aux utilisateurs. Les différentes instances ont également simplifié mes échanges, et le RTE savait poser les bonnes questions pour clarifier les besoins.
Quelle a été ta pire expérience lors d’un PI Planning ? Comment as-tu réagi et quelles actions as-tu mises en place ?
Lors de mon premier PI Planning, tous les développeurs ont mis la note de 3 au vote de confiance à la fin de la journée, alors même que nous manquions cruellement de ressources, que la charge était trop élevée et que je l’avais remonté lors de précédentes instances du PI Planning. En réalité, ce 3 servait surtout à éviter les questions, mais le manque de volonté de s’impliquer et la remise en question de ma crédibilité m’ont heurtée.
Après réflexion, il me semble que les développeurs n’avaient pas encore créé suffisamment de liens et de confiance pour s’exprimer librement lors du PI Planning, d’où l’importance de favoriser ces connexions pour encourager la remontée des alertes.
Quelles convictions partagerais-tu avec un Product Owner qui intègre un train SAFe ?
Ne pas arriver avec des a priori. Prendre ce qui est utile, questionner ce qui semble moins pertinent et ne pas hésiter à exprimer son point de vue : “Je ne vois pas mon intérêt ici.” Il ne faut pas se forcer à créer un besoin artificiel.
Il est essentiel de bien communiquer avec le RTE, le Product Manager et les Business Owners. D’ailleurs, ces derniers se sont montrés aussi accueillants et présents que le RTE, ce qui a renforcé le sentiment de ne jamais être seule.
Selon toi, quelle est la bonne posture du RTE pour qu’il soit un vrai facilitateur ?
Un bon RTE s’assure toujours qu’un besoin réel est derrière chaque initiative. Il joue un rôle clé dans l’ouverture du dialogue entre les équipes, l’organisation des instances et la gestion des dépendances et des roadmaps. Lors des Scrum of Scrums ou des Product Owner Synchronisations, il garantit des échanges constructifs, avec un timing respecté et sans laisser de questions en suspens.
Si une équipe envisage de quitter un train sans réelle réflexion ni argument, cela peut révéler un problème. Le rôle du RTE est alors essentiel pour assurer la bonne dynamique du train. Il est crucial d’interroger les équipes sur leurs motivations et d’évaluer l’utilité de leur présence au regard de leurs dépendances afin de prendre une décision éclairée et, si nécessaire, d’adresser les problèmes soulevés.
Tu as quitté un train SAFe sur un de tes produits : comment cela s’est-il passé ?
Au sein de l’un de mes produits, notre équipe a dû évaluer la pertinence de notre intégration dans un train SAFe. Bien que ce cadre organisationnel soit efficace pour aligner les équipes et gérer des interdépendances complexes, il est essentiel de s’interroger sur la valeur ajoutée réelle qu’il apporte à chaque équipe.
Nous nous sommes donc posés plusieurs questions clés :
- Cette organisation facilite-t-elle le travail de mon équipe ?
- Notre participation génère-t-elle une valeur pour le produit et ses parties prenantes ?
- D’autres équipes bénéficient-elles de notre présence en termes de coordination et de vision produit ?
L’organisation SAFe, bien que structurante, peut également être lourde en termes de temps, d’instances et de synchronisation. Il est donc crucial d’évaluer en continu si cette méthodologie est adaptée à la nature et aux enjeux spécifiques de chaque produit.
Dans le cas de mon produit, après plusieurs participations aux instances, nous avons constaté que notre présence dans le train n’apportait pas de bénéfices significatifs, ni pour nous, ni pour les autres équipes. Plusieurs éléments ont motivé cette réflexion :
- Absence de dépendances critiques : Nos développements étaient autonomes et ne nécessitaient pas d’alignement constant avec d’autres équipes.
- Risques limités : L’ancienne version du produit étant toujours opérationnelle, il n’y avait pas d’enjeu bloquant nécessitant une coordination intensive.
- Vision produit pour les parties prenantes : L’unique avantage de notre présence était d’apporter une visibilité aux décideurs, mais cet objectif pouvait être atteint par d’autres moyens plus légers.
Finalement, que retiens-tu de tes 4 années en tant que PO dans plusieurs trains SAFe ?
SAFe a permis à mon équipe de :
- Mieux gérer les risques et les dépendances inter-équipes
- Structurer et synchroniser notre travail efficacement
- Améliorer notre organisation et nos processus internes
- Adapter notre cadre de travail pour maximiser notre impact
Ainsi, SAFe peut être un levier de performance, à condition d’être appliqué dans un contexte approprié et avec discernement.
Par Tiffany Noël, Product Owner chez Valeuriad.
