L’agilité à l’échelle

Références

• L’agilité à l’échelle, c’est quoi ? (Agile at Scale), par Scrumlife
• Team Topologies, la synthèse de tobysinclair.com
• Team Topologies selon Atlassian
• Le site officiel (qui renvoi vers leur bouquin)
• FAST Guide
• Nexus framework
• LeSS framework
• Le point d’Atlassian sur LeSS
• SAFe référence
• Le point d’Atlassian sur SAFe
• Unfix, le petit dernier

Introduction

Une équipe agile, telle que définie par la méthodologie elle-même, est conçue pour ne compter au maximum 10 personnes, afin de se concentrer sur un problème donné.

Mais si le problème est trop conséquent pour une telle équipe, il s’agit d’adapter l’agilité à une taille d’équipe nettement plus importante.

L’ajout de règles réduit l’agilité de l’équipe, plus grosse, ainsi constituée. Cela pourra également entraîner de la dette technique, fonctionnelle, organisationnelle, etc.

Nous pouvons identifier trois grandes approches :

“Unscale the problem”

Essayer de “couper” le problème pour avoir un ensemble de petits problèmes susceptible d’être gérés de manière agile.

• Team Topologies : 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 cette objectif).
• OKR “Radical Focus” : sur la base des OKR d’entreprise, créer des OKR par équipe, pour maintenir leur autonomie.

Autonomie + Alignement

S’assurer que toutes les équipes aient des objectifs alignés (et pas orthogonaux), tout en étant autonome.

• Modèle de Spotify, grosso modo une matrice entre squad et chapitres/guildes.
• Kanban : centré sur le processus et le flux de travail.
• Fast : une seule grosse équipe, capable de former, reformer dynamiquement des équipes sur différents sujets lorsqu’ils arrivent et à intervalles réguliers.

Cadencement

Il réduit fortement l’agilité de l’ensemble.

• Nexus : objectif commun pour le sprint de chacune des équipes, et sprints cadencés des différentes équipes, afin de résoudre les problèmes de dépendance entre les équipes.
• LeSS : adapter Scrum pour le travail en parallèle de plusieurs équipes, toujours cadencés sur les mêmes sprints, avec des rituels de début/fin de sprint commun.
• Scrum@Scale : construire des “scrum of scrum” de façon fractal, le cas échéant, avec des scum masters et Product Owner à chaque niveau.
• SAFe : imposer un train de release entre toutes les équipes, avec un système de Pogram Increment permettant d’aligner les wagons de toute l’équipe.

OKR

Comme vu plus haut, le principe de base des OKR est de les créer d’abord au niveau de l’entreprise, puis de les décliner au sein des équipes.

Ils peuvent être utilisés en combinaison avec n’importe quel autre méthodologie (présenté plus bas), et doivent s’accorder avec les priorités des équipes et sprints.

À noter que les OKR visent à s’appliquer sur des périodes de 3 à 6 mois, avant d’être modifiés. Ce peut donc être un bon outil pour assurer la continuité des objectifs et priorités de sprint.

Team Topologies

Team Topologies décrit un ensemble de … “topologies” d’équipes, c’est-à-dire la façon de la structurer afin de favoriser la performance de l’équipe, autour de concepts du Lean (éliminer le superflus, etc.).

Team Topologies ne défini pas de rôles spécifiques, mais se concentre uniquement sur ces différentes façon de structurer l’équipe, leurs avantages, et leurs 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 technique, et l’expertise associée,
• la faculté à collaborer et communiquer avec les autres équipes, notamment commerciale,
• le périmètre des responsabilités de l’équipe.

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 reposes 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 jour 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 terme 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.

Cette méthodologie défini ensuite trois approches, pour mettre en relation les équipes :

• la collaboration, impliquant un rapprochement important, entre les deux équipes;
• “as a Service”, où l’une des équipes met à disposition ses services sans plus de collaboration;
• facilitateur, où l’équipe apporte son aide au traitement d’un problème spécifique.

La méthodologie va ensuite encourager l’une des approches en fonction des topologies concernées :

• Enabling + Stream-Aligned = facilitateur;
• Stream-Aligned + Complicated-Subsystem = collaboration;
• Complicated-Subsystem + Stream-Aligned = “as a Service”;
• Stream-Aligned + Platform = “as a Service”.

Les méthodes d’interaction vont ainsi varier en fonction des topologies d’équipes concernées. Là encore, l’entreprise pourra piocher dans les différentes méthodologies pour intégrer leurs topologies.

Il s’agit finalement de faire preuve de créativité et de flexibilité, dans l’approche en matière d’organisation des équipes pour répondre aux besoins, et suivre leur évolution au sein de l’entreprise.

Feature Team et Guildes

TODO : Spotify https://blog.crisp.se/2014/03/27/henrikkniberg/spotify-engineering-culture-part-1

FAST - Fluid Scaling Technology

Cette méthode se base sur les concepts d’Open Space (l’aménagement des bureaux) et d’Open Allocation (le fait de choisir son sujet par affinité) pour créer de la collaboration créative et organique, à petite ou plus grande échelle.

Le modèle se prête bien aux besoins de réactivité et d’innovation, particulièrement dans une organisation Agile (FAST for Agile) dans le cadre de développement logiciel.

Cette approche compte beaucoup sur l’autonomie et l’engagement des collaborateurs, y compris dans la gestion des dépendances : il rejoint clairement le modèle d’organisations ouvertes (“Verte”, voir “Opale”, dans le jargon de “Reinventing Organization”).

En contre-partie, ce modèle d’organisation, ultra-léger, impose peu de processus et de réunions. FAST s’appuie sur l’intelligence collective et la diversité des profiles de collaborateur (ceux-ci doivent être autonomes, favorisant l’intérêt du groupe sur l’intérêt personnel, et motivés pour apprendre de nouvelles choses).

Pour ce qui est des réunions, FAST propose un “FAST Meeting”, au début de son “Value Cycle”, au cours du quel l’ensemble des collaborateurs prennent connaissance des priorités, autour desquelles les équipes vont se former.

Ces équipes planifient, développent et livrent leur incrément au cours du Value Cycle, et font le point sur leur avancement au prochain “FAST Meeting”.

Le Value Cycle n’a pas de durée imposée (il est quand même recommandé de commencer par 2 jours). De plus, la logique de FAST étant de fonctionner en flot, l’idée est uniquement de partager la progression, et prendre connaissance des changements sur les priorités (évolutions, nouveautés, etc.).

FAST inclut les rôles de :

• Product Manager (porteur de la vision, des besoins clients, et de son expertise spécifique sur le discovery);
• Collaborateur Expérimenté (“T-Shaped”, ce qui signifie expert d’un domaine, compétent dans les autres);
• les autres collaborateurs, impliqué dans son équipe jusqu’à produire la valeur attendue, et montant progressivement en compétence;
• Coordinateur (un rôle de leader, pas de manager, qui n’est pas figé sur une personne, mais évolue en fonction des besoins, pour assurer la coordination des différentes équipes);
• Coordinateur de Fonctionnalité (assurant la finalisation d’une fonctionnalité, dans la mesure où les autres collaborateurs peuvent passer à un autre sujet à la fin d’un cycle, même si la fonctionnalité n’est pas achevé).

FAST repose sur :

• une cartographie produit, donnant une visée haut niveau des sujets à prioriser;
• le Discovery Tree d’un sujet (qui peut être un Opportunity Solution Tree);
• la Place de Marché donne l’état du cycle à l’instant donné, c’est-à-dire le travail en cours d’exécution;
• l’Accord Collectif rassemble les règles de vie de l’équipe FAST (processus de prise de décision, gestion de conflit, etc. là encore, confère “Reinventing Organization”, le sujet mérite bien un bouquin);
• le FAST Meeting, au cours du quel on clôture le cycle actuel, les collaborateurs se synchronisent, l’équipe refait le point sur la vision, les objectifs et les priorités, pour laisser les collaborateurs s’organiser sur la nouvelle itération.

Nexus

L’idée est de synchroniser, au sein d’une “Nexus”, entre 3 et 9 équipes Scrum (comptant 5 à 9 membres), autour d’un unique backlog produit.

Une Équipe d’Intégration, composée d’un Product Owner, un Scrum Master, et au moins un membre de chacune des équipes intégrées, est responsable de la coordination de l’ensemble du Nexus. Cette équipe est également garante de l’accomplissement des sujets listés dans le backlog produit.

Du point de vue produit, les items du Product Backlog doivent être affinés, de sorte à ce que chaque sujet intégrés au sprint planning puissent être traités indépendamment les uns des autres.

Chacune des équipes Scrum travaille sur l’une des fonctionnalités identifiée au cours du précédent Sprint Planning et intégrées dans le Nexus Sprint Backlog.

Le travail des équipes Scrum se déroule dans le bon vieux cadre du Sprint.

L’organisation de Nexus identifie des dailies à deux niveaux :

• celui de chacune des équipes Scrum, qui sont les dailies habituels, et
• celui de l’ensemble de l’équipe Nexus, auquel participent un représentant de chaque équipe (en plus du Scrum Master et du Product Owner), afin d’une part de suivre le progrès des équipe, et d’autres part (et surtout) pour identifier les éventuels points de dépendance entre plusieurs équipes Scrum (le cas échéant, cela peut entraîner d’autres points de synchronisation hors daily, directement entre les collaborateurs).

À la fin du sprint, une revue est organisée, comme dans le Scrum classique, afin de collecter les retours sur le sprint. Cette revue se fait avec le PO, le Scrum Master, et des représentants des différentes équipes. Cette revue inclut également les parties prenantes, afin de remonter les progrès effectués au cours du sprint.

La revue est également accompagnée de la rétrospective, identique à celle du Scrum classique, ramené à l’échelle de l’ensemble de l’équipe Nexus.

Le Nexus repose sur :

• le product backlog, définissant les objectifs produit;
• le Nexus sprint backlog, rassemblant les objectifs sélectionnés pour le sprint en cours;
• l’incrément intégré, cadré par sa “Definition of Done”, et inspecté à l’occasion de la revue de fin de sprint.

unFIX ?

unFIX fait partie des derniers nés des méthodologies de mise à l’échelle de l’Agile. Il repose sur un écosystème de petites équipes (les Crews) spécialisées.

Les équipes au sens d’unFIX comptent 3 à 7 personnes, et le modèle défini 7 modèles d’équipe :

• une Équipe Agile (Value Stream Crew), ou Scrum, dont le rôle est de gérer tout le processus de création de la valeur, et ce dès la réception du besoin client (d’où le “équipe Agile”, avec PO, Scrum Master, dev, etc.);
• une Équipe Support, ou de Coordination (Facilitation Crew), assure la coopération entre les différentes équipes agile (elle embarque des Product Managers, architectes, ingénieurs qualité, etc.);
• une Équipe d’Experts (Capability Crew), apportant, par définition, une expertise spécifique pour répondre à un besoin tout autant spécifique, de l’équipe Agile;
• une Équipe de Gestion (Governance Crew), apporte la vision et la stratégie de l’entreprise au niveau des différentes équipes et des collaborateurs, et sont à même d’affecter des rôles au sein équipes (développés plus bas);
• une Équipe Infrasctructure (Platform Crew), est l’équipe en charge de l’environnement dans lequel travaillent les équipes agiles, depuis les plateformes d’intégration, jusqu’aux plateformes de production (dans notre cas, peut s’étendre à “l’infrastructure” au sens où nous l’entendons aujourd’hui);
• une Équipe Expérience Utilisateur (Experience Crew), assure le lien avec les utilisateurs, autant pour la collecte des besoins, que pour leur soumettre les démonstrations, pour documenter les produits, etc.;
• une Équipe Partenariat (Partnership Crew), fournit une interface avec tout les interlocuteurs commerciaux, partenaires, sociétés de services, indépendants, etc.

On observe donc que les équipes agiles sont débarrassés de toutes les spécialisations afférentes à la production de valeur afin de pouvoir se concentrer sur cette dernière.

Pour chaque équipe (excepté l’équipe de gestion) sont définis des rôles particuliers, comme le capitaine, modérateur (chair) :

• le capitaine, assumant la fonction de leader pour son équipe (représente et assure l’unité de son équipe), ou
• le modérateur (chair), assure l’organisation des forums (sans pour autant avoir d’autorité sur les participants), ou encore
• les chefs (chiefs) qui sont les membres spécifiques de l’équipe de gestion (cf. plus haut).

unFIX défini également des forums, au sens littéral du terme, c’est-à-dire un espace d’échange et de prises de décisions relatives à un domaine de compétence spécifique (un peu comme les guildes dans d’autres modèles). Elles garantissent l’homogénéité de technique et de méthodes de travail entre les différentes équipes.

Les équipes sont construites sur une base, fournissant toutes les compétences et toutes les ressources nécessaires à la formation et au développement des équipes. C’est un peu le cadre de référence de l’entreprise, voir l’entreprise elle-même. À noter que, dans la logique d’unFIX, cette base est limitée à une centaine de personnes, centrés sur une gamme de produits communs. Pour une plus grande structure, il s’agit d’organiser plusieurs bases en leagues, et un système de clusters forment une échelle plus grande aux forums, ou aux équipes (pour garantir les collaborations entre elles à grande échelle).

LeSS

L’agile à grande échelle reste de l’agile. LeSS consiste à synchroniser jusqu’à 8 équipes de (maximum) 8 membres chacune sur une même base de cycles agiles (un format plus large de LeSS “Huge” permet d’aller jusqu’à une centaine de personnes).

Ces équipes travaillent sur le même produit :

• un seul backlog produit;
• une seule Definition of Done;
• un produit livré à la fin du sprint;
• un Product Owner;
• un seul sprint.

Chacune de ces équipes doivent être transverses (e.g. Dev, Ops, Q.A., etc.), afin de travailler sur une fonctionnalité donnée.

Le premier Sprint Planning rassemble toutes les équipes (par leurs représentants) autour du Product Owner, pour sélectionner les sujets à traiter sur le nouveau sprint. Cette réunion est également l’occasion d’anticiper les dépendances entres les équipes sur les différents sujets, pour préparer une éventuelle collaboration.

Le second Sprint Planning permet à chaque équipe, individuellement, de s’organiser au sein de leur propre sprint. L’équipe va découper ses tâches et répartir le travail, avant de se lancer dans son sprint.

Chaque équipe va également tenir ses rituels, comme le daily.

À noter qu’au cours de ces rituels, de même qu’au second Sprint Planning, un observateur d’une équipe donnée peut assister à l’un ou l’autre rituel d’une autre équipe, pour favoriser le partage d’information et la coordination (et éviter les points de blocages).

Le Product Backlog Refinment (PBR) est un événement prenant place au cours d’un sprint donné, pour préparer le sprint suivant, et plus précisément : pour revoir et affiner les sujets du backlog produit, de sorte à pouvoir les qualifier et prioriser, au cours du prochain Sprint Planning. Le Product Owner doit être entouré de représentants de chacune des équipes Scrum. À noter que des variantes du PBR sont évoqués : le “Overall PBR” sert lorsqu’un sujet donné sera partagé par plusieurs équipes (celles-ci se réunissent alors pour préparer le Sprint Planning), tandis qu’un “single-team PBR” est déconseillé, car une équipe donnée n’est pas sensé avoir à réaffiner ses sujets avant le Sprint Planning (ou alors, c’est un sujet vraiment très complexe).

Les Sprint Reviews et Restrospectives se font avec l’ensemble des équipes, pour suivre la progression globale sur le produit, et relever les éventuels besoins de coordination pour la suite.

LeSS Huge, le LeSS a (très) grande échelle, de 50 à plusieurs milliers de personnes, définira des rôles supplémentaires (comme le “Area Product Owner”) et des évolutions sur les artefacts et réunions de l’organisation.

Scrum@Scale

Comme LeSS, Scrum@Scale ambitionne de prolonger les principes Scrum à grande échelle. Il consiste à connecter plusieurs équipes Scrum en restant cohérent avec les préceptes du Scrum Guide : il s’agit en quelques sortes d’une organisation fractale.

Scrum@Scale met la valeur produite au centre du processus (les équipes Scrum travaillent chacune sur ses fonctionnalités). La mise à l’échelle commence par un premier groupe d’équipes, dont les sprints seront synchronisés. Ce premier groupe de référence sera coordonné par deux entités, socle du Scrum@Scale :

• l’Executive Meta Scrum, concentré sur la valeur produite (“Product Owner Cycle” : elle se constituera sur la base des Product Owners, puis Head of Product, puis autour du Chief Product Owner, pour propager vision, stratégie et objectifs de l’entreprise jusqu’aux équipes), et
• l’Executive Action Team, concentré sur la façon de produire cette valeur de la façon la plus efficace (“Scrum Master Cycle” : elle coordonnera, à terme, l’application des principes Scrum à l’ensemble de l’organisation).

Comme pour la plupart des autres méthodologies, celle-ci insiste sur l’importance pour chaque équipe Scrum d’avoir toutes les compétences métiers requises à la mise en production des fonctionnalités.

La première échelle du Scrum@Scale est le Scrum of Scrums :

• chaque équipe Scrum inclut (en plus des autres métiers) son Scrum Master et son Product Owner;
• chaque équipe Scrum a ses artefacts et rituels.

L’équipe “Scrum of Scrums” aura à son propre niveau les mêmes métiers de Scrum Master et Product Owner, ses artefacts, et ses rituels (avec un représentant pour chaque équipe Scrum - Team Lead ou PO ?). De la même façon qu’il est recommandé entre 4 et 5 membres pour une équipe Scrum (NB : 10 max), il est recommandé, pour le Scrum of Scrums, d’intégrer entre 4 et 5 équipes Scrums.

On peut ensuite pousser le vice plus loin, et faire un “Scrum of Scrums of Scrums” en appliquant les mêmes règles, un cran plus loin. Bien entendu, les responsabilités étant plus grandes, les intitulés peuvent évoluer (par exemple, les Product Owners des Scrums of Scrums seront plutôt des Head of Product, eux-mêmes encadrés par un Chief Product Owner).

À noter que le Daily à l’échelle du Scrum of Scrums (et au delà) sera orienté sur les points d’achoppement et la coordination entre les équipes Scrum du niveau inférieur (le Daily de l’équipe Scrum se concentre sur les éventuels points de blocage du collaborateur, qui ne sont pas forcément liés à d’autres personnes ou équipes).

Une autre façon de se représenter le Scrum of Scrums consiste en une sorte d’équipe virtuelle, uniquement composée de représentants des différentes équipes Scrums.

À noter que l’Executive Action Team (donc la partie Scrum Master de l’organisation) est :

• porteuse du Backlog produit (elle s’assure qu’il est alimenté, se charge d’y faire le tri, et de le prioriser),
• encadre l’élaboration de l’Executive Meta Scrum (et de l’organisation produit autour des Product Owners en elle-même), et
• s’assure du développement des équipes (expérience, apprentissage, etc.).

L’Executive Meta Scrum, le côté Produit de la Force, sera pour sa part, en charge de la déclinaison de la vision de l’entreprise (stratégie, objectifs, découpage, priorisation, etc.).

Les deux entités se retrouvent sur l’exploitation des processus Scrum (pour la production de valeur) et sur le suivi de la valeur produite (au moment du feedback). Elles demeurent ainsi au centre de l’organisation.

SAFe

SAFe ajoute un ensemble de principes et recommandation aux fondements de l’Agile, pour en permettre l’application à plus grande échelle.

Un peu comme Scrum@Scale, SAFe commence par l’accroissement de l’équipe Scrum, en introduisant de nouveaux rôles, artefacts et processus.

Le point d’entrée d’une organisation SAFe est le Program Backlog, qui s’apparente grosso modo au traditionnel Product Backlog. Il est donc logiquement sous la responsabilité du Product Manager (“Manager”, pas “Owner”, donc on met l’accent sur le Discovery, avec cette nuance). Les éléments de ce backlog sont également passés entre les mains d’experts systèmes et d’architecte, le cas échéant, pour l’élaboration des solutions (une version encore plus complexe de SAFe inclut un “Solution Backlog” pour centraliser le fruit des recherches sur les aspects techniques).

SAFe définie le PDCA comme structure de base de ses itérations :

• Plan : plannification des tâches de la prochaine itération.
• Do : réalisation des tâches planifiées.
• Check : les tâches planifiées sont intégrées, qualifiée, et soumise à validation fonctionnelle.
• Adjust : l’équipe va faire le point sur les tâches réalisées, et les éventuelles problèmes rencontrés, que ce soit d’un point de vue fonctionnel ou technique. Elle pourra alors intégrer de nouvelles tâches pour la prochaine planification.

Dans la méthodologie SAFe, PDCA peut être employé :

• à l’échelle de la journée (stand-up pour faire le point et ajuster sur la base de la veille planifier la journée, pour sa réalisation),
• ou sur un ensemble de quatre itérations, appelé “Program Increment”.

Le Program Increment est donc un ensemble logique d’itérations, qui se termine par la livraison d’un incrément de valeur à destination du client. Ce cycle aura une durée de 8 à 12 semaines, suivant les implémentations de SAFe.

Le Program Increment reprend donc les 4 étapes du PDCA, chacune sur une itération, avec en bonus une itération dédiée à l’innovation. Enfin, il intègre des étapes de synchronisation entre les équipes (par le biais de leurs POs pour les aspects fonctionnels, et de “Points Scrum” pour les aspects organisationnels) et par rapport aux objectifs de l’entreprise (notamment avec le concours d’un Product Manager, ou un supérieur hiérarchique, suivant l’organisation choisie).

PI Planning : chaque team se prend une partie du travail (une portion insécable de la fonctionnalité). On repère les dépendances et, soit on arrive à remodeler pour supprimer la dépendance, soit on prend acte, on assume pour débloquer la situation, et on porte le point pour l’amélioration (le but ultime c’est le 0 dépendances).

SAFe défini également une implémentation des méthodologies de (CE/)CI/CD (plus étendu, avec l’idée du “Continuous Exploration”), pour permettre des releases en continue des fonctionnalités, au fil de leur développement.

À noter qu’on observe en filigrane l’idée d’une organisation fractale, en terme de processus, de sorte à appliquer le CE/CI/CD à l’échelle d’une itération et d’un Program Increment.

Le schéma plus haut nous fait comprendre que SAFe défini également, très en détail, toute l’organisation autour de notre organisation d’équipes.

Synthèse des modèles d’organisation