Mettre en place des squads dans son équipe : mon retour d’expérience

Les Product owners ont réalisé un premier travail en amont. Il s’agissait de voir comment découper le périmètre fonctionnel pour faire travailler les squads en parallèle tout en limitant au maximum les adhérences.

La première étape a été de lister toutes les fonctionnalités attendues ainsi que les composants techniques impactés. Puis, avec l’aide du Leader technique et du Lead développeur, de faire une macro-estimation de chaque sujet afin de les répartir pour avoir des périmètres de tailles équivalentes et en minimisant les adhérences entre eux.

Cette phase préparatoire était primordiale pour offrir à l’équipe un cadre clair et faciliter les échanges à venir.

La deuxième étape a été de définir et trouver les profils manquants pour renforcer l’équipe. Ainsi nous avons accueilli plusieurs nouvelles personnes : des développeurs, un ingénieur de tests et un Product owner.

Nous avons profité de cette arrivée massive pour faire une journée sur site avec toute l’équipe réunie afin de mieux apprendre à nous connaître, partager les enjeux du projet avec les nouveaux arrivants (et une piqûre de rappel pour les anciens) et présenter à l’équipe la répartition des périmètres.

Vient la dernière étape, celle de la constitution des squads. A partir de la présentation des périmètres, les développeurs ont pu se répartir dans les squads en fonction de leurs préférences fonctionnelles et technologiques, tout en maintenant une séniorité équilibrée.

A noter que les rôles supports (ex : Agile master, Leader technique, Product manager) sont volontairement restés transverses afin de garantir la cohérence globale du produit, tant sur le plan technique que fonctionnel et méthodologique.

Ainsi l’équipe est répartie de cette manière :

• Transverse : Agile master, Leader technique, Product manager ;
• Par squad : Lead développeur, Développeurs, Product owner, Ingénieur de tests

Pour finir, nous avons échangé sur nos différentes instances pour identifier celles qui resteraient au niveau de l’équipe entière et celles qui seraient propres à chaque squad. Dans notre cas, notre choix s’est porté sur l’organisation suivante :

• Équipe entière : Sprint review ;
• Par squad : Daily meeting, Refinement, Rétrospective, Sprint planning.

Sans doute le pilier le plus important, il s’agit de préserver l’esprit d’équipe. Nous faisons une journée commune sur site qui est très appréciée car elle permet à chaque membre de se voir, de “faire équipe” et de favoriser les échanges. Nous avons complété par une seconde journée sur site hebdomadaire, cette fois-ci par squad, afin de renforcer les liens au sein de chaque groupe.

Le deuxième pilier consiste à organiser une synchronisation constante. Pour cela, nous avons plusieurs instances hebdomadaires :

• Un point technique entre tous les développeurs pour partager les bonnes pratiques et les problèmes rencontrés ;
• Un point entre les Product owners pour assurer la cohérence des sujets ;
• Un point entre les référents techniques pour garantir l’alignement technique global.

Enfin, pour garder le cap, il est important de conserver une vision d’ensemble. Nous avons fait le choix de conserver un unique Product backlog car toute l’équipe travaille sur le même produit. De la même manière, nous avons maintenu une unique “Definition of Done” pour garantir un niveau de qualité homogène sur l’ensemble des fonctionnalités. Et la Sprint review menée avec l’équipe complète permet à tous de voir l’avancement global et de célébrer les succès.