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 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).
