| 💡 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 mars dernier, la startup lilloise Sencrop, qui conçoit des stations de météo agricole, faisait un petit retour d’expériences (avec la startup Dashdoc) sur Shape Up. On en parle avec Kevin Guilbert, son Head of Product.
Bonjour Kevin. Peux-tu déjà nous rappeler le contexte de Sencrop avant l’introduction de Shape Up ?
Kevin Guilbert : On était la boîte “usine à fonctionnalités” classique avec des idées qui arrivent de partout, des sprints de 15 jours et pas trop de questionnement sur les problèmes. Il y avait une dizaine de dev’ pour 1 designer et 1 PM.
Sauf qu’on n’arrivait plus à tenir le rythme : alimenter 10 dev’ sur un rythme de deux semaines, cela devenait trop intense et on sentait cette perte de sens et cette impression de tourner en rond, comme l’indique le sous-titre de Shape Up. D’autant que nous étions en pleine croissance avec le passage de une à plusieurs équipes. Il fallait donc trouver une façon d’être plus responsabilisé.
Comment s’est fait la découverte de Shape Up ?
K.G. : Nous sommes basés à Euratechnologies à Lille et c’est une personne sur place qui nous a recommandé ce bouquin. Je l’ai lu et ça m’a parlé dès l’intro ! Je savais qu’il fallait que l’on passe plus de temps sur le problème que la solution et la méthode était assez claire pour y arriver.
Je l’ai donc filé au CTO et à l’un des fondateurs qui s’occupe de la partie produit. Qui l’ont passé au lead tech et aux équipes. Il y a eu certes quelques réticences parmi des développeurs car, évidemment cela nous sort de notre zone de confort.
Mais, après un projet de 3 sprints qui avait dérapé, on s’est dit qu’on allait tester. On a fait une Betting Table avec les cofondateurs, le CTO, deux lead dev’ et moi côté produit. Et on est parti sur un cycle de 6 semaines !
Comment ça s’est passé ?
K.G. : Je dois avouer que la première semaine fut compliquée. Beaucoup de dev’ se sont dits : “Bon, qu’est-ce qu’on fait ? On n’a pas de design, on n’a rien…” Même aujourd’hui, la première semaine n’est jamais évidente. Elle est très incertaine pour les dev’ et certains le vivent plus ou moins bien.
Ensuite, on a le support qui est arrivé en panique à la 3e semaine ! On s’était dit en effet qu’on respecterait les 6 semaines et qu’on règlerait les bugs pendant le cool down. Bon, ce fut un fail… et l’on a toujours pas trouvé la solution aujourd’hui à ce niveau !
Comment expliques-tu cela ?
K.G. : Tout simplement car il y a des produits qui sont stables et d’autres un peu moins. Nous, on avait constamment des petits retours de clients, remontés par le support. Et jusque là, on prenait les tickets les plus urgents et on les traitait dans les sprints.
Mais quand on leur a dit qu’on partait sur un cycle de 6 semaines, la première semaine, ils ont dit OK, la deuxième, ça commençait à vaciller et la troisième, ça n’allait plus du tout !
D’autant que, normalement, le cool down est censé être le moment où tu prépares les prochains sujets et gérer un peu les bugs. Mais là, quand tu ouvres ton Trello, tu as une liste de 50 tickets donc c’est compliqué. On a testé un rôle tournant de “Ops of the week » qui traite ces tickets mais ça n’a pas marché. Donc on cherche encore…
Vous avez abandonné la Betting Table. Pourquoi ?
K.G. : On en a fait deux ou trois. Mais dans les faits, on n’avait pas 36 pitchs. La discussion ne portait que sur un ou deux donc cela n’avait pas trop d’intérêt.
As-tu vu le changement dans ton rôle de PM ?
K.G. : Désormais, on échange beaucoup au début des cycles avec les dev’ mais ce n’est plus les PM qui vont dire il faut faire ça ou ça. Des dev’ ont repris ce rôle. Pendant les vacances, on a d’ailleurs un dev’ qui a écouté un podcast et qui est revenu en disant à l’équipe : “Ecoutez ce que eux ils font, on pourrait faire pareil !” Et il a pris son téléphone pour appeler des clients. Une chose qui était inconcevable il y a un an et demi !
Il y a vraiment des bonnes surprises avec des dev’ qui sont clairement devenus forces de propositions. Personne n’aurait soupçonné que cela aurait aussi bien marché.
Avec du recul, qu’en retiens-tu ?
K.G. : Dans le contexte où l’on était, c’est vraiment le meilleur mouv’ qu’on a fait dans la boîte côté tech. C’est loin d’être parfait. Mais on a gardé l’essence de la méthode qui met l’accent sur le focus, qui ne dissocie pas front-end et back-end et place le problème en priorité numéro 1. Sans parler de l’autonomie des équipes et l’ownership des dev’. Je ne repartirais pour rien au monde sur un rythme de deux semaines !
Quels sont les points négatifs que tu signalerais toutefois ?
K.G. : Déjà, je ne pense pas que cela soit adapté pour les jeunes boîtes qui sont en recherche de leur product market / fit. Quand je suis arrivé il y a 4 ans, cela aurait vraiment été compliqué de ne s’engager que sur un sujet pendant 6 semaines.
J’ai parlé de la gestion des bugs. J’ajouterais également le sujet de la discovery pour lequel nous n’avons pas trouvé la solution non plus encore. C’est compliqué de bosser dessus pendant le batch en cours. On essaie de la faire pendant le cool down. Et on va essayer de fixer une journée dédiée dans la semaine.
| 💡 Retrouve tous nos articles sur le sujet dans notre dossier complet sur Shape Up ici 💡 |
Comment ?! Vous n’êtes pas abonné(e) ?
Corrigeons tout de suite cela 👇
