System Team dans SAFe, quels scénarios d’organisation ?

Dans un premier article, nous vous avons présenté quelques généralités sur la System Team, sa mission, ses responsabilités et sa composition telle que le décrit SAFe. A présent, nous aimerions vous présenter le résultat d’une réflexion que nous avons menée sur différents scénarios d’organisation des System Team (ST).

En savoir plus sur les System Team dans SAFe

Nous avons vu qu’une System Team était une équipe agile spécialisée et que sa principale raison d’être était de pouvoir apporter un soutien aux autres équipes agiles dans le cadre de la réalisation de leurs travaux, en leur fournissant un environnement de développement agile.

En termes d’organisation, SAFe ne préconise rien de bien précis sur les System Team, et plusieurs scénarios peuvent être envisagés.

·        Scénario 1 : Il y a une équipe système par Agile Release Train (ART) qui coordonne l’intégration et la validation de la solution

·        Scénario 2 : Il existe une seule équipe système pour l’ensemble des trains de la solution (Solution Train), qui peut assumer ces responsabilités pour tous les ART

·        Scénario 3 : Il existe des équipes système pour les ART et pour le Solution Train

D’autres scénarios peuvent être imaginés comme par exemple la mise en place de compétences OPS directement dans les équipes de réalisation… l’imagination humaine est sans limite ! Cependant, nous nous intéresserons ici uniquement à des scénarios prônant l’existence de System Team en tant qu’équipe agile.

Quid des System Architect / System Engineering ?

Avant de présenter plus en détails les scénarios, il est utile de revenir sur les rôles de System Architect (SA) et de System Engineering (SE) en quelques mots. Dans sa version 5, SAFe ne fait pas trop de différence entre les deux appellations et à tendance à les unir en permanence. SAFe parle de SA / SE comme un rôle de personne en charge de définir et communiquer une vision technique et architecturale commune pour un ART pour s’assurer que le système ou la Solution en voie de développement est adapté à l’usage auquel il est destiné.

Nous aimons introduire une différence entre SA et SE en précisant que le SE se positionne plus sur la définition et la communication sur la manière de réaliser le système ou la solution. C’est le SE qui précise le cadre de réalisation ; les principes et les règles de fabrication, les frameworks à utiliser… Quant à lui, le SA se concentre plus sur l’architecture du produit ou de la Solution en cours de développement.

Dans les scénarios retenus, nous pouvons choisir que les System Architects et les System Engineers font soit  partie de la System Team, soit n’en font pas partie. Arrêtons-nous quelques instants sur ces deux options possibles, sur leurs avantages et leurs inconvénients.

  • Option avec les SA/SE dans la System Team

Cette option offre l’avantage d’une proximité forte entre les profils architectes et les profils OPS, ce qui favorise la diffusion de l’information et améliore le traitement des sujets de type MCO (Maintien en Condition Opérationnelle) qui représentent une part importante des travaux à mener par la ST. Dans ce cas, les informations sont mieux communiquées, plus rapidement et avec moins d’ambiguïtés et d’incompréhensions au sein de l’équipe. Les architectes travaillant souvent en avance de phase, le transfert de connaissances est grandement facilité pendant toutes les cérémonies de l’équipe. Du fait de la nature des activités d’architecture et d’opération pouvant être différente entre les membres de l’équipe, le principal inconvénient réside dans le fait que deux sous-groupes peuvent se former au sein de l’équipe, avec d’un côté les architectes et de l’autre les OPS. Cela nécessite alors souvent de mettre en place des points spécifiques d’échanges et de synchronisation, et des « boards » particuliers.

  • Option avec les SA/SE en dehors de la System Team

Lorsque que les System Architects et les System Engineers ne font pas partie de l’équipe System Team, ils constituent alors un pool de compétences au sein du train, au même niveau que le Program Management. Le regroupement des SA et SE n’est pas considéré comme une équipe agile en tant que telle, avec un PO et un SM. Les principaux avantages de cette situation, c’est qu’il existe une meilleure émulation entre les architectes du train et les architectes de la Solution, et une meilleure visibilité sur le traitement de bout-en-bout des sujets techniques. Dans ce cas, la ST se concentre plutôt sur la construction et le maintien de la pipeline CI/CD et le support opérationnel auprès des équipes agiles de réalisation. A l’inverse, les SA / SE ne faisant pas partie de la ST, la transmission de l’information et le suivi de la réalisation des tâches techniques peuvent être plus compliqués.

Scénario 1 – Une équipe ST par train

Ce scénario est assez fréquent et fait appel au bon sens puisqu’il met en œuvre une équipe ST spécialisée par train. Les besoins d’intégration et de support des équipes sont importants et nécessitent l’appui d’une ST au niveau du train.

Avantages : L’équipe ST offre un support au plus près des équipes de réalisation avec un fort niveau de réactivité. L’équipe ST est considérée comme une équipe agile faisant partie intégrante du train et par conséquent, elle participe au PI Planning et gère son propre « board » d’équipe. Le PO et le SM de l’équipe participent à l’ART Sync. L’équipe est en charge de fournir le meilleur environnement de développement aux équipes de réalisation et travaille sur ses propres sujets (MCO internes et amélioration continue). Les sujets de l’équipe ST doivent être maturés au même titre que les autres sujets des équipes et intégrés au « board » du niveau Program sous forme d’Enablers.

Inconvénients : L’équipe ST est vu comme une équipe « services » et cela peut engendrer des tensions avec les équipes de réalisation qui ont souvent des attentes fortes, en particulier sur la disponibilité des environnements. L’organisation bascule souvent vers un système de « ticketing » qui peut sembler contraignant par les équipes[1] [2] . Il y a un risque d’isolement de l’équipe ST de par la nature des activités très différentes qu’elle exerce. Les membres de la ST peuvent avoir le sentiment d’être simplement des exécutants.

Pour que ce scénario fonctionne, il faut que la ST soit considérée à part entière comme une équipe agile, avec la présence d’un PO qui gère le backlog de l’équipe et d’un SM comme facilitateur et protecteur de l’équipe. Il y a nécessité de bien définir le mode de fonctionnement et les interactions entre les équipes de réalisation et la ST au sein du train, et de bien délimiter les zones de responsabilité de chacune d’elles.

Scénario 2 – Une seule équipe ST pour l’ensemble des trains de la Solution

Ce scénario propose la création d’une seule équipe System Team pour l’ensemble de la Solution. Le Solution Train est le concept organisationnel utilisé pour construire des solutions grandes et complexes qui requièrent la coordination de plusieurs Agile Release Trains (ART), ainsi que les contributions de fournisseurs (Suppliers).

Avantages : Il n’y a qu’une seule équipe ST à gérer, ce qui semble être plus simple, mais attention à ce que cette équipe reste de taille acceptable pour une équipe agile. Les compétences OPS sont concentrées au sein d’une seule équipe ce qui favorise les échanges et les partages des bonnes pratiques, ainsi qu’une certaine émulation et une homogénéité dans les manières de faire. Ce qui nous fait dire aussi que ce scénario convient bien lorsque les trains ont des problématiques très similaires en termes d’intégration et de déploiement. L’équipe peut également travailler sur des sujets et préoccupations transverses à tous les trains de la Solution.

Inconvénients : Il y a un risque que les membres de l’équipe se spécialisent sur un train en particulier, en délaissant les autres trains. L’équipe peut paraître plus éloignées des préoccupations spécifiques à certains trains et à des équipes en particulier. Le niveau Program d’un train peut avoir des difficultés dans l’activité de maturation de ses propres sujets techniques.

Pour que ce scénario fonctionne, il faut que les trains aient les mêmes besoins dans leur recherche d’autonomie. L’équipe System Team ne pourra pas (ou peu) répondre efficacement à des sollicitations d’un train en particulier. Et il y aura peut-être la nécessité de positionner quelques compétences OPS dans les équipes de réalisation afin de combler les lacunes ou les vides pouvant être engendre par l’existence d’une seule équipe ST au niveau de la Solution.

Scénario 3 – Une coexistence entre des équipes ST au niveau des trains et une équipe ST au niveau de la Solution

Ce scénario peut paraître luxueux, mais pourquoi pas ? Si les trains ont à la fois besoin de compétences OPS mutualisées au niveau de la Solution, tout en offrant une possibilité de satisfaire des demandes spécifiques, cette approche peut être intéressante.

Avantages : Les équipes ST au niveau des trains ont des périmètres plus réduits, ce qui favorise la réactivité et la maîtrise des connaissances et compétences nécessaires à chaque train.

Inconvénients : Il y aura mathématiquement un nombre d’équipes ST plus importants et des effectifs proportionnellement plus importants. Il y a un risque de zone de flou entre les périmètres des équipes au niveau des trains et de celle au niveau de la Solution. La multiplicité des équipes nécessite des synchronisations et des partages de connaissances plus fréquents entre les membres des différents équipes et apporte une certaine lourdeur à l’organisation.

Pour que ce scénario fonctionne, il faut une bonne répartition des responsabilités entre les équipes System Team.

En conclusion

En fonction du contexte et de la maturité de l’organisation, en fonction du type de produits et de solutions réalisés, nous voyons qu’il n’y a pas une seule manière de faire. La voie empruntée par les organisations est souvent un mix de scénarios, et la feuille de route est souvent ponctuée par des objectifs nécessitant la mise en place de transitions entre des scénarios.

Nous aurions pu évoquer également d’autres scénarios. Nous pensons en particulier à un scénario mixant à la fois des compétences OPS dans les équipes de réalisation, en charge d’une partie du processus d’intégration et de déploiement, et une équipe System Team en soutien sur des activités d’expertise ou d’appoint.

L’objectif ultime doit être toujours de rendre les équipes agiles les plus autonomes possible, et de faire en sorte qu’elles construisent et déploient en continu.

System Team dans SAFe, savez-vous ce qui se cache derrière ce terme ?

Lorsque l’agilité se déploie à l’échelle, une difficulté réside dans le fait de pouvoir faire travailler ensemble des équipes agiles et être en capacité d’intégrer les différents éléments d’un système produits par ces dernières. Autant l’agilité à petite échelle, c’est-à-dire au niveau d’une équipe, est bien maîtrisée aujourd’hui, autant la mise à échelle nécessite une organisation rigoureuse et une attention particulière. 

La System Team, un support aux équipes de réalisation

Ce que dit SAFe

Dans SAFe (le “framework” d’agilité à l’échelle le plus répandu), les équipes agiles ne sont pas des unités totalement autonomes. Au lieu de cela, elles font partie d’un ensemble que l’on appelle un Agile Release Train (ART). Ce train est responsable collectivement de la fourniture d’un système complet et d’une valeur de solution plus importants. Les pratiques de qualité intégrées nécessitent généralement un travail d’infrastructure supplémentaire pour créer, intégrer, déployer et publier des artefacts de solution plus fréquemment et en continu à travers plusieurs étapes d’une chaîne que l’on appelle pipeline. 

Pour soutenir cela, une ou plusieurs équipes systèmes spécialisées sont souvent formées, appelées System Team (ST). Concrètement, en tant que type d’équipe agile « habilitante », les System Team aident à créer les environnements et à intégrer le système et la solution. Les ST peuvent aussi accélérer les vitesses des équipes agiles en effectuant certains des tests les plus lents, de bout en bout et non fonctionnels (NFR). Elles aident également à faire la démonstration de la solution au fur et à mesure de son évolution.

Une mission claire, des responsabilités et des activités diverses et variées

Mission et responsabilités d’une System Team (toujours selon SAFe)

La mission d’une ST est d’aider à créer et à prendre en charge l’environnement de développement agile. Principalement, elle réalise le développement et la maintenance de la chaîne d’outils qui constitue le “pipeline de livraison continue”. Si besoin, elle prend en charge l’intégration des actifs des équipes agiles, effectue des tests de solution de bout en bout si nécessaire et aide au déploiement et à la publication des fonctionnalités à la demande (Deploy and Release). 

Sur l’intégration de l’infrastructure de développement agile, l’équipe doit créer et maintenir la chaîne d’outils du pipeline de livraison continue, y compris l’intégration continue, les builds automatisés, les tests de vérification de build automatisés et le déploiement automatisé. Elle doit créer des plates-formes et des environnements pour le développement, les démonstrations de solutions et les tests d’acceptation utilisateurs. Enfin, elle doit faciliter les aspects techniques de la collaboration avec des tiers, tels que les fournisseurs de données ou de services et les installations d’hébergement.

Sur l’intégration de la solution, l’équipe doit participer au PI Planning et aux événements pré et post-PI Planning dans la Large Solution SAFe et au raffinement du backlog pour définir l’intégration et tester les éléments du backlog. Elle doit déterminer et aider à maintenir les décisions et les politiques pour la gestion des versions. Elle doit exécuter des scripts de génération et d’intégration au niveau de la solution ou intégrer manuellement là où l’automatisation n’existe pas encore. Enfin, elle doit se tenir informée de l’avancement pour soutenir les activités quotidiennes des autres équipes.

Sur les tests de bout-en-bout de la solution, elle participe aux activités de test comme la création de nouveaux scénarios de tests automatisés, l’organisation des cas de test conçus par les équipes individuelles en suites ordonnées, l’exécution de certains tests manuels et des tests automatisés pour les nouvelles fonctionnalités, l’aide aux équipes dans la création de « smoke tests » ou de suites de tests réduits qui pourront être exécutés rapidement et indépendamment pour les versions des développeurs, le test des performances de la solution par rapport aux NFR (Non Functionnal Requirements) et le support aux System Architect (SA) et System Engineering (SE) du train et de la solution dans l’identification des lacunes et des goulots d’étranglement du système.

Sur la démonstration au niveau système et au niveau solution, l’équipe doit aider à préparer les environnements techniques pour une démonstration la plus fiable possible de la nouvelle fonctionnalité.

Sur la livraison de la solution, l’équipe doit soutenir l’ART ou le Solution Train pour préparer, packager et déployer une solution dans le cadre des activités DevOps et du pipeline de livraison continue.

La System Team, une équipe à géométrie variable

Nos retours d’expérience montrent que les System Team sont à géométrie variable en termes d’activités. Des équipes peuvent être plus ou moins engagées dans la réalisation des tâches d’intégration de la solution, la mise en oeuvre des tests de bout-en-bout ou les gestion des environnements de production et hors-production.

Composition et organisation d’une System Team

Une ST est une équipe agile spécialisée. Agile, cela veut dire qu’elle doit comprendre et appliquer le cadre de travail agile en mettant en œuvre les pratiques adéquates. Pour cela la présence d’un coach pour l’équipe est fortement conseillée en tant que garant et facilitateur. L’équipe System Team travaille sur le pipeline d’intégration continue (CI) et de déploiement continu (CD). Elle est en étroite collaboration avec les System Architect (SA) et les System Engineering (SE) du train. Agile, cela veut dire aussi qu’une personne de l’équipe doit jouer le rôle de « owner » pour définir la vision du produit de l’équipe (le pipeline CI/CD en l’occurrence) et sa feuille de route, gérer le backlog de l’équipe (maturation des sujets, priorisation des sujets en fonction de la valeur, …) et participer aux cérémonies de l’équipe et du train.

La System Team, des compétences d’OPS, mais pas uniquement !

SAFe n’impose pas de rôle particulier dans la ST, mais nous voyons bien que pour fonctionner correctement, cette équipe doit rassembler a minima des compétences d’OPS agissant sur l’infrastructure du système et des compétences d’architecture œuvrant sur la conception du système et l’environnement de développement agile. SAFe indique que des System Architect/ System Engineering peuvent faire partie de cette équipe mais cela ne revêt pas de caractère obligatoire. Il peut être intéressant que l’équipe dispose de compétences dans le développement avec des profils LeadDEV ou les techniques avec des LeadTECH.

Différentes configurations possibles dans l’organisation SAFe

Une ST aide un ou plusieurs ART à créer et à utiliser l’infrastructure de l’environnement de développement agile. SAFe laisse le choix du nombre et du positionnement des ST dans l’organisation agile. 

Plusieurs scénarios peuvent être envisagés :

  • Scénario 1 : Il y a une équipe système par ART qui coordonne l’intégration et la validation de la solution
  • Scénario 2 : Il existe une seule équipe système pour l’ensemble du train de solutions, qui peut assumer ces responsabilités pour tous les ART
  • Scénario 3 : Il existe des équipes système pour les ART et le train de solutions

En fonction du contexte et de la maturité de l’organisation, en fonction du type de produits et de solutions réalisés, nous voyons qu’il n’y a pas une seule manière de faire. Il est fortement recommandé que l’organisation soit accompagnée par un coach agile ou le LACE dans SAFe.

Nous verrons dans un prochain article les avantages et les inconvénients de ces différents scénarios et nous décrirons plus précisément le fonctionnement d’une System Team aux travers des rôles et des activités de ses membres.

Article extrait de la série publiée par Modern Product Agility, dans la rubrique "ÉCLAIRAGE SUR L'AGILITÉ"