Business Analyst : quel rôle en Agile / Scrum ? BA vs Product Owner / Developer / Scrum Master

Donnons la définition du rôle de Business Analyst ou BA avant de voir quelle serait sa place dans l'équipe Scrum ! Faisons un "vs", comparons-le aux rôles de Product Owner / Product Manager, Developer, Scrum Master et enfin partie prenante ou stakeholder ! Et bien sûr, on est obligé de parler du redouté "proxy PO"... 🤢 #ScrumLife #BusinessAnalyst #ScrumTeam

----------
SOMMAIRE️
00:00 Le "problème" du B.A.
01:07 Business Analyst, c'est quoi ?
03:02 Business Analysis et Scrum
07:19 Ne faites pas de Proxy-PO !

----------
CREDITS

[ScrumLife]

Une question, un doute, quelque chose à ajouter ? Ajoute-le en commentaire ! ⌨👇

[davidpaquet]

Je pense qu'il serait bien de lister les "responsabilité" des divers roles.
Certaines responsabilités a mon avis peuvent etre prises par diverses personnes.
Les roles ne veulent rien dire d'une organisation a l'autre. Si on veut des organisations plus circulaire ou changer pour le mieux nos structures organisationnelles, nous devons s'orienter "responsabilités". En ce moment je trouve que votre vidéo aide a en comprendre certaines mais on tourne autour du pot un peu car cela suppose que l'on connait déja tous les rôles correctement. Ce qui est cool c'est les idées de mélange de responsabilités. Par exemple "rapprocher les tech des utilisateurs" peut tres bien a mon avis etre pris par BA et scrum. Ça donne des idées.

[benjaminfeireisen]

Merci pour la vidéo !
Sur ma mission d'accompagnement, j'ai justement des BA.
Leur rôle est clarifiée : faire de la maturation de sujets pour préparer les critères d'acceptations (pas de SFP dégueulasse, je le refuse cash et c'est rentré heureusement !), discuter au quotidien avec les business et les devs, amener les développeurs à discuter avec le business, accompagner le métier sur les UAT pour qu'ils soient faits rapidement. Ils sont inclus dans l'équipe de dévs. Et ça marche très, très bien ! L'important c'est la communication au quotidien avec PO, dévs et business.

[yarazakaria]

je n'arrive pas à comprendre c'est quoi un BA concrètement dans une équipe scrum.. on dit que s'il y a de la valeur rajoutée à l'avoir, c'est bien de l'intégrer dans l'équipe developers de scrum, mais les developers sont les gens qui travaillent activement sur les éléments du sprint, et quand les US sont dans le sprint je ne vois pas ce qu'un BA fera de plus s'il n'est pas technique; alors s'il y a des gens qui font le rôle SM et PO pourquoi on a BA? j'ai l'impression que c'est de l'attachement à des postes qui existent déjà, qui sont sûrement toujours nécessaires d'une sorte, mais on lui trouve pas concrètement de place dans une équipe.

je suis scrum master depuis quelques mois, j'ai jamais travaillé en cycle en V, ni en agilité à l'échelle, et j'ai commencé récemment une mission dans un contexte de transformation de l'organisation de "traditionnel" en "agile à l'échelle". Je n'ai jamais travaillé avec un BA non plus, alors même après cette vidéo, je ne comprends pas sa place. J'ai vraiment l'impression que c'est exactement comme le PO et j'ai du mal à mettre le doigt sur ce qui est là car c'est à agile mais à l'échelle, ce qui est là car c'est du cycle en V hérité, ce qui est juste là car il y a un manque d'organisation, etc...

[davidallard]

Le rôle de Business Analyst est clairement défini dans DSDM (AgilePM). Et comme le cadre DSDM peut intégrer une équipe Scrum, la cohabitation est bien existante. Faut-il encore avoir le bon framework adapté à son organisation . DSDM (AgilePM) est, à mon avis, une solution oubliée et sous-estimée au profit de cadre plus connus.

[bullmille]

Un rapport anti-Scrum très bien fait sur le PO & Proxy PO (Secrétaire

[garancera]

Je comprends votre vision, mais je considère que le Proxy PO peut garder un sens... Prenons un produit large pour lequel on ne peut se passer de passer à l'échelle, on va donc générer un passage type Nexus : 3 équipes, 1 PO, 1 SM... On a avec un produit de cette ampleur une masse conséquente de stakholders qui eux vont avoir au moins besoin de se sentir écoutés... Malheureusement le PO ne peut se démultiplier et là se justifie le Proxy PO qui va prendre en charge une partie des attentes avant l'arbitrage produit conduit par le PO.
Certes la solution n'est pas optimale, mais on trouve là bien des soucis des passages à l'échelle avec des attentes complexes à concilier et un passif organisationnel parfois prenant sens. Tout comme SAFe n'est pas forcément "la" solution, le Proxy PO peut trouver sa place pour permettre à terme un passage vers plus d'agiliité...

[WalidBouanani]

Bonjour, vous dites dans la vidéo qu'il y a 4 rôles dans une équipe Scrum, PO/SM/Devs/Stakeholders, mais à ma connaissance il devrait y avoir que 3 rôles qui sont PO/SM/Devs, es ce une erreur ou ça a changé ?

[cleytonsilva]

Pendant différents missions j'ai pu remarquer que le BA sont suivant utilisé comme ProxyPO, en venant en aide à un PO avec plusieurs équipes.

[yns]

J'ai l'impression que le BA dans un environnement agile c'est celui qui va pondre des spec détaillés car le PO de l'équipe se retrouve côté métier et ne connait rien au SI...
Dans un environnement non aigle c'est celui qui va pondre la spec techniconfonctionelle de 159 pages

[modernproductagility]

Les périmètres des PO et BA sont à géométrie variable et dépendent du contexte de l'organisation. Et je pense que le BA est plus proche d'un PO que d'un chef de projet. Dans certaines organisations agiles, le BA peut faire partie de l'équipe agile ou alors faire partie d'un pool commun à plusieurs équipes agiles.
PS : il n'y a pas de rôle "partie prenante" dans Scrum.

[KarimLfr]

PO, BA, ProxyPO, PM, AMOA ca en fait des rôles 😂
Souvent pour faire presque la même chose ! On pourrait même rajouter l’UX designer qui se chevauche
Je constate qu’on a plus de gens qui disent que faire que de gens qui font réellement
Comment expliquez-vous ce phénomène d’entreprise ?

[olivierdurand]

Ouais, bah, c'est un peu triste au final. J'ai un peu l'impression que la conclusion finale de la vidéo, c'est de balancer l'analyste d'affaire (BA) par la fenêtre pour déléguer ses tâches à gauche et à droite ou de le reconvertir dans un rôle où son expertise ne servirait plus. C'est quand même dommage tout de même. En tant que BA, j'ai généralement une vision très intéressante sur le produit, car je peux à la fois avoir une vue d'ensemble et une certaine connaissance du détail fin. Tout en possédant des outils qui m'aide à vulgariser le technique et vice versa que ça soit dans les rencontres avec le client ou le PO.
Je comprends bien qu'il faut virer le proxy PO pour garder un contact plus direct avec la clientèle et les métiers, mais ne pourrait on pas profiter de l'expertise d'un vrai BA chez les développeurs? Pour aider au niveau de la modélisation par exemple ou pour trouver des solutions créatives en profitant de son point de vue de plus haut niveau pour éviter l'effet tunnel ?

IMHO : rôles (même ceux de scrum) = prisons. Faites un RACI, chaque fois qu'une responsabilité (un livrable) doit être engagée, ajoutez la ligne, trouvez qui mettre dans les colonnes R-A-C-I (ajoutez les autres colonnes VSS si vous en avez besoin).

INSPIREZ-vous des rôles du cadre quand vous en avez besoin.

Le plus important, c'est de savoir qui fait quoi pour délivrer. Plus que de savoir comment on nomme l'étiquette à mettre sur la personne.

Et là quand ça tourne, on peut regarder le delta entre le cadre et la réalité, puis enclencher l'amélioration continue si besoin.


Rôle => Responsabilité

Est-ce que BA est un rôle ? pour moi, c'est plus un "métier", qui représente une "expertise, un lot de compétence qui vient compléter le paquet de compétence de l'équipe.

Et puis pour en ajouter une couche de débat : il y a l'intitulé de poste sur le contrat de la personne ? C'est son rôle ? Son métier ?

Question subsidiaire : qui le pouvoir de décision est un "rôle", un poste, un métier  ?