Le contexte projet

😱 Business Analysts : faut-il avoir peur du grand méchant SAFe ?

Petit Chaperon Rouge

Vous venez tout juste de rejoindre un projet appliquant le framework SAFe, et avez encore du mal à comprendre ces acronymes étranges que sont les ART, PI, RTE, PO ou autres PPM. La dernière fois que vous avez dû faire un tel effort d’adaptation, c’était pour un projet géré de manière agile.

Une pensée nostalgique des projets traditionnels gérés « en V » ou en « cascade » vous effleure… Ah, c’était le bon temps!

Car à nouveau, avec ce f*** framework SAFe, il faut essayer de comprendre votre périmètre métier, vos livrables, vos activités, vos interlocuteurs… bref, tout réapprendre !!

Bonne nouvelle : vous n’êtes pas seul.e dans cette galère.

Confrontée à 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 1994, une enquête internationale réalisée par le Standish Group faisait le constat d’un taux d’échec effarant des projets informatiques de 83%. Dans le top 10 des causes racines de ces échecs, on retrouvait :

  • Le manque d’implication des utilisateurs finaux (12,8%)
  • Et les changements des exigences en cours de projets (11,8%).

A l’époque, les projets étaient uniquement gérés de manière traditionnelle, c’est-à-dire « en cascade » ou en « cycle en V ». Le client ne découvrait malheureusement son logiciel qu’à la toute fin du projet, au moment des tests d’acceptance. Cet « effet tunnel » était bien entendu désastreux, car il était souvent trop tard pour rectifier le tir, malgré la fréquente inadéquation entre la solution et les besoins métiers.

Ces méthodes de gestion de projets dites traditionnelles sont encore largement utilisées de nos jours.

>> Lire aussi : Pourquoi 83% des projets informatiques échouent-ils?

Au début des années 2000 est apparu l’approche agile, dont l’objectif était de réduire l’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.

Grâce à son adoption de plus en plus fréquente dans la gestion des projets informatiques, le taux d’échec de ces derniers a ainsi commencé à diminuer, passant de 83% en 1994 à 71% en 2015. Un bon point, mais un taux bien entendu encore 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.

>> Lire aussi : Business Analyst: un métier incontournable

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 : la définition de 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 (France)
  • …

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é »)

>> Lire aussi : Marre des pseudo-projets agiles!

Ça y est, vous avez identifié un rôle qui vous semble correspondre à votre mission : c’est Product Owner (PO)!

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 et supervisées par un PO “en chef”. Mais honnêtement, à l’heure où j’écris cet article, mes recherches montrent encore une fois le retard de nos entreprises françaises et européennes sur la situation dans les pays anglosaxons, et car ce genre de cas est très rare (n’hésitez pas à indiquer en commentaire si votre entreprise fait partie de ces cas rarissimes!!)

Faites-vous alors préciser vos responsabilités respectives pour ce rôle de Product Owner. 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.

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.

>> Lire aussi: 5 étapes pour identifier les contributeurs d’un projet

  • 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.

Pour conclure…

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.

Je suis toujours intéressée par obtenir des retours d’expérience de Business Analysts « agiles », donc si c’est votre cas, n’hésitez pas à contribuer à cet article en postant vos commentaires 😊.

Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!

Alice Svadchii
Alice Svadchii
Auteure du blog et Business Analyst enthousiaste

6 réflexions au sujet de « ðŸ˜± Business Analysts : faut-il avoir peur du grand méchant SAFe ? »

  1. Merci Alice pour votre excellent billet. Travaillant comme “Business Owner” dans une grande organisation Product / IT Delivery qui n’est pas SAFE (mais ce dit Agile), je vous confirme aussi la difficulté de définir la mission d’un BO. Ne pensez vous pas que BO et BA sont en réalité la même personne dans SAFE ?. Si non, quel est le rôle du BO ?. Merci et bravo pour votre travail. Continuez !

    1. Bonjour Laurent,
      Pour répondre à votre question, je vous renvoie à la définition très précise du Business Owner donnée sur le site de SAFe: https://www.scaledagileframework.com/business-owners/
      Un BO n’est donc pas un BA ;). Il s’agit d’un référent métier clé ayant les prérogatives nécessaires à la prise de décision. C’est un “sachant”, un Subject Matter Expert (SME), qui est aussi un décideur car il permet d’orienter le train SAFe (ART) pour s’assurer qu’il apporte bien la valeur attendue aux utilisateurs métier.
      Le Business Analyst peut, par contre, assister le BO dans son travail en jouant l’interface et le facilitateur entre celui-ci et les équipes techniques.
      Amicalement,
      Alice

    2. Les BOs sont l’instance de gouvernance ultime du train. Ce sont les instances financières du train venant généralement de la couche de la gestion de portefeuille, mais pas que. Ils travaillent étroitement avec le Product Management. Ils sont en somme les derniers remparts d’imputabilités de la valeur livrée par le train. Ils participent à la priorisation des features et valident, quantifient les PI objectifs lors du PI Planning. Il ne sont pas du tout au même niveau des BA (si BA il y a).

      1. Merci Etienne, votre explication est très claire et cela lève les ambiguïtés.
        Petite réflexion personnelle: quand une méthode / une approche devient trop compliquée à appliquer dans la “vraie vie” – dans le sens où elle nécessite une formation continue et approfondie, ainsi qu’une implication opérationnelle sans faille de tous les acteurs du projet et de l’organisation – elle finit par être mal appliquée dans 99% des cas. C’est inévitable. “Make it simple” devrait être le motto des méthodes de gestion de projet.
        Je vois trop de mauvaises utilisations autour de moi pour être une fan inconditionnelle des méthodes qui sortent tous les ans, même si je suis absolument persuadée qu’il faut suivre une méthode pour ne pas se disperser et apporter le maximum de valeur.
        Les différentes couches de SAFe me laissent songeuse (Essential, Large Solution, Portfolio, Full). Je comprends la raison théorique de ces différentes configurations mais dans la pratique, les grosses organisations commencent par Essential pour se faire la main, puis progressent dans les strates SAFe de manière hétérogène selon leurs départements… Cela alimente le business de formations continues et de coaching, mais dans la réalité, un département peut être “mûr” pour SAFE Portfolio et un autre même pas pour de l’agilité! (du vécu). Donc on implémente du “SAFe-like” … ce qui est pire. Et vu les changements organisationnels que cela implique dans l’entreprise, peu de managers / cadres exécutifs osent arrêter une machine en route même si elle ne fonctionne pas dans leur contexte.
        De plus, la validité des certifications SAFe obtenues par les collaborateurs et managers sont à mon avis sujettes à caution [… obtenues en “trichant” mais apparemment les examinateurs ne sont pas très gênés par cette pratique… cela permet de “répandre” un peu plus le schéma de certification). OK tous font la même chose (pas que SAFe) mais quand la bonne idée de départ de la méthode est dépassée par le “business” des certifications, cela me gêne.
        Le manque de recul et de pragmatisme, le dogmatisme de certains que l’on peut constater dans la “vraie vie” est vraiment dommage.
        Je ferme la parenthèse de mon coup de gueule “anti-méthode à la mode”- votre commentaire est le bienvenu et très éclairant sur le rôle de Business Owner ;). Un grand merci!

  2. Merci Alice pour cet article encore très intéressant 😉

    SAFe peut être déployé à plusieurs échelles au niveau d’une organisation.
    – SAFe Essential qui permet de déployer un système minimum d’agilité à l’échelle, sur des solutions simples
    – SAFe Large Solution qui permet de déployer un système d’agilité à l’échelle sur des solutions complexes
    – SAFe Portfolio qui permet de gérer un portefeuille avec une stragégie d’investissement et une gouvernance Lean
    – Fulle SAFe qui englobe l’ensemble du framework et répond au besoin de déployer l’agilité à l’échelle au sein de grandes organisations

    Quelque soit le niveau de déploiement de SAFe, le rôle de Business Analyst n’est pas décrit dans SAFe mais cela ne veut pas dire que le BA, tel que nous le connaissons, n’existe pas ou n’est pas utile !

    Dès lors qu’il s’agit de déterminer les problèmes, d’imaginer des solutions, de recueillir des besoins auprès des utilisateurs et des différents métiers de l’entreprise, nous pouvons dire qu’un rôle d’analyste est nécessaire. Soit ce rôle est porté par une personne distincte dans l’organisation, ce qui nécessite sûrement la création d’un BA, soit ce rôle est dilué dans les autres rôles de SAFe. Dans le premier cas, le Business Analyst peut donc être présent aux côté des autres rôles de SAFe à différents niveaux de l’organisation et de déploiement de SAFe.

    Il est souvent plus facile de dire ce que n’est pas un BA, y compris dans SAFe , nous pouvons affirmer que le BA n’est pas un Product Owner, n’est pas un Scrum Master, n’est pas un Release Train Engineer, n’est pas un Architecte Système, n’est pas un Solution Train Engineer, n’est pas un Architecte Solution, n’est pas un Architecte Entreprise (bien que comme tu le dis, après une “petite” formation, un BA pourrait traiter de certains aspects de l’architecture ;-).

    Si ce rôle de BA devait co-exister avec les rôles SAFe, en terme de collaboration, le BA serait plus en interaction avec un Product Owner (situation classique à petite échelle), un Product Management et un Business Owner (au niveau du Train), un Solution Management (au niveau de la Solution) ou d’un Epic Owner (au niveau Portfolio).

    Voilà pour apporter un peu d’eau au moulin !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *