Tech.Rocks K2

Meetup Trustpair x Tech.Rocks - La méthodologie Shape Up

Publié le 29 octobre 2021

meetup Shape up

Meetup Trustpair x Tech.Rocks - La méthodologie Shape Up

Introduite par Basecamp, la méthodologie Shape Up fait beaucoup parler d'elle depuis peu. Trustpair et Tech.Rocks passent cette méthodologie à la loupe, le temps d’un meetup. Définition, mise en œuvre, efficacité (souvent comparée à la méthodologie scrum) : quatre tech leaders qui l’utilisent partagent leurs retour d'expériences. Replay.

meetup shape up

Speakers, who’s who :

  • Olivier Versanne, Engineering Director of Supply chez TheFork (anciennement LaFourchette).
  • Louis Vernhes, Product Director chez TheFork.
  • Simon Elcham, Co-founder & CTO de Trustpair.
  • Corentin Smith, Co-founder de Dashdoc.

Ce meetup a été animé par Céline Bayer, Deputy CTO de Mangopay.

Shape Up : c’est quoi ?

Simon Elcham : De façon très synthétique, cette méthode fait s’enchaîner plusieurs grandes phases. Le point de départ est l’idée, la demande, dont on shape ensuite les contours. Puis, on sélectionne des fonctionnalités à développer. Vient la phase de build durant laquelle on livre scope par scope. Enfin, arrive la fin du cycle.

Sur quels concepts repose cette méthode ?

Simon Elcham : Le premier concept est lié à la durée des cycles. Jusqu’ici, on était habitué à des scrums d’une, deux, quatre… semaines. Avec Shape Up, on part tout de suite sur six semaines. Une durée considérée comme juste pour réaliser des features concrètes et délivrables. À chaque cycle, l’idée est simple : faire évoluer le produit. L’objectif étant : un cycle = une livraison.

Le deuxième concept est lié à la façon d’adresser les sujets, la réflexion émane d’une part d’une équipe dédiée. Product Managers, Data Engineers, développeurs et designers… travaillent sur les demandes, les évolutions du produit. Ils dessinent les premiers contours de la solution. Ils définissent ce qu’ils veulent et ce qu’ils ne veulent pas, doivent laisser suffisamment de liberté aux équipes qui vont ensuite transformer l’esquisse en solution.

Troisièmement, dans le Shape Up, l’appétit est une notion importante. En clair, la solution ne doit pas conditionner le temps passé à l’adapter. Au contraire, je vais plutôt me demander « combien de temps suis-je prêt à investir sur telle feature ? ». Il s’agit ainsi de trouver des solutions qui vont entrer dans ce timing.

Une autre notion importante liée à l’appétit est celle du choix. La question qui se pose est parmi tous les sujets à shaper, lesquels sont prêts à être implémentés ? Lesquels vais-je sélectionner dans mon cycle ? Et en fonction de l’appétit, des capacités de l’équipe, on choisit ceux que l’on intègre. Ce, encore une fois, dans une démarche de délivrabilité. Dès lors, on va ainsi essayer de caper au maximum en déterminant un moment auquel on va se forcer à s’arrêter pour éviter de dépasser son cycle.

Dans la pratique, comment le Shape Up se met en œuvre ?

Simon Elcham : Dans la version originale du Shape Up, on organise tout d’abord une session avec les parties prenantes. Ils réalisent la phase de définition et transmettent ensuite leurs demandes aux équipes. Dans la partie run, d’autres concepts sont aussi à envisager. En l’occurrence, après avoir choisi le projet sur lequel travailler et qu’arrive la phase build, l’approche consiste à se dire : « tel sujet est shapé, maintenant on l’aborde scope par scope ». Il s’agit de progresser au fur et à mesure des six semaines. C’est très important, cela permet aux équipes mises à contribution sur une implémentation d’autogérer leur risque. Cette approche, scope par scope, induit de se concentrer sur ce que l’on est capable de livrer. L’idée est de confier des responsabilités aux équipes, de considérer que les bonnes personnes ont été mises autour de la table pour implémenter les fonctionnalités.

Quelles sont les spécificités d’un cycle en Shape Up ?

Simon Elcham : Dans la méthodologie originale, les cycles ne sont pas continus. Ils sont interrompus par des cool-down. Une période de deux semaines intercalée dans les six semaines. Cela permet aux équipes de relâcher un peu la pression. On les libère pour qu’elles puissent travailler sur des projets plus transverses, comme la R&D, le bug fix, etc. Et puis, cela permet surtout d’ouvrir la réflexion sur ce que l’on va faire durant le cycle suivant.

Dans le Shape Up, il n’y a pas de backlog. Je trouve ça à la fois hyper intéressant et fondamental comme différence par rapport à d'autres méthodes que l’on connaît. À la fin d’un cycle - que le projet soit terminé ou non - d’un cycle à un autre, les bons sujets à prioriser reviennent naturellement. On considère qu’une idée intéressante qui n’a pas été adressée, si elle est vraiment pertinente, elle reviendra d’elle-même. On rompt ainsi avec la logique de faire telle ou telle fonctionnalité juste pour le principe que ça fait 6 mois qu’elle est inscrite quelque part. À chaque cycle, on part d’une feuille blanche, on redéfinit la priorité, le besoin du moment.

Comment Shape Up s’est intégrée à vos organisations ?

Olivier Versanne : J’ai bien connu les différentes évolutions de cycles. On est passé par des cycles en V, le scrum, etc. On s’est mis au Shape Up chez TheFork, il y a un peu plus d’un an, en juillet 2020.

Louis Vernhes : La mise en place du Shape Up s’est avérée une démarche de transformation globale. Le modèle est aujourd’hui implémenté dans toute l’organisation product et tech. Pour y parvenir, on s’est inspiré de différentes sources. On ne s’est pas dit « on prend la méthodologie telle quelle ». On l’a adaptée. Et en ce qui nous concerne, nous avons conservé 4 grands principes. Nous avons tout de suite mis en place les cycles de 6 semaines, les cool-down de 2 semaines. Nous avons également gardé la dimension d’objectif unique. Dans un cycle, l’équipe aborde un sujet et rien d’autre. L’approche shape aussi, nous l’avons conservée, en taclant bien en amont le problème à traiter. L’aspect bottom up, les propositions des équipes, a été gardé.

Olivier Versanne : En réalité, on mélange un peu la méthodologie Shape Up avec celle du discovery. On essaye de toujours trouver des problématiques accessibles par les équipes d’ingénieurs et de products. Elles-mêmes proposent d’ailleurs des solutions. Cela amène la logique d’appétit. Du coup, on se focus vraiment sur ce qui est important, ça change tout. Au bout des 6 semaines, on atteint le maximum de valeur.

En revanche, comme dans tous les business, il y a toujours ces petites demandes à passer “vite fait” qui apparaissent. Toutefois, six semaines, ça passe vite. Et, il est tout à fait envisageable de dire à un stakeholder : « on le fait à la fin du cycle ». Aujourd’hui, on consacre 20% de la bande passante du cool-down à ce qu’on appelle des must have, ces demandes où il y a un intérêt business à les réaliser.

Corentin Smith : On s’est posé la question du Shape Up, à Dashdoc, il y a un an et demi. On était une petite dizaine dans l’équipe technique et produit. On venait de recruter un product manager. On voulait faire les choses bien. On a commencé par faire ce que l’on entendait autour de nous. On a mis en place le scrum pendant trois mois. Mais, je sentais que ce n’était pas adapté. Des soucis émergeaient. On passait beaucoup de temps à discuter du nombre de points pour faire une user-story, beaucoup de temps à découper les epics en stories… Et puis cela prenait une grosse bande passante au product. Finalement, l’équipe technique se retrouvait dé-responsabilisée. On avait l’impression d’avoir une liste de tâches pré-mâchées, à partir de laquelle dérouler de la feature. J’ai commencé à regarder ce qui se faisait ailleurs. Avec le product manager, on s’est documenté sur Shape Up. Ça cochait un peu toutes les cases. Ça contribue notamment à rendre des responsabilités aux équipes. On a testé sur un premier cycle et on a été convaincu. On a commencé il y a un an et on est toujours contents. Toutefois, on a aussi fait pas mal d’ajustements.

Simon Elcham : En ce qui nous concerne, on utilise Shape Up chez Trustpair, depuis deux ans. Avant, on était en scrum. On s’est posé la question dès que le livre a été publié. À l’époque, on avait cette problématique de courir après le temps. On avait l’impression de ne pas préparer les sujets correctement, de faire des livraisons pas toujours correctes, un peu dans la douleur. On souhaitait améliorer ça. On a testé un premier cycle en septembre 2019. On a itéré pas mal, notamment sur la façon d’implémenter. Immédiatement, le bénéfice obtenu a été de rattraper la vision. Ce que j’aime dans le Shape Up, c’est une méthodologie produit et non pour la tech. C’est comme ça que nous l’avons abordée. On l’a adoptée en mettant toutes les équipes à contribution en faisant du bottom up. À chaque cycle, tout le monde est sollicité pour évoquer ce dont il a besoin. Ça met tout le monde autour de la table pour dire où va le produit.

Quels sont, selon vous, les principaux avantages du Shape Up ?

Louis Vernhes : Pour moi, il y en a quatre. Le premier est l’aspect focus. Dans une entreprise comme la nôtre, on a énormément de parties prenantes côté business. Avec le Shape Up, on parvient à bien protéger les équipes durant les cycles de ceux qui poussent des demandes en face. Le deuxième avantage, la méthodologie oblige à penser impact. Le troisième, elle permet d’éviter de mauvaises surprises au niveau du budget. Le quatrième se situe au niveau de la communication avec le reste de l’organisation. Shape Up facilite les conversations autour des investissements, des choix produits que l’on fait.

Olivier Versanne : Selon moi, cette méthodologie est très orientée sur le temps. Là où le scrum est davantage un enchaînement de cycles. Le Shape Up, c’est 6 semaines durant lesquelles on fait tout ce qu’on peut pour atteindre un objectif défini et pour partir en prod. Il y a donc peu de risque de créer de gros cycles en V et perdre la vision, le cap. À la fin, on organise des démo où les équipes exposent ce qu’elles ont accompli. Enfin, l’autre aspect positif tient au fait qu’il n’y a pas non plus de roadmap.

Corentin Smith : L’avantage, pour moi, réside dans l’alignement des parties prenantes de la boîte à propos de ce que l’on fait sur un cycle et la manière de s’y tenir.

Simon Elcham : Il y a un autre avantage à mes yeux assez important, propre aux développeurs et à leur implication. Cette méthodologie leur permet de pousser des demandes eux-mêmes dans les cycles et jusqu’à la livraison. Ça, c’est hyper apprécié car dans ce contexte, ils ne sont pas considérés comme de simples exécutants. Le travail côté produit n’est pas pré-mâché. Ils participent à la réflexion.

Des inconvénients ?

Corentin Smith : Là où l’on n’est pas encore tout à fait satisfait, c’est sur la gestion des bugs. En effet, durant le peu de temps où l’on s’y consacre, on perd un peu le côté focus.

Simon Elcham : Je pense que certaines difficultés peuvent apparaître au moment du shape et de la formulation des attentes. Ce n’est pas évident car il faut rester sur un niveau assez abstrait et cadrer suffisamment en même temps. Mais franchement, des inconvénients, je n’en vois pas vraiment.

Merci à toutes et tous pour ces retours.

undefined

Retrouvez les prochains événements et meetup Tech.Rocks :

https://www.meetup.com/fr-FR/Meetup-CTO-Tech-Rocks/?_locale=fr-FR