[Inside Dougs] Pourquoi nous sommes passés de Scrum à Shape Up ? #startup #tech

Fin 2019, l’équipe tech de Dougs, c’était seulement 5 Software Engineers. En mars 2021, nous étions à 19 collaborateurs dont 3 Product Managers. En juin, nous serons 25. Et ce n’est pas fini : au moins 19 postes sont à pourvoir pour renforcer l’effectif Tech / Produit en 2021. Ce contexte de croissance inédit pose un défi de taille : comment scaler une équipe technique pluridisciplinaire, tout en maintenant la vision et les objectifs de la boîte ? Pour répondre à cette problématique, nous avons repensé notre organisation et sommes passés d’une méthodologie Scrum à Shape Up. On vous explique notre démarche !

Étape 1 : l’implémentation de la méthode Scrum 

En bref

Scrum s’est imposé comme un premier choix pour appréhender la forte croissance de nos équipes de développement. Chez Dougs, cela s’est traduit par la mise en place de sprints de 2 semaines, au cours desquels nos Product Managers (PM) ouvraient des tickets détaillés, se basant principalement sur des remontées terrain : suggestions d’améliorations, bugs à régler… Nos Software Engineers s’emparaient alors du ticket pour implémenter les solutions répondant aux problématiques décrites par les PM.  

Côté Produit : déconnexion de la réalité + manque de recul

Rapidement, on a été confronté à deux inconvénients. Le premier, c’est que d’un point de vue Produit, on est parfois déconnecté de la réalité de la plateforme : difficile de mesurer précisément la nature des implémentations réalisées par les Software Engineers, ou encore leur coût. Le deuxième, c’est que l’on n’a pas toujours le temps de prendre du recul, de savoir si ce que l’on doit réaliser est un “quick fix” provisoire ou s’il s’agit d’une implémentation plus profonde, qui aurait nécessité davantage de temps et d’anticipation. 

Conclusion = frustration

Le résultat ? On avait de plus en plus de difficultés à programmer et résoudre l’ensemble des tickets. D’autant plus que prendre le temps de faire les choses correctement, avec du refactoring et du code maintenable, devenait compromis sur un sprint de deux semaines. 

On s’est vite rendu compte que les tickets manquaient de consistance, et qu’ils n’étaient pas priorisés par objectif, mais par urgence.

Une nécessaire remise en question 

C’est à ce moment-là qu’on a décidé de revoir notre méthode de fonctionnement. L’idée n’était pas de changer du tout au tout, mais de trouver une approche qui s’adapte mieux à nos contraintes en matière d’organisation, d’objectifs, de vision. De la méthodologie Scrum, nous avons donc décidé de conserver : 

• Les rituels : notamment les reviews, les démos et les rétrospectives, qui sont portés en public, devant toute la société ; les comptables peuvent alors apprécier tout ce que l’on a réalisé côté Tech / Produit. 
• L’organisation en squads : chez Dougs, nos équipes sont pluridisciplinaires. Nos squads comprennent des PM, des Software Engineers mais aussi des profils métiers comme des comptables. 

Pour le reste, nous avons décidé d’explorer d’autres possibilités, et de fil en aiguille, la méthode Shape Up s’est imposée à nous !

Étape 2 : la découverte de la méthode Shape Up 

En bref

Shape Up est une méthodologie définie et mise en lumière par la société américaine Basecamp. Il s’agit d’une entreprise SaaS de gestion de projet, qui a pour habitude de documenter énormément son aventure. C’est elle qui est à l’origine des ouvrages Getting Real – le livre de chevet de l’un des fondateurs de Dougs – ou encore Rework. Dans son ouvrage Shape Up, Basecamp explique comment structurer et organiser une équipe Tech et Produit, quand elle passe de 5 à 30, puis 50, puis 100 personnes. 

Pourquoi on valide Shape Up

Ce qui nous a plu avec cette méthode, c’est qu’elle redonne le pouvoir aux équipes Tech et Produit. Rappelons qu’un PM n’est pas là pour spécifier des choses, mais pour aborder un problème ou une opportunité, et être sûr qu’on arrive à construire LA solution adaptée. Côté Engineering, l’enjeu est de construire une solution, de la maintenir et de la faire évoluer. Pour que cela fonctionne, les équipes ont besoin d’un fort ownership. C’est là le point fort de Shape Up, car cette méthode permet d’objectiver les équipes autour d’une solution qu’elles vont réaliser. C’est une méthode agile qui maximise l’impact et le focus des équipes qui travaillent dessus.  

Et concrètement ?

Là où avec Scrum, on était sur des sprints de deux semaines, avec Shape Up, on est sur des cycles de six semaines entrecoupées de périodes de cooldown de deux semaines. Les cycles sont organisés en trois phases :  

• La phase de shaping : les Product Managers identifient un problème / une opportunité d’amélioration / une opportunité de création de nouveau produit. Ils en définissent les contours et donnent des premières pistes sur la façon dont il convient d’adresser ces problématiques. On se concentre vraiment sur la problématique à résoudre et sur l’objectif à atteindre. Le shaping est d’ailleurs un processus bien cadré : on répond d’abord à une série de questions pour bien définir les contours du problème, puis on s’attaque à la partie discovery, où on prend connaissance du problème et on voit les solutions qu’on peut designer. On s’appuie sur un petit schéma qui nous permet de mesurer la progression du cycle jusqu’à sa complétion (le “hill chart”).

• La phase de betting & de cooldown : à l’issue du shaping, on choisit les sujets qui vont être développés et on y définit un “appétit”, qui correspond au temps qu’on souhaite y allouer. En parallèle, toute l’équipe Tech est en cooldown, période qui permet de faire tout ce que l’on n’a pas eu le temps de faire pendant le cycle : bugs, quickwin, polish, tests d’une nouvelle techno, brainstorming strategy, hackathon, etc.

• La phase de building : une fois les sujets identifiés et l’appétit défini, c’est la phase de building. Là, ce sont surtout les Software Engineers qui prennent les choses en main, de la définition des scopes projet jusqu’à la livraison. Ils ont totalement l’ownership, en fonction de l’objectif défini en amont. En contrepartie, on s’engage à ne pas les interrompre dans la phase de développement afin qu’ils puissent allouer toute leur énergie à l’atteinte de l’objectif. 

Adapter Shape Up à Dougs 

On s’est rapidement aperçu que des cycles de six semaines entrecoupés de phases de cooldown, ça fonctionne mal sur un trimestre. Un nouveau challenge s’est donc imposé : il fallait adapter la durée des cycles avec les contraintes de la société. En effet, chez Dougs, comme dans beaucoup de boîtes, on a des objectifs trimestriels. On a donc décidé de passer sur 5 semaines de cycle + 1 semaine de cooldown. Cette semaine de cooldown est importante : elle est là pour amortir la fin de projet, finaliser ce qui doit l’être, nous aider à prendre du recul et à réaligner tout le monde sur la stratégie Tech et Produit de l’entreprise… C’est aussi l’occasion de faire du team building, de se détendre autour de petits jeux, car on est un peu moins dans l’opérationnel.

Autre point : on a opté pour une organisation des squads par domaine, c’est-à-dire avec un focus métier qui concerne une seule problématique.

Qui dit forte croissance dit nécessité de responsabiliser les équipes. Et ça a plutôt bien fonctionné ! 

Enfin, le sujet du support et de la maintenance a aussi été traité. On reste une solution live, avec plus de 5000 clients et près de 100 utilisateurs internes. Le challenge ici : gérer la maintenance sans affecter le focus des équipes. La solution qu’on a trouvée ? Partager la maintenance et la réserver uniquement aux créneaux prévus (en l’occurrence trois demi-journées par semaine réparties entre nos Software Engineers).   

Puisque l’on a implémenté Shape Up en janvier, on vient de finir notre troisième cycle. On a encore peu de recul, mais pour l’instant, on est convaincu du bien-fondé de cette méthode, et de tout ce qu’elle peut nous apporter d’un point de vue ownership. Elle permet un focus plus fort, évitant aux équipes de s’éparpiller sur des tâches multiples. Clairement, on y croit beaucoup ! Pour l’heure, on a encore beaucoup de questions à creuser, et on n’hésitera pas à continuer à partager avec vous nos retours d’expérience. 

En attendant, on rappelle qu’on recrute plusieurs postes Tech / Produit pour consolider la croissance de Dougs.