| 💡 Cet article fait partie de notre dossier complet sur Shape Up à découvrir ici 💡 Et si tu as besoin d’un rappel sur ce qu’est Shape Up, voici la session de rattrapage. |
En résumé :
- Date de mise en pratique de Shape Up chez Lucca : 4e trimestre 2020
- Ce qu’ils ont changé : Pas grand chose à vrai dire !
- Les avantages de la méthode pour eux : Engagement des équipes, Productivité, Fin des effets tunnel, Travail à plus forte valeur ajoutée pour les PM
- Les limites / difficultés : Ownership des dev’ à “culturellement” améliorer, Circuit breaker, Différence Appétit / Estimation
Après avoir parlé de TheFork, Sencrop ou Alan, descendons désormais la Loire pour nous rendre à Nantes. On se prend un P’tit Beurre chez Vincent Guerlais – une tuerie – et on file rendre visite à Lucca, une startup qui a un annuaire d’équipe très sympa (on n’a pas résisté, on s’est fait tout le monde, même le chien Halcid) et qui édite une suite de solutions RH et administratives.
Depuis la fin de l’année dernière, eux aussi sont passés à Shape Up. Enfin, précisons : Lucca est composé de 6 Business Units (BU) autonomes et l’une d’elles, Cleemy, le logiciel de gestion des notes de frais, est passée à Shape Up. Les autres fonctionnent toujours en Scrum ou en Kanban.
Et le lien avec TheFork est tout trouvé puisque Thomas Moyse, l’engineering manager de la BU en question et initiateur de Shape Up est… un ancien de La Fourchette. “C’est en discutant avec des anciens collègues qui tentaient ça que j’ai commencé à me pencher sérieusement sur le sujet”, confirme-t-il.
“Plus du boulot de gestion de projet que de PM”
Le contexte de départ est globalement le même que pour TheFork.
“Quand je suis arrivé en 2019, on était en Full Scrum. Cela faisait même partie de l’onboarding de se remettre à jour sur Scrum, se souvient Antoine Diekmann, Lead Product Manager de Cleemy. Les PM passaient leur temps à rédiger les tickets et il n’y avait pas d’ownership des dev’. On essayait constamment d’imaginer comment les dev’ allaient faire le travail pour le découper en tâches et en User Stories. C’était plus un boulot de gestion de projet que de PM.”
Mais contrairement à TheFork, on passe en Shape Up de manière plus progressive chez Lucca. “On ne voulait pas faire de révolution. Moi, ça me faisait peur les 6 semaines sachant qu’on ne s’engageait que sur 2 semaines avant”, témoigne Thomas. La BU part donc sur un cycle de 3 semaines puis 1 semaine de cool down. Ceinture et bretelles.
Ce qui permettait de rester synchro avec les engagements du trimestre par la même occasion.
“Mais rapidement, on s’est dit : “On s’en fout !” Un projet, qu’il soit fini ou pas, ça ne change rien pour la roadmap en soi. Donc on a augmenté petit à petit à 4 semaines puis à 6 semaines, ce qui a permis de roder les choses et de voir l’engagement des équipes qui augmentait », explique Thomas Moyse.
Allez, rentrons concrètement dans les coulisses. De toutes les interviews qu’on a faites, disons d’emblée que c’est la mise en application qui se rapproche le plus du livre. Avec le dual track Shaping / Building et les 3 moments du cycle : Shaping, Betting, Building.
1. Shaping
“Notre job ici va être d’identifier les principaux problèmes que l’on veut résoudre, grâce à l’outil Product Board et à notre connaissance du produit et des utilisateurs, pour travailler ensuite sur des pitchs de projets cohérents avec les objectifs de notre roadmap, décrit Antoine. Ces pitchs ne sont pas simplement 5 lignes de texte. On a un modèle dans Confluence dans lequel on retrouve :
- La description du problème : ce qui nous a amené à envisager ce sujet
- Les solutions envisagées. Pour y arriver, on va parler au lead dev’, au designer, au responsable business etc… pour commencer à travailler sur une direction.
- Les no-gos : ce que l’on ne veut surtout pas faire pour éviter les malentendus et les mauvaises directions
- Les risques (dette technique par exemple)
- Et la notion d’appétit : combien on est prêt à dépenser. Par exemple, si c’était mon argent, je serais prêt à investir 2 temps plein pendant les 6 semaines sur ce sujet.”
Certains dev’ vont alors intervenir en relecture de pitch.
“Pour mesurer si ça sent bon ou si on est à côté de la plaque en termes d’appétit, poursuit Antoine. Le pitch est vraiment une zone de feedback et d’échange en amont, car il va donner ensuite une bonne direction au problème que l’on veut résoudre”.
Si, en théorie, tout le monde peut écrire un pitch, dans les faits, ce sont principalement les PM qui s’en chargent. “Si une personne est surprise qu’on ne fasse pas un projet, on lui dit : “Vas-y, tu peux le pitcher !” Je dirais qu’on a environ 10% de projets techniques qui sont pitchés par le lead dev’. Mais beaucoup de dev’ sont impliqués malgré tout dans la rédaction des pitchs”, assure Antoine.
2. Betting
La fameuse Betting Table se tient 2 semaines avant le démarrage des projets. Soit au tout début du cool-down si tu as bien suivi le rythme de Shape Up.
“Avant, on la faisait 4 jours avant la phase de Building. Mais c’était trop tard. Donc on l’a avancé pour que le cool down soit en fait un peu un warm-up (échauffement) et que les équipes puissent rentrer petit à petit dans leur projet, lire les pitchs en amont, comprendre les enjeux et la direction qu’on va prendre etc,” relate Thomas.
“Il peut aussi arriver qu’on fasse des ateliers à cette occasion pour onboarder des personnes sur des sujets qu’elles vont avoir à traiter ensuite durant leur cycle,” ajoute Antoine.
Chez Lucca (enfin, dans la “BU Shape Up” !), la Betting Table réunit lead dev’, product designer, les PM et le responsable de la BU, qui joue un peu le rôle de la partie prenante. La décision d’inclure des personnes externes à l’équipe a eu lieu une fois… sans grand succès !
Un arbitrage collégial
Généralement, ce conseil doit trancher entre 8 à 12 pitchs. Le déroulé est globalement le suivant : chaque personne présente son ou ses pitchs pendant 1 à 2 minutes (même si chacun est censé les connaître en arrivant dans la salle). Quelques questions interviennent parfois.
Puis, de façon collégiale, tout le monde donne son avis pour, au final, en arriver à 4 pitchs retenus, avec le responsable qui tranche en dernier recours. Il arrive parfois que certains pitchs reviennent d’une Betting Table à l’autre, s’ils n’ont pas été retenus.
“On sort de cette Betting Table avec la liste des projets qui correspondent à la bande passante qu’on veut y dédier. Et, ensuite, c’est Thomas qui va commencer le travail d’assignation des personnes sur chaque projet”, conclut Antoine.
Forcément, la question qui se pose : ce système ne crée-t-il pas un esprit de compétition entre PM ?
“Il arrive que certains PM n’aient en effet aucun pitch retenu, répond Antoine. Mais on est une BU, on est une équipe. On a un chiffre d’affaires à maximiser ensemble. Je ne dis pas qu’il n’y a pas de frustration mais, normalement, si le projet d’un.e autre PM passe, tu dois être d’accord car tu fais partie de l’arbitrage. Et il ne faut pas oublier que c’est ultra motivant pour les PM de se dire que, toutes les 6 semaines, on a la responsabilité de présenter des problèmes à résoudre”.
3. Building
Les premiers lundis de chaque cycle, une réunion de démarrage (allez kickoff si tu préfères) a été instaurée. “L’erreur qu’on a faite, c’est de se tenir la main et relire le pitch ensemble, se rappelle Antoine. Alors qu’en fait, à ce stade, tu es censé le connaître et avoir déjà posé tes questions. Le but, ici, c’est plutôt de bien délimiter le scope du projet avec les must have et nice to have, et de voir comment on l’organise et par quoi on commence”.
Puis les équipes (entre 2 et 4 dev’) se débrouillent librement. Les Hills Charts ont été adoptés dans cette phase pour suivre l’avancement des projets (avec l’outil Hillia pour info). Quelques rituels Scrum ont également été gardés comme les réunions quotidiennes avec toute l’équipe, la retro ou la démo publique de fin.
A entendre Antoine et Thomas, la difficulté ici réside plus dans la révolution culturelle du rapport entre PM et dev’, une notion clé dans Shape Up.
“Il faut encore qu’on travaille sur la partie ownership des dev’, confirme Thomas Moyse. En fin de projet, ils ont souvent l’impression de ne pas avoir tout fait car ils ont pris le pitch comme l’alpha et l’omega de ce qu’il fallait faire”.
“On est tous responsable de ça, enchaîne Antoine. En tant que PM, c’est naturel, on est toujours ambitieux sur les pitchs. Et l’objectif reste d’atteindre ces ambitions. Mais il faut comprendre que le temps n’est pas illimité et que, en tant que dev’, ta responsabilité n’est pas de dire “Je peux prendre ce raccourci ?” mais “J’ai décidé de prendre ce raccourci, t’en penses quoi ?”. Pour qu’au final tu arrives à mettre dans les mains des utilisateurs une solution qui ne résoudra peut-être pas 100 % mais disons 60 % du problème.”
La résolution de problèmes à tous les niveaux
Antoine Diekmann précise : “Dans le pitch, on va par exemple dire que la solution envisagée sera ABCD. Mais l’équipe va peut-être réaliser la solution BCEF, qui répondra aussi en gros au problème”. Exemple concret : un item devait être rendu modifiable sur la plateforme. Sauf que les dev’ se sont rendus compte que, pour une petite minorité d’utilisateurs et dans un cadre fonctionnel bien précis, cela allait demander un très gros travail. Le raccourci retenu ? Dans ce -rare- cas de figure, la modification ne serait pas possible.
“Les dev’ ne sont pas des techniciens, ce sont des ingénieurs, lance Antoine. Leur rôle est aussi de résoudre des problèmes. C’est quand même plus enrichissant que de se sentir esclave d’un backlog avec des PO qui te donnent une liste de tickets à dérouler. Dans Shape Up, les PM sont là en support mais pas en gestion du projet”. “On a inversé la démarche, complète Thomas. Les dev’ ne sont plus au service de User Stories décidées par des PM, ce sont les PMs qui sont à leur service pour répondre à leurs questions.”
Toujours est-il qu’il existe encore quelques projets qui s’appellent “finition du précédent projet” dans les cycles… “Cette contrainte de circuit breaker (rappel : arrêt du projet s’il n’est pas fini à temps) est vraiment très difficile et douloureuse, concède Thomas. C’est très lié à la notion de good enough. Sachant que, normalement, dans les 6 semaines, tu as 4 semaines de build, une de recette et une dernière pour lisser tout ça, afin que le projet ressemble à quelque chose à la fin. Autrement dit, après l’avant-dernière semaine, tu ne développes plus aucune nouveauté”.
Alors, heureux ?
Malgré tout, la productivité est en hausse à les entendre. Et Antoine redécouvre son métier :
“Je suis passé du boulot de project manager à celui de product manager. Avant, j’avais l’impression de faire essentiellement de l’animation de sprints, de découpage de sujets… Avec Shape Up, on a moins cette scission dev’ et produit avec cette relation gênante au backlog”.
100% convaincus, ils s’apprêtent même à créer une Betting Table supplémentaire spécifique pour les sujets de discovery. “La discovery, c’est ce qu’on fait pour tracer la bonne route. Le shaping, c’est déterminer les différents projets de cette route”, distingue Antoine.
Avant d’illustrer concrètement ses propos : “On fait de la note de frais. Faut-il qu’on fasse de l’intégration avec des agences de voyage ou qu’on aille sur les montres connectées par exemple ? Je n’ai aucune idée de la valeur économique que cela aurait, d’où ce travail à mener en amont.” Actuellement, il indique que son temps est réparti entre 50% de discovery, 30% de shaping et 20% de support.
Et d’ici fin septembre, Thomas et Antoine vont faire un atelier de présentation de Shape Up à l’ensemble de la boîte. Pour faire naître des vocations, qui sait.
(Au pire, partagez cet article les gars. Ça vous évitera d’avoir à faire des slides).
