Vous venez tout juste de rejoindre un projet appliquant le cadre méthodologique Scaled Agile Framework, plus connu sous le nom de SAFe, et avez encore du mal à comprendre ces acronymes étranges que sont les ART, PI, RTE, PO ou autres PPM?
Dans cet article, je vais aborder SAFe sous l’angle du Business Analyst, dont le positionnement est souvent difficile à cerner dans les contextes agiles. SAFe propose en effet une fusion des principes agiles et du Lean Management, ce qui peut sembler intimidant au premier abord… Mais pas de panique, l’objectif ici est de vous aider à mieux comprendre comment vous, en tant que Business Analyst, pouvez trouver votre place et contribuer efficacement.
Il faut bien l’admettre, quand on est habitué à travailler de manière traditionnelle, avec des projets informatiques gérés en suivant le modèle de cycle en V ou “waterfall”, avec ce framework SAFe, il faut tout réapprendre.
Bonne nouvelle : vous n’êtes pas seul.e dans cette galère!
Confrontée il y a quelques années à ce même grand moment de solitude, je tente dans cet article de répondre à ces questions existentielles partagées par toute notre profession.
Scaled Agile Framework (SAFe) : qu’est-ce-que c’est ?
En 2015, le Standish Group publiait une version réactualisée de son célèbre “Chaos Report” de 1995, et renouvelait le constat alarmant du très fort taux d’échec des projets informatiques – soit 71% en 2015 vs. 83% en 1995.
Les principaux facteurs d’échec évoqués étaient les suivants :
Manque de soutien de la direction
Exigences mal définies ou en évolution
Manque de planification et de gestion de projet
Changement de priorités au sein de l’entreprise
Technologie mal adaptée
Manque de compétences ou de ressources
Complexité du projet
Communication inadéquate
L’utilisation de plus en plus répandue des méthodes de gestion de projet agiles fait partie des facteurs d’amélioration du dramatique taux d’échec des projets de systèmes d’information, qui est passé de 83% en 1995 à 71% en 2015.
En 1995, les projets étaient uniquement gérés de manière traditionnelle, c’est-à-dire avec des modèles de type « en cascade » ou en « cycle en V ». Ces méthodes de gestion de projet avaient comme principal inconvénient « l’effet tunnel », qui fait référence au manque de visibilité sur l’avancement et la performance d’un projet, souvent due à un manque de communication ou de points de contrôle réguliers, et conduisant à des incertitudes et des surprises en fin de projet.
Elles sont encore majoritairement utilisées de nos jours (même camouflées derrière un jargon agile, mais ça, c’est une autre histoire).
Au début des années 2000 est apparu l’approche agile, dont l’objectif était de réduire ce fameux effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en suivant un processus de développement à la fois itératif et incrémental.
Scrum, XP et consorts sont des variantes de cette agilité à petite échelle, conçues pour des équipes petites à moyennes et appliquées au développement d’un produit logiciel spécifique.
Le Standish Group Chaos Report fait le constat que leur adoption de plus en plus fréquente dans la gestion des projets informatiques a permis au taux d’échec de ces derniers de commencer à diminuer doucement, bien que restant encore bien trop élevé.
Comme à chaque fois qu’une méthode est lancée, elle résout des problèmes mais en crée aussi de nouveaux, car son application implique de faire des modifications au niveau de l’entreprise, que ce soit en termes d’organisation, de stratégie, de formation des collaborateurs, de prise en compte des contraintes internes et externes etc. Or c’est rarement le cas.
En parallèle de l’évolution des méthodes des gestion de projets, on a vu fleurir de nombreuses nouvelles démarches / techniques / méthodes de management : Lean Management, Kanban (ancienne méthode remise au goût du jour), BPM, Six-Sigma etc… Bref, de nos jours, il y en a un nombre incalculable, qui ont parfois bien du mal à cohabiter et qui durent le temps que la « mode » passe auprès des cadres dirigeants.
Revenons au Scaled Agile Framework.
Né en 2007, ce concept a été formalisé en 2007 par un entrepreneur américain, Dean Leffingwell. Son objectif était de « permettre l’agilité commerciale nécessaire aux entreprises pour être compétitives et prospérer à l’ère numérique. Pour ce faire, chaque partie de l’organisation impliquée dans la délivrance de solutions technologiques – développement, opérations, production, juridique, marketing, finances, conformité, ventes et autres – doit adopter les principes et les pratiques du Lean et de l’Agile. »
On peut donc voir SAFe comme l’amélioration de la démarche agile par l’intégration de l’approche de Lean Management, au niveau de l’Organisation, et non pas uniquement au niveau d’un projet.
Pourquoi est-ce si important de connaître votre rôle dans un projet SAFe ?
Déjà, avec les méthodes agiles – créées initialement par les développeurs pour les développeurs, il n’est pas évident au premier abord de se positionner en tant que Business Analyst puisque ce rôle n’a pas été décrit. La méthode SCRUM, par exemple, définit uniquement 3 entités : le Scrum Master, le Product Owner et la « development team ».
Or, le framework SAFe ne parle ni ne décrit davantage le rôle de Business Analyst.
Nombre de Business Analysts, quand ils ne perçoivent pas bien l’objectif de leur mission, se contentent d’être réactifs au lieu d’être proactifs. Ils font ce qu’on leur demande de faire à un instant T. Or, un Business Analyst est là justement pour porter la vision métier, il doit constamment s’assurer que le projet ou les tâches qu’il réalise vont dans le sens d’un apport de valeur global au client et aux utilisateurs.
La première chose à faire est donc de lever la tête du guidon, et d’identifier sans ambiguïté son rôle et ses responsabilités exactes au sein du projet.
Alors, kesako ?
Les activités du Business Analyst selon l’IIBA®
Pour ce faire, il suffit en réalité de revenir aux fondamentaux : au lieu de chercher, dans chaque nouvelle méthode ou démarche, où se situe le rôle de business analyst, cherchez plutôt qui, au sein de la méthode employée (ici, SAFe), endosse tout ou partie des responsabilités de Business Analyse.
Voici comment l’International Institute of Business Analysis (IIBA) décrit l’analyse métier :
« La Business Analyse est la pratique qui consiste à favoriser le changement dans une entreprise en définissant les besoins et en recommandant des solutions qui apportent une valeur ajoutée aux parties prenantes. Elle permet à une entreprise d’articuler les besoins et la justification du changement, ainsi que de concevoir et de décrire des solutions qui peuvent apporter de la valeur.
La Business Analyse est réalisée de différentes manières sein d’une entreprise. Les initiatives peuvent être stratégiques, tactiques ou opérationnelles. La business analyse peut être effectuée dans le cadre d’un projet ou tout au long de l’évolution de l’entreprise et de son amélioration continue. Elle peut être utilisée pour comprendre l’état actuel, pour définir l’état futur et pour déterminer les activités nécessaires pour passer de l’état actuel à l’état futur. »
Un Business Analyst peut exercer sans que ce titre soit spécifiquement libellé dans sa fiche de poste ou son bulletin de paie. On peut donc être Business Analyst mais être connu en tant que :
- business architect,
- business systems analyst,
- data analyst,
- enterprise analyst,
- management consultant,
- process analyst,
- product manager,
- product owner,
- requirements engineer
- systems analyst
- consultant fonctionnel
- AMOA (assistant à la maîtrise d’ouvrage)
- …
Les activités réalisées par le Business Analyst sont très variées, depuis la compréhension des problèmes des organisations et de leurs objectifs jusqu’à la conduite du changement, en passant par l’analyse des besoins et des solutions, la recommandation stratégique, la facilitation etc.
Commencez donc par identifier les activités principales que vous aurez sur ce projet.
Par exemple, vous demande-t-on de décrire les features d’un Program Increment, d’être garant de la vision stratégique, de faire de la gestion de risques, ou de gérer le Product Backlog ? Est-ce que vous intervenez sur les analyses stratégiques, tactiques ou opérationnelles ?
Les activités de business analyse et les rôles SAFe
Une fois que vous êtes au clair avec les objectifs qui vous sont assignés, et que vous savez à peu près délimiter votre périmètre métier, vous devez vous référer au cadre méthodologique SAFe. L’objectif est d’identifier votre rôle – car on ne vous l’a pas forcément dit…
C’est le framework SAFe qui va définir tout le cycle de vie de votre projet / produit / service, ses interactions, son cadencement, ses rôles, ses livrables etc.
Le site du framework SAFe est extrêmement complet, n’hésitez pas à le parcourir pour identifier clairement les objectifs, rôles et responsabilités de chaque membre de l’équipe – et les vôtres. Surtout, ne réinventez la roue en recréant des R&R personnalisés, faute de quoi le cadre SAFe risque d’être mal utilisé, à l’image des méthodes agiles dont l’usage est malheureusement souvent dévoyé (et confondu uniquement avec « rapidité »).
Imaginons une mise en situation. Après avoir listé les tâches qui vous incombent sur ce projet, vous identifiez que le rôle de Product Owner (PO) est celui qui se rapproche le plus de votre mandat.
Mais il y a un hic : il y a déjà un PO sur ce projet, il s’agit d’un des collaborateurs du client (admettons que vous soyez prestataire). Vous êtes bien embêté… Retour à la case départ, vous ne savez plus quel est votre rôle !
Pas de panique, c’est un cas classique, et pas que sur SAFe. Souvent, les représentants métiers sont des collaborateurs « internes ». S’ils maîtrisent les besoins métiers, ils ne sont pas tout le temps formés aux projets de systèmes d’information, et pas forcément disponibles car ils ont leur quotidien opérationnel à gérer, ou encore, il leur manque une partie des compétences prévues et décrites dans le framework.
Dans les grosses entreprises bien structurées pour travailler en agile, il peut également y avoir des équipes “PO”, composées de plusieurs Product Owners secondaires ou des Proxy Product Owners, et supervisées par un PO “en chef” (Primary PO).
Il convient donc de valider avec votre hiérarchie ou responsable opérationnel vos responsabilités exactes. Par exemple, le PO « officiel » validera le backlog que vous aurez préparé et priorisé, c’est vous qui le représenterez lors des System demos, mais c’est lui/elle qui sera le référent lors des PI planning. Il rédige les user stories et c’est à vous d’écrire les critères d’acceptance. Etc.
A retenir: comme dans toutes les méthodes agiles de gestion de projet où le rôle de Business Analyst n’est pas précisé, votre intervention dépend du contexte et des compétences disponibles au sein de l’équipe projet.
Les différents rôles SAFe du Business Analyst
Voyons à présent les différents rôles SAFe que peut avoir le Business Analyst :
- Portfolio Manager: il/elle représente l’autorité ayant la responsabilité du contenu au niveau du program level et de son backlog. Il est responsable de l’identification des besoins du client, de la priorisation des features, du développement de la vision du programme et de la roadmap du programme. Si l’entreprise ne dispose pas de Business Analyst dédié à ce rôle, le Portfolio Manager et l’Epic Owner peuvent gérer ces activités en collaboration avec le Business Owner.
- Epic Owner : il/elle est en charge de faire progresser les epics dans le système de portfolio kanban, il/elle développe le business case et, lorsque celui-ci est approuvé, travaille directement avec les principales parties prenantes sur les Agile Release Trains (ARTs) sélectionnés pour procéder à la mise en œuvre. Il contribue à l’analyse stratégique, à l’analyse des exigences, à la définition de la solution ainsi qu’aux activités de tests fonctionnels. L’Epic owner est un acteur clé qui permet de s’assurer de la cohérence « end-to-end » et transverse entre toutes les couches SAFe.
- Product Manager(PM): il/elle a la responsabilité du contenu au niveau du program level et de son backlog. Il/elle est responsable de l’identification des besoins du client, de la priorisation des features, du développement de la vision du programme et de la roadmap du programme. Le Product Manager pilote l’équipe chargée du Product Management, il facilite les tâches d’analyse stratégique, d’analyse des besoins et de définition de la conception fonctionnelle. Il coordonne la gestion des exigences (suivi du référentiel et traçabilité des exigences), ainsi que de leur hiérarchisation et leur validation. L’équipe de Product Management peut intégrer des Subject Matter Experts spécialisés solution / métier.
- Product Owner (PO): c’est la personne en charge du « team level ». Il ou elle est responsable du team backlog, de la priorisation et de l’acceptation des user stories. Il représente le client auprès de l’Agile team. Il/elle impulse la direction à suivre à l’équipe agile en facilitant et en contribuant aux tâches d’analyse des besoins et de définition de la conception au niveau des Stories. Il facilite et coordonne la gestion du cycle de vie des exigences au niveau des Stories.
- Release Train Engineer (RTE) est un responsable-serviteur et coach pour l’Agile Release Train (ART). Il facilite les processus, les événements et l’exécution du « train SAFe ». Il ou elle fait remonter les problèmes et contribue à la gestion du risque, à la livraison de valeur et à l’amélioration continue. Bien que l’approche agile et donc SAFe ne parle pas des rôles de chef de projet et de Projet Management Officer, les tâches de pilotage sont quand même réparties sur différents rôles. Le RTE est en quelque sorte le superviseur – bien que n’ayant pas de responsabilité hiérarchique. Le Business Analyst peut donc être amené à endosser cette casquette de RTE.
- Agile Team : c’est un groupes de 3 à 9 contributeurs dédiés couvrant tous les rôles nécessaires pour définir, construire et tester un incrément de valeur, au niveau de la qualité requise, dans une itération. Le Business Analyst peut faire partie de l’Agile Team s’il travaille côté MOE (maîtrise d’œuvre) et qu’il aide à la définition de la solution côté équipe technique, au niveau des user stories.
- Enterprise Architect : Il / elle promeut des pratiques de conception et d’ingénierie adaptives, et pilote les initiatives stratégiques d’architecture pour un portefeuille. L’Enterprise Architect facilite la réutilisation des idées, des composants et des modèles éprouvés à travers les solutions. Il a un rôle clé dans l’analyse des actifs et des capacités existantes réutilisables par l’entreprise pour répondre à tout nouveau besoin. Les compétences requises ici sont relativement techniques, donc ce rôle ne sera endossé avec succès que par un Business Analyst ayant suivi une formation informatique / d’architecte des SI préalable.
- Solution Manager : Il ou elle a la responsabilité du contenu au niveau de la chaîne de valeur. Il/elle travaille avec les clients pour comprendre leurs besoins, définir la vision et la roadmap, définir les exigences et guider le travail via la value stream kanban.
A retenir
Le Scaled Agile Framework (SAFe) est une approche récente en gestion de projet informatique, développée pour contrer le taux élevé d’échec des projets dans ce domaine. Né en 2007, SAFe intègre les principes agiles et du Lean Management pour améliorer la visibilité et l’efficacité des projets, intégré aux objectifs stratégiques des organisations. Le rôle du Business Analyst dans le cadre de SAFe est crucial mais souvent ambigu, soulignant les défis et les opportunités de se positionner efficacement dans ce cadre méthodologique.
Vous savez à présent ce qu’est l’approche SAFe, en quoi elle impacte votre positionnement de Business Analyst sur un projet et enfin, comment identifier votre rôle et vos responsabilités même si le label « Business Analyst » n’a pas été défini dans le cadre méthodologique SAFe.
Comme toujours, je suis toujours intéressée par obtenir des retours d’expérience de Business Analysts « agiles » (à petite ou grande échelle), donc si c’est votre cas, n’hésitez pas à contribuer à cet article en postant vos commentaires!
