De Scrum à Shape Up : quand le cadre doit évoluer avec l’équipe

Retour en 2019. Meeko grandit. Avec mes associés Antoine et Christian, nous portons le produit depuis son lancement. J’y occupe le rôle de CTO, tout en restant développeur. Nous travaillons ensemble depuis un moment, partageons une compréhension assez implicite du produit et avons peu besoin de formaliser nos échanges pour nous comprendre.

L’arrivée des premiers développeurs change ensuite la donne. Il faut maintenant transmettre notre compréhension du produit à une équipe qui est encore en train de se l’approprier.

C’est dans ce contexte que nous adoptons Scrum pour structurer davantage notre manière de travailler. Mais lorsque les tickets manquent de précision, le résultat ne correspond pas toujours à ce que nous avions en tête.

Je me souviens notamment d’une phrase entendue à l’époque sur une chaîne YouTube dédiée à Scrum :

« Tu auras ce que tu as demandé, pas forcément ce que tu voulais. »

Elle résumait assez bien notre problème. Celui qui écrivait une user story savait probablement ce qu’il voulait. Celui qui la réalisait, lui, se limitait à ce qui avait été écrit.

Scrum nous a tout de même poussés à mieux spécifier et à formaliser davantage. Et à ce moment-là, ce cadre nous a probablement aidés.

Quand le cadre devient trop étroit

Quelques années plus tard, notre équipe avait évolué.

Les développeurs cherchaient davantage à comprendre le produit, à challenger la solution et certains changements émergeaient directement pendant la réalisation.

Les tickets n’étaient pas toujours remis à jour et le Kanban finissait par ne plus représenter complètement le travail réel. Il aurait fallu reporter chaque décision dans les différents tickets concernés. Et dans les faits, une partie des échanges passait directement par Slack, qui était pour nous un canal plus simple et plus direct.

Le pré-découpage et les spécifications bridaient aussi la prise de décision. Lorsque les développeurs voulaient modifier la solution prévue ou corriger des problèmes qui n’avaient pas été identifiés initialement, ils faisaient souvent escalader ces changements pour validation.

Je pense même que certaines propositions d’amélioration ne sont probablement jamais remontées, simplement parce que remettre en question ce qui était écrit pouvait donner l’impression de revenir sur une décision déjà prise.

Au fil de ces années avec Scrum, certains mécanismes avaient perdu de leur sens pour nous. Les sessions de planning poker n’avaient plus lieu, et terminer tout le travail prévu dans un sprint n’était pas un objectif en soi : nous déployions en continu, lorsque le niveau de qualité attendu était atteint.

Je ne pense pas pour autant que Scrum entraîne cette lourdeur que nous avions fini par avoir, ni qu’il soit d’ailleurs incompatible avec davantage d’autonomie. Nous aurions probablement pu continuer à faire évoluer notre manière de l’appliquer.

Mais à ce moment-là, nous avions aussi besoin d’une rupture.

L’équipe avait évolué, mais notre cadre était resté le même.

Du découpage au cadrage

J’avais déjà entendu parler de Shape Up sans vraiment m’y intéresser. C’est une discussion autour de l’ownership avec un ami qui m’a poussé à regarder la méthode plus sérieusement et à tenter une première approche en reprenant certaines de nos user stories sous forme de pitchs.

L’une de mes premières réactions a été assez simple : nous n’avions finalement peut-être pas besoin de découper un problème en une série de user stories.

Mais une deuxième question est rapidement apparue.

Si je regroupe simplement toutes ces user stories dans un pitch, tout en conservant leurs spécifications, je n’ai finalement rien changé. J’ai seulement déplacé le contenu des tickets dans un document devenu immense.

Il fallait donc accepter que ce document, le pitch, ne définisse pas tout.

Une partie de la réflexion et des décisions se déplace alors inévitablement dans la phase de Build. L’équipe ne suit plus un chemin entièrement tracé : elle doit continuer à le construire tout au long du cycle.

En regardant notre propre fonctionnement, je me suis aussi rendu compte que nous faisions déjà une partie de ce travail. Lorsque les spécifications ne suffisaient pas, les développeurs continuaient simplement la réflexion pendant la réalisation.

Ce constat m’a conforté dans l’idée que ce cadre correspondait probablement à notre manière de travailler. J’ai alors décidé de l’appliquer dans l’équipe.

Donner la direction, pas le chemin

Le changement le plus important avec Shape Up n’a pas seulement été de remplacer des tickets par des pitchs.

Une partie de l’effort que nous mettions auparavant dans le découpage en user stories, les spécifications millimétrées et le maintien du système de suivi était désormais investie dans le cadrage du sujet.

Le shaping est réalisé avec le produit, mais aussi avec des développeurs. Leur rôle est de participer au cadrage du problème et de la direction à prendre.

Cela change fondamentalement la manière dont un pitch arrive dans l’équipe de Build.

Même lorsqu’un développeur n’a pas participé au shaping, il récupère un sujet qui a déjà été travaillé avec d’autres développeurs : le problème, les principaux risques et la direction ont déjà été cadrés.

Le pitch ne cherche donc pas à définir toutes les étapes de la réalisation. Il donne une direction et des limites, puis laisse à l’équipe la responsabilité de construire le chemin pendant le Build.

S’écarter de la solution imaginée au départ n’est plus une exception à faire valider. Cela fait partie du travail de l’équipe pendant le Build.

Suivre les inconnues plutôt que les tâches

Avec moins de tickets, notre Kanban est devenu beaucoup plus léger et nous ne l’utilisons plus pour faire le suivi au quotidien.

Ce n’est pas que nous n’avons plus de processus. C’est que le système utilisé pour représenter le travail est devenu beaucoup moins important que le travail de réflexion lui-même.

Pour garder une vue d’ensemble des sujets pendant le Build, j’ai plutôt mis en place un board qui rassemble leurs Hill Charts.

Nous ne cherchons pas à mesurer un pourcentage d’avancement, mais à comprendre si l’équipe cherche encore à lever les inconnues ou si elle sait maintenant comment terminer le sujet.

Si l’équipe reste sur la montée alors qu’une part importante du temps est déjà consommée, cela devient un signal : nous nous synchronisons pour comprendre ce qui bloque et nous décidons ensemble des compromis à faire.

L’autonomie était déjà là

Ce qui m’a probablement le plus surpris dans cette transition, c’est à quel point cette nouvelle manière de travailler a rapidement trouvé sa place auprès des développeurs et du reste de l’équipe.

Avec le recul, je comprends que cette autonomie existait déjà. Les développeurs challengaient activement les décisions et prenaient des initiatives pendant la réalisation, alors même que notre ancien cadre ne les y incitait pas particulièrement.

Shape Up demande justement ce niveau d’implication, autant pendant le shaping que pendant le Build.

C’est aussi pour ça que je ne pense pas que ce modèle convienne de la même manière à toutes les équipes. Shape Up peut encadrer et favoriser cette implication, mais il ne peut pas la faire apparaître à lui seul.

Ce qu’on ne sait pas encore

Notre passage à Shape Up reste récent.

Le principal point à surveiller pour nous aujourd’hui est que les développeurs que nous souhaitons impliquer dans le shaping sont souvent aussi ceux dont nous avons le plus besoin pendant le Build.

Pour l’instant, cela ne met pas réellement nos Builds en difficulté. Nous n’avons cependant pas encore assez de recul pour savoir si cette fragmentation entre le shaping et le Build restera une contrepartie acceptable de ce fonctionnement.

Ce que le processus ne peut pas résoudre

Avec le recul, le principal apprentissage que je retire de cette transition dépasse finalement le cadre de Shape Up.

J’ai probablement essayé pendant longtemps de résoudre par le processus des problèmes que le processus ne pouvait pas résoudre.

Créer des workflows avancés, multiplier les états de suivi ou maintenir des boards parfaitement cohérents peut effectivement aider à représenter le travail.

Cela ne crée pas pour autant l’implication, l’ownership ou l’envie de comprendre le produit.

À force de vouloir trop structurer le travail pour essayer d’en garantir le résultat, nous avions peut-être construit un cadre qui laissait moins de place à la prise d’initiative, sans vraiment nous en rendre compte.

Scrum nous avait aidés lorsque notre équipe avait besoin de davantage de structure. Quelques années plus tard, cette même équipe avait surtout besoin d’un cadre qui traduisait notre confiance.