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.