La méthodologie Shape Up : Betting, Building et Cooldown

Lors de notre première partie, nous avons abordé les grands principes de Shape Up ainsi que la phase de shaping. Nous allons désormais nous intéresser aux autres grands moments: le Betting (comment choisir les projets qui seront implémentés), le Building (lorganisation des équipes et du travail de développement) et le Cooldown (pause entre deux cycles ou réelle opportunité? ).

La phase de Betting

Adieu au backlog produit

Le "Betting" a pour but de sélectionner, parmi les projets pitchés, ceux qui seront développés.

Il n'y a rien d'autre à disposition, pas de listes d'idées, ou de backlogs à revoir en session de grooming. Il y a uniquement quelques options formalisées dont les risques ont été réduits : les pitchs produits.

Les réunions de "Betting" sont moins fréquentes, souvent courtes et très productives. Les pitchs sélectionnés seront traités dans le cycle suivant, autrement, ils seront oubliés (rien n'empêche un collaborateur de garder une idée, et de la re-proposer lors du prochain cycle, ou lors d'un moment plus opportun).

L'idée principale est bien de repartir d'un état d'esprit frais à chaque nouveau cycle, de ne pas maintenir du legacy avec des fonctionnalités du dernier trimestre, de s'assurer que les projets sur lesquels on "Bet" soient nécessaires, et apportent une réelle plus-value à l'instant T.

On remarquera automatiquement une problématique qui n'est pas sélectionnée et qui refait surface régulièrement. De plus, chaque personne est libre de tracker individuellement des éléments qui lui semblent intéressants (bugs, retours utilisateurs, données, concurrences), afin de proposer une solution en phase de "shaping".

Chacun peut garder une liste individuelle de ce qu'il souhaite voir implémenté un jour.Voici une répartition du périmètre qui peut être appliquée :CTO : architecture / technologiesProduct Manager : nouveau produit / améliorationsProduct Owner : nouvelle feature / outilsDesigner : ergonomie / comportementsDéveloppeur : bug / refactorisations

La table du Betting

Les personnes présentes lors des séances de "Betting" sont généralement les mêmes que celles du "shaping". Il peut cependant y avoir des variations, comme la présence du CEO ou d'une partie prenante extérieure. Les personnes assises autour de la table doivent avoir les connaissances nécessaires pour évaluer les solutions et les risques (CTO, Développeur sénior, Product Strategist, Business Analyst, etc).

On cherche à définir notre cycle de 6 semaines, les décisions prises sont définitives et ne seront pas influencées par la suite. Il est donc essentiel d'avoir les compétences et le poids décisionnel nécessaires pour cela.

C'est également le moment où l'on assigne les équipes aux projets. On choisit les profils selon leurs compétences, au sein de notre "Core Team" afin qu'ils soient en adéquation avec les besoins du projets.

En présence de pitchs bien définis, de risques minimisés, de compétences correctement allouées, et de décisionnaires informés, les sessions de "Betting" sont désormais des moments ou l'on exerce un contrôle sur le futur du produit, plutôt qu'une bataille de ressources ou encore, une demande de priorisation.

Nos "Bets" doivent être respectés, on cherche à livrer un projet en 6 semaines, un projet avec une réelle plus-value et non pas de simples incrémentations produit. Ce sont de réels engagements, les équipes y seront dédiées et ne seront pas interrompues dans leur processus de développement. Enfin, 6 semaines, c'est aussi ce que l'on est prêt à "perdre", mais en aucun cas on ne perdra plus que le temps alloué. C'est notre plafond maximum.

Dans une logique d'amélioration, suivez vos équipes, vos projets, on notera les éléments suivants :

• big_batch : plus grosses et travaillant sur un seul projet conséquent
• small_batch : plus petites et travaillant sur plusieurs projets raisonnables
• circuit_breaker : des projets mal définis qui risquent de casser la machine. On arrêtera tout pour repartir depuis la phase de "shaping", plutôt que de forcer le passage en "Building".

Les modalités sur les cycles de développement

Il y a deux types de cycles très distincts lors du développement :

• l'ajout de fonctionnalité à un produit existant (Mode Feature)
• la création d'un nouveau produit

Pour le premier, nous sommes dans un univers connu, il n'y a pas de surprises et les phases de Betting sont donc assez simples. Dans le cas du deuxième en revanche, cela devient plus compliqué, on aura donc de petites variations au sein de nos cycles : les modes.

• Mode R&D : on ne "bet" pas sur des pitchs précis, mais sur des idées phares du produit, on cherche à apprendre lors de la phase de développement pour les prochains modes. Seuls des profils seniors font partie de l'équipe afin de répondre aux questions fondamentales (marché, architecture, technologie, etc). Enfin, on ne s'attend pas à livrer quelque chose à la fin du cycle mais à savoir ce qui fonctionne afin de finaliser les décisions structurantes.
• Mode Production : on "bet" de nouveau sur ce que l'on espère obtenir à la fin du cycle. On ne se limite plus à des profils seniors, on couvre plus de terrain avec plusieurs équipes. On délivre, cependant, le produit n'étant pas accessible aux utilisateurs, la livraison signifie "merger" sur le Codebase principal sans y retoucher ensuite.
• Mode Cleanup : il n'y a pas de période de "shaping", ici le leadership est à la manœuvre et précise les priorités, ce sur quoi il faut se focaliser. Il n'y a pas d'équipes précises, tout le monde aide de la façon possible. On continue de merger sur la Codebase, cette fois, le plus souvent possible et par petite fraction.

Chacun de ces modes peut durer plusieurs cycles, jusqu'à ce qu'une première version du produit soit disponible aux utilisateurs. On se trouvera alors de nouveau dans un cycle : ajout de fonctionnalité à un produit existant.

En mode R&D, l'équipe n'est pas forcément la même que d'habitude. On pourra y trouver les dirigeants, des C-levels et des consultants externes. Ajustez à vos objectifs, à la taille de votre structure et à la taille de vos équipes.

Comment faire ses "Bets" produit ?

On utilisera plusieurs types de questions lors des sessions de "Betting" afin de bien différencier et choisir les projets qui seront développés.

• Est-ce que la problématique est importante ? En effet, est-ce vraiment utile de prendre du temps pour une solution concernant ce problème en particulier ? Quel est le plus gros problème en ce moment ? En fonction de notre problématique personnelle, l'importance accordée à un problème variera d'une personne à l'autre.
• L'appétit est-il bien défini ? On peut, par exemple, avoir une fonctionnalité qui apporte une réelle plus-value, mais uniquement à 5% des utilisateurs. Un CTO sera peut-être moins intéressé par une fonctionnalité entraînant des dépendances. Il faut s'assurer que les appétits définis le sont pour les bonnes raisons et perspectives.
• La solution est-elle attractive ? La problématique peut être des plus importantes, la solution apportée le sera tout autant, et aura un impact sur les développements futurs du produit. Il faut donc s'assurer que l'on choisit celle correspondant le mieux à ce dernier, à notre marché, à nos utilisateurs et à nos futures évolutions.
• Est-ce le bon moment ? Le projet est peut-être "shapé" à la perfection, mais ne convient pas au but que l'on essaye d'atteindre sur ce cycle spécifique, comme stabiliser le système ou améliorer des fonctionnalités existantes.
• Avons-nous les bonnes personnes sur le projet ? On s'assure que les compétences des personnes correspondent au besoin nécessaire pour le développement du projet. Faut-il davantage de Designers ? Devrait-on avoir un Développeur Back-end ? Un Data Scientist ?

Maintenant que l'ensemble des "Bets" ont été fait pour nos pitchs, il ne nous reste plus qu'à annoncer les projets sélectionnés pour la phase de "Building".

Après la session de Betting, annoncez les pitchs sélectionnés avec un message de lancement. Vous pouvez même aller plus loin avec un compte rendu de session.

Exemple de message de lancementSource : [[https://basecamp.com/shapeup/2.3-chapter-09](https://basecamp.com/shapeup/2.3-chapter-09)](https://basecamp.com/shapeup/2.3-chapter-09)

La phase de Building

Comment lancer sa phase de Building

Le "Building", outre la livraison d'un produit ou d'une fonctionnalité, sert également à responsabiliser les équipes et collaborateurs. On leur fait confiance pour travailler à l'intérieur des limites du pitch, puis définir eux-mêmes leurs tâches et leurs approches. Ils ont une autonomie complète, pour des décisions réelles de Design et d'implémentation.

L'équipe organisera une réunion rapide de "kick-off", où l'on centralise les informations du projet, le pitch et ce qui le constitue. C'est l'occasion de poser quelques questions sur des éléments qui n'auraient pas été compris, ou qui resteraient trop vagues. Elle s'attaquera ensuite à une phase d'exploration et ne développera pas directement. C'est un moment où chaque personne de l'équipe explore la problématique, les possibilités, les solutions. Elles analysent le pitch pour comprendre comment le système fonctionne, et pour trouver le meilleur point de départ. Il est important de respecter ce moment car c'est un travail légitime : "j'essaie encore de comprendre par où commencer".

Enfin, une fois le point de départ trouvé, chacun commence réellement son design ou son développement. Puisque nous n'avons pas de backlog ou de tâches assignées, c'est un travail réel impliquant de la découverte et des dépendances. On notera, après l'ajout d'un nouveau bouton sur l'interface, qu'il manque de l'espace pour la version Mobile. Ou encore, lors d'un travail sur une base de données, que celle-ci aurait besoin d'être migrée. En bref : le meilleur moyen de comprendre ce qui doit être fait, c'est en réalisant un travail concret.

Créez des espaces de travail indépendants pour chacune des équipes. Elles ne doivent en aucun cas être perturbées par des imprévus ou des éléments extérieurs.

Morceau par morceau et critères de sélection

On pense généralement les projets en 2 couches : front-end et back-end, Design et code. Le problème, c'est que peu importe l'état d'avancement de l'un ou de l'autre, si les deux ne sont pas interconnectés, alors rien n'est réellement fait, terminé. Une page de profil ne contiendra aucune information si elle n'est pas connectée à la base de données utilisateurs. On va donc chercher à réaliser une tranche du projet en particulier. Un Designer peut se contenter des éléments d'un questionnaire et de leur hiérarchie, ce qui permettra au développeur de connaître rapidement les bases de données avec lesquelles communiquer.

Exemple de structuration rapide de formulaireSource : [[https://basecamp.com/shapeup/3.2-chapter-11](https://basecamp.com/shapeup/3.2-chapter-11)](https://basecamp.com/shapeup/3.2-chapter-11)

Il faut impérativement partir du centre du projet, quel est le but principal, quelle est la fonctionnalité principale ? En choisissant le centre, les dépendances suivront naturellement. On pourra s'appuyer sur 3 critères pour choisir ce que l'on développe en premier :

• Ce doit être central : au sein du projet, quelle fonctionnalité est essentielle pour le client ? Se créer un compte ou modifier ses informations ? L'un passera forcément avant l'autre
• Ce doit être petit : on cherche à avoir quelque chose de fonctionnel le plus rapidement possible, afin d'avancer rapidement avec les autres membres de l'équipe et s'assurer que tout le monde prend la bonne direction
• Ce doit être nouveau : si deux éléments sont centraux et petits, on choisira celui que l'on a jamais réalisé jusqu'ici. Cela permet d'éliminer des incertitudes rapidement et de mieux définir le scope du projet, de le faire avancer. On apprend.

Arrivez rapidement à quelque chose de concret, une production, et non un prototype.

Définir la portée des fonctionnalités

Avec la phase de shaping et l'analyse des points de départs, on commence à découvrir des tâches qui devront être réalisées. Puis, lors du développement, on réalise les dépendances existantes ainsi que la structure dont nécessite le projet. C'est alors que l'on peut définir les "scopes" de ce dernier, les grandes zones de développement.

Exemple de délimitation de scopeSource : [[https://basecamp.com/shapeup/3.3-chapter-12](https://basecamp.com/shapeup/3.3-chapter-12)](https://basecamp.com/shapeup/3.3-chapter-12)

Les scopes représentent les parties importantes d'une fonctionnalité qui devront être réalisées. Elles peuvent d'ailleurs l'être indépendamment les unes des autres, et sur une courte période, quelques jours tout au plus. Les scopes deviendront les éléments de langage du projet à un niveau macro afin d'aligner les parties prenantes sur l'avancement du projet.

Attention à ne pas retomber dans le spectre de la planification. On ne recherche pas les scopes, on les découvre petit à petit, ils émergent des dépendances que l'on rencontre. C'est pourquoi ils ne sont pas visibles au début du projet mais plutôt après 1 à 2 semaines, une fois le développement commencé.

On saura que l'on a défini de bons scopes lorsque :

• On a une vision générale du projet et des éléments importants
• On a un langage commun à l'ensemble de l'équipe
• On sait où placer une nouvelle tâche
• On sait donner l'état d'avancement
• On a un nombre raisonnable de tâches pour chaque scope

Il devient évident que tout au long du processus de lancement, nous découvrons de nouveaux éléments, de nouvelles dépendances, de nouveaux scopes et donc, de nouvelles tâches à réaliser. Notre date de fin étant fixée, notre créneau étant défini, nous ne pouvons tout réaliser. C'est l'occasion de faire la différence entre les “must-have” et les “nice-to-have” afin de ne pas se perdre sous une tonne de tâches à développer. Les “nice-to-have” pourront être réalisés lors de la période de Cooldown par exemple.

On découvre toujours de nouvelles tâchesSource : [[https://basecamp.com/shapeup/3.4-chapter-13](https://basecamp.com/shapeup/3.4-chapter-13)](https://basecamp.com/shapeup/3.4-chapter-13)

Vous pouvez représenter vos scopes sous forme de “to-do lists” :

• Le nom du scope
• Les tâches à réaliser
• Les tâches découvertes (must have / nice to have)

Comment définir son état d’avancement ?

Shape Up utilise un système particulier pour définir l'état d'avancement des scopes et donc du projet : the Hill. L'idée est de voir le statut d'une fonctionnalité sans avoir à compter les tâches réalisées, ni estimer celles à venir. The Hill se divise en deux parties :

• L'inconnu à découvrir et comprendre
• Le connu à réaliser et livrer. Le sommet de la colline correspondant à une tâche clairement définie, avec ses dépendances et ses points d'attention, prête à être réalisée : on sait ce que l'on a à faire. On y retrouvera donc l'état d'avancement de chacun des scopes, que les Managers pourront suivre sans perturber les équipes.

The Hill selon Shape UpSource : [[https://basecamp.com/shapeup/3.4-chapter-13](https://basecamp.com/shapeup/3.4-chapter-13)](https://basecamp.com/shapeup/3.4-chapter-13)

The Hill est un outil spécifique a Basecamp, à vous de l'adapter selon vos outils, l'important est de garder la distinction entre les éléments inconnus et connus :

• up_hill (en définition de périmètre)
• down_hill (en développement et implémentation)

Mais où doit-on s’arrêter dans le développement ?

Lorsque l'on design ou développe une fonctionnalité, chacun souhaite livrer la meilleure version possible. Nous avons pu voir, qu'au cours du développement, nous trouvions de nouvelles idées, de nouvelles dépendances, des “nice-to-have”. Au fur et à mesure que le cycle avance, il faut pourtant définir un point d'arrêt. A quel moment arrêtons-nous de développer un scope, une fonctionnalité ?

Shape-up se base sur ce qu'ils appellent la "Baseline" : ce qui est déjà disponible pour l'utilisateur (en tant que fonctionnalité actuelle ou produit concurrent). On s'intéresse ensuite au performance de la fonctionnalité, comparé au temps de développement passé par rapport à cette baseline.

Définition de la BaselineSource : [[https://basecamp.com/shapeup/3.5-chapter-14](https://basecamp.com/shapeup/3.5-chapter-14)](https://basecamp.com/shapeup/3.5-chapter-14)

A partir du moment où notre fonctionnalité apporte une plus-value par rapport à la baseline, alors le progrès est suffisant. Il est d'ailleurs également possible que notre scope ait été mal défini, et que ce dernier soit trop important.

Rien ne nous empêche alors, de redéfinir ce dernier, en se posant les bonnes questions sur les nouveaux éléments (ajouts, bugs, améliorations, redesigns), on appelle cela “le hammer” :

• Est-ce un "must-have" pour la fonctionnalité ?
• Est-ce que l'on peut livrer sans ?
• Que se passe t'il si on ne le réalise pas ?
• Est-ce un nouveau problème ou un existant ?
• Quelle probabilité d'occurrence ?
• Quels utilisateurs sont impactés ? Combien ?
• Quel en est l'impact actuel ? plus tard ?

La QA est réalisée par les membres de l'équipe directement. Tout ce qui est détecté est automatiquement un "nice_to_have" et ne change donc pas le scope. En fonction des disponibilités et de l'avancement, l'équipe passe certains "nice_to_have" en "must_have" pendant le cycle ou la période de Cooldown.

La phase de Cooldown

Le "Cooldown" a pour but de marquer une pause entre deux cycles. Cette phase ne signifie pas une relaxe totale. On s'intéresse à de la refactorisation, au traitement de bugs, à de l'amélioration de processus, de l'implémentation de “nice to have”, ou peut-être de retours utilisateurs ?

A vous d'organiser ce temps, et pourquoi pas, demander à vos équipes comment elles souhaitent en tirer profit ? Seul ? A plusieurs ? En votant ? C'est le moment d'être créatif et collaboratif !

En conclusion

Shape Up est définitivement un framework intéressant à mettre en place. Il faut cependant prendre le temps de l'analyser, de l'implémenter, en s'assurant qu'il réponde aux problématiques rencontrées au sein de l’organisation.

Il conviendra particulièrement aux petites équipes qui cherchent à optimiser leur temps de conception et de développement. Dans les faits, se passer d'une QA en tant que telle restera difficile mais pas insurmontable, à vous d'adapter le framework à vos besoins.

Cette méthode assure une réelle autonomie des équipes avec beaucoup d'effets positifs pour les collaborateurs. On regrettera un manque de visibilité sur les tests et retours utilisateurs.

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

• 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
• On "Bet" sur des projets, des fonctionnalités (pas de roadmap)
• On s'engage sans interruption (pas de nouvelles priorisations)
• On choisit son mode (Feature, R&D, Production, Cleanup)
• On définit la juste période de cycles (6 semaines conseillées)
• On respecte une période de Cooldown entre 2 cycles (2 semaines conseillées)
• On rationalise les projets en scopes (la portée des sujets d'une fonctionnalité)
• On visualise l'avancement des scopes sur deux axes “The Hill” (et non les projets)
• On priorise en différenciant les “must-have” des “nice-to-have”
• On "Hammer" ses scopes (on redéfinit la portée) lorsque trop importants
• On recommence !