Le contexte projet

7 choses que les Business Analysts doivent savoir sur l’agilité

7 choses sur les Business Analysts et l'agilité

Si vous êtes Business Analyst et que vous avez toujours exercé votre métier dans le cadre de méthodologies traditionnelles (par exemple, un projet géré avec un cycle en V), je suis sûre que vous vous posez la question de votre positionnement dans le cas de projets agiles.

Kent McDonald est un Business Analyst expérimenté puisqu’il cumule plus de 20 années d’expérience dans des domaines aussi divers que l’analyse métier, la planification stratégique, la gestion de projet ou encore le développement produit. Il a également écrit l’ouvrage « Beyond Requirements: Analysis with an Agile Mindset » et est co-auteur de « Stand Back and Deliver: Accelerating Business Agility ». J’ai sélectionné pour vous l’un de ses récents articles, en raison de son intérêt pour nous autres, Business Analysts en recherche d’information quant au positionnement de l’analyse métier sur des projets agiles.

Je vous le retranscris donc ci-après en français – faîtes-moi confiance, vous allez sans doute apprendre ou redécouvrir bien des choses, même si vous êtes déjà certifié Scrum, SAFe & Co 😊 !

1.     Agile n’est pas une méthodologie, c’est un état d’esprit

« Agile » fait partie des mots à la mode, bien qu’il ne soit plus totalement nouveau (le terme étant appliqué au développement de logiciels depuis plus de 16 ans). Quand les gens le rencontrent pour la première fois, ils le perçoivent souvent comme une méthodologie de développement logiciel ou de gestion de projet.

En réalité, cela n’est ni l’une ni l’autre : c’est une façon d’envisager et de réfléchir à la manière d’aborder le travail de la connaissance. Agile n’est pas un nom, c’est un adjectif.

C’est Alistair Cockburn qui l’a le mieux décrit sur son blog. Ce qu’il faut essentiellement retenir de sa réflexion est que la méthodologie agile est un ensemble de conventions que l’équipe accepte de suivre. Scrum, Kanban, XP, SAFe, etc. sont des cadres que les équipes utilisent comme point de départ pour créer leur propre méthodologie, en fonction du contexte (ce que certaines personnes, dans les mondes Scrum et SAFe, oublient).

L’état d’esprit agile fournit une certaine orientation que les équipes peuvent suivre lorsqu’elles créent leur méthodologie, y compris le fait qu’elles devraient commencer par créer leur propre méthodologie… J’ai ma propre façon de voir la mentalité agile, et j’aime assez la description que Joshua Kerievsky a faite récemment :

  • Rendre les gens géniaux
  • Faire de la sécurité une condition préalable
  • Expérimenter et apprendre rapidement
  • Offrir de la valeur en permanence

2.     L’agilité va au-delà de Scrum

Le framework Scrum a remporté la guerre des parts de marché, puisqu’il est désormais le plus utilisé par les organisations lorsqu’elles adoptent une démarche agile. Cela amène beaucoup de gens à conclure qu’Agile = Scrum. En réalité, Scrum n’est que l’un des nombreux cadres que vous pouvez utiliser comme point de départ pour travailler de manière agile. En quelque sorte on peut dire que Scrum est à Agile ce que Kleenex est aux mouchoirs en papier.

Pourquoi est-ce important ? Parce que Scrum n’est qu’une façon d’aborder les valeurs et principes agiles, et qu’elle n’est pas appropriée à toutes les situations, car ce n’est pas une solution complète. Si les gens pensent qu’ils doivent faire du Scrum pour être agiles, ils concluent aussi qu’ils doivent faire des sprints, même lorsque la nature de l’objectif conduit à réviser souvent les priorités et à déployer beaucoup plus fréquemment qu’une fois tous les quinze jours. Ils passent également à côté des excellentes pratiques techniques que l’on trouve en XP.

Note : Scrum n’est pas un acronyme. C’est un terme emprunté au rugby.

3.     Analyser est toujours pertinent

Ce n’est pas parce que la plupart des frameworks agiles ne mentionnent pas les Business Analysts que celui-ci n’est plus nécessaire. Les frameworks agiles ne se veulent pas exhaustifs.

Ils ont été créés par des développeurs de logiciels pour résoudre les problèmes auxquels ils sont confrontés. Ils ont tous un rôle qui consiste à déterminer le bon item sur lequel l’équipe doit travailler. Avec Scrum, c’est le Product Owner. En XP, c’est le onsite customer. Or, la plupart de ces frameworks ne précisent pas comment y arriver.

C’est là qu’intervient l’analyse. Les techniques d’analyse sont toujours utiles, mais la manière et le moment où vous les utilisez diffèrent des modèles traditionnels. En effet, vous analysez des périmètres plus réduits et ce, plus fréquemment, pour faciliter la communication et bâtir une compréhension commune, au lieu de faire toutes vos analyses en même temps pour produire et communiquer la photo globale.

Lire aussi: Les techniques d’analyse et de modélisation

4.     Agile seul ne vous rendra pas meilleur, ni plus rapide, ni moins cher

Analyser permet également aux équipes et aux organisations de déterminer ce qu’il faut faire et ce qu’il ne faut pas faire. Comme la plupart des frameworks agiles n’en parlent pas, cette responsabilité est renvoyée à un rôle spécifique, sans pour autant donner d’indications sur la façon de le faire.

Lorsque les entreprises adoptent l’agilité au sein de leur département informatique, mais qu’elles ne modifient pas l’organisation du travail, elles constatent rapidement qu’elles sont effectivement devenues plus efficaces … à produire les mauvaises choses.

C’est la combinaison entre une prise de décision appropriée, une concentration sur les résultats, produits par des équipes de développement qui fonctionnent bien et qui intègrent la qualité à ce qu’elles construisent, qui leur permet d’exploiter au mieux les avantages de l’état d’esprit agile.

5.     La somme des user stories n’est pas l’histoire intégrale

La Business Analysis n’a pas pour objectif d’éliciter, de documenter et de gérer les exigences.

Lire aussi : 

[VIDEO] Les techniques de collecte de l’information (Part 1)

[VIDEO] Les techniques de collecte de l’information (Part 2)

Non. C’est en réalité « la pratique qui permet le changement dans une entreprise en définissant les besoins et recommandant des solutions qui apportent de la valeur aux parties prenantes » (note de bestofbusinessanalyst.fr : définition du BABOK® de l’IIBA®).

Lire aussi Quelles certifications pour devenir Business Analyst?

Les exigences ne sont qu’un moyen parmi d’autres d’atteindre ces objectifs.

Dans le même ordre d’idées, comprenez que la mentalité agile permet d’aller beaucoup plus profondément dans l’analyse que ne le font les user stories. Ce ne sont là que quelques mécanismes que vous pouvez utiliser pour aider à établir une compréhension commune avec votre équipe au sujet du problème posé et de la solution à recommander. Il existe beaucoup d’autres techniques intéressantes que vous devez piocher dans votre boîte à outils, comme les job stories, les spécifications par l’exemple, le story mapping, les diagrammes de contexte, la décomposition des processus, les maquettes, les wireframes etc…

La prochaine fois que vous serez obsédé par la manière d’écrire des user stories, rappelez-vous des mots de Jeff Patton : « Les histoires tirent leur nom de la façon dont elles devraient être utilisées, pas de ce qui doit être écrit ».

6.     Les Business Analysts peuvent aussi être Product Owners

Être Product Owner se résume à être garant des trois points suivants :

  • Focaliser tout le monde sur les résultats plutôt que sur les livrables,
  • Établir et maintenir sur la durée une compréhension commune,
  • Prendre des décisions.

Il existe plusieurs situations où le Business Analyst a le rôle de Product Owner, et a donc ces trois responsabilités. Le prérequis est qu’il puisse être en mesure de prendre des décisions (3ème point). En ce qui concerne les deux autres points, ils s’imposent comme une évidence auprès de tout « bon » Business Analyst.

Dans certains cas, les Business Analysts ne prennent pas eux-mêmes les décisions, notamment lorsqu’ils ont affaire à plusieurs intervenants qui n’ont pas la propriété du produit, mais qui ont un droit de regard considérable sur sa conception. Dans ces situations, le Business Analyst peut toujours être le Product Owner, mais le troisième point est reformulé ainsi : « S’assurer que les décisions sont prises ». Si l’analyste métier fait bien son travail, cela ne fera aucune différence pour l’équipe de développement, qui ne subira pas d’interruptions dues à des retards dans la prise de décision. Il est même possible que celle-ci ne se rende même pas compte que le processus de décision est différent.

7.     Les Business Analysts n’ont pas besoin d’être Product Owners

Si le Business Analyst n’est pas le Product Owner, cela ne signifie pour autant pas qu’il est inutile en contexte agile. Effectivement, l’organisation la plus fréquemment rencontrée est celle où le Product Owner et le Business Analyst travaillent ensemble, le Product Owner étant décisionnaire tandis que le Business Analyst se concentre sur l’établissement et le maintien d’une compréhension commune. Cette organisation est également très répandue lorsque plusieurs équipes travaillent sur un produit complexe.

J’ai aussi vu des projets où les Business Analysts se glissaient dans le rôle de coach (Scrum master) parce qu’ils possèdent d’excellentes compétences de facilitateur et qu’ils peuvent travailler sur des questions de dynamique de groupe. Cela démontre d’ailleurs bien l’intérêt d’utiliser les collaborateurs en fonction de leurs compétences et de leur expertise pour remplir un rôle, et non pas seulement en fonction de leur place dans l’organigramme ou de l’intitulé de poste, n’est-ce-pas?

Et vous, que pensez-vous du positionnement du Business Analyst en environnement agile ? Comment l’avez-vous vécu ? N’hésitez pas à alimenter la discussion avec 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

Envie de devenir Business Analyst?

Téléchargez dès maintenant mon e-book GRATUIT et apprenez enfin les fondamentaux de ce métier!

Recevoir le livre !

2
Poster un Commentaire

  S’abonner  
plus récent plus ancien Le plus populaire
Notifier de
Stéphanie FC

Pour ma part je trouve que le Product Owner est tout simplement un BA en « version agile ».
Ils font pareil mais dans des méthodes de projets différents.