En préambule : Avec Adrien Orcel et Stéphane Hoinounou, nous souhaitons vous partager ce retour d’expérience sur la mise en place d’un rituel d’alignement de la direction portant sur la phase de Product delivery.
Contexte
Historiquement, Meetic utilisait le Release Planning Day (RPD) ou le PI Planning, des rituels à l'échelle permettant aux équipes d'échanger et de synchroniser leurs dépendances. Animé par l’Agile team et la PMO, nous avions pour objectif d’augmenter son efficacité et bien sûr, par son biais, celui de l’organisation et la mise en œuvre des initiatives Produit.
Problèmes identifiés : complexité et limites du modèle de gestion des dépendances
Découverte tardive des projets :
Les équipes de Meetic étaient souvent confrontées à la découverte tardive des projets, ce qui engendrait un manque de maîtrise technique et fonctionnelle significatif. Cette situation affectait négativement la coordination des dépendances, ce qui est logique en soi : on ne peut comprendre l'étendue d’un projet à réaliser à partir d'une description sommaire. C’est globalement le paradigme du cahier des charges.
Pression sur les équipes "component" :
Les équipes situées au carrefour des demandes, se retrouvaient sous une pression intense pour organiser et prioriser une multitude de tâches en seulement deux jours. Ces équipes se voyaient régulièrement contraintes de faire des choix cruciaux de priorisation sans une compréhension complète des enjeux.
Limitation de la vélocité organisationnelle :
Cette approche limitait fortement la vélocité de l'organisation. L'augmentation de la complexité avec le nombre d'équipes impliquées dans une initiative rendait la situation encore plus ardue, aboutissant à des délais de livraison étendus et à un modèle ressemblant à un cycle en V.
Efficacité systémique et qualité impactées :
Finalement, ce fonctionnement entraînait un niveau d'efficacité systémique défaillant, caractérisé par des projets souvent bloqués et une qualité globale affectée.
Outcome souhaité :
L'objectif était de permettre aux équipes d'anticiper leurs préparations et de ne plus découvrir les sujets au dernier moment. Il était crucial de diminuer le nombre d'équipes impactées par les dépendances et d'augmenter leur autonomie.
Un RPD sur-mesure : vers une approche plus aérée et anticipative
transition d'un framework intense à une version plus flexible :
Nous sommes passés d'un framework de deux jours consécutifs, souvent intense et subi par les équipes, à un framework "aéré".
La première version visait à créer une répétition forçant l'organisation à approfondir les sujets. La seconde version, quant à elle, a évolué en tirant profit des apprentissages, offrant ainsi plus de temps pour une meilleure anticipation de la part de l’ensemble des équipes.
déroulement du nouveau framework RPD :
- Une première journée : Présentation des objectifs de l'entreprise par la direction
- Une semaine de préparation pour les équipes : Étude des initiatives et élaboration d'un premier plan de release sur 6 semaines..
- Une deuxième journée : Construction des plans de release et échange des dépendances entre équipes.
- Une semaine supplémentaire de préparation : Intégration des nouveaux sujets au plan de release.
- Une Troisième journée : Présentation des plans de release matures à la direction pour valider le prochain sprint de 3 mois.
évolution vers une fréquence plus adaptée :
Les retours ont indiqué que la pertinence d'un plan de release sur trois mois devenait de moins en moins évidente.
Après avoir affiné le RPD, nous avons augmenté sa fréquence, passant d'un rythme trimestriel à toutes les 6 semaines.
Cette modification a permis de :
- fiabiliser les engagements
- réduire l'effort et le coût des initiatives
- s'assurer la livraison d'une première version en 6 semaines.
Le tout pour des équipes composées virtuellement d'un développeur (plusieurs développeurs mais sur plusieurs plateformes), cela représentait une avancée significative.
Travail sur l'autonomie des équipes : réduire la dépendance et simplifier la gestion du RPD
Vers une organisation générant moins de dépendances :
La clé pour améliorer la gestion des dépendances, particulièrement celles émergentes durant le RPD, réside dans la constitution d'une organisation qui, par nature, en génère moins.
L'objectif principal a été d'accroître l'autonomie des équipes, permettant à chacune de concevoir, développer et mesurer l'impact de leurs projets de manière indépendante, sans intervention extérieure.
Évolution de la structure organisationnelle :
Pour renforcer cette autonomie, Meetic a progressivement transformé son modèle d'organisation matricielle. Cette transformation s'est faite en plusieurs étapes clés :
- Plateforme team : des équipes centrées sur le développement et la maintenance de plateformes (ios, android, web..)
- Feature team : des équipes travaillant sur des fonctionnalités spécifiques sur toutes les plateformes
- Product team : des équipes créant des expériences utilisateurs qui transcendent les fonctionnalités pour atteindre des Product Outcomes.
Impact sur la réduction de la dépendance :
Chaque évolution de notre cadre organisationnel a joué un rôle important dans la réduction des dépendances inter-équipes, simplifiant grandement leur gestion. Cette transition vers des équipes plus autonomes a allégé le processus de planification et a favorisé une plus grande réactivité et adaptabilité, en réponse à des facteurs variés tels que les retours des utilisateurs, les ajustements de la direction, ou l'invalidation d'hypothèses. Cette capacité d'adaptation est caractéristique d'un développement itératif, difficilement réalisable dans une organisation contrainte par une gestion rigide des dépendances. En effet, le véritable avantage réside dans le passage à un modèle de livraison en continu. Cependant, cela nous amène au-delà du cadre de notre Release Planning Day (RPD), qui est un autre sujet en soi :)
Perspectives : maintenir l'équilibre entre autonomie et coordination
Importance du maintien du RPD :
Malgré l'amélioration significative de l'autonomie des équipes chez Meetic, le maintien du Release Planning Day (RPD) demeure nécessaire. Le RPD continue de jouer un rôle essentiel dans la gestion des dépendances qui subsistent, la discussion des sujets à venir, et l'assurance d'un alignement adéquat des équipes avec les enjeux stratégiques de l'entreprise.
Il sert également de rétrospective régulière, un moment de réflexion et de recalibrage pour l'ensemble de l'organisation.
Recherche d’excellence
Bien qu'il puisse parfois sembler que le RPD ne soit pas nécessaire, surtout quand les équipes gagnent en autonomie, son rôle est comparable à celui d'une rétrospective dans un cadre agile. Omettre le RPD pourrait faire manquer des occasions de remise en question et d'amélioration continue. Il est un élément clé dans la recherche de l'excellence et dans l'évaluation continue des processus et stratégies en place.
intégration d'un rituel de direction à l'échelle :
En complément du RPD, un rituel de direction à l'échelle a été intégré pour préparer le terrain en amont. Ce rituel sert à aligner les dirigeants sur les objectifs stratégiques et les plans d'action avant d'entrer dans le cycle plus détaillé du RPD. Il permet une meilleure préparation et une vision plus claire pour toutes les parties impliquées. (Lien vers l’article strat to exec)
Take aways
Contexte :
Meetic utilisait le RPD pour synchroniser les dépendances inter-équipes.
Problèmes :
Découverte tardive des projets par les équipes.
Pression sur les équipes "component" pour organiser et prioriser rapidement.
Limitation de la vélocité organisationnelle et qualité impactée.
Objectifs :
Anticipation des préparations par les équipes.
Réduction des dépendances et augmentation de l'autonomie des équipes.
Améliorations du Processus :
Augmentation de la fréquence du RPD pour une meilleure adaptabilité.
Renforcement de l'autonomie des équipes pour diminuer les dépendances.
Perspectives :
Maintien du RPD malgré l'autonomie accrue.
Intégration d'un rituel de direction pour un alignement stratégique amélioré.