4 étapes pour devenir un vrai Business Analyst agile

Quand on est habitué à travailler sur des projets informatiques gérés de manière traditionnelle (modèles « en cascade » ou « cycle en V »), il n’est vraiment pas évident de s’adapter aux méthodes agiles. En ce qui me concerne, j’ai vraiment dû apprendre à être une Business Analyst agile. Il m’a fallu me réapproprier un métier que je connais pourtant très bien et que je pratique depuis des années.

Dans cet article, je vais donc vous partager mon plan en 4 étapes pour vous positionner avec succès dans votre “nouveau” rôle.

Etape 1 : se documenter sur la méthode agile utilisée

Même si, pour beaucoup d’entre vous, le terme d’agilité n’a plus trop de secrets, sachez que l’application des méthodes agiles est de plus en plus sujette à controverse.

Voir par exemple mon article Marre des pseudo-projets agile ! , dans lequel je cite Ron Jeffries, l’un des pionniers des méthodes agiles, qui dénonce leur mauvaise application et la dérive de la qualité logicielle qui en découle.

Dans cette première étape, je vous recommande donc de vous documenter sur la méthode employée.

Pourquoi vous devez impérativement comprendre la méthode agile employée

Tout simplement pour mieux appréhender ce que l’on attend de vous, pourquoi, quand vous intervenez dans le cycle de vie du projet, avec qui vous interagissez et de quelle manière cette interaction se passe.

En tant que Business Analyst, vous restez responsable de la conformité de la solution aux besoins du client final. Cependant, ce rôle n’existant pas en agile, vous devez commencer par comprendre la méthode utilisée par l’équipe (SCRUM, XP, SAFE…) afin d’identifier où et comment vous positionner pour atteindre cet objectif.

Où se renseigner ?

Internet regorge de tutoriels, vidéos, articles de blogs et autres ressources gratuites (Je vous ai d’ailleurs mis quelques liens dans le paragraphe précédent). Vous pouvez aussi vous former au travers des MOOC (Openclassroom, Coursera, Udemy, pour n’en citer que quelques-uns parmi les plus connus).

Il n’est pas indispensable d’être un expert hors catégorie en agilité, aussi des formations vous procurant un vernis (terminologie, acteurs, organisation projet) sont-elles suffisantes. Vous pourrez apprendre les subtilités ultérieurement.

Et si je préfère me former au fil de l’eau ?

Je n’ai en général rien contre l’apprentissage au fil de l’eau, bien au contraire, mais là, vous risquez d’être vite submergé par l’enchaînement rapide des sprints (les itérations). Vous allez être réactif et non plus proactif. En d’autres termes, vous allez perdre le sens de votre « mission » de Business Analyst, et passer votre temps à faire le bouche-trou entre le Product Owner (PO) et l’équipe de développement.

Comprenez-moi : agile ne veut pas dire ne pas s’organiser. Or, comprendre la méthode employée vous permet de mieux vous organiser. Cela permet aussi à toute l’équipe de percevoir clairement votre plus-value et ainsi, de fluidifier la communication entre tous.

Voyons maintenant la deuxième étape : identifier qui fait quoi dans ce contexte précis … et en particulier vous, Business Analyst agile !

Etape 2 : identifier les rôles et responsabilités

L’objectif de cette étape est d’identifier les personnes composant l’équipe projet, ainsi que leurs rôles et responsabilités.

Pourquoi est-ce important de bien identifier les rôles et responsabilités ?

Lorsqu’un projet est géré de façon traditionnelle, on a l’habitude de s’adresser à différentes personnes, chacune ayant des responsabilités précises et en général reproductibles d’un projet à l’autre: le chef de projet, l’architecte, le leader technique, le business analyst, le développeur, le designer UX/UI, le key user etc…

Les méthodes agiles rebattent les cartes de cette organisation, notamment parce qu’initialement, elles ont été imaginées par des développeurs pour des développeurs.

Par exemple, dans la méthode SCRUM, seuls trois rôles sont mentionnés : la Scrum development team, le Product Owner, et le Scrum master.

Est-ce que cela signifie que l’agilité se passe de toutes les compétences sollicitées sur des projets gérés de manière classique (architecte, chef de projet, business analyst…) ? Non, bien entendu. Les équipes de développement sont considérées comme multi-compétentes, mais cela ne veut pas dire qu’un développeur sera capable à lui seul d’être business analyst, développeur, UX/UI designer, testeur, intégrateur etc.

Selon les compétences disponibles dans l’équipe projet, un membre de l’équipe de développement pourra avoir un ou plusieurs rôles. Certains seront capables d’être multi-casquettes : business analyst, développeur, testeur. D’autres mono-casquette : par exemple, développeur.

Certains Product Owners connaissent très bien les projets informatiques, et seront capables de faire de l’analyse métier orientée solution. D’autres maîtrisent parfaitement leur domaine métier, mais ne savent pas retranscrire leurs besoins en exigences fonctionnelles applicatives, ou encore ne manient pas bien les Product backlogs.

Ainsi, il ne suffit pas de savoir qu’en SCRUM, on a trois rôles projet. Il faut aussi comprendre les responsabilités que chacun des acteurs de votre équipe a, en fonction de son expérience et de ses compétences.

Cela vous permettra de mieux discerner la valeur ajoutée que vous-même pourrez apporter au projet, en tant que Business Analyst agile.

Comment faire ?

Je vous conseille la lecture de cet article : 5 étapes pour identifier les contributeurs d’un projet.

Vous y trouverez une méthode pratique pas à pas pour identifier les contributeurs de votre projet, ainsi que leurs rôles et responsabilités.

Les erreurs classiques à éviter

Je vous en liste quelques-unes parmi les plus communes :

  • Penser que l’analyse métier n’existe plus en agile, parce qu’elle n’est pas mentionnée dans la méthode utilisée par votre projet.
  • Penser que le Business Analyst = Product Owner. Même si cela arrive souvent que le BA soit aussi PO, cela n’est pas une norme. En effet, comme je vous l’ai expliqué plus haut, une personne peut avoir un certain rôle (nommé PO par son chef), mais ne pas avoir les compétences ou la disponibilité requises. Il peut donc arriver qu’il y ait délégation de responsabilité, totale ou partielle. C’est à vous d’en identifier le périmètre, selon le contexte de votre projet.
  • Penser que le Business Analyst = Scrum Master. De même, le chef de projet en tant que rôle n’existe pas en agile. Ses responsabilités sont portées par chaque membre de l’équipe, à des degrés divers. Un Business Analyst peut ainsi être amené à être RTE (en SAFe, Release Train Engineer), ce qui peut se rapprocher peu ou prou du rôle de chef de projet. De même, la gestion du Product Backlog nécessite des compétences de pilotage. Etc.
  • Ne pas avoir le « mindset » agile… L’agilité est un état d’esprit. Quand on vient du monde « traditionnel » des gestions en cascade ou en V, on est habitué à un cadre assez stricte de fonctionnement. En agile, chacun est sollicité pour apporter de la valeur à l’utilisateur final, le plus rapidement possible, et il est important de jouer collectif.

Maintenant que vous avez identifié qui fait quoi sur votre projet, vous inclus, il est temps de découvrir concrètement ce que vous devez faire et livrer comme outputs. C’est ce que nous allons voir ensemble dans l’étape 3.

Etape 3 : identifier les activités, livrables et artefacts agiles

Dans cette étape, vous allez commencer par définir votre feuille de route, laquelle dépend de votre positionnement dans le cycle de vie du projet. Certains Business Analysts arrivent très en amont, au moment du cadrage du projet, ou même de l’étude d’opportunité (avant-projet), tandis que d’autres arrivent en cours de sprint.

>> Voir aussi: [VIDEO] E04 – Le quotidien d’une BA : l’étude d’opportunité

Les artefacts, ce sont les activités agiles réalisées pendant le sprint. Ce que j’appelle ici activités et livrables, c’est tout ce qui est produit en dehors des sprints.

Pourquoi est-ce nécessaire de préparer sa feuille de route alors qu’on est censé découvrir le périmètre au fur et à mesure ?

Dans un projet agile, le périmètre de la solution n’est jamais défini de manière intégrale et complète avant le début du développement, contrairement à ce qui se fait sur les projets gérés de manière traditionnelle.

Le périmètre émerge par itération et incrément.

Pourquoi donc s’astreindre à planifier une road map puisque rien n’est figé?

  • Première raison: puisqu’un Business Analyst peut intervenir bien avant le début du développement, il peut être amené à faire une étude d’opportunité, un benchmark, rédiger un business case etc. Et dans ces phases amont du projet, le client a besoin d’éléments clés pour prendre des décisions. La road map en fait partie.

>> Lire aussi[VIDEO] E03 – Le quotidien d’une BA : la road map

Toutes ces activités « hors sprint » peuvent être réalisée par le Business Analyst, et elles peuvent évidemment conduire à la livraison de documents formels.

  • Une seconde raison est d’éviter de se laisser emporter par le « flow » sans savoir où l’on va et ce qu’on doit faire : il s’agit d’être réactif ET proactif.
  • Une troisième raison est de ne pas perdre de vue l’objectif ultime qui est de proposer la meilleure solution possible répondant à un besoin de changement. Si vous voulez réussir à gérer votre Product backlog, tant du point de vue des fonctionnalités de la solution que de la priorisation des développements, il vous faut conserver une vision d’ensemble.

Comment identifier ses activités et artefacts quand on est Business Analyst agile ?

Dans un projet géré avec un cycle en V, on valide chaque étape après livraison de spécifications (fonctionnelles, d’architecture, techniques), puis on développe et on teste.

A contrario, dans un projet agile, la documentation est un moyen et non une fin. Cela ne veut pas non plus dire qu’on ne rédige rien – demandez donc à un architecte de s’engager sur une architecture technique en lui interdisant de faire un dossier d’architecture, ou à un intégrateur de préparer ses intégrations de composants sans préparer ses diagrammes…!

De même, un Business Analyst va s’appuyer sur les Epics et les User Stories, mais rien ne l’empêche d’écrire ses exigences fonctionnelles et règles métier pour lever toute ambiguïté ou manque de clarté qui nuirait à la bonne exécution du sprint.

La différence entre méthodes agiles et traditionnelles, c’est quand dans le premier cas, les artefacts viennent appuyer et soutenir le développement, tandis que dans le second cas, les activités et livrables sont un prérequis indispensable aux activités de développement et de test.

En plus de votre formation à la méthode agile employée par votre projet, je vous recommande donc très fortement de vous former aux différentes activités de la Business Analyse. Connaître cela vous permettra de vous poser la question de la pertinence de telle ou telle activité pour atteindre votre objectif (lequel est, je vous le rappelle : recommander, décrire et aider à mettre en place la meilleure solution possible en réponse à un besoin métier).

>> Voir aussi : Les activités de la Business Analyse

Ce qu’il ne faut pas faire

  • Croire que méthode agile = pas de documentation, que les User Stories se suffisent à elles-mêmes
  • Croire que le Business Analyst délègue son rôle au développeur et à l’UX/UI designer
  • Croire que agile = pas de planification
  • Croire que le Product Owner et le Scrum Master sont les « chefs » : par habitude des projets gérés en V, le PO peut être assimilé au client omnipotent et le Scrum Master, au lieu d’avoir un rôle de facilitateur, prend une casquette de chef de projet. Au contraire, l’organisation agile permet la collaboration en s’affranchissant des frontières “hiérarchiques”.

Et si vous avez lu tout ce que j’ai écrit dans cet article, je n’ai normalement pas besoin de développer pourquoi il vaut mieux éviter de tomber dans ces pièges…

Maintenant que vous avez identifié avec qui vous traiterez, quand, comment et pourquoi vous les solliciterez, et que vous êtes au point sur votre propre rôle et vos responsabilités au sein de votre projet agile, il est nécessaire de…

Etape 4 : valider et informer les autres membres de l’équipe

Vous avez passé un certain temps à clarifier tous ces points d’organisation et de périmètre, mais le reste de l’équipe projet a aussi besoin d’être informée pour savoir quand elle peut vous solliciter.

Comme vous l’avez vu, les rôles et responsabilités agiles ne sont pas suffisamment décrits dans les méthodes agiles. Ne croyez donc pas que vos collègues savent précisément ce que vous allez apporter au projet. D’une part, tout le monde n’est pas forcément expert certifié SCRUM / SAFe, et d’autre part, chaque projet est géré de manière unique, en fonction du contexte de l’entreprise mais aussi des compétences propres à chaque membre de l’équipe de développement.

Regardez ce qu’en dit Dorra (vous pouvez lire son article complet ici : Dans la peau d’une Business Analyst). Dorra, développeuse, a été sollicitée pour prendre la casquette de Business Analyst agile. Il est intéressant de voir la difficulté qu’elle a eu au début pour comprendre la différence entre Business Analyst et Product Owner :

« Nous avons fait un point avec le client pour savoir à la fois ce qu’il attendait de moi pour cette mission et quelles seraient les tâches affectées au poste de BA.  Sa réponse a été la suivante : il s’agissait de recueillir le besoin utilisateur, de gérer le backlog et de valider les US (User Stories) réalisées. Immédiatement je me suis interrogée : n’est-ce pas le rôle du PO (Product Owner) ? Quelle est la différence entre le BA et le PO ? »

Il est donc très important que vous partagiez avec le reste de l’équipe la définition de votre rôle et de vos responsabilités sur le projet. Il n’y a en effet rien de pire que l’incompréhension, car c’est ainsi que les « patates chaudes » se refilent indéfiniment, chacun pensant que c’est à l’autre de s’en occuper.

Comment faire ?

Tout d’abord, il vous faut identifier à qui vous voulez transmettre l’information, en fonction de votre feuille de route, et des activités qui vous incombent.

Il vous faut également tenir compte des contraintes du projet : quelle est la taille de l’équipe ? Où est-elle localisée ? Et le client / les key users ? Quelle langue est employée pour communiquer ? Quels sont les canaux de diffusion privilégiés ?

Ces éléments vous permettront de définir le format et la manière la plus efficiente d’informer vos collègues.

Par exemple, vous pouvez organiser une réunion, ou profiter des réunions de base (par exemple en SCRUM, planification du sprint, scrum quotidienne, revue de sprint, rétrospective), envoyer un email à l’équipe, imprimer et afficher à côté du Project Board une infographie… Faîtes jouer votre imagination pour diffuser l’information de manière efficace, claire et non ambiguë 😉

Et bien entendu, évitez ces écueils « classiques »

  • Penser que tout le monde sait pourquoi vous êtes là et ce que vous faîtes
  • Informer le PO ou le Scrum Master et penser qu’ils transmettront l’information au reste de l’équipe.

Je rajoute a posteriori un intéressant commentaire de Benoît, Agiliste – Product Owner & Scrum Master et Business Analyst, 

Je suis d’accord avec le fait de ne pas être un bouche trou sur les lacunes d’un PO. En revanche, avec le bon mindset, un BA peut être PO ou Scrum Master (on retrouve des activités du BA dans les deux rôles, tels que définis par Scrum. Quand à la Roadmap (…), et bien j’ai envie de dire que c’est normalement de la responsabilité du PO / Scrum Team.

Roadmap = Vision Produit (en partie) = Product Ownership.

Tout dépend de l’approche qu’on a eu lors du démarrage de ce projet: approche plus standard avec cadrage, élicitation etc…(Attention à ne pas faire du “FrAGILE”) OU approche plus agile avec une co-contruction de la Vision Produit (et on peut commencer à parler Milestones).

Vous savez à présent comment vous positionner avec succès en tant que Business Analyst sur des projets agiles. Bien sûr, cela demande des efforts, et nécessite de passer un peu de temps pour s’(in)former et dialoguer avec les différents acteurs de votre projet.

Croyez-moi, si pensez que cela n’en vaut pas la peine, vous allez vite vous retrouver pris dans vos urgences quotidiennes et les exigences des sprints, et vous risquez de perdre de vue l’objectif réel de votre projet.

Rappelez-vous le constat alarmiste de Ron Jeffrey, pionnier des méthodes agiles :

Lorsque les idées « agiles » sont mal appliquées, elles entraînent souvent plus d’interférences avec les développeurs, moins de temps pour effectuer le travail, plus de pression, et des demandes pour « aller toujours plus vite ». C’est mauvais pour les développeurs, et, en fin de compte, également mauvais pour l’entreprise. Mal travailler en « agile » conduit, le plus souvent, à développer une solution ayant beaucoup plus de défauts, et une progression beaucoup plus lente que ce qui aurait pu être réalisé.

Alors… Etes-vous prêt pour un petit challenge ?

Voici votre première action pour devenir définitivement un Business Analyst agile et éclairé :  recherchez un témoignage (ils sont plus nombreux sur les sites anglophones)  décrivant l’expérience d’un Business Analyst ou d’un Product Owner travaillant sur des projets agiles. Identifiez l’une de ses problématiques, et imaginez comment vous pourriez l’aider à la résoudre.

Merci d’avoir lu cet article jusqu’au bout, et à bientôt sur bestofbusinessanalyst.fr !

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

0
Would love your thoughts, please comment.x