Shape Up : agile ou pas ?Avec un récent changement de contexte (passage d’un éditeur de logiciels faisant parti d’un groupe composé d’une dizaine de milliers de collaborateurs à un acteur du secteur immobilier à taille humaine, dont le cœur de métier n’est pas l’informatique), j’ai eu l’occasion de me confronter à quelque chose que je ne connaissais pas encore et qui sort des approches habituelles que l’on peut croiser autour de l’agilité : ShapeUp.

Shape Up, dans les grandes lignes

D’où ça vient ?

La société Basecamp, initialement un acteur du secteur du webdesign, n’était pas convaincue par les méthodes de gestion de projet qu’ils utilisaient jusqu’alors. L’opposition entre détails d’implémentation à gérer au jour le jour et planification à plus long terme est un constant dilemme à gérer.

C’est donc partant de ce constat que Ryan Singer a décidé d’élaborer sa propre solution pour répondre à cette problématique, en la consignant dans un ouvrage : « Shape Up – Stop running in circles ». Mais il ne s’est pas contenté de cela, il a également conçu l’outil informatique permettant d’aider dans la mise en oeuvre de cette méthode, et c’est avec cette même méthode qu’il conçoit l’outil. Fantastique, un peu comme construire une imprimante 3D avec une imprimante 3D !

Comment ça marche ?

L’approche Shape Up se compose de trois grandes étapes :

• Shaping : phase durant laquelle le besoin est étudié. Il en résulte un pitch, présenté par la suite lors d’une « betting table », durant laquelle sont sélectionnés les pitchs qui entreront ensuite dans la phase de construction.
• Betting : Cette phase est marquée par un évènement nommé la betting-table. C’est le moment durant lequel les prochains sujets (pitchs) sont élus pour être pris en charge par les équipes de réalisation.
• Building : d’une durée fixe de 6 semaines, durant laquelle chaque équipe (composée de 2 ou 3 personnes) entre en mode ininterruptible et met en oeuvre tous les moyens qu’elle a à sa disposition pour répondre au besoin énoncé par le pitch et dont la phase de conception précédente aura permis d’éliminer au maximum les risques et les inconnues, tout en laissant à l’équipe un maximum de libertés dans son implémentation.
• Cool-down : Oui je sais, j’avais dit 3 😅, mais en fait, elle intervient en parallèle de la phase de betting. Phase de 2 semaines durant laquelle les équipes peuvent souffler. Ce temps-là peut être alloué comme bon leur semble : formation, dojos, projets personnels, résolution de bugs, …

Dans les détails

Shaping

Cette phase présente un process bien cadré, bien défini, tant sur les personnes impliquées que sur la méthode utilisée ou le résultat attendu. On y déroule 4 étapes :

• Set boundaries
• Rough out the elements
• Address risks and rabbit holes
• Write the pitch

Set boundaries

C’est la toute première étape qui marque l’émergence d’une idée, avant qu’elle ne devienne un projet. Il s’agit ici de définir l’appétit que l’on souhaite se donner sur un sujet donné. Nous en reparlerons un peu plus loin, cet appétit est conditionné à la dimension de l’équipe (1 à 2 développeurs + 1 designer) et à la dimension temporelle du batch (6 semaines). A partir de là, il est donc possible pour les personnes réalisant le shaping, de déterminer ce qui est envisageable ou non de réaliser avec ces contraintes, est-ce que l’on souhaite consommer l’intégralité de ces 6 semaines sur ce sujet (ce qui en fait un big batch), ou bien, seulement une partie, qui sera alors combinée avec d’autres sujets sur cet intervalle de 6 semaines (on parlera alors de small batch).

An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.

p. 22

Shape Up tend à renverser la tendance qui est de définir les limites d’un projet et estimer le temps nécessaire à le réaliser. Ici, la limite temporelle est posée, il faut voir ce qui est réalisable dans ce contexte.

Rough out the elements

Alors que les contraintes ont été posées, et donc que l’appétit à été défini, il faut maintenant définir un peu plus précisément ce qui est souhaité. A cette étape, la méthode tend à trouver un équilibre entre donner un maximum de détails afin qu’il n’y ait pas de confusion possible sur le besoin et le résultat attendu, le « quoi », mais sans pour autant orienter de manière trop précise le « comment », afin de laisser une marge de manœuvre maximale à ceux qui réaliseront l’implémentation.

A cet effet, le livre présente notamment deux outils : le breadboarding (abordé un peu plus loin dans cet article), et les dessins au marqueur. Ce n’est pas plus compliqué que ça.

Address risks and rabbit holes

L’objectif de cette phase est de faire en sorte d’être le plus serein possible lorsque le pitch sera rédigé, réduire le risque au maximum, afin de garantir que ce qui est proposé, est raisonnablement réalisable. Ainsi, le risque de faire totalement échouer le batch est très réduit.

Notamment, les questions suivantes, directement extraites du livre sont posées :

– Does this require new technical work we’ve never done before?
– Are we making assumptions about how the parts fit together?
– Are we assuming a design solution exists that we couldn’t come up with ourselves?
– Is there a hard decision we should settle in advance so it doesn’t trip up the team?

p. 38

Write the pitch

Une fois le sujet identifié, borné, dérisqué, il est temps de le présenter. Pour cela, chez Basecamp, ils utilisent un formalisme qu’ils nomment le pitch. Celui-ci se compose de 5 ingrédients :

• Problème : Qu’est-ce qui a amené à envisager ce sujet ?
• Appétit : Combien de temps se donne-t’on pour la réalisation ? Habituellement 6 semaines ou moins dans le cadre d’un small batch
• Solution : Qu’est-ce qui est envisagé pour répondre au problème ?
• Risques : quels problèmes pourraient survenir lors de la réalisation et comment les éviter ?
• No-gos : Dans quelle direction ne souhaite-t’on pas partir pour rester réaliste ?

En principe, les réponses à toutes ces questions ont été apportées durant la phase de shaping. Il s’agit simplement ici de les mettre en forme. Ce pitch doit prendre la forme d’un document facile à lire. A cet effet, il peut embarquer les breadboards réalisés, les dessins au feutre, éventuellement des maquettes très sommaires. Il doit donner envie. Il est important de noter qu’il n’est pas l’équivalent d’une spécification, l’esprit de Shape Up étant de laisser un maximum de place aux équipes de réalisation pour décider de leur implémentation (tant sur le côté UI/UX que technique).

Ci-dessous, un exemple de pitch réalisé chez Basecamp :

Betting

Les pitchs étant prêts, vient alors la période de les soumettre aux décideurs, aux équipes de réalisation, bref, à tout ceux qui pourraient avoir un avis à émettre à leurs sujets. Ceux-ci sont soumis de manière totalement asynchrone.

We prefer asynchronous communication by default and escalate to real-time only when necessary. This gives everyone the maximum amount of time under their own control for doing
real work. That means the first step for presenting a pitch is posting the write-up with all the ingredients above somewhere that stakeholders can read it on their own time.

p. 50

Chacun peut donc commenter le pitch, pour alerter sur des informations manquantes, de potentiels risques, …

Un évènement capital vient marquer cette phase : la betting table. Durant celui-ci, seuls les pitchs produits durant le dernier cycle de 6 semaines de shaping sont présentés. Ceux-ci ont été à la disposition de tous avant l’évènement, le rendant ainsi assez bref : 1 à 2 heures. Un aspect important, est que tous les décideurs se doivent d’être présents, car c’est à ce moment-là qu’est acté ce qui sera réalisé dans les 6 semaines à venir. En dehors de ce temps, les sujets sont verrouillés et il n’y a pas de retour arrière possible.

Parmi les pitchs présentés, certains ne sont pas retenus. Ces pitchs-là ne sont pas conservés. Cela permet de conserver une bonne clarté du travail en cours, sans surcharger avec des choses qui seront potentiellement faites un jour, qui seraient alors potentiellement réévaluées régulièrement. L’idée étant que si le sujet est suffisamment important, alors il reviendra de lui-même.

Building

Cette phase a une durée fixe de 6 semaines. Durant ces 6 semaines, l’équipe sera totalement focalisée sur la réalisation du sujet défini par le pitch (sélectionné lors de la betting table), sauf dans le cas de sujets où l’appétit est moindre. Pour ce cas particulier, on parlera alors de small batchs qui rentrent dans le cadre d’un cycle.

L’équipe est assez restreinte. En effet, elle est composée d’un designer, un ou deux développeurs et un testeur.

Durant cette phase, l’équipe est encouragée à intégrer rapidement de petits pans fonctionnels démontrables. La fonctionnalité globale est donc vue comme un gâteau qu’il faut produire part après part et non couche après couche, comme le montre l’illustration ci-contre.

Aussi, designers et développeurs travaillent de manière assez indépendante. Au début du batch, le développeur doit travailler avec un design très minimaliste, suffisant pour pouvoir démontrer la fonctionnalité. Le designer de son côté, travaille sur des maquettes HTML, fait des essais, présente plusieurs options pour s’assurer du meilleur choix. L’idée derrière cela étant de valider le plus rapidement la solution, sans devoir attendre d’avoir implémenté au détail près la fonctionnalité.

Un autre concept encouragé par cette méthode, c’est de travailler sur le cœur de la fonctionnalité en premier (start in the middle), pas forcément dans l’ordre logique d’un workflow utilisateur. Par exemple, tel que décrit dans le livre, il n’est pas nécessaire d’implémenter toute une mécanique d’authentification pour montrer une fonctionnalité traitant les données d’un utilisateur. Il est possible par exemple d’utiliser une mécanique d’authentification HTTP BASIC ou bien utiliser un utilisateur prédéfini, « codé en dur ». Le tout étant toujours de pouvoir démontrer la fonctionnalité.

Comment suivre l’avancement ?

Shape Up n’aime pas les estimations. D’une part, bien souvent, les tâches sont découvertes au fur et à mesure de l’avancement et il est donc compliqué de prévoir combien de tâches vont devoir être rajoutées pour compléter le périmètre de la fonctionnalité.

D’autre part, une tache démarre toujours avec une très grosse part d’incertitude. Ce n’est qu’après avoir démarré le travail et exploré les difficultés que l’on peut réellement prévoir un atterrissage.

Singer propose une approche assez originale pour représenter le travail accompli et celui restant à faire : la colline. Au départ, le développeur ne connait pas l’ampleur du travail qui l’attend pour réaliser son implémentation (il monte la pente). A force d’exploration, il a écarté tous les risques et fini par identifier ce qu’il doit faire (il est au sommet de la colline). A partir de là, il est capable de dire à quel moment son implémentation sera terminée (il redescend la pente).

En représentant ainsi le travail accompli/restant à faire, l’équipe est transparente sur son avancement. Le management possède la visibilité sans avoir besoin de déranger l’équipe.

Jusqu’où l’équipe doit aller dans la réalisation ?

Done means deployed.

p.80

Ce qui signifie que l’équipe ne doit considérer son travail terminé que lorsque celui-ci a été livré. D’accord, mais quand est-ce que l’équipe a atteint un résultat suffisamment satisfaisant pour être en mesure de livrer ?

L’auteur recommande de ne pas essayer d’atteindre un idéal, qui par définition est inatteignable, mais plutôt de se poser la question par rapport à ce que possède l’utilisateur à ce jour. Il faut donc définir une baseline, et une fois celle-ci atteinte, se poser un certain nombre de questions pour savoir s’il est pertinent de continuer ou non. Par exemple :

• Est-ce que c’est un « must-have » pour la nouvelle fonctionnalité ?
• Est-ce qu’on peut livrer sans ça ?
• Que se passe-t-il si on ne livre pas ça ?
• …

De cette manière, l’équipe détermine les « must-have » et « nice-to-have » des nouvelles fonctionnalités. Ces derniers ne seront implémentés que si le temps restant alloué (l’appétit) le permet.

A propos des feedbacks ?

Si après cette période de 6 semaines, des feedbacks sont faits sur la nouvelle fonctionnalité, alors ceux-ci devront faire l’objet d’un nouveau cycle de shaping/betting/building. Cela permet d’assurer que l’inclusion de nouveaux détails ne viendra pas perturber l’existant, et surtout d’éviter la dette en ayant pris le temps de designer, réfléchir aux risques, etc…

Au delà de la méthode, des outils concrets

Breadboarding

Concept directement issu de l’électronique, le breadboarding a largement inspiré l’un des outils utilisés par Basecamp dans sa méthode, qui en a même repris le nom. Pour reprendre les mots issus du livre :

Wireframes are too concrete …. Words are too abstract

p. 15

Cet outil est utilisé durant la phase de shaping. L’idée est de représenter une fonctionnalité, un workflow, sous une forme suffisamment précise afin qu’il n’y ait pas de doutes sur le quoi, mais tout en laissant suffisamment de place au « comment », tant d’un point de vue graphique que technique.

Cela prend la forme d’un schéma tel que ci-dessus. On y retrouve 3 éléments clefs :

• Emplacements, pages d’un site web, boites de dialogues, là où l’utilisateur peut naviguer. Ce sont les éléments soulignés.
• Affordances, ce sur quoi l’utilisateur peut agir (boutons, champs de saisie, …). Ces éléments sont représentés par le texte simple.
• Connexions : représente le lien existant entre une affordance et un emplacement. Symbolise la manière dont l’utilisateur pourra naviguer de page en page.

Le livre détaille assez précisément un exemple d’utilisation de cet outil. Je vous encourage donc à le consulter si vous souhaitez en savoir plus.

Représentation en colline

Work is like a hill

p. 100

Chez Basecamp, le burndown chart et les estimations ne sont pas spécialement appréciés. Selon l’auteur, ils ne montrent pas une projection suffisamment fiable du travail restant à faire, tant la part d’incertitude peut être conséquente.

Nous l’avons évoqué dans le chapitre « Building », Shape Up présente une approche assez différente : la représentation sous forme de colline. Le principe de base est de dire que les développeurs commencent par une phase durant laquelle l’incertitude est maximale, la prévision n’est pas possible. Une fois le sommet de la colline atteint, il n’y a plus aucune incertitude, les développeurs sont alors en maitrise du travail restant à faire et sont en mesure d’estimer l’effort nécessaire pour arriver au bout.

En représentant l’ensemble des taches sur ce schéma, on montre alors l’incertitude relative existant sur le travail a faire, et donc le taux de confiance dans la réussite du batch en cours de réalisation.

Conclusion

D’un point de vue très personnel, j’ai été très gêné dans la lecture de ce livre, dans la mesure où à plusieurs reprises, il s’oppose directement à des pratiques agiles courantes. Le problème dans cette opposition, et c’est mon point de vue personnel, c’est que Singer expose une mauvaise interprétation de ces pratiques, en présentant plutôt les anti-patterns. D’ailleurs, un prochain article sera dédié à ce sujet. Ils y opposent ensuite les concepts de leur méthode Shape Up, qui finalement correspondent à l’esprit de son équivalent agile. (backlog, implémentation verticale, rendre le travail visible, …)

J’ai également beaucoup de mal avec la temporalité de 6 semaines imposée par la méthode, qui selon moi présente plus un risque qu’autre chose. D’autant, que l’ouvrage préconise de faire la résolution d’anomalie en dehors de cette période de 6 semaines.

Néanmoins, si je n’ai pas été séduit par le cadre, je l’ai plus été par les méthodes et outils employés aux différentes étapes du projet (représentation en colline, breadboarding, pitch, …). Ce sont des choses qui peuvent aisément être extraites de ce cadre là pour les appliquer dans d’autres contextes. D’autant qu’en annexe, le livre propose quelques approches plus incrémentales ou allégées pour adapter la méthode à différents contextes.

Et vous, seriez-vous prêts à tester cette méthode de travail, avec une approche assez différente ? Trouvez-vous ces outils intéressants ?

N’hésitez pas à laisser un petit commentaire pour en parler.

Pour aller plus loin

Le livre « Shape Up – Stop Running in Circles and Ship Work that Matters » de Ryan Singer, qui présente la méthode de manière très détaillée avec beaucoup d’exemples de mise en pratique chez Basecamp :

https://basecamp.com/shapeup/shape-up.pdf

Quelques articles de blog qui résument la méthode, dont je me suis inspiré :

https://www.productplan.com/glossary/shape-up-method/

https://medium.com/swlh/ship-faster-with-the-shape-up-method-215bfc7a44fc

L’excellente vidéo de Scrum Life parlant du sujet : Shape Up : agile ou pas ?