Selon le Scrum Guide, le cadre Agile le plus répandu, une équipe ne devrait pas compter plus de 10 personnes. Dans ma lecture sur le Management 3.0, j'avais également noté que Jurgen Appelo recommande 3 à 20 personnes maximum.

Dans le monde réel, les équipes peuvent faire face à des problèmes trop conséquents pour une telle équipe. Dans ces conditions, il s'agira alors d'adapter l'agilité à une taille d'équipe nettement plus importante, de l'adapter à une structure plus large... en déformant plus ou moins les principes de l'agilité : l'ajout de règles va en effet réduire l'agilité de l'équipe ainsi constituée, avec d'autres effets de bord, comme les risques de dette technique, fonctionnelle, organisationnelle, etc.

L'agilité à l'échelle

Pour y remédier, nous voyons revenir trois grandes approches dans la plupart des modèles d'agilité à l'échelle.

« Unscaling the problem »

Un bon point de départ est d'essayer de « couper » le problème pour avoir un ensemble de petits problèmes susceptibles d’être gérés de manière agile.

Par exemple, dans Team Topologies, il s'agira de structurer l’organisation en petites équipes capable de gérer leurs problèmes en toute autonomie (également le nom du livre fournissant 4 approches pour atteindre cet objectif).

Avec les OKR, présentés par Christina Wodtke dans « Radical Focus », l'idée est de définir des objectifs d'entreprise, globaux, pour ensuite les décliner au sein des équipes, pour maintenir leur autonomie. Les OKR sont constitués d'objectifs qualitatifs ,« inspirants et temporels », destinés à motiver l'équipe, et de résultats clés (« Key Results ») permettant de mesurer la progression de façon quantitative. Les OKR peuvent être utilisés au sein de n'importe quelle stratégie d'agilité à l'échelle pour accorder les priorités des équipes entre elles. Les OKR s'appliquant sur des périodes de 3 à 6 mois, ils permettent d'assurer la continuité des objectifs et priorités de sprint dans le temps, tout en permettant des réajustements réguliers.

Dans les deux cas, nous voyons bien remonter l'idée de subdiviser le problème en problèmes plus petits. C'est d'ailleurs un point qui ressort de Management 3.0 : passer d'un problème complexe (environné d'incertitude) en une série de problèmes compliqués, mais plus faciles à cerner.

Autonomie et Alignement

Pour s'assurer que les équipes avancent toutes dans la même direction, tout en préservant leur autonomie, il faut s'assurer qu'elles ont des objectifs eux-mêmes alignés, et non orthogonaux.

Dans le modèle de Spotify, se trouve grosso modo une matrice entre squad et chapitres (ou guildes). Les squads traitent chacune d'un problème, tandis que les chapitres assurent l'alignement pour chaque métier (présents dans les squads) sur des méthodes de travail homogènes.

Si nous regardons le fonctionnement de FAST, nous voyons qu'il s'agit d'une seule grosse équipe autour d'un produit donné, traitant des problèmes qui lui sont spécifiques. FAST permet de former et reformer dynamiquement des sous-équipes en fonction des sujets identifiés au sein du produit.

Cadencement

Le cadencement permet d'aligner les équipes sur un rythme commun, au prix de l'agilité de l'ensemble.

Un exemple clair de cette idée est Nexus, où les équipes partagent un objectif commun, et même si chaque équipe à son propre sprint, ils commencent et finissent en même temps. LeSS repose également sur un cadencement des sprints, avec des rituels de début et de fin communs. SAFe est probablement le plus extrême, car il impose un train de releases commun à toutes les équipes, avec un système de Program Increment permettant d'aligner les wagons des équipes.

De son côté Scrum@Scale propose de construire un « Scrum of Scrum » à l'image d'une fractale : à chaque niveau se retrouvent des Scrum Masters et Product Owners.

Team Topologies

Au sein d'une organisation, les équipes peuvent également endosser des rôles et missions qui leur seront spécifiques. Elles vont alors s'agencer et s'interconnecter de la façon la plus adaptée pour favoriser la collaboration entre elles.

Comme son nom l'indique, Team Topologies décrit un ensemble de « topologies » d’équipes, qui vont précisément se focaliser sur la structure de l'équipe, avec leurs avantages et inconvénients. Ceux-ci sont évalués selon 5 axes différents :

la spécialisation de l’équipe,
la vision d’ensemble sur le produit, sa finalité, etc.,
la vision d’ensemble sur ses aspects techniques, et l’expertise associée,
la faculté à collaborer et communiquer avec les autres équipes, notamment commerciales,
le périmètre des responsabilités de l’équipe.

Les topologies

Complicated-Subsystem team : cette topologie est conçue pour gérer les systèmes ou composants complexes et les équipes sont formées en fonction de leur expertise technique. Elle repose donc sur la spécialisation de l’équipe, avec une collaboration efficace, et une meilleure compréhension du système complexe. Cependant, elle manque de collaboration avec les équipes commerciales, et manque de vision sur l’ensemble du produit.

Stream-Aligned team : cette topologie est conçue pour aligner les équipes sur le flux de travail du produit et du client. Cela correspond grosso-modo à l’équipe produit, ou du moins qui travaille sur des fonctionnalités du produit. Cette topologie joue sur une meilleure collaboration avec les équipes commerciales, et une vision plus large sur l’ensemble du produit. Cependant, l’équipe aura moins de spécialisation, et sera moins efficace en termes de collaboration entre les équipes techniques.

Platform team : cette topologie est conçue pour construire des plateformes ou services pour soutenir les produits, leur fournir une abstraction (ce peut être le matériel, un framework commun, etc.). Elle favorise la réutilisation des plates-formes et une meilleure compréhension de l’infrastructure technique. Cependant, l’équipe manquera de collaboration avec les équipes commerciales, et ne disposera que d’une vision limitée sur les produits.

Enabling team : cette dernière topologie est conçue pour soutenir les autres équipes en fournissant des outils et des services. Ce sont des équipes transverses, destinées à faire progresser les autres équipes (ils ne vont pas traiter les sujets eux-mêmes). Elle fait ressortir une meilleure collaboration avec les autres équipes, et améliore l’efficacité des échanges avec les autres équipes. En contre-partie, elle manifeste un manque de vision sur les produits finaux, et moins de reconnaissance pour les contributions de l’équipe.

Chaque entreprise est ensuite encouragée à piocher parmi ces quatre modèles, en fonction des besoins, et à réfléchir à leur bonne combinaison.

Les interactions

Pour cela, Team Topologies définit trois formes d'interaction parmi lesquelles l'entreprise pourra piocher, pour interconnecter deux topologies d'équipe différentes.

La collaboration, impliquant un rapprochement important, entre les deux équipes, sera recommandée pour interconnecter des topologies Stream-Aligned et Complicated-Subsystem.
« as a Service », correspondra plutôt au cas où des services proposés par une topologie Platform ou Complicated-Subsystem doivent être utilisés par une équipe « Stream Aligned » sans plus de collaboration.
Enfin, l'interaction de type facilitateur, où l’équipe apporte son aide au traitement d’un problème spécifique, correspondra plus au cas où une équipe adoptant la topologie Enabling doit soutenir une équipe « Stream-Aligned ».

Pour l'entreprise, il s’agit finalement de faire preuve de créativité et de flexibilité, en matière d’organisation des équipes pour répondre aux besoins tels qu'ils se présentent.

Maintenant, Team Topologies n'est pas un framework autonome, mais plutôt un moyen pour faciliter la transition de l'organisation vers un modèle d'organisation plus agile : il doit être vu comme une structure complémentaire.

Les usages en entreprise

Si SAFe reste l'un des modèles les plus utilisés (comme le confirme macertif.com), LeSS est privilégié pour sa structure minimaliste et empirique.

SAFe est en quelques sortes une boîte à outils, avec de nombreux processus sur lesquels les responsables de l'organisation peuvent s'appuyer pour coordonner leurs équipes. Pour cela, SAFe introduit une notion de « Train » où les équipes sont des « Wagons » travaillant de concert sur un « Program Increment » ou itération du produit. Cet incrément est constitué d'une série de sprints menant à la livraison d'une nouvelle version du produit. Enfin, SAFe inclut explicitement Team Topologies comme moyen pour organiser les équipes autour de la création de valeur.

LeSS, quant à lui, consiste à synchroniser plusieurs équipes (ou « sous-équipes ») sur les mêmes artefacts, rituels et rôles de Scrum (Backlog, Sprints, sprint planning, daily stand-up, Product Owner, Scrum Master, Dev, etc.), tout en les laissant autonome quant à la résolution de leur objectif respectif. Ces équipes peuvent d'ailleurs se recombiner à chaque début de sprint en fonction des objectifs à traiter.

Beaucoup d'entreprises conservent également une base mixant Scrum et Kanban communément appelée « Scrumban ». Cette approche consiste à prendre Scrum, en y ajoutant le suivi des tickets selon la démarche de Kanban : en fonction de la progression du ticket, divers membres de l'équipe interviennent (Product Owner pour la conception, Dev pour l'implémentation, etc.). Ce modèle pourra être encadré dans une structure plus large comme LeSS ou reprenant tout simplement les principes de Lean (d'où est tiré Kanban).

Certaines entreprises conçoivent également leur propre modèle, comme IBM qui avait proposé « Disciplined Agile Delivery » en 2016 (en gros, des sprints encapsulés dans un flux macro, avec exploration/validation, construction et déploiement en production). De mon expérience personnelle, j'ai vu émerger de cette façon une organisation combinant peu ou prou Scrumban et LeSS.

Finalement, quelle serait la meilleure approche ?

Personnellement, j'ai un faible pour FAST et LeSS, justement pour la souplesse qu'ils apportent à l'organisation de l'équipe en interne (je suis toujours très attaché à l'autonomie et la flexibilité).

FAST a de commun avec LeSS qu'il permet de créer des sous-équipes temporaires, qui peuvent ensuite se coordonner de manière souple, au sein de l'ensemble plus grand que constitue l'équipe. Elles mettent ainsi l'accent sur la simplicité structurelle et la recherche de la bonne granularité d’équipe, plutôt que sur des règles de gouvernance très détaillées.

Là où FAST se distingue de LeSS, c'est qu'il est moins à cheval sur le respect et la coordination des équipes autour des rituels et artefacts de Scrum. L'alignement se retrouvera plus au niveau des interfaces entre les services développés par les équipes (au sens technique du terme, comme les contrats d'API).

Maintenant, ceci est mon avis personnel, basé sur mes préférences. D'autres personnes préfèrent des cadres plus structurés.

Au bout du compte, la meilleure approche est probablement celle proposée par Wemanity : « adopter une démarche progressive et adaptée à votre secteur, à votre contexte, à vos équipes et aux process déjà existants. » Connaître Scrum, Kanban, Lean ainsi que les frameworks et leur philosophie apporte une bonne base de réflexion, mais cette réflexion doit amener à l'organisation qui convient le mieux aux produits (donc aux clients) et aux personnes composant les équipes.

L’agilité à l’échelle