Business Analysis et Agilité Scrum

Le Business Analyst se doit d’être le chainon manquant entre les métiers et les équipes de développement, entre la MOA et MOE.
A-t-il sa place ? Surement ! Mais quelle est la meilleure manière de s’inclure dans une équipe Scrum?
En PPO? Dans l’équipe des DEVS? …
Vos suggestions et remarques m’intéressent.

2 « J'aime »

J’ai occupé un poste de business analyst dans une équipe Scrum. On m’a très rapidement donné le titre de PPO.
Et ma fonction était exactement celle que tu décris : le lien physique entre le PO parisien et l’équipe de développement lyonnaise. J’ai aussi beaucoup déchargé le PO sur la rédaction des US, sur la réponse aux questions des devs, sur les animations de réunions d’affinage ou de planning.

Pour la petite histoire, j’étais aussi Proxy SM car lui aussi etait éloigné de l’équipe :blush:

Sympa ! Merci pour le partage !
Tu avais des relations avec les métiers en tant que BA, tu intervenais dans la rédaction du Product BackLog, US et autres définitions des Sprints… En termes de gouvernance, pour les prises de décisions et la vision du produit, tu as eu, in fine, suffisamment d’autonomie ?
Étonnant d’avoir eu le rôle de proxy SM. Uhlala ! La mission devait être très prenante ! :smiley:
Beau cas d’école ! Tu étais interne ou externe à l’entreprise ?

Alors… relations avec les métiers pas trop non, c’est ce qui m’a manqué.
En revanche le backlog, la redaction des US, la definition du Sprint oui. Pas en autonomie puisqu’avec le PO on a vraiment travaillé en étroite collaboration. Et les prises de décision à deux aussi. Très enrichissant.
Le proxy SM on l’a inventé !
Et oui effectivement un poste hyper intéressant, j’étais prestataire.

C’est une bonne question communauté ça :grin:

1 « J'aime »

En scrum, c’est facile, « DANS l’EQUIPE »

C’est une discipline de plus que l’équipe doit prendre en charge. Et c’est à elle de s’organiser sur le comment.

1 « J'aime »

On a une vidéo sur le « PPO » : Le Proxy PO c'est quoi ? Proxy Product Owner - Scrum Life 77 - YouTube

On a pas de vidéo sur le BA, ça manque surement.
En gros pour moi, l’activité de business analyse, c’est une activité de PO. Qui peut donc déléguer ça à un membre de l’équipe, mais je trouve ça quand même assez dommage tellement c’est clé. Le/la PO prend les décision stratégique sur le produit, pour ce faire il/elle doit comprendre le marché, le business.

1 « J'aime »

Je pense que ça dépend beaucoup de ce qu’on met derrière le terme « business analysis » !

2 « J'aime »

Oui Jean-Pierre c’est ça. Ça dépend de ce que l’on met dedans.
Adapté à la méthode scrum, on peut dire par exemple le cadre général d’interventions suivant :
Initialiser le projet :
• Comprendre et identifier les contraintes liées :
◦ à l’organisation,
◦ à la création de valeur,
◦ aux contraintes de la solution existante,
◦ aux contraintes du projet.
• Identification des Parties Prenantes, des acteurs et des contributeurs (RACI).
• Initialisation, cadrage, étude d’opportunité, business case, Gouvernance de la BA,
Recueil des besoins :
• Élicitation – recueil des besoins : préparer, conduire, diffuser, vérifier & valider.
Traduction des besoins en Exigences de la solution : Conception
• Construire la solution et innover avec une information exhaustive, consensuelle et validée :
◦ Analyser, recommander, Modéliser, Rédiger & mettre à jour les livrables, faire valider.
◦ La conception prend en compte les aspects fonctionnels
◦ ET contraintes non fonctionnelles de la solution cible :
:black_small_square: infrastructure : matériels, logiciels, réseau,
:black_small_square: stratégie et reprise de données éventuelles,
:black_small_square: formation des équipes de tests,
:black_small_square:
• Analyser les écarts :
◦ AS IS ANALYSIS : Analyse de l’existant,
◦ TO BE ANALYSIS : Analyse des besoins et des exigences de Système Cible,
◦ GAP ANALYSIS : Analyse et recommandation des fonctionnalités manquantes,
◦ BENCHMARK : Analyse Comparative. Aide au choix (services, logiciels, fonctionnalités, stratégies),
◦ RISK ANALYSIS : Analyse des risques : Identification et gestion des risques.
• Conception fonctionnelle et définition de la solution cible :
◦ ou Product Backlog et User Stories.
• Participation aux cérémonies et soutiens aux équipes en charge du projet et au Product Owner.
Vérification et Validation :
• Planification et Gouvernance
◦ Analyse d’impact,
◦ Conception du plan de tests :
:black_small_square: fonctionnels
:black_small_square: et non fonctionnels : volumes, charges, etc,…
◦ Mise en œuvre de l’environnement technique de tests fonctionnels
◦ Exécution des tests par les équipes : pilotage et contrôle
◦ Clôture,
• Go Live.
Approche – Méthodologies - outils
• Système de Développement Logiciel : Agile (Scrum)
• Technique d’Élicitation :
◦ analyse documentaire,
◦ prototypage,
◦ analyse des interfaces,
◦ brainstorming ,
◦ jeux collaboratifs,
◦ sondages et questionnaires,
◦ interview,
◦ design thinking,
◦ workshop.
• Modélisation :
◦ Métier :
:black_small_square: Analyse des flux et processus : Cartographie BPMN2.0/UML,
◦ IT :
:black_small_square: Analyse des interfaces : cartographie des logiciels,
:black_small_square: Analyse de l’infrastructure IT : cartographie de systèmes, réseaux et moyens télécoms.
Bref, un lien entre les métiers et l’équipe Scrum pour embarquer les parties prenantes et les contributeurs au projet.
Quels sont les éléments qui vous paraissent pertinents pour aider à l’agilité de l’équipe ? Qui pourraient libérer les experts, faciliter, embarquer les users, …?

Je peux faire également un retour car je suis dans une situation assez proche de ce qu’a décrit Cécile.
Je suis devenu BA sur ma mission actuelle il y a quelque années dans notre équipe devenu par un coup de baguette magique « Scrum » mais sans PO nommé et sans description claire du poste de BA.
Après des tâtonnements, je me suis bombardé PO (il fallait quelqu’un pour alimenter le backlog) jusqu’à ce qu’il soit nommé côté Client, 2 ans après et là bonne suprise pour moi, il m’a dit « OK je suis PO sur le papier mais vu que tu fais déjà le boulot, je te propose de continuer à le faire et on s’accorde sur la priorisation quand c’est nécessaire ». En fait, il s’est d’office plus positionné comme une partie prenante que comme PO au sens Scrum.
Donc je suis (P)PO et ce qui me manque le plus, c’est un contact direct et régulier avec les utilisateurs… et une vrai approche produit.

Du coup pour répondre à la question j’aurai tendance a dire : Si le BA est là pour se substituer à un PO trop absent, peu disponible etc, il serait bon de se demander s’il ne serait pas plus pertinent de le nommer PO et d’avoir l’actuel PO comme partie prenante… ca nécessite une bonne coordination et de la confiance mais permet une préparation en amont.
Dans le cas contraire, le BA est au sein des Devs et dans ce cas, c’est comment s’organiser pour que l’équipe soit efficace durant un sprint.

Voila je suis sur que j’ai donné à certains de la matière pour débattre sur ma proposition (merci qui ? :rofl:)

1 « J'aime »

Merci Benjamin pour ce retour d’expérience. Tu arrives à des conclusions assez similaires.
La partie BA est intégrée à la mission de PO.
Peut-on dire que dans certains cas, le « PO interne » est là pour contrôler le projet : un genre de Product Manager. Dans ce cas, on met en place un PO ou un PPO qui reporte au « PO interne » et qui embarque l’aspect BA. Mais dans ce cas, il y a une perte d’agilité et d’autonomie de l’équipe. Non? Ou alors, on le met avec les DEVS et là…? Il s’occupe refinement ou il est facilitateur?
Qu’en penses-tu?

Je pense qu’il faudrai mieux reformuler en « suivre le projet » que « contrôler ».
Et pourquoi le PPO devrait reporter au PO, pourquoi l’équipe (dans sa globalité) ne mettrait pas en place de la transparence à ce niveau pour que n’importe qui et içi le « PO interne » puisse suivre facilement l’avancement.
Après il ne faut pas perdre de vue que le but pour un PO est de maximiser la valeur résultant du travail de l’équipe et de viser un ROI positif, donc son but n’est pas de noyer les Devs sous le boulot mais d’obtenir le maximum de valeur avec un minimum de dépense. Et j’exclus dans mon discours l’atteinte des objectifs !

Pour la seconde question concernant le BA au sein de l’équipe, honnêtement je sèche un peu, je me suis déjà demandé ce que serait mon boulot si je travaillais en tant que Devs au sein du Sprint et je pense que ca serait de l’analyse, préparation des cas de tests et contrôle des tests. Ça serait sport et ma problématique serait alors de comment organiser le travail pour ne pas manger trop de temps en début de sprint et de ne pas me retrouver coincé par le manque de temps en fin de sprint.

Salut à tous, pour information, on a prévu de sortir une vidéo sur le sujet !

Que cela ne vous empêche pas de continuer les discussions, la vidéo ne sortira pas tout de suite et en général on ne dit pas la même chose que vous :grin:

4 « J'aime »

Hello Benjamin,
Je suis d’accord que la notion de Contrôle est maladroite. Je l’ai utilisé avec à l’esprit, une équipe externalisée avec des consultants extérieurs. Dans ce cas de figure, je souhaite attirer l’attention sur le fait que l’organisation, celle qui paie, doit avoir un lien avec cette équipe autonome. Par exemple pour capitaliser, pour valider que cela va dans le bon sens, avec les bonnes priorités, …
Comment s’organise l’articulation (la gouvernance) entre l’Orga et l’Équipe ? Entre l’Orga est un PO externe ?

Super, merci Jean-Pierre. Votre expérience et votre vision seront utiles, je pense.
Le constat, c’est qu’il y a de la BA dans Scrum. C’est pris en charge par le PO et les rétrospectives successives avec les PP, et autres retours d’expérience.
Par une approche "multitenant’', le BA peut être amené, (suite aux ateliers et au challenging des besoins des PP,) à proposer un élément de solution à forte valeur ajoutée, dont elles n’ont même pas idée : tant l’IT peut être un monde à part pour les PP.
Où : comment générer de l’innovation métier par l’IT avec SCRUM ?

Pour étoffer nos réflexions, une vidéo Scrum Life : Scrum : Product Owner pas NECESSAIRE ? Comment s’en PASSER ? avec Frédéric Leguédois!

J’aurai tendance a dire que le PO va rendre transparente à tous et toute la progression de l’équipe vers les objectifs définis et qu’en Review (si ce n’est durant le Sprint), on va collaborer - Scrum Team et Partie prenante, ce qui inclut le sponsor, celui qui paye - pour définir ensemble la suite à donner

Dans ma société il y a des BA et des PO, j’ai du mal avec ce concept.
j’ai tendance à croire que si une équipe a des BA, et en a besoin, c’est que l’analyse agile, le backlog refinement et la proximité entre Métier et l’équipe ne sont pas mature, appliquées
fort est de constater que ce « rôle » ou « poste » est répandu, je me questionne, pour moi c’est un rôle de transition, entre Cycle en V et Agilité.

Oui je suis d’accord, je pense qu’il y a clairement un reste de silo MOA/MOE ici, merci d’avoir soulevé ce problème

1 « J'aime »