Meetup : Comment s'organiser en squad ?

Changer d’organisation, passer à des équipes projet dédiées, est-ce une bonne solution ? Cette question se pose fréquemment en tant que tech leaders. Deux d’entre eux, qui ont franchi le pas, ont partagé leur vision à ce sujet lors du meetup Tech.Rocks du 8 avril 2021. Replay. 

Speakers who’s who ?

• Eric Tinoco - CIO de LittleBIG Connection, plateforme spécialisée dans les achats de prestations de conseil dans le domaine de l’IT et de l’ingénierie.
• Ronan Quillevere - CTO & CPO de Pitchy, logiciel de création et de montage vidéo en ligne adressé aux entreprises.

Ce meetup a été animé par Thomas Sérès - CTO de Pandacraft, plate-forme d’abonnement proposant des contenus éducatifs pour les enfants.

Qu’est-ce qui vous a poussé à passer en organisation squad ?

Eric Tinoco : Avant notre passage en squad, le fonctionnement de LittleBIG Connection était classique. On pratiquait un mode Scrum avec des sprints organisés plutôt en silos ou par compétence. En l’occurrence, la responsabilité du silo produit concernait les spécifications, l’assignation, le design et l’UX/UI. Il passait la main ensuite au développement, lui-même chargé de l’architecture, des estimations, du développement bien sûr et dans une certaine mesure du testing. La phase de test se poursuivait par le déploiement, la livraison, les feedbacks des utilisateurs, etc. Ce schéma fonctionnait bien jusqu’à une certaine taille d’équipe. À partir du moment où nous avons commencé à grandir, une problématique de distance est apparue, avec la difficulté de partager de manière orale et visuelle. Nous nous sommes donc interrogés sur l’efficacité de notre organisation. 

Ronan Quillevere : Quand on a démarré, chez Pitchy, il y a deux ans, on était une petite équipe de développeurs. On faisait aussi du Scrum classique avec des sprints de 2 semaines. Entre parenthèses, le fait d’être éditeur de notre logiciel, de l’héberger, on a la main sur notre mise en production. Ceci dit, l’équipe produit faisait son travail d’identification des stories, de définition de la priorisation avec les stakeholders, à savoir les fondateurs, le sales, le marketing… 

Toutefois, ce modèle posait des soucis notamment au niveau de la roadmap. Chaque fin de trimestre, on se réveillait au moment de la préparer. Les stories étaient à peu près claires mais il fallait les sizer dans l’urgence. Elles s’avéraient bien souvent imprécises et pas respectées le trimestre suivant. On n’arrivait jamais à tenir notre roadmap. 

Comment avez-vous franchi le pas ? 

Eric Tinoco : On est parti de plusieurs constats. Le premier, le fait d’avoir plusieurs silos, plusieurs product owners, plusieurs team lead créait parfois des doutes sur le fait de savoir vers qui se tourner pour avoir de l’information, malgré les cérémonies. Deuxième constat, cette confusion et le manque de réponse amenait des plaintes - des uns et les autres - de ne pas disposer d’assez de temps pour faire le job. À partir de là, on a lancé une phase de benchmark. En l’occurrence deux personnes ont fait ce travail, sont allées discuter avec d’autres organisations. Elles ont regardé ce qui se pratiquait pour trouver la solution qui pouvait corriger notre problématique. 

En interne aussi, on a beaucoup discuté, impliqué le COMEX et les équipes en général, à la fois pour acquérir une vision 360° de la situation et embarquer tout le monde. 

Ronan Quillevere : On est, tout d’abord, passé sur un mode à deux équipes. Un système où l’on a synchronisé les sprints. Ça n’a pas arrangé les choses. On n’avait pourtant exclu de se diviser sous un principe d’avoir le front end et back end de chaque côté. On pensait que ça allait poser trop de problèmes de dépendance. On avait plutôt une équipe orientée fonctionnalités vues par les utilisateurs, features. De l’autre, une équipe était plus engine orientée vers le moteur qu’on utilise pour rendre nos vidéos. Toutefois, on avait tout de même un peu de dépendance. 

Ceci étant, un autre défaut est apparu au niveau de la manière d’organiser le code et dont le logiciel est livré. Tout le monde travaillait sur la même branche et ça créait des moments de blocage de livraison de features. Finalement, on tombait vers ce même problème en fin de trimestre, à être dans le rush, à passer à côté de nos objectifs de roadmap. C’était un cercle vicieux. 

Comment fonctionnent vos équipes maintenant ?

Eric Tinoco : On a décidé de passer en cross-functional team tout en gardant ce qui nous semble pertinent dans le Scrum, à savoir les cérémonies. On a donc conservé daily, backlog, planning poker, retrospective. Ces dernières sont très importantes, dans la mesure où elles nous ont permis de récupérer pas mal de feedbacks pour poser la nouvelle organisation. 

Dans ce mode cross-functional team, on mixe un peu tous les corps de métier. On a un team lead, responsable de la communication et du reporting de l’équipe. Le tech lead est responsable de la partie technique et fait partie du comité tech lead qui gère, entre autres, l’onboarding et le code review. On a ensuite une QA qui permet de tester au plus proche des développeurs et de remonter les régressions le plus vite possible. On a défini une taille de dév raisonnable de 5 à 7 personnes. Par ailleurs, on a des profils mutualisés comme l’intégrateur web, l’UX et la partie PO. Celle-ci est précieuse car elle crée le lien de proximité entre les sujets et permet d’avoir une équipe orientée features. On est passé d’un mode très skills oriented à features oriented. Dans l’état, l’organisation n’est pas figée. On reste dans une recherche d’amélioration continue. 

Ronan Quillevere : On est passé à un mode squad après des discussions avec les équipes et toutes les parties prenantes. Ce qui m’intéressait dans ce fonctionnement était la perspective d’avoir une productivité linéaire par rapport aux ressources et aux gens dans l’équipe. Et puis, c’est un point sur lequel j’étais challengé, en tant que CTO, par les fondateurs de Pitchy. Ils étaient, certes, partant pour embaucher 10 personnes si le retour sur investissement était avéré et non pour gagner 10% de rapidité. Autre chose, le mode squad m’intéressait en termes d’isolation des équipes, plus pluridisciplinaires et autonomes. 

Maintenant, on fonctionne avec des streams dans lesquels on compose une team qui va gérer une feature, la créer, la développer en étant autonome. Quand la feature est prête, on la livre tout de suite. 

Est-ce efficace ?

Ronan Quillevere : Ça nous permet de réduire le time-to-market et d’améliorer le produit rapidement. C’est crucial pour nous qui sommes dans un milieu compétitif. Aujourd’hui, nos cycles de livraison ne sont pas liés à des cycles de Scrum, mais plutôt au fait que la feature est prête ou non. Dans ce contexte, nous pouvons lancer plusieurs mises en production sur des streams simultanés et on ne s’empêche pas de restructurer les équipes pour chaque feature. Désormais, nous avons le temps d’anticiper la préparation de la roadmap. 

Eric Tinoco : On a beau être des équipes feature, on a tout de même des moments (de réconciliation) consacrés à la démonstration. Aujourd’hui, tout le monde présente son travail. C’est un point qu’on avait mis en place, auquel on tient. On a une organisation à deux dimensions. La première, c’est le côté vertical chapter où les compétences sont partagées, où on a cette capacité à s’orienter sur la productivité. Ça permet de mettre tout le monde autour de la table pour monter des circuits de discussion très courts et  pouvoir tacler les problèmes très rapidement. 

Comment se passe la gestion des bugs ? 

Ronan Quillevere : Avant leur gestion était intégrée aux sprints. Ça ne marchait pas car bien souvent, ils étaient moins prioritaires que les nouvelles features. Aujourd’hui, on a mis en place un stream dédié à ça, avec des gens qui les gèrent. 

Eric Tinoco : Par rapport aux bugs, on utilise un concept de Google. Le principe est de dédier de la bande passante à certains sujets, dont les bugs. Ainsi, on a dans les feature teams une équipe dédiée à ça.  

En conclusion ?

Thomas Sérès : Adapter toutes les règles d’une méthodologie stricto sensu n’est pas forcément la meilleure solution. Le mieux est de prendre les principes qui font sens, les retours d’expérience, selon la situation de l’entreprise. Souvent une partie de la méthodologie peut suffire pour mieux fonctionner. Il faut donc rester en alerte sur ce qu’il faut prendre ou pas. D’autant que les choses bougent beaucoup.

À bientôt, durant le prochain meetup Tech.Rocks !

À vos agenda : https://www.meetup.com/fr-FR/Meetup-CTO-Tech-Rocks/