La méthodologie produit Shape-up : les grands principes

La méthode Shape Up est une nouvelle mise en application de lagilité. Formalisée par Ryan Singer, elle s'est conceptualisée auprès des équipes de Basecamp. Au revoir Backlogs, Sprints, Dailies et Story Points, on y trouve des cycles de 6 semaines (shaping, Betting, Building), des moments de Cooldown et des définitions dappétits. On obtient un haut niveau de qualité et de livraison, une grande implication des équipes, et une responsabilisation des collaborateurs.

Les grands principes

Les problématiques du développement produit

L'agilité a révolutionné les méthodes de travail depuis son arrivée, l'époque du développement en cascade semble lointaine, pourtant, il subsiste quelques problématiques.

L'alignement des équipes autour d'un projet, d'un groupement de fonctionnalités, est bien meilleur qu'auparavant, cependant, on observe toujours une séparation des métiers (Opération, Produit, Développement, Data).

Les cycles de développements s'enchaînent, les produits évoluent, les utilisateurs sont de plus en plus exigeants, de nouvelles idées émergent constamment. Les développeurs travaillent donc sans apercevoir une fin de projet : ils délivrent en continu.

Les Product Managers sont guidés par les tests utilisateurs, les données, les insights et n'ont plus le temps de penser une réelle stratégie produit.

De manière générale, le sentiment de satisfaction lors de la mise en production d'une fonctionnalité se dissipe. Affinage après affinage, découpe après découpe, nous ne sommes plus que les exécutants de tâches partagées : l'implication diminue.

Shape Up n'est pas pour autant un framework clé en main tel Scrum, ou Kanban. C'est une méthodologie qui se doit d'être adaptée à la taille et aux compétences des équipes en fonction des problématiques que l'on cherche à résoudre.

Pour un premier essai, on vous conseille de ne pas chercher pas à respecter toute la méthodologie Shape Up. Choisissez une équipe (2 à 4 personnes), travaillant sur un projet entier (ou fonctionnalité), pendant 6 semaines (laisser un peu de marge), sans aucune interférence (ni interruption). Il ne reste plus qu'à itérer en améliorant, et en se rapprochant petit à petit de la méthodologie.

Des cycles de 6 semaines (+2)

Premièrement, le temps de cycle. On ne cherche pas à obtenir une livraison à valeur ajoutée pour le produit, constitué d'User Stories, de micro-tâches, d'améliorations et de corrections de bug. L'objectif est la définition, conception, construction et livraison de fonctionnalités complètes.

C'est sûrement l'une des premières difficultés lorsque l'on souhaite mettre en place Shape Up. Il faut décider d'un temps de cycle permettant :

• une livraison de fonctionnalités significatives (même 1 seule)
• une gestion du temps efficace
• une date de mise en production à portée de main

Les cycles se divisent ainsi (et sont en parallèle) :

• 6 semaines de Shaping + 2 semaines de Betting
• 6 semaines de Building + 2 semaines de Cooldown

Les cycles de Shape Up_Source :_

Libéré des cérémonies agiles, du backlog ou de la roadmap, on se concentre sur le produit à un niveau plus élevé : quelles fonctionnalités actuellement utiles souhaitons-nous mettre en production à la fin du cycle ?

La constitution des équipes est à adapter selon vos besoins.Les équipes Shape & Bet : 3 à 5 personnes séniors (expertise)Les équipes Build & Cooldown : 2 à 4 personnes (livraison)

Le Shaping produit, c'est-à-dire ?

Deuxièmement, on "Shape" le projet. Cette phase se déroule en parallèle du "Build", elle concerne des collaborateurs seniors pour toutes les parties prenantes concernées (Opération, Design, Développement, Data, etc). L'équipe définit les éléments essentiels aux solutions. Elle cherche à définir le scope du projet sans pour autant se perdre en détails. Un juste milieu entre abstrait et concret, afin de laisser libre cours à la créativité des équipes embarquées. Cela permet de repositionner une phase de discovery au centre du processus Produit.

C'est lors du Shaping que la notion d'appétit apparaît. A quel point souhaitons-nous voir cette fonctionnalité livrée ? Combien de temps souhaitons-nous y consacrer ? Quelle est sa valeur ? On définit l'investissement et l'intérêt porté à un projet et non sa complexité.

A vos débuts, si la phase de Shaping vous semble offrir trop de possibilités, choisissez quelques thèmes, afin de restreindre les champs possibles pour le développement de nouvelles fonctionnalités. Exemple : nouvelles fonctionnalités uniquement + "ajout de produit" + "paiement"

Les phases de Betting et de Cooldown

Troisièmement, les phases de Betting et Cooldown se déroulent en même temps.

La phase de Betting, c'est celle ou l'on choisit les projets qui seront livrés, on priorise parmi tous ceux qui sont proposés, on s'assure du scope et de la faisabilité. Que se passe-t-il pour les projets laissés de côté ? On les met de côté, tout simplement. Rappelez-vous, nous n'avons plus de backlog. Ces projets n'apportent peut-être pas assez de valeur à l'instant T ? Ils seront peut-être exécutés plus tard, lorsque leur valeur sera plus en adéquation avec les besoins utilisateurs.

La phase de Cooldown permet aux équipes de souffler, de s'aérer et surtout de marquer la fin du projet sur lequel elles ont travaillé. Car c'est bien là l'objectif de Shape Up : avoir des cycles permettant de délimiter le début et la fin d'une étape à valeur ajoutée. On pourra dès lors se concentrer sur un projet annexe, un nouvel outil, de la refactorisation, de l'amélioration, etc.

Betting : invitez de temps en temps une personne plus junior, elle pourra ainsi monter en compétence, tout en partageant un point de vue différent. Cooldown : proposez des thèmes généraux, faites voter les équipes, ou laissez la place à l’autonomie individuelle.

Une responsabilisation des équipes favorisée

Enfin, on responsabilise une équipe chargée de la réalisation. Constituée des compétences nécessaires à la réalisation de ce dernier (Designers, Développeurs, Data Scientists), l'équipe est libre de ses choix quant aux solutions à apporter, aux technologies à utiliser, et à son organisation. Elle ne se focalise pas uniquement sur la résolution de tickets.

On arrive ainsi à allouer efficacement le travail de l’équipe. Les équipes Senior passent moins de temps à accompagner les opérationnels et peuvent se concentrer sur la phase de Shaping. Les équipes sont davantage indépendantes et responsables de leur projet sur la phase de Building. Les projets sont mieux définis et donc mieux réalisés. Shape It !

Redéfinissez les équipes à chaque cycle : les compétences nécessaires ne sont plus forcément les mêmes. Le changement est également rafraîchissant au bout de 6 semaines.

Shape Up, avant d'aller plus loin

Nous allons par la suite nous pencher sur ces différentes phases (Shaping, Betting, Building, Cooldown), avec les avantages et les inconvénients qu'elles procurent. Avant cela, prenons le temps de résumer.

Shape Up permet de répondre aux problématiques rencontrées lors de l'utilisation de frameworks tel que Scrum. Elle doit être mise en place et adaptée à chaque structure, itération après itération. Son approche est très différente, si ce n'est unique. On se focalise sur des cycles de 6 semaines, des projets scopés, des équipes réduites. Dans l’idéal, ces dernières ont toute autorité quant à leur organisation et aux choix effectués.

Pour des conseils et astuces afin de mettre en place Shape Up, voici le guide (anglais).

La phase de shaping

Est-ce du Sketching ?

Le "shaping" a pour but de cadrer et pitcher le projet, tout en laissant de la place pour la créativité et l'autonomie des équipes lors du "Building". Il faut donc définir le cadre sans apporter trop de détails. C'est la toute la subtilité et la difficulté du sujet. Habituellement, lors de la phase de delivery, les équipes se retrouvent à digérer des wireframes et des User Stories.

Les premiers sont bien trop concrets et imposent un cadre aux Designers, ils les interprètent et les réalisent. Ils ne participent donc pas à leur élaboration et non pas la possibilité de les re-penser, basé sur leur connaissance en la matière. Les seconds sont au contraire bien trop abstraits, les Développeurs ne visualisent pas le rendu, n'ont pas le contexte, et manquent d'information.

Quand on Shape, on Sketch !

Exemple de Sketch "Shapé" d'une fonctionnalité AgendaSource : [https://basecamp.com/shapeup/1.1-chapter-02#wireframes-are-too-concrete](https://basecamp.com/shapeup/1.1-chapter-02#wireframes-are-too-concrete)

Le principe est donc de dessiner l'idée générale sans éléments spécifiques. On laisse ainsi l'espace nécessaire aux Designers et Développeurs, pour apporter leur expertise et leur créativité. Ils sont maîtres de la solution et des choix techniques, ils sont responsables et impliqués.

La méthodologie parle de projets. Concrètement, à la fin du shaping, vous aurez plusieurs pitchs. Un pitch concernera par exemple une fonctionnalité Agenda pour le site internet (c'est un projet).

Qui "Shape" lors du shaping ?

Nous l'avons vu, la phase de shaping concerne l'ensemble du projet : les priorités business, l'interface du produit, les choix techniques opérés. On design le travail : ce que fait la fonctionnalité, comment elle fonctionne, quelle est sa place au sein du produit actuel ?

L'ensemble de ces aspects devant être abordés, on retrouvera des Lead Designers, des Leads Développeurs, des Product Managers, des parties prenantes, etc. Des profils seniors avec les connaissances nécessaires pour justifier les solutions choisies. Attention, on ne cherche pas le détail, mais des solutions aux problématiques.

Que cherche t'on à résoudre ? Pourquoi cela a-t-il de la valeur ? Quel sera le succès ? Quels utilisateurs sont concernés ? Quel est le coût de cette solution par rapport à une autre ?

On notera 4 étapes lors du shaping :

• Définir les limites : on détermine le temps que le projet brut mérite pour la définition du problème. Cela fixe nos limites pour le shaping.
• Sketcher les éléments : la partie créative. On cherche à dessiner rapidement des solutions, entre abstrait et concret. Le but étant de rapidement explorer un maximum de possibilités. A la fin, une solution est choisie, sans avoir défini son "appétit".
• Gérer les risques et les oubliés : maintenant que l'on a une solution, on cherche à prévenir des oubliés, des risques techniques, des dépendances, etc. On analyse les points sensibles pour que les équipes ne se retrouvent pas bloquées.
• Écrire le pitch : maintenant que l'on a "shapé" notre solution, on la pitch. On résume la problématique, les contraintes, la solution, les risques et les limites. C'est ce qu'on présentera lors de la phase de Betting et du kick-off projet.

Rédigez une liste de questions et de points à respecter pour ces 4 étapes. Revisitez-les à chaque nouveau cycle afin de les améliorer. Faites-les challenger.

La construction du Pitch produit

Le pitch produit se structure autour de 5 éléments :

• La problématique : une idée brute, un cas spécifique, un sujet motivant, une fonctionnalité
• L’appétit : combien de temps souhaitons-nous investir et quelle est l'importance de la solution
• La solution : l'élément principal que l'on a définit, sous une forme facile à comprendre pour les équipes
• Le risque : les points de la solution qui méritent une attention particulière
• Les no-gos : tout ce que l'on ne couvrira pas, afin de ne pas dépasser le scope du projet et respecter l'appétit défini

Exemple de pitchSource : [https://basecamp.com/shapeup/1.5-chapter-06](https://basecamp.com/shapeup/1.5-chapter-06)

Vous pouvez utiliser n'importe quel outil permettant de vous construire un centre de documentation et de suivi de tâches (to-do liste) : Asana, Basecamp, Google Suite, Notion, Confluence. Prenez simplement garde à ne pas renouer avec Roadmaps, Backlogs, Vélocité, etc.

En attendant la suite du Framework

Dans la suite de notre article, nous appréhenderons les autres phases de Shape up :

• le Betting (comment choisir les projets qui seront implémentés)
• le Building (l'organisation des équipes et du travail de développement)
• le Cooldown (pause entre deux cycles ou réelle opportunité ?)

Si l'on devait retenir quelques éléments de cette méthodologie jusqu'ici :

• On "Shape" notre travail (on encadre, on délimite)
• On définit des appétits et non des Story Points (l'intérêt et non la difficulté)
• On design au juste niveau d'abstraction (sketches)
• On conceptualise les idées (pas de prototypes)
• On formalise nos pitchs