Commençons tout d’abord par un petit rappel du contexte. En septembre 2014, soit quelques mois après l’arrivée de Stéphane Lebas, Meetic lance ses premières équipes agiles.
La période coïncide aussi avec la refonte de ses différentes plateformes, le passage en équipes fonctionnalités (= feature teams, dont nous avons longuement parlé dans le Ticket 003 avec les exemples de BlaBlaCar ou de Deezer)… et la multiplication des projets transverses et donc des dépendances. Pas un mince problème quand on parle de 120 personnes à la tech et une trentaine au produit.
Avec l’aide de consultants d’Octo, un nouveau rituel est alors créé : le Release Planning Day (journée de planification des nouveautés, si tu aimes la sssssensualité de la French Touch).
L’idée ? Faire la roadmap du trimestre sur deux jours en incluant toute la boîte. “On a commencé avec juste une partie de l’équipe IT et produit au début, mais on s’est rendu compte que, un peu comme pour les OKR, cela n’avait de sens que si c’était un exercice global avec tout le monde,” se rappelle Stéphane Lebas.
Une image vaut mille mots (doux), voici à quoi ça ressemble grosso modo (tu peux cliquer sur l’image pour l’agrandir) :
On t’explique les différentes étapes en détail.
Étape 1 : Présentation de la stratégie
9h30, premières doses de caféine ou de théine dans les veines, la journée commence par un défilé des patron(nes) de départements qui viennent présenter leurs 3 grandes priorités du trimestre en 4 ou 5 slides et une dizaine de minutes. Il est indiqué “head of product” ou “IT Manager” dans le schéma mais, en l’occurrence, c’était plutôt le management qui était au tableau.
L’occasion d’anticiper les temps forts commerciaux et marketing notamment. “Je me rappelle que la marque et la com’ venaient nous parler dès Q4 des idées pour la Saint-Valentin de l’année d’après, donne Stéphane comme illustration. On savait ainsi qu’il fallait qu’on se garde un ou deux sprints en décembre pour préparer les fonctionnalités pour cette campagne de com’”.
Comme le fameux “en couple dans un an ou remboursé”. (quelle agence Buzzman quand même…)
Étapes 2-3-4 : Réunion entre équipes
A la suite de ces bonnes paroles, chaque équipe se rassemble dans une salle dédiée jusqu’au début de l’après-midi, parfois avec les principales parties prenantes.
L’occasion de présenter les différents projets envisagés, d’évaluer leur bande passante respective puis d’identifier les risques associés avec le modèle RAOM (pour Resolved, Owned, Accepted et Mitigated, selon leur niveau de complexité, en résumé très simpliste).
Étapes 5-6-7 : La (presque) kermesse
En milieu d’après-midi, tout le monde se retrouve dans une grande salle et chacun commence à placer les post-it de ses projets, bien calibrés selon le nombre de sprints nécessaires pour les réaliser, sur son board. C’est là où l’on se rapproche le plus de la kermesse de Deezer.
A ce moment en effet, chacun va mettre des post-it sur les boards des autres pour leur signaler une dépendance, c’est-à-dire d’un besoin de tel ou tel pré-requis. Quoi de plus efficace que le management visuel !
Bon, comme tout le monde était un peu cramé de tout le jus de cerveau produit dans la journée, la résolution de ces dépendances n’intervenait que le lendemain matin, pendant deux heures. “Cette phase était vraiment super importante car c’est là qu’on arrivait à gagner des semaines de travail,” confie Stéphane.
Étapes 8-9 : Vérification et présentation du plan des releases
Vient alors une phase fatidique (pire que celle du texto à la fin de la première date) : la vérification de tous les boards par Stéphane Lebas himself et le CTO.
“Les équipes nous présentaient alors ce qui avaient été mis, mais aussi enlevés. Tous les post-its initiaux ne rentraient jamais en effet du premier coup. Et on les challengeait. Ça nous arrivait de changer leur périmètre si on estimait que c’était trop ou pas assez ambitieux. Voire de transférer des développeurs d’une équipe à l’autre si nécessaire,” explique-t-il.
Étape 10 : Le vote de confiance
Enfin, en conclusion de cette session de deux jours, les équipes devaient indiquer, sur une échelle de 1 à 5, leur niveau de confiance envers le plan qu’ils devaient délivrer pour le trimestre.
“En toute logique, si on n’avait rien changé au board d’une équipe, elle était censée mettre 4/5 ou 5/5. On les engueulait s’ils mettaient moins car cela voulait dire qu’ils n’avaient pas confiance dans leur propre système d’évaluation,” indique Stéphane Lebas.
Ce dernier se rappelle avoir eu des 2/5, après qu’il ait fait des modifs dans les boards de certaines équipes. “Ce score était affiché lors de la restitution et le management ne pouvait pas le masquer. Ce système de transparence était utile car il permettait de potentiellement faire un plan d’actions et simplifiait la discussion sur l’atteinte des objectifs,” poursuit-il.
La 11e et dernière étape (surprise, car pas indiqué sur le schéma) : retour à la case départ, chaque équipe présente sa roadmap finale devant tout le monde. Ce qui était rentré… comme ce qui ne rentrait pas. “Je fais systématiquement cet exercice depuis, quand je fais une roadmap, ajoute Stéphane. Dire ce que l’on va faire comme ce que l’on ne va pas faire. Aucune ambiguïté comme ça !”
Verdict ?
Stéphane Lebas en convient, ce processus est assez lourd et convient pour une organisation structurée, suffisamment mature et qui doit jongler avec de nombreuses complexités. “C’est adapté pour le type de boîtes entre la startup et le grand compte,” précise-t-il, lui qui ne l’a pas réutilisé depuis, ayant travaillé essentiellement pour des startups (CPO de Malt puis de Quare aujourd’hui).
“C’est un peu exagéré quand tu as une poignée de PM et une trentaine de dev’. Au pire, pourquoi pas dans une version condensée…”
Il en retire malgré tout beaucoup de bénéfices pour le type de scale-up qu’était Meetic à l’époque : “C’était certes deux jours de perdus mais cela en faisait gagner beaucoup derrière. Et l’avantage, c’est que tu faisais en même temps de l’alignement d’équipes, de la com’ interne, de la levée de risques et de dépendances. Ce qui, au final, prend moins de temps que de mobiliser plusieurs fois, plein de monde sur plusieurs heures.”
“Le RPD n’est pas seulement un processus de planification. 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,” indiquait, dans cet article, Nicolas Kalmanovitz, l’un de ses instigateurs, devenu aujourd’hui coach chez Octo. Une phrase qui pourrait inspirer des grands groupes en pleine phase de diffusion de la culture produit…
Selon Stéphane Lebas, ce type d’exercice ne peut fonctionner toutefois que s’il implique vraiment toutes les équipes (pour ne pas laisser passer des dépendances) et ne doit pas se faire en dessous du trimestre (car il réclame tout de même pas mal de préparation).
Enfin, ce dernier relativise une chose :
“Malgré le Release Planning Day, il y avait toujours des trucs qui venaient se greffer en cours de route, que cela soit du juridique, du réglementaire etc. On n’a jamais respecté le plan à 100 %. Mais c’est le jeu : rien ne te mettra à l’abri des aléas de la vie d’une entreprise et il faut accepter que ta roadmap soit disruptée de toute façon…”
Il était dans le Ticket :
Cet article est issu du Ticket n°006. On l’a publié avec ce sujet sur la kermesse de Deezer, qui ressemblait un peu au RPD .
Comment ?! Vous n’êtes pas abonné(e) ? Corrigeons tout de suite cela 👇
