Après avoir mis en place ma nouvelle équipe, et alors que celle-ci avait trouvé son rythme et son organisation, nous avons fait face à un nouveau défi. En effet, suite à une décision de la direction, l’objectif de notre projet a été totalement remanié. Ceci a entraîné un changement complet du périmètre fonctionnel, qui devenait bien plus conséquent qu’initialement, avec une date de mise en service inchangée.

Pour faire face à ce défi, nous avons dû nous réorganiser et renforcer l’équipe. Comme celle-ci devenait trop grande, nous nous sommes inspirés de ce qui se fait en agilité à l’échelle (ex : LeSS, Scrum of Scrum, Nexus, etc.) et avons fait le choix de diviser l’équipe en “squads”. Avec un double objectif : optimiser notre capacité à paralléliser le travail et permettre à chaque squad de se concentrer sur un périmètre dédié.

Vous trouverez dans la suite de cet article mon retour d’expérience sur cette transformation, depuis la préparation du périmètre de chaque squad jusqu’à la manière dont nous avons facilité la synchronisation pour avancer ensemble vers notre objectif. Une nouvelle aventure organisationnelle et humaine.

Les étapes de la transformation

Préparation par les PO

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.

Renforcement et présentation

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.

Constitution des squads

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.

Les piliers de notre collaboration au quotidien

La mise en place de squads marque le début d’une nouvelle manière de travailler pour l’équipe. Pour que cette nouvelle organisation fonctionne, nous avons rapidement identifié trois piliers sur lesquels nous veillons au quotidien.

La cohésion humaine

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.

La synchronisation

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.

Une vision partagée

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.

Conseil final : adapter avant tout

Mon dernier conseil : il peut être tentant de vouloir directement appliquer un framework d’agilité à l’échelle comme LeSS ou Nexus. S’ils peuvent être pleins de bonnes idées, les appliquer sans les adapter à son propre contexte est souvent une erreur. Dans notre cas nous avons préféré piocher les concepts qui nous semblaient les plus pertinents. C’est en faisant du sur-mesure que nous avons trouvé notre propre modèle.

Par Mathieu COUTAND, Agile Master chez Valeuriad