Shape Up
Shapez le problème avant de coder. La méthode de Ryan Singer (Basecamp) pour livrer des fonctionnalités significatives en cycles de 6 semaines sans backlog infini.
Description
Shape Up est une méthodologie de développement produit créée par Ryan Singer chez Basecamp en 2019, qui remplace les sprints courts et les backlogs infinis par des cycles de 6 semaines avec un shaping stratégique en amont, une betting table pour sélectionner les projets, et une autonomie totale des équipes pendant l'exécution. Sa finalité : permettre aux petites équipes de livrer des fonctionnalités complètes et significatives sans la surcharge de planification des méthodes agiles traditionnelles. Singer a publié Shape Up comme un livre gratuit en ligne sur basecamp.com/shapeup, exposant la méthode que Basecamp utilise depuis plus de 15 ans pour construire ses produits (Basecamp, HEY). Shape Up repose sur un constat simple : les sprints de 2 semaines sont trop courts pour livrer quelque chose de significatif, et les projets de 3 mois dérivent sans fin. Six semaines est le juste milieu. La méthode fonctionne comme un studio de cinéma : le shaping est l'écriture du scénario (on définit le problème, les contours de la solution et les limites, sans spécifier chaque détail), la betting table est le greenlight meeting (les décideurs parient sur les projets qui méritent 6 semaines d'investissement), et le build est le tournage (l'équipe a toute liberté pour réaliser le film dans le budget temps imparti). Trois concepts clés distinguent Shape Up de Scrum. Le shaping produit des "pitches" qui définissent l'appétit (le budget temps) et les rabbit holes à éviter, pas des spécifications exhaustives. La betting table remplace le backlog : si un pitch n'est pas sélectionné, il retourne à la pile sans garantie d'être repris, ce qui évite l'accumulation infinie de tickets. Le cooldown de 2 semaines entre chaque cycle laisse de l'espace pour la dette technique, les explorations et la respiration. Basecamp, GitLab et ConvertKit appliquent cette méthode en production.
Objectifs
- Prioriser les fonctionnalités
- Structurer le développement
- Améliorer la collaboration d'équipe
Utilisé par
- -Basecamp (créateur de Shape Up, utilise la méthode en production depuis plus de 15 ans pour développer Basecamp et HEY)
- -GitLab (a adopté des éléments de Shape Up pour structurer ses cycles de développement à distance)
- -ConvertKit (utilise Shape Up comme méthodologie principale de développement produit)
Avantages
- Livraison de fonctionnalités complètes en 6 semaines. Contrairement aux sprints de 2 semaines qui livrent des morceaux, Shape Up livre des blocs de valeur entiers que les utilisateurs perçoivent.
- Zéro backlog infini. La betting table élimine l'accumulation de tickets et la culpabilité associée. Si un pitch ne convainc pas, il disparaît.
- Autonomie totale des équipes pendant le build. Pas de micro-management, pas de tickets détaillés, pas de daily standups imposés. L'équipe est propriétaire de sa solution.
- Le cooldown prévient le burnout. Les 2 semaines entre chaque cycle offrent un espace de respiration structurel que la plupart des méthodes agiles ne prévoient pas.
Limites
- Le shaping requiert des seniors expérimentés. Un pitch mal shapé (trop vague ou trop détaillé) condamne le cycle. Sans shapers compétents, Shape Up ne fonctionne pas.
- Moins adapté aux équipes de plus de 15 personnes. Shape Up a été conçu pour des équipes petites et autonomes. Au-delà, la coordination entre cycles devient un problème que la méthode n'adresse pas.
- Le circuit breaker peut frustrer les équipes. Abandonner un projet à 80% de complétion parce que le temps est écoulé demande une maturité organisationnelle rare.
- Pas de gestion des urgences intégrée. Si un bug critique arrive en semaine 3 d'un cycle, Shape Up ne prévoit pas de mécanisme formel pour le traiter sans perturber le cycle en cours.
Comment appliquer Shape Up
- 1
Identifier un problème à résoudre (raw idea)
Tout commence par un problème observé : un retour utilisateur récurrent, une friction dans le parcours, une opportunité business. Ne sautez pas à la solution. Formulez le problème clairement : "Les nouveaux utilisateurs abandonnent pendant la configuration parce que le formulaire a 12 champs". Laissez les raw ideas mûrir quelques semaines avant de les shaper. Output : problème formulé et validé comme digne d'attention.
- 2
Shaper le pitch (4 éléments)
Le shaping est le travail stratégique de cadrage. Un pitch contient quatre éléments : le Problem (le problème à résoudre), l'Appetite (le budget temps, fixé à 2 semaines "small batch" ou 6 semaines "big batch"), la Solution (les contours de la solution, esquissés en fat marker sketches, pas en wireframes détaillés), et les Rabbit Holes (les pièges à éviter et les limites explicites). Le shaping est fait par des seniors qui comprennent à la fois le business et la technique. Output : pitch documenté prêt pour la betting table.
- 3
Organiser la betting table
Toutes les 6 semaines, les décideurs (CEO, CTO, Head of Product) se réunissent pour parier sur les pitches qui méritent le prochain cycle. Chaque pitch est évalué sur son appétit (le rapport valeur/investissement). Si un pitch n'est pas retenu, il n'est pas mis dans un backlog : il retourne à la pile et devra convaincre à nouveau lors de la prochaine session. Pas de backlog, pas de dette de promesses. Output : 1 à 3 projets sélectionnés pour le cycle de 6 semaines.
- 4
Former les équipes pour le cycle
Chaque projet est assigné à une petite équipe (1 designer + 1 à 2 développeurs). L'équipe reçoit le pitch mais pas de tickets, pas de user stories, pas de backlog détaillé. Elle est responsable de découper le travail, de résoudre les problèmes et de livrer dans les 6 semaines. L'autonomie est totale : pas de daily standup imposé, pas de reporting quotidien. Output : équipes formées avec leurs pitches assignés.
- 5
Construire pendant le cycle de 6 semaines
L'équipe travaille en intégrant design et développement dès le premier jour. Singer recommande de commencer par les "unknowns" (les parties risquées) plutôt que par les parties faciles. Le suivi se fait via un hill chart (colline) : chaque scope passe de "figuring things out" (montée) à "making it happen" (descente). Si un scope reste bloqué en montée à la semaine 4, c'est un signal d'alerte. Output : fonctionnalité complète livrée à la fin du cycle.
- 6
Utiliser le circuit breaker si nécessaire
La deadline de 6 semaines est un circuit breaker : si le projet n'est pas livrable à la fin du cycle, il ne reçoit pas automatiquement de temps supplémentaire. L'équipe doit livrer une version réduite ou le projet est arrêté. Cette contrainte force à prendre les décisions de scope tôt plutôt que tard. C'est inconfortable mais c'est ce qui empêche les projets de dériver indéfiniment. Output : livraison ou décision d'abandon documentée.
- 7
Prendre le cooldown de 2 semaines
Après chaque cycle de 6 semaines, toute l'équipe prend 2 semaines de cooldown. Pas de projet shapé, pas de deadline. C'est le moment pour corriger des bugs, explorer des idées techniques, nettoyer la dette, ou simplement respirer. Le cooldown n'est pas optionnel : sans lui, le rythme de 6 semaines devient insoutenable. Output : bugs corrigés, explorations menées, équipe rechargée.
- 8
Itérer avec le prochain cycle
Le cycle suivant commence avec une nouvelle betting table. Les pitches non retenus au cycle précédent peuvent revenir, améliorés par les apprentissages. Les pitches déjà livrés peuvent engendrer des follow-ups shapés. Chaque cycle est une ardoise fraîche : pas d'accumulation de dette de backlog. Output : nouveau cycle lancé avec les projets les plus prometteurs.