Scrum vs. Shape Up : les différences

Auteur : Marc Rovira Vall
Source : Scrum vs. Shape Up: Diferencias
Date : 05/01/2023

---

Traducteur : Fabrice Aimetti
Date : 19/12/2023

---

Traduction :


Illustration créée par l'auteur avec Excalidraw

Dans l'article précédent, nous avons vu que Scrum et Shape Up partagent certaines similitudes. Dans cet article, nous verrons qu'il existe également des différences significatives entre les deux.

Quelles sont donc ces différences ?

Sprints vs Cycles

Illustration créée par l'auteur avec Excalidraw

Scrum fonctionne généralement par sprints de deux semaines, sans interruption entre la fin d'un sprint et le début du suivant, selon un modèle de développement itératif et incrémental (en).

En revanche, les cycles de développement standard de Shape Up sont d'environ 6 semaines, plus une période de relâchement (Cool-down) de 2 semaines, suivant également un modèle "itératif et incrémental", mais non consécutif dans le temps. Dans Shape Up, nous partons d'un document Pitch, qui est le résultat de l'étape Shaping, et à partir de là, l'équipe (de développement) commence à ordonner le travail qu'elle découvre qu'elle doit faire, en identifiant les différents éléments du logiciel qui le composent, en commençant par l'épicentre, découvrant ainsi les problèmes à résoudre en suivant un ordre logique d'exécution. Dans Shape Up, pratiquement toute nouvelle fonctionnalité est mise en œuvre en un seul cycle de 6 semaines au maximum, mais il peut arriver que quelque chose d'important ait été oublié dans le cycle par manque de temps (le but que nous nous sommes fixé). Dans ce cas, nous pouvons toujours procéder à une nouvelle mise en forme (shaping) des améliorations qui ont été laissées de côté (qu'il s'agisse d'aspects de conception UX/UI, de cas d'utilisation non envisagés, de nouveaux paramètres de configuration, etc. De cette façon, nous appliquerions un développement "itératif", car il nécessite une nouvelle itération sous la forme d'un nouveau mini-projet dans lequel le même processus de travail est répété ; et "incrémental" parce que cette nouvelle itération serait comme un affinage de la première. Et tout cela dans des intervalles de temps non consécutifs, contrairement à Scrum où les sprints d'affinage se succèdent les uns après les autres.

Estimations vs But

Illustration créée par l'auteur avec Excalidraw

Une autre différence essentielle est que, normalement, lorsque nous planifions un sprint dans Scrum, nous le faisons en estimant les user stories que nous avons dans le Backlog Produit, habituellement avec des story points. Mais il est bien connu que les estimations se révèlent souvent erronées. Et bien sûr, c'est tout à fait compréhensible, en particulier pour le travail de nature technique : ce que nous imaginons devoir faire et ce que nous devons réellement faire lorsque nous nous salissons les mains en touchant du code sont deux choses différentes. Ensuite, lorsque le travail prend plus de temps que prévu, des tensions se créent entre les équipes Produit et Ingénierie, car le projet traîne en longueur au fil des sprints successifs.

L'approche Shape Up est complètement différente, et nous parlons ici de but plutôt que d'estimation. Il n'est plus demandé à l'équipe de développement de dire ce qu'elle pense être l'effort requis pour réaliser un travail donné, mais c'est en fait le responsable produit (avec la bénédiction des responsables commerciaux) qui décide de la quantité de temps et d'argent que l'entreprise est prête à investir dans ce travail. En d'autres termes, ils donnent à l'équipe un budget temps (selon une configuration d'équipe donnée) pour réaliser un travail, et il s'agit là d'un raisonnement complètement différent. Il s'agit en fait d'une focalisation stratégique sur la valeur de ce qui doit être fait, sur l'urgence du moment, ainsi que sur les autres choses qui se produisent dans l'entreprise et qui devront être faites par la suite. Tout cela est possible parce qu'il y a différents niveaux dans lesquels nous pouvons faire les choses. Par exemple, si nous disons que nous voulons construire un bateau, nous pouvons construire un bateau à rames, un bateau à moteur ou un yacht ; et bien sûr, les concepteurs, les programmeurs et les personnes qui fabriquent des objets voudront toujours faire des yachts pour donner le meilleur d'eux-mêmes. Le Produit-Commercial, quant à lui, peut avoir une idée complètement différente.

Affinage du Backlog vs Shaping

Illustration créée par l'auteur avec Excalidraw

L'affinage du Backlog dans Scrum est souvent considéré comme une activité à temps partiel, réservant 5 à 10% de la capacité de l'équipe Scrum (complète ou partielle) pendant le sprint en cours pour préparer les stories du prochain sprint (ou des deux prochains sprints).

En revanche, le Shaping dans Shape Up est pratiquement un travail à temps plein effectué par un profil Produit senior (type Product Manager) pendant les 6 semaines du cycle, qui, après que le pari ait été effectué (dans l'étape Betting), le Pitch résultant est transmis à l'équipe de développement pour qu'elle l'exécute. Au cours de l'étape Shaping, les experts techniques (analystes, architectes, programmeurs, concepteurs UX/UI, testeurs QA, etc.) sont impliqués de temps à autre pour évaluer la faisabilité technique de ce qui est défini (en effectuant des spikes si nécessaire). Leur implication précoce aide également l'équipe de développement à s'approprier le projet (meilleure acceptation) au moment de se mettre au travail (à l'étape de la construction).

Une autre différence est que l'affinage dans Scrum se fait au niveau de la story utilisateur et affecte le Backlog Produit (ajout de détails techniques et d'estimations dans les stories, repriorisation du Backlog, etc.) ; alors que dans Shape Up le shaping se fait au niveau du document Pitch sans aucun effet sur le Backlog parce que dans Shape Up le concept de Backlog tel que nous le connaissons n'existe pas.

Epics et User Stories vs Document Pitch

Illustration créée par l'auteur avec Excalidraw

Une autre différence que nous constatons est que dans Scrum, vous travaillez avec des " flux de tickets ", où vous avez essentiellement un tas de tickets (compris comme des éléments qui composent le Backlog Produit) dans un outil de ticketing comme JIRA, Github, Trello ou autre, et il y en a toujours un qui commence par un : en tant que <type d'utilisateur>, je veux <fonctionnalité>, pour <obtenir un bénéfice>. En soi, ce n'est pas mauvais, mais le problème est que chaque ticket provient souvent de différentes parties de l'application/du système, ce qui signifie que l'équipe doit constamment changer de contexte. Imaginons qu'un développeur travaille, par exemple, sur quatre ou cinq tickets pendant le sprint et que chaque ticket provienne d'une partie complètement différente de l'application. Il est alors continuellement obligé d'apprendre différentes parties de l'application, ce qui lui prend beaucoup de temps et d'énergie. Parfois, cela se produit parce que l'objectif du sprint n'a pas été défini de manière suffisamment claire.

Là encore, l'approche est complètement différente de celle de Shape Up. La personne responsable du produit est celle qui prépare une proposition de mini-projet (ou Pitch), qui définit, au niveau d'abstraction approprié, ce qui doit être réalisé au cours des 6 prochaines semaines (ou 2 semaines s'il s'agit d'un projet plus petit). Une fois la proposition préparée et prête à être mise en œuvre, l'équipe de développement se voit accorder l'autonomie sur le mini-projet dans la phase de construction, et l'équipe s'auto-organise comme elle l'entend pour mettre en œuvre ce qui est décrit dans le Pitch.

Priorités vs Binarité

Illustration créée par l'auteur avec Excalidraw

Dans Scrum et d'autres cadres agiles, nous avons l'habitude d'utiliser des techniques de priorisation comme celles décrites dans la partie gauche de l'illustration pour prioriser les Backlogs ou les longues listes de choses que nous voulons faire. Les gens semblent les adorer, mais dans le développement de produits digitaux, lorsqu'il s'agit de choisir ce qu'il faut faire ensuite, la réponse finit toujours par être binaire : "oui" ou "non", "maintenant" ou "pas maintenant", un "peut-être" est un "non" (pour l'instant). Le fait d'être binaire sur ce que nous choisissons de faire apporte de la clarté sur ce que nous devrions faire.

Shape Up est binaire dans la prise de décision qui a lieu à la table de pari dans l'étape Betting (choisir les quelques options dans le format Pitch qui vont dans le cycle suivant), par opposition au choix des différents tickets qui constituent le backlog du sprint dans Scrum.

Taille et composition de l'équipe

Illustration créée par l'auteur avec Excalidraw

En ce qui concerne les équipes, la taille standard d'une équipe Scrum est de 10 personnes au maximum, avec au moins un Product Owner, un Scrum Master et plusieurs développeurs composant l'équipe Scrum, selon le Guide Scrum 2020.

Avec Shape Up, les équipes de développement de produits sont composées de 2 ou 3 personnes au maximum (généralement un concepteur et un ou deux programmeurs). Les testeurs QA et les autres profils techniques transversaux sont impliqués ponctuellement lorsque cela est nécessaire. Avec des équipes de 3 personnes au maximum dans l'équipe de développement principale, la communication et l'interaction sociale entre les différents membres de l'équipe sont grandement simplifiées. Une équipe de 3 personnes signifie qu'il ne peut y avoir qu'un maximum de 3 canaux de communication ouverts à tout moment (voir la partie droite de l'illustration). Le simple fait d'ajouter une personne à l'équipe augmente la complexité de manière exponentielle (4 personnes signifient 6 canaux de communication possibles ouverts en même temps). Avec deux personnes, il y a une communication directe, c'est-à-dire qu'elles peuvent se parler. Avec trois personnes, elles ne se parlent plus, mais ont une conversation. Et avec quatre personnes ou plus, la seule chose qu'ils peuvent faire est une réunion. Il devient alors plus difficile de tenir tout le monde informé. Plus il y a de personnes impliquées, plus les choses vont lentement.

En outre, les équipes de taille importante impliquent des discussions plus longues, il est plus difficile de parvenir à un consensus, il est plus difficile de partager des connaissances importantes entre les membres, et l'alchimie qui se crée n'est pas la même que dans les petits groupes. Des silos peuvent même être créés au sein de l'équipe elle-même (les programmeurs d'un côté, les concepteurs de l'autre, les testeurs QA de l'autre, etc.)

Une autre différence concernant les équipes est que dans Shape Up, les personnes sont généralement sélectionnées (à la table de paris) pour travailler sur un projet spécifique, c'est-à-dire que les équipes sont reconfigurées à chaque fois. Dans Scrum, en revanche, le travail est confié à l'équipe et la composition de l'équipe ne change généralement pas en fonction des besoins du projet.

Vélocité de l'équipe

Crédits à Salsita Software (partie droite), retouché par l'auteur (partie gauche) avec Excalidraw

Dans Scrum, il existe une formule (voir la partie gauche de l'illustration) qui sert d'indicateur de la performance de l'équipe à un moment donné. Cette formule de vélocité de l'équipe est ensuite utilisée pour prédire le temps nécessaire (ou le nombre de sprints nécessaires) pour terminer une fonctionnalité donnée qui se trouve encore dans le Backlog.

En revanche, Shape Up propose de créer des environnements sans distraction afin d'atteindre une productivité élevée au sein de l'équipe. Chaque petite distraction peut coûter 20 minutes à un développeur avant qu'il ne revienne à un état productif. Si nous devions résumer l'approche de la productivité chez Shape Up par une formule fictive, elle ressemblerait à celle qui figure à droite de l'illustration : pour atteindre une productivité élevée, nous devons limiter le nombre de réunions, éviter les conversations inutiles et ne pas perdre de temps avec des tâches bureaucratiques qui n'ajoutent pas de valeur à l'équipe ou au produit, comme l'utilisation d'outils de ticketing (tels que JIRA), de rapports inutiles ou de contrôles du temps de travail. Si nous parvenons à protéger l'équipe des distractions, nous avons déjà gagné la moitié de la bataille. La deuxième partie de la formule consiste à s'assurer que l'équipe ne perd pas de temps et d'énergie sur des choses sans importance. Par conséquent, l'équipe ne doit pas compliquer à l'excès la mise en œuvre des fonctionnalités (il faut toujours viser la simplicité), ne doit pas sur-ingénieriser le code et ne doit pas travailler sur des tâches nice-to-have.

Conclusion

Alors, est-il possible de travailler dans un environnement sans backlogs, sans que les managers découpent le travail à faire et que les programmeurs agissent comme de simples preneurs de tickets (ticket-takers), sans post-its sur les murs, sans estimations avec des story points, sans la nécessité de participer à des rituels tels que des mêlées quotidiennes et d'autres cérémonies où l'on accorde beaucoup d'importance aux choses qui sont faites, sans la nécessité de suivre constamment la vélocité de l'équipe, sans le rôle d'un Scrum Master, et enfin sans un Chef de Projet chargé de maintenir l'équilibre entre le périmètre, le coût et le délai (le triangle de fer) du projet ?

La réponse est oui, et elle s'appelle Shape Up.

Voilà pour les différences entre Scrum et Shape Up. Dans un prochain article, nous verrons comment passer de Scrum à Shape Up sans mourir en cours de route.

Merci beaucoup d'avoir lu cet article, partagez-le si vous l'avez aimé et postez vos commentaires ci-dessous. Si quelque chose que vous avez lu a éveillé votre intérêt et que vous avez envie d'essayer Shape Up, n'hésitez pas à me contacter.

À propos de l'auteur

Je suis passionné par les nouvelles méthodes de travail et par l'organisation des équipes de produits et d'ingénierie afin d'en faire des équipes performantes et très motivées, garantissant la prévisibilité et la qualité des produits livrés. Je suis très attaché à la méthode Shape Up, une nouvelle approche du développement de produits numériques qui va au-delà des méthodes Agile, Lean, Kanban et Scrum.