Shape Up, est-ce une avancée ou un Scrum au rabais ?
J'ai participé au meetup Shape Up avec Laurent Meurisse et Pablo Pernot. J'y ai pris un grand plaisir.
En complément, quelques notes que j’avais prises pour me mettre en forme (shape up en français).
Déclaration préliminaire
Je n’ai pas pratiqué Shape Up, mes commentaires se basent sur ce que j’ai lu de Basecamp et sur le retour d’expérience auquel j’ai assisté il y a quelques jours lors du forum ouvert à Agile tour Toulouse.
À propos des expérimentations qui sont racontées, j’observe le résultat avec un point de vue pragmatique : des développeurs contents et qui ne voudraient pas revenir en arrière.
Très bien ! Shape Up est pour eux une réponse à un problème (les sprints de 2 semaines ça met une pression de dingue ) et que ce soit agile ou pas n’importe pas.
Mais dans ce meetup nous allons discuter de l’intérêt de Shape Up dans d’autres contextes. Alors comme Shape Up demande des efforts pour être appliqué, vaut-il mieux mettre les efforts pour aller vers une autre méthode que de les mettre pour bien appliquer l’agilité ?
Shape Up, c’est de l’agilité ou pas ?
Pour y répondre, je propose de positionner Shape Up. Laurent Meurisse présente Shape Up comme une méthode agile. Je suis d’un avis différent, voici pourquoi.
Basecamp ne fait pas référence à l’agilité pour définir sa méthode. Pas du tout. Elle n’est pas citée comme inspiration, mais juste évoquée pour réfuter des pratiques : pas de backlog, pas de mêlée quotidienne.
En ce qui concerne les principes fondamentaux : voyons le premier l’équipe auto-organisée. Euh ben il n’y a pas d’équipe dans shape up. On est plus dans la division du travail.
Pour le 2e principe, les boucles de feedback orientées utilisateurs, il y a bien au cœur de Shape up la notion de cycle, avec sa durée particulière, sur laquelle nous reviendrons, mais on ne parle pas des utilisateurs.
Dire que Shape up ne soit pas de l’agilité n’est évidemment pas un anathème pour moi, l’agilité n’est qu’un outil. Et d’autre part j’ai trouvé beaucoup de matière à réflexion en approfondissant les concepts proposés.
C’est intéressant de noter qu’à partir du constat des mêmes problèmes (par exemple les sprints de 2 semaines, ça met une pression dingue), Shape up propose une solution (radicale ?) extrême — cycle de 6 semaines plus deux semaines d’interlude — alors que, comme dans la masterclass avec Pablo, je mets en avant une approche systémique : les devs sont dans une équipe, elle-même dans un système plus large avec les parties prenantes qui ont sûrement leur part de responsabilité dans la pression de dingue.
Shape Up, itératif et incrémental ?
Sans parler d’agilité, voyons si Shape Up est itératif et incrémental.
Shape Up n’est pas incrémental : on fait un projet d’un coup.
Shape Up n’est pas très itératif : on peut faire des changements suite à un feedback des utilisateurs mais dans un temps long. Un projet prend 14 semaines et revenir sur ce qui a été fait pour faire des changements va prendre 16 semaines de plus (cool down, shape, cool down, build).
Non, mes mots itératif et incrémental ne peuvent pas y être associés non plus. Pourtant lors de notre discussion le mot itération est revenu souvent, un signe que la culture de l’agilité est dominante dans les esprits ?
L’organisation des personnes
La notion d’équipe auto-organisée n’existe pas, il n’y a pas d’équipe complète ni stable dans Shape Up.
0n a un senior (avec experts) sur le shape, 2-3 devs sur le build, mais ensemble uniquement pour les 6 semaines.
Le dual track (shape/build) m’a fait penser à la séparation MOA MOE… ou alors à un PM qui serait en dehors de l’équipe.
Sur le pouvoir de décider : c’est la direction qui décide du choix des bets et c’est le senior shaper qui décide du quoi et du comment (pas le détail, mais l’architecture).
L’organisation du temps
Il y a 2 temps dans le travail : le temps du produit (le résultat) et le temps de l’équipe (sa vie).
Le problème avec Shape Up c’est un alignement total du temps du produit avec le temps de l’équipe. Depuis des années, l’agilité combat l’idée que les deux doivent coïncider, c’est à dire que la livraison rentre dans une boite de temps.
La durée de 6 semaines (plus 2) est imposée (c’est une règle, le retour du standard ?), basée sur l’expérience de basecamp (je ne vois pas de raison de la généraliser). On retrouve de l’effet tunnel avec la planification projet.
Je me suis d’abord dit que le shape correspondait à la notion d’affinage, mais fait une seule grosse fois au début du projet. À la réflexion, en observant le résultat de cette phase, appelé le pitch (attention, c’est un document), je considère que c’est plus proche de ce qu’appelle le prélude. Mais un prélude interdit aux personnes qui vont réaliser le projet… L’équivalent du pitch, c’est la charte projet.
Le sens, la performance
Avec Shape Up, on est dans la collaboration plutôt que la coopération, dans la spécialisation plutôt que la pluridisciplinarité et pas de trace d’amélioration (avec la rétrospective ou autre chose).
Même pendant le cool down, on ne réfléchit pas à faire mieux.
J’aime bien cette idée de s’arrêter de produire. Depuis l’édition 5 de mon livre, je propose la notion un pu similaire d’interlude entre deux saisons, je reconnais qu’interlude c’est moins cool.
Tout semble fait pour que les gens ne perdent pas de temps à échanger pour se consacrer à la production : pas de réunion, de la doc, des outils, pas de synchro.
L’attention au résultat
On ne parle pas beaucoup des utilisateurs dans Shape Up. Pas de démo.
La notion de valeur pour prioriser est à la discrétion exclusive de la direction.
Vocabulaire
Pour une personne qui débarque, c’est une horreur, le jargon est omni-présent !
on va chéper, et après le pitch du bet pour donner de l’appetite, on bilde le chèpe,
À côté, c’est cool le down.
On trouve aussi une volonté d’utiliser des mots différents de ceux de l’agilité : project au lieu de feature, scope au lieu de story, pitch au lieu de charte projet, par exemple. Les notions de bet et d’appetite, les collimes, plutôt faibles, vont aussi dans l’idée de faire nouveau et intéressant.
La diffusion de Shape Up
Shape Up c’est malin :
- pour rassurer les devs : 6 semaines sans rites + cool down,
- pour convaincre la direction : c’est elle qui décide.
Un analogie dans l’histoire de l’agilité m’est venue : le modèle Spotify qui a été utilisé à tort comme un modèle alors que ce n’était qu’une expérimentation dans un contexte donné. La différence est que Basecamp offre un outil. Pour avoir longtemps travaillé chez des vendeurs d’outils je me méfie de leur discours apparemment désintéressé : on vous offre notre méthode.
Comme on l’entend dans les retours d’expérience, Shape Up c’est l’occasion de changer et de se poser des questions, c’est déjà bien. On peut aussi se dire que c’est mieux que du faux agile. Cependant je ne pense pas que ce soit une bonne alternative.