Pourquoi et comment utiliser la méthode Shape Up ?

Dans cet article
Table des matières
Like it? Share it

Nicolas De Greef & Aurélia Amalvict, Product Manager chez Trustpair, étaient les invités de Maestro à l’occasion du webinar MaestriX sur la méthode Shape Up. Nous vous proposons de revenir sur les échanges entre nos deux PM, Rachida Laraache & Flavie Chanut.

Le contexte produit chez Trustpair

Lorsque Trustpair se lance dans le développement de sa solution digitale de lutte contre la fraude, la fintech est encore de petite taille. Une dizaine de personnes composent les deux équipes mises en place à l’époque : l’équipe Engineering et l’équipe Produit. Trustpair appliquait alors la méthodologie SCRUM* en observant des sprints de 2 semaines.

Malgré de nombreuses itérations avec SCRUM, certaines difficultés perdurent, et poussent les équipes Trustpair à s’orienter vers un autre modèle.

  • Difficulté à livrer dans les temps, à respecter les deadlines
  • Trop de questions sans réponses au cours des phases de Sprint
  • Une mauvaise valorisation des équipes Engineering
  • Un Backlog difficile à maintenir

Face à ce constat, et à l’initiative de l’un des développeurs Trustpair, un intérêt naît autour de la méthode Shape Up.

La Méthode Shape Up

La méthode se décompose en 3 grandes phases : Shape, Bet table & Dispatch table, Build.

En amont de ces 3 étapes, Trustpair réalise des interviews en interne afin d’identifier les besoins sur le cycle à venir. Une rédaction détaillée est réalisée, suivie d’une séquence de priorisation des sujets en fonction de la méthode RICE : Reach, Impact, Confidence et Effort (Portée, Impact, Confiance et Effort).

« En utilisant la méthode RICE, on va faire un calcul : Reach X Impact X Confiance divisé par l’Effort, ce qui nous donnera un score et nous permettra de prioriser les différents items. » – Aurélia Amalvict

Shape

Suite à la priorisation des différents sujets, l’étape de “Shape” permet d’identifier les problématiques que l’équipe souhaite adresser, ainsi que les potentielles solutions souhaitées. Les équipes définissent ainsi les Boundaries (limites) avant-projet et les Rabbits-Holes (embûches) à éviter.

« Habituellement, les Shapes sont élaborés par une seule personne avant d’être soumis à la Bet table. Chez Trustpair nous avons choisi de systématiquement constituer des équipes ad-hoc pour étudier ces sujets. » – Nicolas De Greef

Bet table & Dispatch table

Se réunissent à la Betting table : les 3 fondateurs de Trustpair, les 2 Lead Engineering et une partie de l’équipe Produit. Cet atelier permet de sélectionner, parmi tous les sujets identifiés précédemment, ceux sur lesquels les équipes vont travailler pendant les 5 semaines à venir lors de la phase de Build. Les sujets de Shape retenus passent donc en Build.

À noter que dans la méthode Shape Up initiale, la période préconisée est de 6 semaines.

« Chez Trustpair, l’ownership est à l’honneur et nous souhaitons que les équipes Dev et PM se positionnent volontairement sur les sujets de leur choix, en respectant les ordres de priorité. » – Nicolas De Greef

La Dispatch table va permettre de constituer les équipes de Shape et celles de Build (plus conséquentes) : les équipes Engineering et Product se réunissent afin de se partager les sujets.

Les appétits définis à la Bet table permettront quant à eux d’identifier les ressources nécessaires au bon déroulement du projet.

« Les équipes ne travaillent plus en matière d’estimation de temps, mais “d’appétit”. En d’autre termes, ils définissent le temps exact qui sera consacré aux projets, ce qui leur permet de définir les contours et l’étendue de la solution. » – Nicolas De Greef

Build

L’étape de Build permet aux équipes de prendre connaissance en détail de la documentation disponible et des recherches menées sur le sujet :

  • Les problématiques à résoudre,
  • Les hypothèses à renforcer ainsi que les nouvelles découvertes,
  • Les Rabbit-holes, No Go, wireframes,
  • La définition et priorisation des scopes afin d’avancer sur les solutions à mettre en place.
    • À savoir, chaque scope doit potentiellement pouvoir être mis en production sans dépendances vis-à-vis des autres scopes.

Lors de cette phase, Trustpair définit également les indicateurs de succès à suivre, en collaboration avec les équipes Data Analysis, pour mesurer l’impact et étudier l’adoption d’une fonctionnalité.

La phase de Cooldown

A l’issue d’un cycle de 5 semaines démarre la phase de Cooldown : une période de 2 semaines pendant laquelle les équipes Engineering vont chercher à apporter de la valeur au produit par des petits travaux et ajustements de leur choix.

Les équipes profitent donc du Cooldown pour : 

  • Fixer certains bugs,
  • Procéder à des ajustements suite au Build,
  • Gommer la dette technique,
  • Se former et monter en compétences.

schema-methode-shape-up-Trustpair

Ce qu’il faut retenir :

« Le Cycle Shape Up se décompose en 5 + 2 semaines : 5 semaines de shape et 2 semaines de Cooldown. Un rythme permettant d’éviter les effets tunnels et les projets à rallonge. » – Aurélia Amalvict

 La partie Shape va d’abord décortiquer le problème et investiguer différentes options sur la partie fonctionnelle. Le choix se fait au fur et à mesure de l’avancée du Shape.

 La partie Bet Table & Dispatch table, dite session de “paris”, constitue les réunions pendant la période de Cooldown où les parties prenantes décident des projets du prochain cycle.

Le Build correspond à la phase de développement, où sont définis en parallèle les hypothèses, problématiques à résoudre et point de vigilance.

Le Cooldown permet de prendre du recul sur le projet et d’identifier si besoin des ajustements à apporter.

Pour aller plus loin …

Vous souhaitez en connaître davantage sur la méthodologie Shape up et son application directe au sein de Trustpair ?

 Visionnez le replay de l’épisode MaestriX juste ici et découvrez l’intégralité des échanges.

Si vous souhaitez échanger avec nos deux intervenants, Nicolas De Greef et Aurélia Amalvict, n’hésitez pas à prendre contact directement avec eux sur LinkedIn.

* La méthode Scrum est qualifiée de “méthodologie Agile”. Le terme est tiré de l’anglais “scrum” et désigne en français “mêlée”. Il est mentionné pour la première fois en 1986 par Hirotaka Takeuchi et Ikujiro Nonaka lors d’une publication. L’article décrit une approche du développement produit, novatrice, plus flexible et plus rapide. Les deux auteurs mettent donc en parallèle cette méthode avec le rugby en XV.

L’équipe avance ensemble dans leur progression, leur jeu s’oriente en fonction des obstacles qui se présentent en s’ajustant au jeu de l’adversaire. Il s’agit avant tout d’un travail d’équipe symboliquement “passé” de main en main. – Source : Planet Phone

Autres articles

FAQ
Questions les plus courantes

Parcourez les différentes sections et trouvez les réponses à vos questions

Aucune donnée n'a été trouvée