💡 Découvrez toutes les fiches de lecture du Ticket ici 💡 

Frédéric Bardolle, le responsable du produit chez Cosmian, vient de lire Shape Up, la méthode pour bâtir son produit en cycles de 6 semaines. Voici ce qu’il en a retenu et ce qu’il en pense.

L’auteur: Ryan Singer

Ryan Singer a passé presque 18 ans chez Basecamp, une entreprise de logiciel, où a notamment été inventé Ruby on Rails. Son rôle là-bas a beaucoup évolué : d’abord designer, il est devenu Product Manager puis Directeur de la stratégie.

En 2019, il écrit Shape Up (en entier : Shape Up: Stop Running in Circles and Ship Work that Matters), un livre à l’intersection du produit, du logiciel et du design. Le livre est disponible gratuitement en ligne sur le site de Basecamp. Ryan Singer a quitté Basecamp en 2021 et travaille sur un nouveau projet, pour l’instant inconnu.

Le livre : Les 5 principaux points abordés dans Shape Up

1/ La découverte (Shaping) et la livraison (Building) fonctionnent en parallèle

Un des premiers aspects de Shape Up, c’est la parallélisation. La personne en charge du produit (que Singer appelle product strategist) et l’équipe de développement travaillent en parallèle.

D’un côté, le product strategist réalise une phase de découverte (shape). En parallèle, l’équipe de développement construit ce qui a été validé côté produit lors de la phase précédente (build).

(source : Shape Up)

Ces phases durent 6 semaines. Pendant ces 6 semaines, l’équipe de développement travaille sur un sujet unique, sans être dérangée. À la fin de ces 6 semaines, elle dispose de deux semaines plus calmes. Pour gérer les bugs et ce genre de choses. En parallèle, le product strategist imagine de son côté de nouvelles fonctionnalités.

2/ Prenons les paris !

Pour décrire ces fonctionnalités, le product strategist rédige des résumés (pitch) où il décrit le problème, la solution et l’appétit. Le problème et la solution : vous voyez ce que c’est. L’appétit ? Il s’agit du temps que l’entreprise est prête à consacrer à la résolution du problème. Cela peut être 6 semaines. Cela peut être 2 semaines. Auquel cas il y aura plusieurs fonctionnalités développées pendant le cycle de 6 semaines.

Avant chaque cycle de développement, l’équipe de direction parie sur plusieurs résumés, en fonction des priorités actuelles de l’entreprise. Une fois qu’un pari est fait sur un résumé, l’équipe qui va travailler dessus a la garantie (promis-juré-craché) qu’elle ne sera pas dérangée pendant le cycle, et qu’elle ne travaillera sur rien d’autre.

3/ Temps fixe et périmètre variable

Il vaut mieux, car lors d’un pari, l’appétit, c’est-à-dire le temps que l’entreprise souhaite dédier à la fonctionnalité, est fixe. 6 semaines (ou 2 selon la taille) et pas un jour de plus. En fixant le temps (et implicitement le niveau de qualité attendu), la seule variable restante est le périmètre.

Fixer le temps et laisser le périmètre (scope) variable est un des points clefs de Shape Up. Grâce à cela, personne ne va travailler sur des fonctionnalités qui prennent trop de temps à être développées, alors qu’elles n’amènent pas tant de valeur que cela finalement. Toutes les 6 semaines, il faut se réinterroger sur l’utilité, grâce au système de pari.

4/ Pas de backlog

Dans Shape Up, il n’y a pas de backlog (j’imagine la panique des disciples de Jira qui lisent cette fiche). La raison ? Les backlogs seraient une perte de temps car il faut passer un temps monstrueux à les gérer, les organiser et les réduire. Pire encore : ils nous enferment dans le passé et bloquent les idées nouvelles.

À la place d’un backlog, il y a des résumés, que n’importe qui peut écrire. Ces résumés sont présentés toutes les 6 semaines à l’équipe de direction pendant la phase de pari. Bien sûr, chaque équipe (support, développement, produit,… ) peut continuer à gérer des listes de requêtes ou de bugs de son côté.

5/ Minimiser les risques et découper intelligemment

La dernière particularité de Shape Up, c’est la minimisation des risques. Pendant la phase de mise en forme, le product strategist va essayer de détecter des pièges éventuels avec le ou la CTO. Pendant le développement, l’équipe précise si elle est dans une phase de découverte (uphill) ou de résolution (downhill) du problème.

Ce travail n’est pas fait pour l’ensemble du projet, mais pour des sous-parties que Singer appelle périmètres (scope). Ces sous-parties sont indépendantes et comprennent à la fois le back-end et le front-end.

Mon avis personnel

Évidemment, l’approche Shape Up est beaucoup plus complète et nuancée que ces cinq concepts. La bonne nouvelle c’est que si cet avant-goût vous a plu, vous pouvez lire tout le livre gratuitement, depuis votre canapé.

Pour ma part, je trouve certains des concepts de cette méthode très pertinents. Le fait que les équipes de développement ne travaillent que sur un seul sujet en même temps, sur une période de temps étendue, correspond bien aux recommandations du monde du DevOps. Dans le livre Accelerate, The Science of Lean Software and DevOps, les auteurs prouvent que limiter le nombre de tâches en parallèle est un des facteurs de succès des entreprises (en résumant grossièrement). Intuitivement, on sent bien qu’on travaille mieux quand on est focus.

L’autre idée géniale, c’est cette histoire d’appétit. Toutes les 6 semaines, par défaut les projets s’arrêtent. Il s’agit d’un excellent remède à notre aversion naturelle aux coûts irrécupérables (sunk cost fallacy), cette erreur qui nous pousse à nous entêter quand nous avons commencé à dépenser des ressources. Shape Up permet d’éviter le gaspillage en arrêtant rapidement ce qui ne fonctionne pas. Finalement, cette idée de pari s’approche de la méthode scientifique qui devrait être à la base du produit : émettre des hypothèses puis les tester de la manière la plus efficace possible.

Une chose me gène un peu quand même : la séparation entre la réflexion et la production. Le fait de prévenir l’équipe de développement qu’elle va travailler pendant 6 semaines sur un sujet, alors qu’elle n’a pas participé à la phase de découverte ferait sûrement bondir Marty Cagan ! Certes, les résumés sont censés rester suffisamment flous pour que l’équipe ait quand même un travail de design intéressant. Reste que le procédé est éloigné du combo gagnant “autonomie + responsabilité” qui existe ailleurs.

Enfin, comme pour toutes les méthodes, il faut essayer d’en dégager les grands principes et de trouver ce qui peut s’appliquer à notre contexte plutôt que de singer le fonctionnement de Basecamp. Dans une startup encore très jeune comme celle où je travaille par exemple, 6 semaines est un temps très long. La méthode Shape Up nécessite également une taille conséquente, ne serait-ce que pour avoir toujours une équipe disponible pour effectuer les corrections rapides, pendant que les autres travaillent en cycle.

Ressources additionnelles

Pour aller plus loin :

Un excellent épisode de podcast où Ryan Singer parle de Shape Up, mais également de design et d’architecture :

https://open.spotify.com/episode/76KysFjzl5TQeS26GwGZzC

Le livre : Infos pratiques

Titre : Shape Up

Auteure : Ryan Singer

Langue : Anglais

Date de sortie : 2019

(En cliquant sur la couverture, vous arriverez sur la page de l’éditeur. Et non chez qui vous savez… déso Jeff)

Je découvre les autres fiches de lecture du Ticket

A propos de Frédéric Bardolle

Frédéric Bardolle

Frédéric Bardolle est responsable du produit chez Cosmian, une startup qui permet aux entreprises d’utiliser leurs données sensibles, grâce à la cryptographie.

Avant cela, il était CPO au ministère des Armées, pour diffuser la philosophie produit dans un des environnements les moins agiles du monde.

Il a également cofondé l’association Data for Good en 2016 et écrit régulièrement sur f14e.fr et Twitter (@seiteta).