Dans les précédents articles de la série Shape Up, nous avons pu parler de sa mise en place avec Perrine, la scrum master, et Sophie, la product owner, et avons pu assister à la première rétrospective en équipe.
Aujourd’hui nous nous retrouvons pour l’interview de Logan, tech lead de l’équipe suivie, qui va pouvoir nous livrer son ressenti par rapport à Shape Up.
Logan est tech lead de l’équipe depuis 2 ans, il était là depuis plus d’un an avec l’équipe avant de suivre le passage à Shape Up il y a désormais 8 mois. Tech lead chevronné, Logan est dans la tech depuis plus de 15 ans ; sur ces 15 années, seules 3 ont été passées sur des projets en cycle en V. L’agilité il connait donc bien, il a pratiqué le Kanban, Scrum, l’agilité à l’échelle et maintenant Shape Up dans des projets impliquant entre 3 et 150 personnes sur des sprints durant de 2 à 4 semaines.
Comment Logan a-t-il connu Shape Up ?
Lors d’un slack day (jour consacré à de la veille ou la découverte de sujets en équipe), Perrine la scrum master, avait fait la présentation de Shape Up à l’équipe en lui fournissant la documentation et en laissant le temps à l’équipe de s’approprier les concepts.
Après des discussions sur des compréhensions qui pouvaient diverger au sein de l’équipe, l’envie d’essayer est apparue.
Le deal initial était d’essayer pendant 2 cycles (de 8 semaines) et de faire un point en rétro pour voir si l’équipe continuait ainsi ou revenait sur une organisation Scrum plus traditionnelle.
Quelles étaient les attentes et les réticences de Logan ?
Réticence :
- Aller à contrecourant de bonnes pratiques tech de continuous delivery :
Dans la tech Logan cite le livre de Gene Kim « Accelerate » qui pousse à aller plus vers une mise en prod par jour en optimisant la CI. Ici on va un peu à contrecourant de toutes ces idées en se laissant le temps de faire des cycles longs.
Attentes :
- Réduire le temps en réunion :
Avec l’organisation Scrum toute l’équipe avait l’impression de passer beaucoup trop de temps en réunion. Les tickets sont très précis, peut-être trop, et cela engendre beaucoup de discussions.
- Pousser les développeurs à livrer de la valeur :
Les devs ont l’ impression d’avoir des entrants pas assez clairs. En Shape up un projet (équivalent d’une Epic) est découpé en scopes (équivalent des US) par l’équipe et non par le PO uniquement. Cela permettrait d’impliquer les développeurs dans le fonctionnel, les poussant à réfléchir à apporter de la valeur en tant qu’ingénieur développeur en s’éloignant d’un découpage purement technique (back/front/bdd etc.).
- Améliorer la collaboration avec une autre équipe :
Les développeurs travaillent avec une autre équipe avec laquelle ils ont beaucoup d’adhérence. En les impliquant pendant la phase de Shaping, ils pensent pour travailler mieux ensemble.
- Avoir une meilleure gestion de la dette :
Avec la période de cooldown de 2 semaines toutes les 8 semaines, Logan voit une occasion de gérer la dette. On met un peu ce que l’on veut dans le cooldown mais pour Logan, l’idée est de faire ce qui plait en allant dans le sens du projet quand même (dette/qualité/ci test coverage etc.)
Comment s’est passée la transition vers Shape Up ?
Finalement la transition s’est faite assez facilement, le backlog a été repris : les US existantes ont été transformées en scope et un cycle a été nécessaire pour réaliser ce reliquat.
Ensuite, chaque nouvelle fonctionnalité était un projet qui devait être « scopé » (découpé en scopes) par l’équipe et les rituels existant ont été repris (refinement/3 amigos /example mapping etc.) la différence est qu’ici les développeurs ont une vision d’ensemble.
Le workflow a été un petit peu adapté pour gérer les différents états et une definition of scoped a été ajoutée (aux existantes definition of ready et definition of done) pour s’aligner sur ce que l’on considère « scopé ».
Les estimations sont passées au niveau du projet concernant risque et délai.
La transition est-elle complète aujourd’hui ? Peut-on dire que l’équipe est en Shape Up ?
Shape Up oui mais avec des limites, une adaptation est donc en train de se mettre en place.
Shape Up a-t-il répondu à tes attentes ?
- Réduire le temps en réunion : NON, le temps en réunion est toujours aussi important, une nouvelle organisation émerge pour condenser les réunions sur une semaine et laisser aux devs de longs créneaux productifs.
- Pousser les développeurs à livrer de la valeur : OUI et NON, les développeurs ont tendance à rester sur leur scope back par exemple et à passer un cycle sans délivrer de la valeur.
- Améliorer la collaboration avec une autre équipe : NON, la collaboration avec l’autre équipe n’est jamais arrivée, ils sont eux en Scrum.
- Avoir une meilleure gestion de la dette : OUI et NON, sur 4 cycles de cooldown, 2 ont été utilisés pour terminer des tâches non accomplies pendant le cycle (build).
Un avis sur Shape Up ? Le recommanderais-tu ?
Après 2 cycles pas de conclusions tirées, il a été décidé de continuer.
Après 4 cycles : l’avis de Logan est que cela peut convenir, oui et non. Il faut l’adapter.
Logan se demande si la méthode est adaptée à l’IT dans le retail. La méthode est bien pour un éditeur (comme basecamp les créateurs de Shape Up) mais chez Adeo c’est plus compliqué.
La notion d’appétit pour savoir si on met de l’argent sur une fonctionnalité (trouver une solution pour un montant donné en envisageant un compromis) n’est pas complètement applicable.
Dans un contexte retail on fait trop peu de concessions sur les fonctionnalités. On ne se pose pas beaucoup la question du coût.
Pour conclure, l’avis de Logan est mitigé, il pourrait recommander Shape Up en fonction du contexte et de la maturité de l’équipe.
Comme il aime le dire, en tant que tech il commence toujours ses réponses par « Ça dépend ».
Il faut garder de l’agilité dans l’application de son framework agile, comprendre les concepts au cœur de l’outil et voir s’ils sont pertinents dans le contexte en question.
