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

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