Shape Up : On y va ?

Actualités > Pilotage & Agilité > Shape Up : On y va ?
Catégories
Perrine MAROYE

Publié le :

Par Perrine MAROYE

Perrine nous présente une nouvelle méthode Agile : Shape UP. Vous connaissez ?

Shape Up : On y va ?

Shape Up, vous connaissez ? C’est cette nouvelle méthode agile, devenu “hype” dans le milieu des startups françaises.

Elle est issue d’une entreprise américaine, BaseCamp, qui est éditeur de logiciels.

L’objectif de cet article n’est pas de vous faire une présentation de Shape Up, mais plutôt de vous expliquer quels en sont les éléments qui me semblent importants / intéressants, et quelles limites je vois à cette méthode.

Pour avoir une vision plus complète sur ShapeUp, la “bible” est ici.

et des articles intéressants qui vulgarisent et expliquent la méthode ici, , et encore .

1) Qu’est-ce que Shape Up, et pourquoi faudrait-il s’y intéresser ?

1.1) Répondre avant tout à un problème métier

Le point de départ de Shape Up, est de ne pas oublier le pourquoi on développe un produit, en se concentrant sur le réel besoin et les problématiques des utilisateurs et commanditaires.

En effet, on voit dans l’utilisation assez répandue de Scrum, associé à l’utilisation des User Stories, qu’on se plonge vite dans le “quoi”, quoi faire, sans avoir pris connaissance du “pourquoi”, quel est le problème. Ainsi, le Product Owner (PO) va décrire à l’équipe de développement les User Stories (US), mais finalement, il est assez répandu que seul le PO connaisse le “pourquoi” d’une US. Le sens va finalement échapper aux développeurs et aux testeurs, et le risque est que la fonctionnalité développée ne soit pas totalement pertinente par rapport au réel problème de l’utilisateur/commanditaire.

Ainsi, Shape Up propose de travailler avec des “projets”, un projet étant la réponse à une problématique. Le rédacteur de la méthode Shape Up donne un exemple très éclairant : une des clientes de BaseCamp les contacte car elle souhaite bénéficier d’un module de calendrier. Si on s’engouffrait tout de suite dans ce besoin, on commencerait à rédiger des dizaines et des dizaines d’US, pour détailler ce qu’il faut mettre dans un module calendaire. BaseCamp a challengé cette cliente, en lui demandant quand elle voulait un calendrier, et que faisait-elle lorsque l’idée lui est venue de le demander. Elle leur a dit qu’elle travaillait dans un bureau avec un grand calendrier dessiné sur un tableau noir. Ses collègues indiquaient sur le calendrier quand ils devaient rencontrer des clients dans les salles de réunion. Un jour, elle travaillait à la maison. Un de ses clients l’appelle et lui demande de fixer un rendez-vous. Elle a dû se rendre au bureau pour consulter le calendrier mural. Elle aurait aimé pouvoir vérifier les places libres sur le calendrier depuis son ordinateur à la maison. Le besoin n’était donc pas d’avoir un module calendaire, avec toutes les dizaines de fonctionnalités sous-jacentes, mais plus précisément de “voir les salles libres”. On voit ici tout l’intérêt de bien comprendre la problématique initiale et pas la solution qu’imaginerait un utilisateur/commanditaire. On confie à la sous-équipe un projet, et non des tâches.

Shape Up propose de rédiger un pitch de projet, qui sera challengeable, visible et accessible aux développeurs et testeurs qui travailleront sur cette ou ces fonctionnalités. La 1ère partie du pitch du projet contient le problème. Ainsi l’équipe est sensibilisée au sens de ce qu’elle développe et teste. Donner du sens permet à la fois de motiver les équipes, elles savent pourquoi elles travaillent, mais c’est aussi un gage de qualité, en comprenant mieux le pourquoi on fait les choses, on diminue grandement le risque de développer une fonctionnalité “à côté”.

Dans les pitchs , on définit aussi un “appétit”, cet appétit est le temps qu’on souhaite passer sur les 6 semaines du cycle à venir pour chaque projet choisi. Cela permet d’aligner les parties prenantes et l’équipe sur le sens et les priorités du cycle. Ce n’est pas “J’estime les User Stories et on voit ce qui rentre dans les 2 semaines du sprint”, mais plutôt “Je définis un temps / une importance à passer sur un projet, puis je m’arrange pour faire un build qui réponde au problème dans ce temps imparti (cela peut amener à faire un développement “quick and dirty”, ou avec une expérience un peu dégradée sur un sujet qui a été jugé moins important, ce qui au final est totalement pertinent).

Ce qui me paraît aussi intéressant c’est que si un projet n’est pas choisi, il n’est pas mis dans un Backlog ou proposé d’office 8 semaines après dans la prochaine betting table (même s’il a été jugé intéressant à l’instant t). Il faut le “repitcher” si l’on souhaite qu’il soit pris dans le prochain cycle. Cela évite de développer des fonctionnalités pas si importantes ou de faire trainer des priorités basses pendant plusieurs mois, alors qu’on ne les fera jamais.

Enfin, avec Shape Up on est moins parasité par des petits sujets, c’est un gain non négligeable en temps.

1.2) Limitation de la dette technique

Un autre point intéressant dans Shape Up est que la méthode encourage et cadre le travail technique de limitation de la dette technique.

Pour l’équipe de développement, la méthode s’organise autour du séquencement d’un cycle de “building” de 6 semaines, suivi d’un cycle de 2 semaines de “repos”, le “cooldown”. En effet, enchaîner des cycles de 6 semaines ne permet pas de respirer et de penser à la suite. C’est pourquoi, après le building est prévu le “cooldown”. Il s’agit d’une période sans travail programmé, pendant laquelle l’équipe peut respirer, se réunir si nécessaire et réfléchir à ce qu’elle va faire ensuite. Pendant cette période, l’équipe est libre de travailler sur ce qu’elle veut. Après avoir travaillé dur pour livrer leurs projets de 6 semaines, elle apprécie d’avoir du temps sous son contrôle. Elle l’utilise pour refactorer, optimiser, investiguer sur des nouvelles technologies, rétro-documenter, corriger les bugs, se former, se perfectionner… Toutes ces activités vont contribuer à limiter la dette technique.

Cette période est bénéfique car l’équipe se sent responsabilisée et soutenue dans ses choix, elle est en maitrise totale de son agenda et de ce qu’elle va produire durant cette période. De plus, en en ayant discuté avec beaucoup de personnes ayant des rôles différents (notamment techniques), le fait de passer 1/4 de son temps à travailler finalement sur la qualité du produit semble intuitivement un bon ratio à un grand nombre de personnes.

1.3) Constitution d’une sous-équipe dédiée à un projet

Dans Shape Up, la répartition des équipes est fluctuante.

Le temps d’un cycle de building de 6 semaines, on construit des sous-équipes éphémères, chaque sous-équipe étant dédiée à un projet. Une sous-équipe est composée d’un designer, et d’un ou deux développeurs. Les sous-équipes ne parallélisent pas leur travail sur les différents projets qui leur sont affectés le temps d’un building (dans le cas où un développeur est affecté à plusieurs projets), elles les traitent un par un, séquentiellement. Cela permet à la sous-équipe de se concentrer pendant quelques jours ou semaines sur une problématique, un projet à la fois.

Quand on travaille avec Scrum, on peut être amenés à l’inverse à traiter plein de “tickets” sur des sujets et problématiques différents, dans la même semaine, voir dans la même journée. Shape Up permet d’être totalement concentré sur un problème, et évite aux builders de devoir sauter de sujet en sujet, avec la perte de temps que cela induit. Ils sont entièrement responsables de l’implémentation de leur problématique, de bout en bout.

Les systèmes d’information des grosses entreprises sont complexes, et très souvent, répondre à une problématique métier a pour conséquence sous-jacente de devoir faire évoluer plusieurs produits, connectés entre eux. Dans le cadre de problèmes touchant à 2 produits, respecter “à la lettre” Shape Up demande alors de créer des sous-équipes éphémères avec deux développeurs, un de chaque produit concerné. C’est là où je trouve la méthodologie très puissante et terriblement efficace : mettre deux développeurs provenant d’équipes différentes côté à côté au quotidien, uniquement le temps du projet (donc maximum 6 semaines), permet de “casser” le silo de l’organisation “classique” de l’entreprise découpée en produits, silo délétère qui empêche l’efficacité.

1.4) Une durée de building qui permet de sortir des projets significatifs de A à Z

La durée du cycle de building de 6 semaines est un temps suffisamment long pour concevoir et sortir des projets significatifs de A à Z.

Dans beaucoup de projets travaillant en utilisant classiquement Scrum, on est sur un rythme court, avec des sprint pouvant durer 2 semaines. Ce qui veut dire qu’en 2 semaines, il faut avoir fait la maquette (par exemple par un UX), avoir développé la feature (par un développeur), effectué les tests fonctionnels de cette feature (par exemple par un test analyst), parfois fait les ajustements infra nécessaires (par exemple par un devops), … Le fait qu’il y ait plusieurs étapes et plusieurs rôles derrière ces étapes est chronophage, encore plus si un des rôles est à temps partiel, on subit alors l’effet “bottleneck”. Cela ne nous permettait pas à titre personnel dans notre équipe de réussir à “tout” mettre dans un seul sprint, on était obligés de prévoir 2 sprint pour qu’une fonctionnalité passe toutes ces étapes… De plus, le fait d’avoir ce laps de temps court pour le sprint, 2 semaines, nous poussait à beaucoup (trop ?) découper nos User Stories (US) “mères” en plusieurs petites US, ce qui fait que ce que nous livrions dans une seule US pouvait avoir une valeur métier limitée et faible.

Avec les 6 semaines de building, en plus de pouvoir livrer une feature complète qui répond en totalité à une problématique, on a le temps de “bien” faire les choses et de de mettre autour de la table tous les rôles qui participeront à l’implémentation d’une feature (UX/UI, développeur, test analyst, devops, …).

Avec Shape Up, on évite les projets qui dépassent indéfiniment leur échéance parce qu’on ajoute mini-US par mini-US sur plusieurs sprints d’affilée, tout cela pour répondre à un seul besoin. D’où le sous-titre de Shape Up : “Stop Running in Circles and Ship Work that Matters”. En effet, c’est 6 semaines, et pas une de plus ! Si le projet n’est pas fini à temps, il est abandonné (principe du “circuit breaker”).

1.5) Limitation de l’”administratif”

En Scrum, on peut vite arriver à des sprints qui contiennent plus de cinquante items, et des Product Backlogs de plusieurs centaines d’items… Même si dans le contexte Scrum ça peut se justifier, cela génère une charge administrative assez forte, principalement sur les épaules du Product Owner, (PO) et sans aucune valeur ajoutée. En effet, sur le sprint, il faut mettre à jour le statut de chaque item, et créer ses “outils” (dashboards ou autre) pour filtrer et voir l’information qui m’intéresse. Ainsi, si je suis PO ou Scrum Master et que je veux voir l’avancement d’une US, si j’utilise JIRA et que je vais sur le DashBoard de “tableau” par défaut, je vais être noyé-e sous les informations et ne pas voir celle qui m’intéresse. En effet l’item d’US a pu être découpée en plusieurs items, comme d’autres items US appartenant au même sprint, du coup avoir l’information globale “où en est mon US” n’est pas simple.

Au contraire, en utilisant Shape Up, on ne manipule plus des dizaines et des dizaines d’items dans un cycle de building, mais un petit nombre, le nombre de projets (actuellement maximum 3 par développeur dans notre équipe). Ainsi le cycle est beaucoup plus lisible en terme de contenu, et personne n’est tenté de faire du micro management en analysant les items qui détaillent une US. Les PO sont moins pollués par la gestion du backlog.

1.6) Shape Up, une boîte à outils efficace

Exemple provenant de https://longpressed.com/Patterns/Product+Development/Shape+Up/Hill+Charts

BaseCamp, l’éditeur qui a lancé Shape Up propose aussi des outils très pertinents. L’un d’entre eux est le Hill Chart. Le Hill Chart est un outil visuel permettant de suivre l’avancée d’un projet sur un cycle de building. Il se présente sous la forme d’une courbe de Gauss, sur laquelle on va positionner des points de couleur, représentant des scopes. Un scope est une petite unité fonctionnelle représentant le projet, une micro-fonctionnalité du projet en quelque sorte. Le hill chart, la colline, est constitué de deux phases : d’abord la phase ascendante, qui consiste à déterminer l’approche et ce que nous allons faire, ensuite une fois que l’on voit tout le travail que cela implique, il y a la phase descendante de l’exécution. Visuellement, cet outil est fort et extrêmement parlant :

  • Il regroupe dans un seul et même schéma toutes les informations détaillées d’avancement qu’on veut savoir sur un projet ;
  • Il est parlant, tout de suite : si le scope est sur la partie gauche de la courbe, c’est que l’équipe est toujours en phase d’analyse-conception sur le sujet, s’il est à droite, l’équipe est en cours de développement.

2) Les limites de Shape Up

2.1) Une organisation d’équipe calquée sur le fonctionnement de BaseCamp

Un des points forts de Scrum est qu’il est agnostique de tout entreprise et de toute organisation. Ce qui fait qu’il a un côté presque universel, beaucoup d’organisations peuvent l’adopter. Au contraire, Shape Up est basé sur l’organisation interne de BaseCamp, et BaseCamp a, avec dans l’équipe qui gère le building, uniquement deux rôles : les “designers” et les “programmers”. En clair, dans leur organisation, les tandems designer-programmer sont totalement autonomes et couvrent la totalité du besoin digital. A contrario, dans les grosses organisations actuelles, et en particulier dans mon équipe, une diversité de rôles est présente : UX/UI, développeurs, mais aussi Tech Lead, Devops, et Test Analyst. Hormis les développeurs qui peuvent se concentrer sur un et un seul projet à la fois, les autres rôles sont contraints à devoir travailler sur plusieurs projets à la fois, ce qui les contraint à ne pas être aussi focus sur un projet que ne peuvent l’être les développeurs. C’est une contrainte à avoir en tête avant de commencer… Le partage des ressources n’est jamais simple. Surtout si les sollicitations de ces rôles multi-projets sont faites en même temps… Un UX/UI aura du mal à répondre en même temps à deux développeurs qui sont en attente de maquettes rapidement… Cela demande à être anticipé, et de mettre à plat le process qui peut convenir à l’organisation en face de cette problématique.

2.2) Gestion des urgences et des opportunités type quick wins

Shape Up est très clair : pendant la phase de building, on build, et on build uniquement les projets qui ont été validés. Quid des urgences et autres opportunités de quick-wins qui “tombent” du ciel (ou plus vraisemblablement du client / commanditaire) ? Elles passent à la trappe. Il faut attendre le prochain cycle de building, soit potentiellement 8 semaines après, pratiquement 2 mois, pour les faire passer… Cela peut être vécu comme très long par le client ! Voir inacceptable…

3) Conclusion, que faut-il faire ?

3.1) S’adapter à son contexte

C’est comme tout, avant d’adopter une approche, il faut voir si elle s’adapte à son contexte. Et avoir l’intime conviction que c’est la bonne, c’est encore mieux, ça permet d’alimenter le moteur…

Si vos Sprint Backlog contiennent plus d’une cinquantaine d’items, que vos développeurs sautent de ticket en ticket avec toute la perte de concentration et de temps que ça engendre, qu’ils perdent le fil du sens même de la problématique / du besoin derrière chaque ticket… Alors l’utilisation de Shape Up semble un scénario à étudier, potentiellement pertinent.

Dans les équipes qui fonctionnent avec Scrum, il est courant que le PO ne priorise pas les fonctionnalités de réduction de la dette technique (dû à une pression managériale sur la livraison de features métiers, un manque de connaissances des enjeux techniques, ou autre…). Dans ce cas-là, la dette technique du produit peut s’aggraver, et la frustration de l’équipe s’agrandir… Utiliser Shape Up et l’exploitation du cooldown permet d’endiguer cette problématique.

Des itérations de 8 semaines, c’est long. Cette durée n’offre pas beaucoup de flexibilité s’il faut changer de priorité rapidement, ce qui peut arriver si l’entreprise ou le produit cherche encore son positionnement. Choisir d’adopter Shape Up dans ce contexte ne semble pas être une bonne idée.

3.2) Ne pas s’empêcher de cumuler les approches, et d’y piocher ce qui nous intéresse

Faire le choix de partir sur Shape Up ne veut pas dire abandonner tout le reste, bien au contraire.

Shape Up ne propose qu’un seul rituel, le “betting table”. On peut très bien cumuler ce “betting table” avec des rituels Scrum qui ont fait leur preuve (Daily Scrum meeting, Sprint Review, Sprint retrospective). Dans notre équipe, on perdrait en qualité si on avait abandonné ces rituels. On peut aussi y associer des rituels spécifiques “faits maison”, nécessaires par rapport au contexte de chacun avec l’arrivée de Shape Up. Ainsi, nous avons fait le choix dans notre équipe de mettre en place deux nouveaux rituels :

  • Un rituel hebdomadaire de “Shaping Talk”, rituel pendant lequel les “shapeurs” (les personnes qui ont “shapé” des projets) présentent ces projets en mode draft aux techs pour avoir leur avis et parfois aussi leur contribution.
  • Un rituel par “cycle”, toutes les 8 semaines, appelé “Scoping Time”. C’est le moment où on creuse les sujets et où on décrit les différents scopes des projets.

Pour en savoir plus, des retours d’expérience enrichissant : chez MemoBank, Alan (assurance santé), Lucca (SIRH), The Fork (ex-La Fourchette), Sencrop (réseau de stations agro-météo).

Merci à Sabine Delhaye pour sa précieuse relecture.

Perrine Maroye, Scrum Master, Xpeho