L’équipe s’agrandit : comment s’organiser ?
Comment mettre en place des feature teams quand le projet gagne en ampleur et nécessite plus de collaborateurs
En l’espace d’un an, l’équipe Player de la Direction du Numérique de France Télévisions a plus que doublée d’effectif. Passant ainsi de 6 développeurs à 12 développeurs plus 2 testeurs, cette transition a posée beaucoup de questions et de difficultés.
En tant que Scrum Master, je vous propose de partager notre expérience de ce passage à l’échelle plutôt réussi — et surtout quelles erreurs avons-nous commis en cours de chemin !
La fin de l’article contient également des pistes pour réussir la mise en place de feature teams.
Plusieurs backlogs, plusieurs équipes donc, mais rituels en commun
L’augmentation de la taille de l’équipe s’est très vite traduite par plusieurs backlogs séparés. En d’autres termes, plusieurs équipes qui avancent en parallèle sur des sujets différents.
Comment s’assurer que chacun serait capable d’adresser tous les sujets ?
Cependant, une question était dans toutes les têtes, une peur assaillait tout le monde : comment s’assurer que chacun serait capable d’adresser tous les sujets ? Cette inquiétude, que je partageais au début, avait guidé notre organisation.
Ainsi s’il s’agissait bien de plusieurs équipes, ses membres tournaient très régulièrement entre les équipes. À un moment, c’était même devenue une contrainte imposée, ou du moins formalisée, avec un nombre fixe de personnes qui devaient changer d’équipe à chaque itération.
Les rituels restaient effectués ensemble et non par équipe
Dans le même ordre d’idée, les rituels restaient effectués ensemble et non par équipe : stand-up quotidien, rétrospective, refinements.
Conséquence immédiate : une amplification de tous les problèmes que nous avions déjà.
Commençons par le stand-up quotidien : je n’ai rien à reprocher à l’équipe, qui malgré son gros effectif réussissait à tenir le challenge du stand-up en 15 minutes. Chapeau !! Là où le bât blesse, c’est que ce point quotidien apportait de moins en moins de valeur à ses participants à mesure que leur nombre augmentait. La partie “qu’ai-je fait la veille” devenait soit inintéressante par manque d’intérêt de l’auditoire, soit creuse par manque de temps pour détailler ce qui compte. De même la partie “organisation de la journée” passait assez souvent à la trappe puisqu’elle ne concernait pas tout le monde, avec l’idée que c’était fait juste après en post-stand-up et en comité réduit.
Dans la même veine, les rétrospectives devenaient de plus en plus douloureuses et inefficaces puisque s’enchaînaient les moments où les commentaires de l’un ne concernaient pas les autres. Le vote sur les éléments à discuter était orienté par la majorité, laissant pour compte les sujets portés par une équipe plus petite. Les actions pour l’itération suivante étaient souvent soit trop généralistes (difficiles à mettre en place), soit trop spécifiques (apportant peu de valeur).
Et, bien entendu, le fait que plus il y a de personnes dans une discussion, plus il y a de chances que des personnes — même non décisionnaires — ne soient pas d’accord et tiennent à en découdre. Ce qui rendait encore plus douloureux les refinements, une réunion déjà difficile à mener en soi.
Ma campagne pour séparer les équipes
Alors que je constatais ces différents problèmes, je me suis convaincu qu’il fallait au contraire séparer complètement les équipes.
J’ai ainsi cité qu’une des valeurs principales de Scrum est focus :
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
Pour qu’une équipe puisse être performante et efficace, elle doit pouvoir se concentrer sur sa mission. Elle ne peut pas prendre en charge trop de missions, au risque de n’en réussir aucune.
L’équipe ne peut pas prendre en charge trop de missions, au risque de n’en réussir aucune.
Échec de Scrum Master : l’équipe veut rester ensemble
Malheureusement, je n’ai pas réussi à convaincre tout le monde du bien-fondé de cette vision. Les membres de l’équipe restaient sur cette idée, cette crainte, que chacun devait être capable de toucher à tout, de suivre tous les sujets.
Un réel besoin d’alignement technique est nécessaire.
D’une certaine manière, je les comprenais. J’étais moi-même bien conscient que même si les sujets n’étaient pas les mêmes, les équipes travaillaient néanmoins sur la même base de code, avec les mêmes process, les mêmes outils. Un réel besoin d’alignement technique est nécessaire. Finalement, la vraie question est là : quelles structures mettre en place pour que plusieurs features teams soient alignées techniquement. C’est probablement la raison principale pour laquelle la mise en place de feature team n’est pas la plus naturelle en général…
Réfléchissez-y : le concept de feature team nécessite une certaine maturité Agile pour bien se convaincre qu’une équipe pluri-disciplinaire et qui prend en charge les problèmes de bout en bout, permet de construire beaucoup plus de valeur, plus rapidement et avec moins de problèmes.
A l’inverse, on visualise très bien tous les problèmes que le passage aux features teams engendre par rapport à un découpage du projet par composants en plusieurs component teams : qui va assurer la cohérence des développements entre chaque équipe qui touche au même composant ? Qui va prendre l’ownership de la bonne qualité du code ? Qui s’assure que le composant compile, est bien géré par une intégration continue, que les tests passent ? Plus important encore : qui s’assure que le moindre changement n’impacte négativement aucun des (autres) projets ?
Rien d’étonnant que, par facilité, on préfère s’orienter vers des component teams… Les responsabilités sont plus simples à gérer.
Faisant fi de ces questions, qui ne me semblaient que des problèmes techniques que l’équipe arriverait bien à résoudre d’elle-même, j’ai tout de même amorcé le changement, étape par étape…
Figer les membres des équipes
Décision d’arrêter de faire tourner les membres des équipes. Plus précisément, l’état par défaut devenait que personne ne changeait d’équipe, plutôt que d’imposer un changement à chaque itération.
Ainsi, le but n’était absolument pas d’interdire aux personnes de changer d’équipe : si leur équipe actuelle ne leur convenait pas, bien sûr que nous trouverions une solution.
Dans l’ensemble, cela n’a pas posé de problème car, finalement, chacun avait ses sujets de prédilection et se satisfaisait de rester dans la même équipe, dès lors qu’il était dans la “bonne” équipe pour lui. Les personnes sont également contentes de pouvoir suivre les sujets dans la durée, de voir grandir leur code et devenir un produit qui bouge.
Les membres de l’équipe apprennent plus facilement de leurs erreurs
Points positifs : les membres de l’équipe ne découvrent plus les sujets, ils les prennent en main puis les maîtrisent. Ils corrigent les bugs qu’ils ont introduit eux-mêmes, ce qui est à la fois plus sain, plus efficace et plus gratifiant. Ils apprennent plus facilement de leurs erreurs.
Rapprocher au maximum les équipes dans l’open-space
Nous sommes tous dans le même open-space, mais toutes les personnes composant une même équipe ne sont pas forcément côte-à-côte. Bien entendu, puisque les membres de chaque équipe changeaient à chaque itération !
En tant que développeur, j’ai déjà eu l’incroyable chance d’avoir pour voisins les collègues avec qui je travaillais directement au quotidien. Scrum prend une toute autre dimension quand les membres de l’équipe travaillent littéralement ensemble.
Scrum prend une toute autre dimension quand les membres de l’équipe travaillent littéralement ensemble.
J’ai donc convaincu les quelques personnes nécessaires de changer de place pour faire en sorte que les équipes soient regroupées.
Quels arguments m’a-t-on opposé pour ne pas procéder au déménagement ? La feignantise bien entendu de procéder au déménagement ainsi que de quitter une place qu’on a appris à aimer, devoir changer ses petites habitudes. Mais aussi, toujours ce même argument, celui de se dire que les personnes vont moins échanger entre les équipes si on ne garde pas une proximité forte.
Séparer les stand-ups
Grosse inquiétude de l’équipe qu’en séparant les stand-ups, l’information ne circulerait plus entre les équipes.
Malgré tout, l’expérience est plus que positive. D’un stand-up de 15 minutes bien rempli où tout le monde se retient de digresser, nous sommes passés à un créneau de 30 minutes où s’enchaînent 3 stand-ups, un par équipe, où les échanges sont directement liés au contenu de l’itération de l’équipe.
Plus de flicage du temps, chacun parle sans trop se limiter, on adresse les vrais sujets
Ce changement a été salvateur dès son premier jour de mise en application. Plus de flicage du temps, chacun parle sans trop se limiter, on adresse les vrais sujets qui concernent les participants.
Séparer les rétrospectives
Le rituel suivant que je m’attache à faire traiter en équipes distinctes est la rétrospective.
Pour faire passer la pilule en douceur, je mélange mise en place et conclusion avec tout le monde, et le cœur de la rétrospective en équipes séparées. Petit truc bien trouvé, nous faisons la rétrospective dans une grande salle en forme de triangle : un coin pour chacune des trois équipes !
- Un petit icebreaker simple et positif avec tout le monde
- Les trois équipes se séparent, et mènent leurs propres rétrospectives dans un format très classique, bien connu de tous
- Les équipes se rejoignent pour une présentation en commun, à tout le monde, des actions retenues pour l’itération prochaine
- On ferme la rétrospective avec une petite question à tout le monde pour un côté fun et positif
- Et le plus important pour la fin… Vérifier que cette rétro a plu à tout le monde et que c’est quand même vachement mieux en séparant les équipes !
(ouf, c’était le cas)
Lors de la rétrospective suivante, seul l’icebreaker est fait avec tout le monde. Alors que deux équipes sur trois mènent une Rétro de Départ, la troisième équipe suit un format plus classique et finit sa rétrospective en avance. Ils quittent la salle plutôt que de perdre leur temps, personne ne s’en offusque.
Les rétrospectives par équipe sont bien plus constructives
Faut-il le préciser, ces rétrospectives par équipe sont bien plus constructives. Les problèmes soulevés sont bien plus pertinents, les actions proposées provoquent moins de débats. Beaucoup plus d’énergie se dégage des rétrospectives, elles terminent à l’heure voire en avance. Génial !
Séparer les revues de sprint
L’étape suivante consiste à séparer les revues de sprint.
De premier abord, il semblait logique de conserver un rituel commun de revue de sprint. C’est le moment idéal pour garder le contact entre les équipes, que tout le monde soit au courant de ce sur quoi travaillent ses collègues. Un point de synchro où on s’assure faire partie du même projet.
La plupart des personnes n’ont qu’un intérêt limité pour le détail des itérations des autres équipes
Là encore, cette hypothèse était erronée. Tout autant que nos stakeholders n’ont qu’un intérêt limité pour le détail de nos itérations, la plupart des personnes n’ont qu’un intérêt limité pour le détail des itérations des autres équipes.
Je m’explique, de peur de passer pour un iconoclaste : nous comptons pour nos stakeholders, ils sont très désireux de suivre nos équipes, de savoir ce qui est terminé, de voir des démos. Mais à un niveau relativement élevé, avec un focus très fonctionnel. Le détail précis des itérations ne les intéresse pas. Ils veulent la big picture.
Nous avons séparé en deux la revue de sprint. La revue technique ne concerne que l’équipe. La revue produit est ouverte à tous.
Pour remédier à la dualité de la revue de sprint, nous avons décidé de séparer en deux ce rituel, en s’inspirant directement d’une recommandation de Jeff Patton dans l’excellent livre User Story Mapping :
- D’un côté une revue technique, très informelle, aucune préparation, où l’équipe fait le tour du board, échange sur ce qui s’est bien et mal passé, et avec démo uniquement si quelqu’un en ressent le besoin.
- De l’autre une revue produit, qui s’adresse à un public beaucoup plus large, et dans laquelle les démonstrations sont à un niveau beaucoup plus fonctionnel et dans un format très concis.
Les deux revues ne sont pas synchronisées. La revue technique correspond à la fin de l’itération (avant la rétrospective) et est en lien direct avec le fonctionnement Scrum.
La revue produit, par contre, suit un autre rythme — un rythme qui reste à définir car les sujets de haut niveau ne sortent pas toujours à la même vitesse.
Comme vous l’aurez deviné, seule l’équipe concernée participe à la revue technique. À l’inverse, nous invitons tout le monde pour la revue produit.
Que reste-t-il ?
Arrivé à ce niveau, tous les rituels des équipes ont été séparés. Les équipes sont indépendantes. On pourrait même les désynchroniser et éviter de mener leurs rituels en parallèle. Cela arrivera peut-être même sûrement au fil des rétrospectives et des préférences de ses membres, qui sait ?
Notre crainte d’origine, celle d’un besoin d’alignement technique entre les équipes, reste vraie.
Alors tout va dans le meilleurs des mondes ? Et bien… Non. Notre crainte d’origine, celle d’un besoin d’alignement technique entre les équipes, reste vraie.
La difficile équation de l’architecture avec des feature teams
C’est une question difficile et récurrente dans un contexte Agile : que fait-on de l’architecture ? Comment réussir à construire un logiciel aux fondations solides, à l’architecture pertinente et adaptée, quand le quotidien consiste plutôt à essayer d’aller au plus vite possible à la valeur ?
Comment réussir à construire un logiciel aux fondations solides quand le quotidien consiste à aller au plus vite possible à la valeur ?
En d’autres termes, comment réussir à allier design émergent et architecture perenne ?
À chacun de trouver sa solution. Voici ce que nous allons expérimenter !
Les tests exploratoires en garde-fou du design émergent
L’idée est simple : faire le minimum et s’assurer que l’on n’a rien raté.
Ainsi, on essaie de pratiquer du design émergent, en essayant toujours d’implanter la solution la plus basique qui répond au besoin minimal. Puis, au fur et à mesure des évolutions, on fait grandir l’existant, on le fait pousser (grow en anglais) pour étendre ses capacités.
Bien entendu, cela ne donne pas un mandat pour faire n’importe quoi. Design émergent ne veut pas dire mauvaise qualité du code — bien au contraire. Les revues de codes se doivent d’être sans pitié, les critères SOLID doivent être respectés, le code doit être prévu pour être facilement remplaçable. Mais on prend bien garde à ne pas partir dans le over-engineering en développant une architecture qui répond à plus qu’au besoin réel.
Des tests exploratoires doivent être menés au plus tôt pour s’assurer que l’architecture permettra d’arriver à la finalité du projet
Enfin, et c’est le plus important, des tests exploratoires doivent être menés sur le logiciel en question. Et ils doivent être menés au plus tôt. Il faut challenger dès que possible les véritables cas d’usage, les contraintes fortes qu’il faudra supporter. Du point de vue du testeur, le but est de s’assurer que l’architecture mise en place permettra d’arriver à la finalité du projet.
Si les tests exploratoires révèlent des doutes sur la capacité de l’architecture à supporter le produit final, c’est super ! Car il est encore temps de changer d’architecture, puisque nous aurons menés ces tests au plus tôt.
Un rôle d’architecte distribué
Une équipe Scrum est constituée de différents spécialistes. C’est d’autant plus vrai en feature team, puisque l’équipe doit gérer une fonctionnalité de bout en bout.
L’idée est d’identifier ces spécialistes dans chaque équipe, et de formaliser leur existence. Ils forment ainsi une entité transverse qui fait office d’architecte distribué, à deux niveaux :
- Plusieurs spécialités, réparties sur les différents membres d’une équipe donnée, permettant d’avoir une vision complète des contraintes d’architectures
- Chaque spécialité est constituée de plusieurs experts, un dans chaque équipe, formant un collectif pour prendre des décisions communes et partagées entre les équipes
Ces collectifs de spécialités permettront un alignement technique des équipes
Au delà de l’aspect architecture, ces collectifs de spécialités permettront également un alignement technique en terme de bonnes pratiques.
L’approche est directement inspirée du concept de Chapter que l’on retrouve chez Spotify :
Conclusion
Curieux de savoir ce que donneront ces pistes ? Je vous donne rendez-vous à dans quelques mois pour de nouveaux partages et retours d’expérience !
