Retour d’expérience : on a réorganisé notre team dev en squads
Plus on est de développeurs, plus on développe vite ? Oui, mais… Les développeurs savent d’expérience que quand une équipe grossit, la productivité individuelle de chaque membre diminue. Cela crée de la frustration, puisqu’on souhaiterait que la croissance de l’équipe abatte des barrières au lieu d’en rajouter.
Les symptômes sont multiples : l’équipe traite beaucoup de sujets en parallèle, la charge cognitive augmente, on est noyés sous les notifications, on sent qu’on perd prise sur la base de code qui évolue plus vite, il est plus difficile de prendre du recul. Bref, une certaine frustration peut faire son apparition.
Entre janvier et mars 2018, notre équipe est passée de 3 à 6 développeurs. Nous avons senti cette frustration poindre et nous avons décidé de nous tourner vers une solution : les squads.
À quel moment a-t-on décidé de se séparer ?
L’organisation en squad est connue et reconnue, elle a été présentée sous toutes les coutures par des entreprises qui la pratiquent depuis longtemps. Elle est attirante et plusieurs membres de l’équipe avaient envie de l’essayer avant même d’en avoir besoin. Tant que nous étions 3, c’était hors-sujet, donc nous avons gardé l’idée dans un coin de notre tête et attendu.
Arrivés à 4 ou 5 membres, nous avons commencé à ressentir une augmentation de notre charge mentale. Mais notre productivité individuelle n’était pas impactée et surtout notre production était en plein boom !
Quand notre 6e équipier est venu grossir les rangs, nous avons ressenti et mesuré que nous étions un peu moins efficaces. Nous avons extrapolé cette évolution aux recrutements à venir et nous avons décidé de changer notre fonctionnement avant que le problème ne soit bloquant. Un nouvel équipier peut nous rejoindre du jour au lendemain, vu les ambitions de recrutement ! Mieux vaut conduire le changement sereinement, avant d’être en situation de frustration et d’inefficacité.
Nous nous sommes dit qu’entre une équipe de 3 et deux équipes de 3, il y avait énormément de similitudes sur les process et la communication. Nous avons donc séparé assez rapidement notre équipe de 6.
Comment conduire le changement ?
Entre la décision de s’organiser en plusieurs squads et la séparation effective de l’équipe, 15 jours se sont écoulés. Juste le temps de nous préparer et de se lancer. Voilà les étapes que nous avons suivies.
Le premier point, qui était pour nous un prérequis crucial, c’est l’engagement de l’équipe : tout le monde avait envie d’opérer ce changement.
Nous avons défini des métriques pour nous assurer que nous allions dans le bon sens. Nous avons choisi de suivre notre indicateur d’épanouissement des équipiers, le nombre de projets traités en parallèle, et le volume de stories embarqué par sprint. Attention, il est plus difficile de suivre ces métriques en période d’instabilité extrinsèque, comme par exemple les vacances d’été. Nous avons changé d’organisation entre avril en juin, donc nous n’avons pas eu ce problème.
Avant de nous restructurer, nous avons pris le temps d’expliquer ce que nous faisions aux autres équipes de Captain Contrat, surtout celles avec lesquelles nous interagissons au quotidien. Nous leur avons décrit les raisons du changement et les conséquences attendues. Nous avons été aidés tout au long du projet par Flore, notre culture manager, qui s’est placée en facilitatrice.
Pour préciser notre nouvelle organisation, nous avons rapidement listé tous les impacts sur notre fonctionnement et les problèmes qui pourraient survenir. Nous nous sommes basés sur nos expériences personnelles et sur celles d’autres entreprises comme Spotify ou Drivy. Nous avons pris quelques décisions sur-le-champ, comme le nombre de squads et la gestion des cérémonies agiles. Nous avons volontairement laissé en suspens de nombreuses questions pour lesquelles nous n’avions pas assez d’information et de pratique : le scope des squads est-il fixe ? Et leur composition ? Nous avons essayé de rester les plus pragmatiques possibles pour ne pas nous perdre en grands plans théoriques.
Enfin, le changement… c’est tout le temps. Notre environnement (l’entreprise, les projets, les effectifs, les ressources, le marché…) évolue en permanence, nous aussi. La moindre frustration est une source de discussion et d’amélioration. Nous itérons régulièrement sur notre organisation et nous sommes toujours à l’affût du petit changement qui va nous permettre d’être plus efficaces.
Conclusion
Le bilan est très positif pour nous, notre productivité et notre valeur ajoutée pour la construction du produit ont augmenté. Notre épanouissement est resté stable, nous traitons a présent deux gros projets en parallèle au lieu d’un seul et notre engagement par sprint a crû pendant que notre effectif augmentait.
Pour généraliser notre expérience, nous pensons qu’il n’y a pas de bon moment théorique pour se restructurer. Chaque équipe a ses contraintes, ses expériences et ses préférences.
Comme pour beaucoup de changements structurels, la clé est l’engagement de tous les équipiers autour du projet. Si tout le monde est convaincu de l’utilité du changement, tout le monde ira de l’avant. L’équipe peut même y prendre du plaisir (c’était notre cas). Dans ce cas, 50% du travail est déjà réalisé. Pour le reste, il faudra faire preuve de flexibilité et de pragmatisme.
Enfin, il ne faut pas oublier que même si nous évoluons dans deux squads distinctes au quotidien, nous restons une seule et même équipe de développement pour beaucoup de sujets. Il ne s’agit pas de se mettre en concurrence.
Après la mise en place de notre nouvelle structure, nous regardons plus loin et de nouveaux challenges font leur apparition :
- nous continuons de grossir. Quand allons-nous créer une squad supplémentaire ?
- nos squads concernant pour l’instant principalement les développeurs, comment les élargir à l’équipe produit (product owner, designer, QA…), voire plus loin pour rendre les squads plus indépendantes ?
Vous avez une expérience différente ? N’hésitez pas à la partager avec nous !
