Shape Up vs. Scrum Guide — analyse et comparaison

Si vous avez atteint les limites de Scrum, cela vaut la peine de regarder Shape Up de près.

Shape Up a été développé par Ryan Singer et publié en 2019 dans le livre « Shape Up: Stop Running in Circles and Ship Work that Matters ». La méthode est née de la manière dont on travaille chez Basecamp (aujourd'hui 37signals), où Singer l'a façonnée pendant des années au fil du développement produit.

→ basecamp.com/shapeup

Je commence par une courte mise en perspective. Vous trouverez ensuite les différences listées côte à côte.

Partie 1 : Mon analyse

Des paris plutôt qu'un backlog

Shape Up fonctionne avec des paris (bets) et non avec un backlog. Je considère cela comme une amélioration très importante par rapport au Scrum Guide.

Dans les transformations agiles auxquelles j'ai contribué, nous travaillions déjà à partir d'hypothèses ou d'un business case. Les deux sont proches de l'idée d'un pari.

Un backlog se remplit rapidement de choses non pertinentes. On perd le focus, on construit parfois des choses qui n'étaient pas encore nécessaires, et on s'éloigne ainsi de la philosophie Lean, qui vise à réduire le gaspillage à travers les huit types de muda.

Shape Up revient à ces racines et se concentre sur des paris dont le cadre étroit limite fortement la portée du travail, et contient donc le gaspillage dès le départ.

Cycles plutôt que sprints

Autre avancée : le cycle. Nous connaissons tous le « waterfall en sprints » et les blagues qui vont avec — et ces blagues ont une origine réelle : on passe une éternité à travailler sur des choses qui n'apporteront peut-être jamais la valeur attendue.

Le fait de fixer la longueur du cycle dans Shape Up évite précisément cela et réduit le risque d'un retour insidieux au mode cascade.

Des équipes petites, dédiées et concentrées

Dans le modèle Shape Up, les équipes sont plus petites et affectées à un seul pari.

Dans les équipes Scrum, la réalité est souvent différente : les équipes sont trop grandes, pas vraiment pluridisciplinaires, pas totalement responsabilisées, et impliquées dans de nombreux projets en parallèle.

Dans la plupart des entreprises, une véritable implémentation complète de Scrum s'est rarement produite — sauf dans celles qui ont pris la transformation agile au sérieux et ont combiné dès le départ Scrum avec d'autres méthodes.

Pas de théâtre de processus — le résultat plutôt que les tickets

Shape Up n'impose pas de processus fixe pour ce qui est des rituels. Cela évite le « théâtre de processus ».

Il existe des organisations qui tiennent tous les événements prescrits par le Scrum Guide, sans que l'effet recherché ne se produise, parce que le respect du processus ne garantit pas que la philosophie derrière l'agilité soit réellement vécue.

Shape Up se concentre davantage sur les projets, sur les résultats.

Scrum, mal réfléchi, peut vite pousser à se concentrer plus sur le processus que sur le résultat.

Il existe des organisations où les ingénieurs se contentent de traiter une pile de tickets et perdent la vue d'ensemble.

Shape Up évite cela dès le départ : aucun ticket n'est créé ; à la place, les paris sont formulés très clairement, pour qu'une équipe ait vraiment la possibilité de travailler de façon pluridisciplinaire sur un livrable porteur de valeur.

Cette chance n'est souvent pas donnée aux équipes Scrum.

Des critères d'arrêt dès le début

Il existe des organisations qui ont introduit Scrum sans former leurs dirigeants à ce que l'agilité change pour eux.

Conséquence : personne ne définit de critères d'arrêt (kill criteria). On ne mesure pas le résultat avec des faits et des données solides.

Il existe des organisations qui ont bien compris cela et qui ont mené leur transformation agile avec exactement ces garde-fous. Mais ce n'est pas la règle.

Shape Up est ici une bonne alternative pour retenter l'expérience. Il est clair dès le départ à quel moment on arrête. On n'a pas ce train fou où l'on prolonge un sujet parce que personne n'a défini comment l'arrêter.

Der Zug hat keine Bremse (« le train n'a pas de frein ») est un tube allemand. Il me revient parfois en tête quand des entreprises n'ont aucune méthodologie pour arrêter des initiatives qui n'apportent pas la valeur attendue, parce que cette valeur n'a jamais été définie assez précisément et qu'aucun levier n'a été donné aux décideurs pour arrêter.

Shape Up est un cadre idéal pour apprendre exactement cette discipline.

Réduire le périmètre, pas la qualité

Scrum, pris au sérieux, dit déjà qu'il faut tenir la qualité et jouer sur le périmètre.

Ce qui implique logiquement que le périmètre doit être régulièrement réduit pour livrer un incrément à la qualité attendue.

En pratique, cela arrive rarement, entre autres parce que ce n'est pas très intuitif.

Shape Up est plus léger ici et oblige l'équipe à livrer, à l'intérieur du cycle, quelque chose qui satisfait le pari.

Le périmètre est donc coupé tandis que la qualité reste constante. Les limites étroites sont précisément utiles pour apprendre ce travail contre-intuitif de réduction du périmètre.

Le niveau portefeuille est intégré dès le départ

Le Scrum Guide ne prescrit aucun cadre de mise à l'échelle. C'est pour cela que sont apparus le modèle Spotify ou SAFe.

Shape Up intègre le niveau supérieur d'emblée.

Dans les transformations agiles auxquelles j'ai participé et qui ont réellement changé les choses, le niveau portefeuille était conçu dès le début.

Car c'est le levier : ne pas faire trop de choses en même temps, corriger le cap, arrêter.

Il faut toujours penser à ce niveau, et si possible à celui juste au-dessus.

Shape Up aide énormément ici. Et il est plus léger que SAFe.

Limites et prérequis : là où Shape Up seul ne suffit pas

Shape Up sera difficile à implémenter dans des équipes qui ne développent pas uniquement des produits ou des logiciels mais gèrent aussi beaucoup de demandes, de daily business, de maintenance, d'opérations et de service requests.

Pour cela, Shape Up ne suffirait pas ; d'autres méthodes seraient nécessaires.

Autre défi majeur : lorsque plusieurs équipes sont nécessaires et que leurs livrables s'appuient les uns sur les autres ou doivent être intégrés.

Ces questions doivent être pensées en amont, pour que les paris tenus par les différentes équipes ne flottent pas dans le vide mais s'intègrent entre eux.

Il faut alors examiner très précisément l'entreprise concernée et concevoir en plus des cadres sur mesure pour que tout s'imbrique.

Shape Up ne fonctionnera pas non plus là où les structures hiérarchiques ou les lignes de reporting rendent l'implémentation impossible, et là où les dirigeants n'ont pas encore développé leur propre vision du travail agile.

Il faut préparer le terrain par un engagement actif avec la philosophie sous-jacente, elle-même enracinée dans le Lean et développée sur plusieurs décennies.

Et pour chaque projet mené selon Shape Up, il faut ajuster les hiérarchies et les circuits de reporting pour qu'ils n'aillent pas à contre-courant.

Dans la pratique Lean de l'automobile, on utilise volontiers des war rooms — obeya en japonais. Il est légitime de se demander si, en phase de transformation, ce type de dispositif — au sens littéral ou figuré — n'est pas nécessaire pour donner à une nouvelle méthode comme Shape Up un terrain sur lequel elle puisse s'enraciner.

Le Lean n'a jamais été un mouvement grassroot ; il a toujours été introduit par la direction. C'est pourquoi il est important que les organisations qui s'intéressent à Shape Up en discutent depuis le sommet de la hiérarchie : comment on le comprend et comment on veut l'appliquer.

Partie 2 : Vue d'ensemble — Shape Up vs. Scrum Guide (2020)

Sources : basecamp.com/shapeup (Ryan Singer) · Scrum Guide 2020 (Schwaber/Sutherland). Seules les affirmations qui peuvent être appuyées directement par ces deux sources. Lorsqu'une source ne dit rien sur un sujet, cela est signalé comme tel.

1. Caractère de la méthode

Scrum Guide

• se définit comme un cadre léger et volontairement incomplet
• se déclare immuable : n'en implémenter qu'une partie, selon le Guide, ce n'est pas Scrum
• ne décrit aucune technique concrète ; indique que les tactiques dépendent du contexte et sont décrites ailleurs

Shape Up

• livre qui décrit la manière de travailler chez Basecamp
• contient des techniques concrètes (par ex. breadboarding, fat marker sketches, hill charts)
• l'annexe « Adjust to Your Size » distingue explicitement les vérités fondamentales des pratiques spécifiques, autrement dit l'adaptation est prévue

2. Réservoir de travail et sélection

Backlog

• Scrum : le Product Backlog est la seule source de travail de la Scrum Team ; émergent, ordonné, affiné en continu via le Refinement
• Shape Up : chapitre « Bets, Not Backlogs » — il n'y a volontairement pas de backlog central ; à la place, des listes décentralisées et un petit nombre de paris potentiels par cycle. Justification du livre : les idées importantes reviennent d'elles-mêmes

Décider ce qui est construit

• Scrum : le Product Owner ordonne le Product Backlog ; les Developers y choisissent des items lors du Sprint Planning
• Shape Up : le Betting Table — une réunion pendant le cool-down au cours de laquelle les parties prenantes décident sur quels pitchs parier pour le cycle suivant

Préparation du travail

• Scrum : Refinement comme activité continue (découpe des items, ajout de détail, ordre, taille)
• Shape Up : Shaping comme flux dédié, en parallèle de la construction ; le livrable est un pitch en cinq parties : problème, appetite, solution, rabbit holes, no-gos

3. Modèle temporel

Longueur du cycle

• Scrum : Sprints d'un mois ou moins ; un nouveau Sprint démarre immédiatement après le précédent
• Shape Up : cycles de six semaines plus deux semaines de cool-down entre les cycles

Cool-down (Shape Up uniquement)

• temps dédié aux tâches ad hoc, aux corrections de bugs et au Betting Table
• aucun élément équivalent n'existe dans le Scrum Guide

Gestion du périmètre et du temps

• Shape Up : « Fixed time, variable scope » — l'appetite fixe le temps que l'on veut y consacrer, au lieu d'estimer combien de temps prendra la chose
• Scrum : les Developers choisissent ce qui tient dans un Sprint ; le Guide cite la performance passée, la capacité et la Definition of Done comme base de la confiance dans le forecast ; les Developers sont responsables du sizing des items

4. Focus, interruptions et travail parallèle

Shape Up

• selon le glossaire, un pari est la décision de dédier une équipe à un projet pendant un cycle sans interruption, avec l'attente de livrer
• une section propre « Uninterrupted time » dans le chapitre sur le Betting Table
• « Keep the slate clean » : le cycle suivant démarre sans engagements pré-remplis
• les bugs ne sont pas tirés dans le cycle mais traités pendant le cool-down (section « What about bugs? »)

Scrum

• la Scrum Team est une unité concentrée sur un objectif à la fois : le Product Goal ; il doit être atteint (ou abandonné) avant d'en commencer un nouveau
• pendant le Sprint, aucun changement n'est fait qui mettrait en danger le Sprint Goal
• travailler en Sprints à un rythme soutenable améliore, selon le Guide, focus et cohérence
• le Guide ne dit pas si des personnes ou des équipes peuvent travailler en parallèle sur plusieurs produits/projets ; le sujet n'est pas traité

Composition des équipes

• Scrum : une Scrum Team, typiquement de 10 personnes ou moins ; quand plusieurs équipes travaillent sur le même produit, elles partagent Product Goal, Product Backlog et Product Owner
• Shape Up : équipes projet composées d'un designer et d'un à deux programmeurs ; les équipes sont constituées par cycle/projet — l'une des questions du Betting Table est « Are the right people available? »

5. Rôles

• Scrum : trois responsabilités définies — Product Owner, Scrum Master, Developers ; le Product Owner est une personne, pas un comité
• Shape Up : ne définit aucun rôle au sens du Scrum Guide
  • décrit des activités et des groupes de personnes : shapers (personnes senior, selon le livre), participants au Betting Table, équipes de construction
  • aucun rôle de processus comparable au Scrum Master n'apparaît dans le livre

6. Événements

• Scrum : cinq événements — Sprint (conteneur), Sprint Planning (max. 8 h), Daily Scrum (15 min), Sprint Review (max. 4 h), Sprint Retrospective (max. 3 h) ; les timeboxes s'appliquent à un Sprint d'un mois
• Shape Up :
  • décrit comme réunion récurrente le Betting Table pendant le cool-down
  • Daily, Review et Retrospective n'apparaissent pas dans le livre
  • la communication de statut passe par les hill charts, section « Status without asking »

7. Planification pendant l'exécution

Scrum

• Sprint Backlog = Sprint Goal + items sélectionnés + plan ; mis à jour en continu pendant le Sprint
• les items sont souvent découpés en pas de travail d'un jour ou moins ; la manière de le faire est décidée par les seuls Developers

Shape Up

• les équipes reçoivent des projets, pas des tâches (« Assign projects, not tasks »)
• le livre distingue les « imagined tasks » (imaginées en amont) des « discovered tasks » (découvertes pendant le travail)
• le travail est organisé en scopes — parties du projet qui peuvent être construites, intégrées et terminées de manière indépendante
• les nice-to-haves sont marqués d'un « ~ » et sont abandonnés si le temps manque

8. Non-livraison et arrêt

• Shape Up : circuit breaker — les projets qui ne livrent pas dans un cycle ne sont pas prolongés par défaut ; ils s'arrêtent. La prolongation est l'exception (section « When to extend a project »)
• Scrum :
  • un Sprint peut être annulé si le Sprint Goal devient obsolète ; seul le Product Owner en a l'autorité
  • les items qui ne satisfont pas la Definition of Done retournent au Product Backlog
  • aucun mécanisme par défaut qui met fin aux initiatives n'existe dans le Guide

9. Achèvement et qualité

• Shape Up : « Done means deployed » — terminé signifie livré à l'intérieur du cycle
• Scrum :
  • la Definition of Done est la description formelle de l'état de qualité d'un Increment
  • les increments peuvent être livrés à tout moment ; la Sprint Review n'est explicitement pas une porte de release

Gérer un périmètre qui grossit

• Shape Up : scope hammering — le design, l'implémentation ou les cas d'usage sont remis en question pour finir dans la timebox fixe ; le livre l'énonce clairement : « Cutting scope isn't lowering quality »
• Scrum : le périmètre peut être clarifié et renégocié avec le Product Owner pendant le Sprint sans mettre en danger le Sprint Goal ; la qualité ne baisse pas

10. Fondement théorique

• Scrum : s'appuie explicitement sur l'empirisme et le Lean thinking ; trois piliers (transparence, inspection, adaptation) et cinq valeurs (engagement, focus, ouverture, respect, courage)
• Shape Up : ne contient pas de chapitre équivalent de théorie ou de valeurs ; comme motifs récurrents, le livre lui-même cite entre autres le ciblage du risque (« Targeting risk ») et la délégation de responsabilité aux équipes

11. Niveau portefeuille (Flight Level 3)

• Shape Up décrit un mécanisme de décision récurrent au-dessus du niveau équipe : pitchs → Betting Table → un pari par cycle ; avec les questions du Betting Table (Le problème est-il pertinent ? L'appetite est-il juste ? La solution est-elle attractive ? Est-ce le bon moment ? Les bonnes personnes sont-elles disponibles ?)
• le Scrum Guide ne décrit aucun niveau au-dessus de la Scrum Team ou de plusieurs équipes travaillant sur un même produit ; la mise à l'échelle n'est mentionnée que dans la mesure où plusieurs équipes sur le même produit partagent Product Goal, Backlog et PO
• aucune des deux sources n'utilise le terme « portfolio »