đŸ˜± Business Analysts : faut-il avoir peur du grand mĂ©chant SAFe ?

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
0 0 votes
Évaluation de l'article
Alice Svadchii

Alice Svadchii

Formatrice, coach, conférenciÚre et productrice de contenus enthousiaste !

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

DĂ©couvrez des articles similaires

6
0
Would love your thoughts, please comment.x