Business Analyst : quel rôle en Agile / Scrum ? BA vs Product Owner / Developer / Scrum Master
Вставка
- Опубліковано 30 чер 2024
- 💜️ Rejoins la communauté Scrum Life 👉 sl.run/TmlxYc (c'est gratuit !)
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
🎁 Le guide du Scrum Master compétent 👉 sl.run/gCO61y
----------
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
Image by studio4rt on Freepik www.freepik.com/free-vector/f...
Une question, un doute, quelque chose à ajouter ? Ajoute-le en commentaire ! ⌨👇
Nous en échangerons lors du 🔴Live jeudi : sl.run/pVnWZp
Un rapport anti-Scrum très bien fait sur le PO & Proxy PO (Secrétaire kkkkk)
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.
Intéressant ! Tu seras là au Live jeudi pour nous partager ça de vive voix ?
Quand tu dis qu'ils sont inclus dans l'équipe, est-ce que cela veut dire par exemple qu'ils partagent le Sprint Goal ?
-- JP
@@ScrumLife Oui, ils partagent le Sprint Goal. Pour l'instant ils découvrent le concept mais c'est quelque chose où ils vont ensembles. Ils sont là pour tous les évènements, sont inclus dans tous les chats des équipes, sont au même niveau hiérarchique et travaillent le plus possible ensemble. Ca dépend beaucoup du mindset des BA et je suis très à l'affut niveau accompagnement et formation sur ça : on attend ça d'eux ! (comme quoi, clarifier l'attente...)
Demain je suis en congé et j'ai un train à prendre mais je pourrai peut-être venir au début !
Du coup, ils sont des "Developers". C'est top ça ! 👍
Viens au Live quand tu peux !
-- JP
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.
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...
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.
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é...
Dans la solution que tu décris, quelle proportion attribues-tu à "un passif organisationnel" comparé aux autres raisons justifiant ce mode de foncitonnement ?
-- JP
@@ScrumLife Je pense que si Scrum est aujourd'hui plus que nécessaire, son adoption tarde dans de nombreuses entreprises qui restent figées sur des modes de production MOA-MOE.
Vouloir faire la révolution, c'est sympathique, mais aucune révolution n'a su s'exempter des rivières de sang qui l'ont accompagnée...
Prendre en compte de l'existant pour le transformer étape par étape peut alors être un point d'ancrage d'une transformation vers l'agilité.
Cela passe alors par une réforme progressive des modes de faire prenant compte des existants (Business Analyst, Consultant fonctionnel, etc), une évolution progressive des pratiques pour engager le passage à l'agilité.
Ce n'est pas idyllique mais le monde des bisounours, c'est assez théorique non ?
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é ?
Salut, les parties prenantes ou stakeholders ne sont pas explicités comme un rôle (ou responsabilité en vocabulaire Scrum Guide 2022), cependant ils sont cités à de multiples de reprises. Par contre, les stakeholders ne font PAS partie de la Scrum Team.
As-tu vu notre vidéo sur le sujet des stakeholders ? ua-cam.com/video/FS8emwnMk6I/v-deo.html
-- JP
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.
Merci pour ce retour d'expérience. Dans ces missions, en quoi consistait le rôle de Proxy PO ? Quelles étaient ses responsabilités et activités ?
-- JP
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
Du coup... On n'a rien changé à part faire du renommage ?!?
-- JP
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.
Complètement, le "BA" n'est pas une définition propre à quelque chose, chacun fait à sa sauce donc c'est bien dans un sens, mais c'est compliquer de chercher du boulot dans ce domaine du coup.
Comment on pourrait factualiser une définition ça à ton avis ? Est-ce que ça serait souhaitable ?
-- Constantin
@@ScrumLife Oui, il existe des certifications dans le domaine (IIBA, IQBBA) qui donnent les bonnes grilles de lecture pour la discipline et le rôle du BA dans différents contextes d'intervention (prédictif, adaptatif, agile...). Le BABOK®(Business Analysis Body Of Knowledge) est LE guide qu'il faut lire avant tout !
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 ?
Je pense que François Dupuy l'explique très bien ! As-tu vu notre échange avec lui ? Voici le lien : ua-cam.com/video/nrjPjYDEC_M/v-deo.html
-- JP
@@ScrumLife merci je regarderai !
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 ?
Points très intéressants ! Est-ce que tu viens au Live pour en parler de vive voix ?
-- JP
@@ScrumLife je crois que cette fois ça va être possible.
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 ?
Oui ! Nous sommes totalement alignés avec ta vision. Il manquait juste une phrase dans la vidéo qui explicitait bien à propos des responsabilités Scrum de Developer : "le BA / analyste d'affaire pourrait donc intégrer la Scrum Team en tant que Developer (Developer au sens Scrum)"
Qu'en dis-tu ?
-- JP
@@ScrumLife En fait, je crois que ça devrait être sa position naturelle. Être plus là pour son expertise et faire profiter ses capacités d'analyse à l'équipe, De toute façon, tous les membres de l'équipe doivent contribuer à l'organisation de l'équipe et le développement du produit. De plus, pour augmenter la vélocité dans l'équipe, un bon analyste d'affaire qui fait une veille constante pourra varier son approche en passant d'une méthode à une autre pour atteindre le fameux "barely juust enough" qu'on désire.