TLDR ; Quand je dis que je ne suis pas fan du modèle des Feature Teams, certains peuvent penser que c'est la conséquence d'un manque de délégation, voire d'un conservatisme organisationnel. Ce n'est rien de tout cela. C'est principalement dans un souci d'efficacité que je privilégie les squads (c'est à dire des équipes autonomes spécialisées par sujet métier / Bounded Contexts) MAIS associées à la technique du Swarming chaque fois que nécessaire. Attention : ce post contient aussi un mini coup de gueule contre la tristement célèbre Inverse Conway Maneuver ;-)

Cet article fait suite à mon post précédent ( DDD est-il de droite ? ) qui parlait de Domain Driven Design et de diverses préoccupations organisationnelles. Article dans lequel je mentionnais très brièvement que je n'étais pas fan des Feature Teams. Je vais expliquer ici pourquoi.

Le monde perdu des Feature Teams

J'ai déjà vécu la mode où tout le monde ne jurait que par les feature teams. C'était dans les années 2010 et la plupart des grandes organisations pensaient bien que cela allait les sauver de leurs problèmes de Culture (), de leur dette technique mais aussi de leur lourdeur bureaucratique. Le principe est simple : nous formons une équipe centrée sur le client, pluridisciplinaire mais stable, qui se verra régulièrement confier différentes missions. Des missions différentes mais à chaque fois autour d'une fonctionnalité particulière que l'équipe gérera seule du début à la fin (tranchage vertical). Pour y parvenir, la Feature Team pourra intervenir seule sur tous les composants qui se dresseront sur son chemin (front, back, infra, db etc).

L'idée d'une feature team est qu'elle n'a pas besoin de faire appel à d'autres équipes pour pouvoir ajouter une fonctionnalité ou une capacité à un produit.

Attention : la notion de « feature » dans l'équipe Feature ne signifie pas qu'elle est responsable d'un domaine métier particulier (ce qui serait sa spécialité). Non, la notion de « feature » correspond plutôt à l'unité de travail de l'équipe (qui peut changer régulièrement). Une feature team c'est un peu comme la A-Team : une équipe autonome qui résout les problèmes qui se posent (au début de chaque épisode) et qui change constamment de sujet avant de repartir vers de nouvelles aventures.

Mais les ennuis arrivent quand…

Dans de telles organisations, nous pouvons potentiellement avoir plusieurs équipes de fonctionnalités travaillant simultanément sur différentes fonctionnalités, mais toutes sur la même plate-forme/le même logiciel. Pour avoir vu ça ici et là dans des expériences anciennes ou chez des clients (quand j'étais consultant), cela peut donner lieu à :

• Problèmes de simultanéité entre les équipes lors du codage sur le même composant
• Base de code hétérogène se terminant par de nombreuses approches de conception différentes. Conduisant donc à un code plus compliqué à lire/comprendre/maintenir/évoluer (clash des cultures de développement ?)
• Conceptions centrées sur le court terme, les gens accordant moins d'attention à la durabilité et à la maintenabilité du code résultant. Comme si c'était presque intrinsèque à leur énoncé de mission.

En effet, traiter un domaine compliqué peut être une vraie galère ou conduire à beaucoup de code de domaine anémique avec les Feature Teams.

Alors. Comment faire face à toutes ces difficultés ?

Le modèle des « escouades » de Spotify

Pas étonnant alors que le modèle qui a émergé dans les années suivantes soit le modèle des « escouades » de Spotify. Celui-ci est parti du concept d'une équipe pluridisciplinaire et stable (comme une Feature team), mais les gens de Spotify sont allés plus loin sur l'aspect de l'autonomie.

Ils ont demandé à chacune de ces escouades d'investir plus longtemps et de rester affectée à un domaine d'activité particulier, à un aspect fonctionnel spécifique du produit. Ils ont compris qu'il fallait investir un minimum fonctionnellement parlant, pour pouvoir être pleinement efficaces, autonomes et capables de prendre des décisions pertinentes.

Et ne vous méprenez pas : "Squad" n'est pas seulement un terme "cool" pour parler d'une équipe. Les escouades sont des équipes AUTONOMES. Nous leur confions une mission qui s'inscrira dans la durée, et nous leur demanderons de s'approprier par eux-mêmes leur Domaine d'activité.

Le domaine sur lequel une équipe travaille doit tenir dans la tête de chacun

Team Topologies (par Matthew Skelton & Manuel Pais ) est venu quelques années après avec le terme « Stream-aligned team ». Mais alors que j'ai trouvé intéressante leur proposition de réduire la charge cognitive des équipes, en plaçant une limite supérieure stricte sur la taille des équipes ("le domaine sur lequel une équipe travaille doit tenir dans la tête de tout le monde"), je continue à préférer utiliser le nom "Squads" pour représenter autonomie.

A noter : travailler sur l'autonomie des équipes est une de mes passions comme j'en parlais récemment ici avec Comment éviter que votre quête d'autonomie des équipes ne tourne au chaos…

Squads & DDD : un duo fantastique pour faire face à la complexité des affaires

L'autonomie est vraiment le point commun entre le modèle "Squads" et le Domain Driven Design (DDD). En effet, ce dernier nous propose d'aligner notre logiciel sur les besoins des Domaines, et de diviser notre produit en différents « royaumes » autonomes mais connectés appelés Bounded Contexts (par exemple Comptabilité, Ventes, Recherche, etc.). Ces domaines/contextes délimités sont censés nous donner plus de liberté et d'autonomie pour délivrer de la valeur (par exemple, nous ne voulons pas nécessairement impacter et demander l'avis des équipes dédiées au marketing lorsque nous changeons une partie concernant la comptabilité). Pour plus de détails sur ce qu'est DDD, vous pouvez voir ceci ( Domain Driven Design expliqué en 3 minutes ).

Pour relever ce défi, nous voulons généralement n'avoir qu'une seule équipe responsable par Bounded Context (et très souvent avec quelque chose comme un module ou une web API par BC) car nous voulons que chacun d'entre eux soit cohérent à l'intérieur (en termes de conception et général approche).

Nous voulons avant tout un bon moment de commercialisation et des équipes autonomes dans leurs prises de décision. Nous adaptons donc notre architecture en conséquence, en suivant les limites de notre domaine. Avoir plusieurs équipes propriétaires du même contexte délimité compliquerait chaque prise de décision. BTW Domain Driven Design a mis un nom sur une situation où plusieurs équipes partageraient un morceau de code : Shared Kernel .

Même si tout est une question de contexte, je peux dire sans trop rougir qu'un noyau partagé est très souvent une situation pénible (une odeur ?) organisationnellement parlant. Au moins, cela demande une certaine maturité et une culture d'entreprise qui valorise la collaboration au sein de l'entreprise (ce que vous n'aurez pas si vous valorisez les gens et donnez des primes individuellement, par exemple) qui sont vraiment rares. Pas impossible mais rare.

En bref : nous voulons généralement éviter les situations où différentes équipes s'occupent de la même partie commerciale de notre produit.

L'utilisation des Feature teams semble insuffisante par essence au regard de cet objectif IMO.

Chez Agicap

Sans surprise, c'est plus ou moins ce que j'ai trouvé chez Agicap lorsque je suis arrivé l'année dernière pour être le VP of Engineering de cette scale-up européenne en plein essor.

Mais contrairement à la situation de Spotify où chaque Squad (comprenez "toute l'équipe") est vraiment autonome dans la prise de décision, les Product Managers d'Agicap ont été ceux qui ont fortement piloté la phase de mise en œuvre du développement.

Cela avait plutôt bien fonctionné jusqu'à présent. Notamment le fait de ne pas avoir de Product Owners (PO) mais plutôt des Product Managers, couvrant à la fois les phases de découverte et de livraison (très efficace).

Néanmoins, les équipes techniques recevaient régulièrement des demandes de la part des Product people pour faire évoluer la structure de leurs équipes. Des choses comme nous demander de déplacer un développeur spécifique d'une équipe à une autre afin qu'il corresponde mieux à leurs besoins fonctionnels actuels ou à venir. Suivre de telles demandes nous aurait conduit à prendre des décisions d'impact à long terme pour les gens mais basées sur l'actualité à court terme du produit (pour les semaines ou les mois à venir).

Quelle que soit la perspective que vous adoptez à ce sujet, cela ne me semble pas être une bonne idée.

Nous ne sommes pas des « ressources » bordel de merde !

Mon désir de favoriser des équipes autonomes remonte au milieu des années 2000, lorsque j'ai découvert XP (eXtreme Programming) au travail. J'ai pu expérimenter la puissance et l'efficacité locale d'une équipe XP autonome sur un projet pilote dans une grande banque d'investissement. Une expérience incroyable à tant de niveaux. Quelques années plus tard, j'ai également pu ressentir la frustration de travailler dans une grande organisation qui ne comprenait pas la dynamique des équipes de développement et le Dynamic Reteaming . Une organisation qui passait son temps à décomposer encore et encore nos équipes au gré des projets en vogue.

Comme je le disais dans mon article précédent, il faut au moins 6 mois pour constituer une équipe de développement efficace où les relations interpersonnelles sont efficaces et une certaine expertise métier est acquise.

Passer du temps à remanier les castings des équipes de développement affecte grandement notre efficacité. Aussi : nous ne sommes pas des machines ! Nous sommes des humains avec des affects, des liens et des attachements que nous tissons au fil du temps avec nos collègues.

(

Petite parenthèse : la manœuvre inverse de Conway (ICM)

Ce sont les mêmes raisons pour lesquelles certains d'entre nous se plaignent lorsque nous entendons parler de la manœuvre inverse de Conway (ICM) . Et je ne parle pas de la version originale de l'ICM qui était bien (c'est-à-dire : "casser les silos qui limitent la capacité de l'équipe à collaborer efficacement" ). Je parle de la façon dont des générations de consultants ont transformé l'ICM en un monstre de frankenstein (c'est-à-dire : « changez votre organisation afin d'atteindre votre architecture cible » ).

Sur ce sujet précis, attention à la prochaine série de supers articles de mon ami Cyrille DUPUYDAUBY (à paraître très prochainement). Il a été le premier à m'alerter sur ce sujet il y a des années et expliquera pourquoi.

Certains comme John CUTLER ou Mathias VERRAES ( Conway's Law Doesn't Apply to Rigid Designs ), ont déjà compris que des concepts comme la manœuvre inverse de Conway étaient probablement trop ambitieux compte tenu de la dette fonctionnelle et technique de certaines architectures :

« Enfin, il est facile de dire "juste responsabiliser vos équipes !" Même avec les meilleures intentions, cela pourrait ne pas être facile. Votre architecture et votre structure organisationnelle actuelles peuvent limiter vos options. » ( John CUTLER — TBM 27/52 : Niveaux de mandat )

Certains d'entre nous disent aussi que cette manœuvre est à la fois contraire à l'éthique et putain de naïve. Raison pour laquelle je parle même d'arnaque pour l'ICM.

Non éthique d'abord, parce qu'on ne joue pas comme ça avec les gens, les vrais humains dans nos organisations. Vous ne "refactorisez" pas les gens. Vous ne jouez pas avec les gens comme vous jouez avec le code.

C'est putain de naïf aussi, car la face cachée de l'Iceberg que vous allez rencontrer, c'est encore une fois la Culture. La chose familière aux passionnés de gestion du changement comme moi. Rappelles toi? Celui qui mange toutes les stratégies au petit déjeuner (cf. Peter Drucker).

)

Cette parenthèse sur le côté humain étant faite, revenons à notre sujet principal : ce que le Swarming peut apporter à des équipes stables et autonomes (ie Squad).

L'essaimage : ce petit plus qu'il nous fallait pour une organisation DDD efficace

Très bien. Tout d'abord : expliquons ce qu'est l'essaimage. L'essaimage est comme une Task Force (donc temporaire), mais au sein de laquelle nous aurons défini dès le départ qui sera responsable du support à la production de tout logiciel résultant (point encore plus important si, comme nous, vous êtes dans un « you build ça, tu le lances !"). Cela met en lumière de nombreuses décisions de conception collectives et évite la situation bien connue lors de la fin d'un groupe de travail : "BTW : qui s'occupe du support pour ce que nous venons de faire ensemble ?!?" (long silence ;-) Comme pour une task force, les membres d'un Swarming viennent de plusieurs équipes différentes et vont devoir travailler ensemble pour résoudre un problème de courte durée (avant de rejoindre leur squad en fin de journée)

Au-delà de son efficacité à faire collaborer les bonnes personnes en fonction du sujet, une initiative de Swarming apporte beaucoup de capital social à une organisation en favorisant temporairement les relations interpersonnelles entre différentes escouades (super utile pour le futur quand chacun reviendra dans son escouade).

Pourquoi avons-nous besoin de l'essaimage ?

Si l'on pousse trop loin et méconnaît le concept d'autonomie préconisé par DDD, on peut être tenté de confondre autonomie et isolement. On peut aussi être tenté de s'isoler un peu trop… Pour voir toute connectivité et toute interaction entre BCs comme le mal absolu à éviter.

J'ai vu beaucoup de gens tomber dans le piège d'arrêter de penser aux autres et de se concentrer uniquement sur leurs propres contextes délimités, sur leur propre équipe. Il peut être facile d'oublier que nous faisons partie d'un écosystème où chaque partie a un rôle à jouer et où les interactions doivent être limitées -certainement- (en termes de surface d'exposition) mais pas ignorées. Notre travail doit être utile et utilisé. Tout le monde (PMs, devs) rêve d'une situation où nous n'aurons jamais besoin d'autres équipes/BC pour avancer et apporter de la valeur. Mais tout le monde rêve...

En tous cas. Rien de tout cela ne correspond à ce que DDD nous dit. Au lieu de cela, DDD veut que chaque contexte délimité soit le plus autonome bien sûr, mais néanmoins utile aux besoins de nos utilisateurs. Pour y parvenir, nous devons connecter judicieusement les différents BC, et non les cacher complètement les uns des autres. Et c'est à cela que servent la plupart des schémas stratégiques de DDD : nous aider à autoriser en toute sécurité ces interactions entre BC.

Eh bien, Swarming intervient précisément dans ces quelques cas où nous devons travailler sur la synchronisation et les interactions entre 2 ou plusieurs contextes délimités.

L'essaimage peut également nous aider à survivre à des situations où nos BC ne sont pas encore bien définis. Avant une clarification de domaine ou de carte de contexte.

Lorsqu'un Swarming est terminé, chacun retrouve son équipe et ses sujets. L'essaimage est juste un moyen très efficace de collaborer avec des personnes de différentes équipes et expertises du domaine pour atteindre un objectif de manière efficace.

C'est pourquoi j'ai voulu que cette technique soit essayée à mon arrivée il y a un an. Et je dois avouer que je ne me lasse pas d'en voir les effets bénéfiques (maintenant que cela fait quelques mois que nous n'en avons pas fait l'expérience ici ou là).

Pour conclure : Swarming FTW !

Comme mentionné au début de cet article, j'ai vu tellement de situations compliquées mais surtout de bases de code incohérentes après avoir été touchées par plusieurs feature teams que je ne pense plus que la Feature Team soit intéressante.

Pire, j'ai vu plusieurs fois des Feature Teams pas très au fait ni intéressées par les subtilités ou le langage omniprésent de chaque partie fonctionnelle/BC. A chaque fois, l'impact sur la base de code a été dramatique (Domaine anémique ou approximatif).

Raison pour laquelle je ne pense pas que les équipes de fonctionnalités puissent rivaliser avec le combo Squads with Swarming chaque fois que nous devons pousser fort sur un sujet ou une collaboration donnée.

Prochaines étapes

Aujourd'hui chez Agicap, les tech sont très proches de leurs Product Managers. Mais la prochaine étape de notre parcours d'amélioration continue consistera pour les chefs de produit à impliquer encore plus tôt les techniciens lors de leur découverte (le fameux « décalage à gauche » pour la technologie).

J'aimerais aussi que nous commencions à réfléchir à la dualité Découverte Continue / Livraison Continue si chère à Marty Cagan & Jeff Patton. Cela devrait nous permettre encore plus de mettre notre énergie & notre force d'ingénierie UNIQUEMENT sur des idées validées par nos clients. Améliorer encore le rapport coût/bénéfice de nos actions.

« Maximiser la valeur, minimiser l'effort » (Jeff Patton)

Mais ce sera le sujet de prochains articles je pense.

Pour en savoir plus sur Agicap :

• Montrez-moi votre domaine ( Séance de cartographie contextuelle pour le suivi et la prévision des flux de trésorerie )
• https://agicap.com/
• https://career.agicap.com/