Dans les pratiques agiles de "passage à l'échelle", le Release Planning Day (RPD) permet une synchronisation des feuilles de route d'un périmètre organisationnel. Nicolas Kalmanovitz et Alban Dalle viendront expliquer la mise en oeuvre du RPD chez Meetic lors d'Agile France 2016 qui se tiendra les 16 et 17 juin aux Chalet de la Porte Jaune à Vincennes.
InfoQ FR a pu échanger avec Nicolas et Alban sur la transformation agile de Meetic, le concept de RPD, son intérêt et sa mise en oeuvre sur les derniers mois, les autres changements engagés chez Meetic, et l'apport de l'agilité à l'échelle.
InfoQ FR : Alban, Nicolas, merci d'échanger avec nous. Avant de commencer, pourriez-vous vous présenter ?
Alban : Je suis Coach Agile, et Leader de la tribu Scaling Agile chez OCTO Technology. Passionné par l’accompagnement des équipes et des organisations dans leur adoption des Méthodes Agiles, je suis tombé dans la « marmite Agile » dès les années 2002-2003 et je me suis tout de suite reconnu dans cette approche. J’ai maintenant plus de dix ans de pratique en tant que Scrum Master, Coach Agile, Consultant et Formateur. J’interviens chez Meetic depuis 2015, pour aider Nicolas à conduire la transformation agile.
Nicolas : Piqué à la culture start-up au début des années 2000 et bien qu’anthropologue de formation, j’ai eu la chance de pratiquer de nombreux métiers différents dans le web. Je participe à l’aventure meetic depuis ses débuts et j’interviens aujourd’hui en tant que directeur de la transformation et coach agile. Dans la pratique, j’aide l’entreprise à être une organisation apprenante en misant sur des équipes agiles autonomes et la culture de l’amélioration continue.
InfoQ FR : Meetic opère une transformation agile depuis plusieurs années. Pourriez-vous revenir sur les grandes étapes ?
Nicolas : La petite graine Agile a été plantée dans les équipes de développement. Entre 2011-2012, nous avons monté huit équipes de Scrum assurant du développement, de l’intégration et du test. En 2013, Kanban est venu enrichir l’approche de ces équipes et influencer d’autres services de l’IT.
En 2014, convaincus qu’il fallait aller plus loin et dé-siloter l’organisation, nous avons demandé à Octo de nous aider à cultiver notre agilité. Nous avons monté ensemble deux équipes pluridisciplinaires rassemblant chacune un product owner, un designer et des développeurs front et back-end. Pilotées par la vision et organisées en Scrum-ban, ces équipes ont relevé le challenge de réinventer l’expérience utilisateur sur les plate-formes mobiles (iOS, Android et Web mobile), tout en tirant une refonte technique en profondeur (Api-fication du back-end, mise en place d’Angular sur le front, intégration continue...).
En 2015, nous avons lancé un programme d’accélération de la mise à l’échelle de notre agilité et de la refonte de notre ingénierie et en 2016, nous comptons cinq équipes agiles pluridisciplinaires, ainsi qu’une équipe dédiée à la mise en place progressive d’une architecture en microservices. La moitié de nos équipes Ops ont également été coachées, comme cela sera le cas des autres équipes IT et Produit d’ici la fin de l’année. La petite graine a bien poussé et essaimé dans tous les services, réinventant au passage les schémas d’organisation et la culture d’entreprise.
InfoQ FR : Lors d'Agile France, vous présentez une session sur le Release Planning Day. Pourriez-vous décrire ce que c'est ?
Alban : Il s’agit d’un rituel trimestriel de planification à l’échelle de l’entreprise, au cours duquel les équipes élaborent et partagent leurs roadmaps prévisionnelles pour atteindre les objectifs stratégiques de l’entreprise et gérer leurs dépendances. L’idée, c’est de concentrer l’effort de planification et de synchronisation sur un délai court, avec tous les acteurs impliqués. En un à deux jours de délai contre six semaines auparavant, on aboutit à des Release Plans trimestriels plus réalistes et mieux partagés, avec un meilleur niveau de confiance et d’engagement des équipes. Même si ces plans seront encore ajustés au cours du trimestre...
Les cinq grands temps de ce rituel sont :
- Une présentation des résultats et de la stratégie par la direction,
- Un travail préparatoire par équipe de leur proposition de Release Plan avec les dépendances et les risques associés,
- Une gestion des dépendances entre équipes et des arbitrages requis,
- Une mise à jour des Release Plans en conséquence avec vote de confiance des équipes,
- Et enfin une présentation finale de ce que chaque équipe a embarqué et sorti de son périmètre pour le trimestre.
InfoQ FR : Comment avez-vous déployé un tel outil dans les équipes Meetic ?
Alban : Contrairement à ce qu’on pourrait imaginer pour un rituel qui concerne potentiellement toute l’entreprise, nous avons fait le choix d’un déploiement progressif. Nous avons tout d’abord testé les principes avec 2 équipes agiles. Nous avons ensuite monté un pilote avec 5 équipes, dont celles qui étaient déjà passées en mode agile. Nous avions besoin de tester et d’apprendre comment mener l’événement et faciliter le travail des équipes pour que la mayonnaise prenne, avant de convier davantage d’équipes.
Les promoteurs de l’agilité au sein de Meetic ont apporté une aide précieuse en acceptant de jouer le jeu à fond dès la première fois. Et les managers ont pris le relais en souscrivant à l’importance de ce nouveau rituel, et en l’inscrivant dans le “sens de l’histoire” de la transformation de l’entreprise. Suite à ce premier RPD, une rétrospective a été organisée avec une sélection de participants pour identifier les points d’amélioration, et en tenir compte pour la fois suivante.
Le trimestre d’après, avec l’élargissement du nombre de participants, la conviction s’est répandue qu’il n’y aurait pas de retour en arrière. Et d’autres équipes ont commencé à demander de monter dans le train !
La communication orchestrée par les PMO, en amont et en aval de chaque session, a eu un rôle déterminant dans le succès du déploiement progressif.
InfoQ FR : Quels sont les effets observés d'un tel rituel sur l'organisation d'une entreprise ?
Alban : Le premier effet, c’est l’alignement des équipes. C’est-à-dire qu’à partir du moment où l’on introduit ce rituel, le travail des équipes commence à s’organiser autour de lui. En amont, les demandeurs comprennent qu’il s’agit d’identifier, qualifier et analyser les projets candidats pour qu’ils soient éligibles à figurer dans la roadmap des équipes concernées. Et que les arbitrages seront traités selon la capacité des équipes, mais aussi selon l’alignement des projets avec la stratégie définie. Tout ce processus devient visible et partagé, moins sujet aux interminables négociations en coulisse... Cela apporte ainsi une meilleure cohérence globale, une plus grande responsabilité des différents métiers sur l’optimum global, et atténue la logique “client - fournisseur”.
Autre effet constaté : la progression vers un système plus “lean”, plus respectueux envers les équipes et leur capacité à s’organiser pour trouver des solutions, qui met davantage les contraintes en évidence, et donne de la matière à l’amélioration continue. Par exemple, les équipes qui arrivaient avec un nombre de sujets candidats bien trop important les premières fois ont, au fil des trimestres, appris à mieux maîtriser leur flux entrant et produit des Release Plans plus fiables et plus soutenables.
Enfin, le Release Planning Day pose la communication et la collaboration comme étant la norme, le standard. Il n’est pas toujours respecté, mais c’est le standard officiel. C’est loin d’être le cas dans toutes les organisations, il y a de quoi en être fier !
InfoQ FR : Dans la mise en oeuvre de ce processus, quels éléments ont été les plus compliqués ?
Alban : Ce qui est compliqué, c’est la friction entre les deux modèles : celui qui était en place, et le nouveau qui émerge. Le déplacement de l’un vers l’autre crée une tension entre les promoteurs et détracteurs : entre “l’adaptation au changement” et le “suivi du plan”, entre “l’estimation en jour-homme” et le “tee-shirt sizing”, entre “command & control”, et “autonomie et responsabilité”.
Justement, les deux choses qui ont beaucoup aidé sont l’autonomie et la responsabilité. L’autonomie car la mise en oeuvre du RPD s’est faite en misant sur l’appropriation du processus par les personnes. En véhiculant le message que c’était le rituel des équipes, par les équipes et pour elles-mêmes. Sur ce point, il s’agit de trouver l’équilibre entre les points de rencontre “obligatoires” pour que le rituel soit efficace - sur les modalités de partage des dépendances par exemple - et ce qui est plutôt laissé à l’appréciation des équipes - comment identifier et gérer les risques sur leur Release Plan. L’autre face de la pièce, c’est la responsabilité. Si vous n’êtes pas satisfait, il est de votre responsabilité de prendre part à l’amélioration du processus, typiquement en participant aux rétrospectives sur le RPD.
Etant visible et partagé, le RPD a naturellement cristallisé les résistances au changement... mais aussi permis de les adresser plus facilement en rendant les gens acteurs du système. Les tentations de revenir en arrière et supprimer le rituel ont finalement été vaincues par la démonstration : ça marche, la majorité apprécie, alors poursuivons !
Nicolas : Je rejoins Alban sur ce point. Une des leçons principales, c’est que chaque résistance au changement, chaque nouvelle critique est une opportunité. A partir du moment où elle est exprimée, nous pouvons travailler sur des solutions en impliquant les sceptiques et au final, cela renforce l’agilité. Cela a également renforcé notre approche de la transformation par l’adoption volontaire, l’expérimentation et la prise en compte de chaque écosystème plutôt que par la prescription.
InfoQ FR : Quelles transformations la mise en place des RPD a-t-elle fait émerger ?
Nicolas : Le RPD n’est pas seulement un processus de planification. Dans notre cas, c’est aussi un outil d’acculturation agile et un puissant levier de transformation de l’entreprise. Il a permis de diffuser les pratiques et les valeurs de l’agilité plus efficacement que si nous les avions affichées sur les murs.
Du point de vue des pratiques, les équipes non encore agiles y ont appris la logique d’itération, l’estimation relative en tee-shirt sizing, la co-construction de Release Plan. Et le RPD rythme toute l’entreprise non seulement en trimestre mais en itérations de deux semaines communes à toutes les équipes.
Il a également permis au collectif d’intégrer des valeurs et des principes agiles par l’expérience : le WHY est revenu au centre de nos préoccupations ; le planning n’est plus un engagement absolu mais une activité visant à faciliter l’adaptation continue ; un plan réaliste n’est plus un Gantt de chef de projet, mais un planning co-construit par les devs, le PO, le design ; la meilleure façon de s’organiser et de communiquer au sein d’une équipe et entre équipes n’est plus via JIRA mais par la communication directe.
Du point de vue du transformateur, le RPD aide à rendre l’ensemble de la chaîne plus lean. Par exemple cette année, remettre les Ops en amont du système et asservir le flux par rapport à la capacité réelle des équipes “contraintes” du processus actuel.
Autre exemple : en mettant en place dès le départ un cycle de rétrospectives sur le processus de roadmap, nous avons ancré le principe selon lequel les processus et l’organisation de l’entreprise peuvent et doivent évoluer par le travail de tous les acteurs. Cela nous a amené à créer de nouveaux rituels et artefacts. Récemment, nous nous sommes mis d’accord pour expérimenter un “company kanban”, un artefact présentant tous les projets de l’entreprise et visant à améliorer l’ensemble du workflow. Le RPD fait des petits et aide à scaler.
Enfin le RPD a créé de la fierté collective, de la fierté pour l’entreprise et pour sa culture car c’est maintenant un élément constitutif de notre identité. Il est le pouls qui bat le rythme de l'entreprise. Tout le monde veut y participer, c’est “The place to be”. C’est aussi cet élément de notre culture dont on parle avec passion auprès des autres sociétés du groupe, auprès des candidats en entretien de recrutement et en conférence aujourd’hui. Ce n’est pas tant du rituel en tant que tel dont il est question, mais de la fierté de pouvoir démontrer tous ensemble et régulièrement la qualité de notre collaboration et la force de notre collectif.
InfoQ FR : Un RPD prend deux jours. En réfléchissant dans une logique purement comptable, n'est-ce pas un investissement un peu élévé ? Comment calculez-vous le ROI d'une telle pratique ?
Alban : La question de la rentabilité est légitime. Ce qui rend la réponse ardue, c’est la difficulté à comparer l’investissement et le retour, avant et après. Avant : le temps plus diffus mais bien réel de préparation des roadmaps étalé sur six semaines, et surtout la perte liée au manque de communication et d’alignement entre équipes. Après : les bénéfices de ré-alignement des équipes, de la collaboration pour définir des objectifs communs... Nous n’avons pas effectué d’estimations mais à ce niveau, c’est presque une question de foi : quel est le niveau de confiance des participants sur le fait que ce rituel contribue positivement aux résultats de l’entreprise et qu’il est rentable ? La question du ROI des rituels agiles revient régulièrement, du daily meeting à la rétrospective : parmi ceux qui les mettent en place, certains les jugent rentables et d’autres moins. Essayez et jugez sur pièce sur les indicateurs qui vous intéressent, en prenant des pincettes sur la causalité entre le rituel et les résultats car les facteurs d’influence sont nombreux. Le retour des équipes à ce stade, c’est qu’elles passent plus de temps qu’avant à s’aligner et se synchroniser, et que les effets sont positifs notamment grâce à la limitation de l’encours. En tenant mieux compte des dépendances entre équipes, on lance moins d’initiatives en parallèle, mais celles qu’on lance sortent plus vite.
InfoQ FR : En déployant une transformation agile à l'échelle sur une période aussi longue, quelles changements avez-vous observé et/ou apporté dans l'entreprise ?
Nicolas : Il est difficile de résumer tous les changements ce qui, en un sens, est plutôt rassurant :) Le changement le plus important est sans doute culturel. Pour citer Richard Sheridan : “Our workspace is the reflection of the culture we have built”. Notre espace de travail montre en effet le signe d’un profond changement de culture car désormais, développeurs, designers, product owners mais aussi d’autres métiers partagent les mêmes open spaces ornementés de tableaux kanban et d’autres artefacts de management visuel. Ce sont quelques-unes des manifestations physiques de la bascule vers une culture agile mettant l’accent sur la boucle de feedback, la collaboration, l’expérimentation et l’autonomie des équipes.
Quand je compare Meetic aujourd’hui et il y a 2 ans, ce qui m'impressionne le plus, c’est la place de l’IT et le rapport à l’utilisateur final. L’IT est désormais moins un fournisseur et plus un “enabler” partenaire du business. La qualité n’est plus un sujet constant de négociation et la dette technique devient l’ennemi public n°1. Quand à l’objectif n°1, c’est le “vrai” client, l’utilisateur final ! Ce dernier revenu au centre, il est maintenant naturel d’aller chercher du feeback utilisateur au plus tôt, avant et pendant les phases de développement pour s’assurer de répondre au mieux à son besoin.
Enfin, Meetic a fait le choix d’avoir deux coachs à temps plein dont les interventions ne se limitent pas aux seules équipes agiles. C’était inimaginable il y a quelques années tant il s’agit d’un rôle qui correspond à une autre culture, et c’est pourtant un élément clé de l’organisation actuelle.
En créant les conditions de nouvelles interactions comme le RPD, nous avons finalement contribué à l’émergence d’une culture de la transformation permanente où le plus grand nombre est à la fois demandeur et acteur de changement.
InfoQ FR : Un secteur comme celui du dating est très concurrentiel, surtout aujourd'hui avec l'explosion des Tinder et autres applications mobiles. Qu'apporte l'Agilité dans ce contexte ?
Nicolas : Tous les secteurs doivent faire face à l’évolution constante du marché, des technologies, des usages et, surtout, des attentes utilisateurs. Il ne suffit plus d’être le premier arrivé ou d’être le leader sur le marché pour perdurer. Chez meetic, nous avons la conviction qu’il faut avant tout proposer le meilleur produit, celui qui répond le mieux aux besoins. Comme ces besoins évoluent continuellement, nous devons pouvoir réinventer notre produit rapidement et être capable de tester et délivrer ces évolutions encore plus rapidement. C’est tout le sens et la valeur de notre agilité.
Il y a quelques années, Meetic était devenu un site un peu daté, pensé desktop et reposant sur un SI endetté. Dans un monde en train de switcher sur de nouveaux usages mobiles, nous n’étions plus les mieux armés. Grâce à l’agilité, Meetic est aujourd’hui le service de dating le plus complet au monde et le seul à proposer une expérience de très grande qualité sur toutes les plate-formes, sur toutes les tailles d’écran et même IRL (In Real Life). C’est en créant des conditions favorables à l’expérimentation, à la collaboration et à la communication directe entre les personnes, les équipes et les clients que nous avons pu relevé ce défi.
InfoQ FR : Si les lecteurs veulent aller plus loin dans la compréhension du RPD, que leur conseillez-vous de lire, regarder, ou écouter ?
Alban & Nicolas : Notre conférence à Agile France le 16 juin :-) Vous pouvez trouver facilement de la littérature sur le web, mais notre conseil pour vous l’approprier, c’est d’essayer. Faites-vous confiance ! ;)