Thomas Moyse a 45 ans quand il découvre en 2020 une nouvelle méthode pour améliorer en continu son produit. Il ne le sait pas encore mais Shape Up va bouleverser à vie sa vision du métier.
Février 2020, Paris. Attablé dans un restaurant du 9e arrondissement, je déjeune avec des développeurs de chez The Fork, l’entreprise que j’ai quittée quelques mois auparavant. Je ne le sais pas encore, mais ce qui devait être un banal déjeuner avec d’anciens collègues va radicalement changer ma vision du métier.
J’ai 45 ans, 20 ans de carrière et j’entends parler pour la première fois d’une méthode pour améliorer en continu son produit. “Shape Up, tu ne connais pas ?” me lance cet ingénieur un brin moqueur. Shape Up ? Késako ? Au fur et à mesure qu’on m’explique le concept, je me surprends à prendre des notes sur la nappe en papier, excité comme un gamin. J’apprends même qu’il y existe une “bible” sur le sujet écrit par un certain Ryan Singer :“Shape Up, Stop running in circles and ship work that matters". Le soir-même, je m’empresse de lire le livre en ligne et c'est une révélation… Adieu les backlogs, les story points, les séries de tickets sans fin et les sprints de 2 semaines. Bienvenue aux cycles de 6 semaines avec des projets concrets et matures ! Car cette méthode permet de lier deux choses qui me semblent alors contradictoires : les ingénieurs peuvent laisser les Product Managers (PMs) réfléchir très loin à une solution - pas à des problèmes - et malgré tout faire leur travail, c’est à dire transformer ce qui leur a été présenté comme une solution en un truc qui va marcher.
À cette époque, je viens d’arriver chez Lucca qui développe des logiciels RH pour simplifier la vie des collaborateurs. Je suis notamment responsable de la refonte d'un des logiciels sur la gestion des notes de frais. À court terme, mon objectif est de devenir Engineering Manager. Encore faut-il que je fasse mes preuves en interne. Je vois alors en Shape Up une formidable occasion d’asseoir mon leadership et de donner du sens aux équipes. Car tout part d'un besoin et d'un manque depuis mon arrivée dans l'entreprise qui travaille - comme à peu près toutes les sociétés d'IT du monde - avec Scrum. Cette méthode est censée fonctionner, mais elle produit des résultats disparates chez Lucca. En cause, une volonté d'avoir des PMs qui fabriquent des logiciels, qui réfléchissent à leur conception et qui se basent sur des spécifications. Je dois l’avouer, j'ai alors du mal avec cette idée qu’il y a des gens qui pensent très fort aux logiciels - jusqu’à la mise en place des spécifications fonctionnelles détaillées comme la définition des API - et d’autres qui les fabriquent. Bref, à qui on demande juste d’exécuter. Cette vision de PMs qui vont très loin dans la définition de la solution dès le début est totalement obsolète et n’entre pas dans ma vision de l'agilité. Qui ne serait pas frustré d’être celui ou celle qui prend juste des tickets pour les réaliser ? Pendant des mois, je vis avec cette impression de ne jamais m'arrêter et je lutte avec cette incapacité en moi de faire changer les choses. Mais c’était sans compter sur Shape Up…
Cette méthode, c’est d’abord un cycle appelé “shaping” qui a pour but de cadrer et pitcher le projet décidé par les PMs par exemple, tout en faisant la part belle à la créativité et l'autonomie des équipes. Il se conclut par la rédaction de pitchs avec le problème qu’on veut résoudre, les éléments clés de la solution ou encore les pièges qui pourraient survenir. Ce cycle est suivi de 2 semaines de “cool down” durant lesquelles des projets sont sélectionnés après une “betting table” (1h ou 2h). Puis on assigne une équipe pluridisciplinaire à chaque projet : développeurs back, développeurs front, designers, etc. Chaque équipe va alors s'auto-organiser pendant 6 semaines (le “building”) pour réaliser son projet qu’elle doit mettre en production. Cette temporalité est suffisamment courte pour pouvoir se projeter dessus et suffisamment longue pour faire quelque chose d’abouti. Et si l’équipe se plante ? Elle a “juste” perdu 6 semaines... Ce n’est pas si grave ! L’autre nouveauté avec Shape Up est qu’il n'y a pas de backlog, partant du principe qu’il est juste une liste de tâches continuellement remise en question et qu'on passe plus de temps à "groomer" cette liste de tâche qu'à vraiment les faire.
Le binôme que je forme avec mon Product Manager est dans un mode "Scrum-fatigue", avec un flux continu de tickets et des sprints qui n'ont plus de sens...
Je parle de la méthode en premier à mon binôme Antoine qui a un rôle de Product Manager/Product Owner. Bref, il écrit des user stories plus qu'il ne fait de discovery... "Pourquoi ne pas adopter Shape Up ? Il y a peut être un truc à jouer pour s'y retrouver toi et moi ?” je lui propose. Antoine est plutôt emballé par l'idée, d’autant que notre binôme est dans un mode "Scrum-fatigue", avec un flux continu de tickets et des sprints qui n'ont plus de sens... Pour résumer, c’est vraiment compliqué ! Sauf que 6 semaines est un sacré gap quand on est habitué à des sprints de 2 semaines. On a donc cette crainte de se dire : "est-ce qu'on est capable de s'engager autant de temps pour une seule fonctionnalité ?" Personnellement j’y crois et ma première mission est d’évangéliser. Me voilà à faire des résumés du livre de Ryan Singer et à enchaîner les réunions pour expliquer la méthode, ce que ça apporte et ce que je veux en faire. J'organise même un atelier dédié. Au départ je sens pas mal de doutes, notamment sur la notion d'appétit, mais je dois convaincre. La chance que j’ai est que Lucca est une société qui est très orientée Produit. On a plusieurs équipes ou business units (BU) dédiées à plusieurs produits, il est donc plus facile de convaincre 10 personnes d'essayer que d'en convaincre 100…
On décide de se lancer et de commencer avec des cycles de 4 semaines. Mais on s'aperçoit paradoxalement qu'on n'a pas le temps de faire grand-chose. Sans compter la frustration de ne pas aller au bout. Le problème est que si on dépasse les 4 semaines, on casse le jouet de Ryan Singer, ce qui n'est pas le but. C'est pourquoi l’auteur de la méthode a raison : 6 semaines de “building” est la bonne temporalité. Reste à se familiariser avec le “cool down”, la phase de 2 semaines qui sert à marquer l'arrêt d'un cycle et d’éviter cette impression de course en avant perpétuelle. Une aubaine pour les ingénieurs qui peuvent se concentrer sur un projet annexe, un nouvel outil ou de la refactorisation. Ce sont alors eux qui “prennent le pouvoir” en apportant de la valeur à leur entreprise d'une façon différente. Et les PMs dans tout ça ? Pour la majorité d'entre eux c'est aussi une révélation ! Avec cette méthode, ils peuvent se focaliser à 100% sur leur métier : concevoir des produits et non pas saucissonner des produits en tickets. Voilà pourquoi Shape Up est vite adoptée par d’autres BU de chez Lucca, avec une nouvelle relation entre Products Managers et développeurs.
Depuis la mise en place de la méthode, je suis devenu Engineering Manager et je supervise aujourd’hui, directement ou indirectement, une vingtaine de développeurs. Comment ne pas y voir une relation de cause à effet ? Shape Up m’a permis d’être aussi vu comme quelqu'un capable de mettre en place des outils et une organisation de delivery qui soutient la roadmap. Si toutes les équipes de Lucca n’ont pas adopté Shape Up, et elles ne le feront peut être jamais, l'important est qu'elles s'organisent comme elles veulent, avec les outils qu'elles veulent. Personnellement ça fait 3 ans que je n'ai pas ouvert un système de ticketing ou un Jira. Et rien que pour ça, qu'est-ce que je suis heureux !
Pour en savoir plus sur le Product Management : télécharger notre livre Les Clés du Product Management
Propos recueillis par Julien Négui
