Lettre à un business analyst

J’ai reçu un message hier d’un ancien collègue de travail auprès de qui j’avais énormément appris plus jeune. Il m’explique que dans son entreprise, ils commencent leur « transition vers le mode agile ». Et me demande, en tant que BA, pour anticiper écueils et problèmes, quelques conseils pour relever ce nouveau challenge. Je lui ai fait une réponse assez courte. Finalement j’ai envie de m’étendre et de lui écrire cette lettre.

Cher Gustave (on va l’appeler Gustave),

Tout d’abord, je suis heureuse pour toi que ton entreprise ait envie de tester une nouvelle façon de travailler. C’est une chance de se donner les moyens de changer. Faire différemment et voir ce qui se passe. Travailler dans une équipe pluridisciplinaire, c’est effectivement un nouveau challenge. Tu vas vivre ce changement à ta façon. J’espère que cela te permettra de découvrir autant de choses sur toi, sur le travail d’équipe, sur l’intelligence collective, que j’ai pu moi-même en découvrir. Des écueils et des problèmes tu en vivras. En m’écrivant, je comprends que ton intention est bonne. Que tu veux bien faire pour toi, pour ton équipe. Et c’est déjà un pas énorme. Demander à des personnes extérieures des conseils, c’est accepter que l’on ne sait pas. C’est se mettre dans une dynamique d’apprendre. Et c’est tout ce dont ton équipe a besoin.

1ER CONSEIL : RÉFLÉCHIR, AVEC L’ÉQUIPE, DE QUOI ELLE A BESOIN ET IMAGINER UNE ORGANISATION DE DÉPART

Quel que soit le stade de vie de ton équipe, c’est important que vous sachiez pourquoi elle existe, quelle est sa mission ? Et comment l’équipe saura qu’elle fait bien ? Comment est-ce que l’on va vérifier que l’équipe a un fonctionnement optimal ? Il peut y avoir plusieurs façons de le mesurer, et avoir des exigences de résultat qui évoluent dans le temps. Commencer par un objectif atteignable et vérifiable à trois mois, puis six, puis… Une fois ces questions traitées, on peut se demander de quoi on a besoin pour atteindre ce premier objectif. De quelles compétences. On a chacun plusieurs types de compétences : celles que l’on a apprises dans ses expériences passées, celles que l’on développe, celles inscrites sur sa fiche de poste (et encore… Pas toujours vrai) et celles qu’on ne soupçonne pas encore. Pour démarrer, chacun dans l’équipe peut dire ce qu’il sait faire, ce en qui il s’estime bon. Et organiser l’équipe avec cette connaissance de départ. On va alors peut-être apprendre qu’un BA est très attiré par le développement. Qu’un développeur a une vraie appétence à la facilitation. En général on démarre avec ce que l’on a. Les budgets ne sont pas extensibles, les recrutements pas toujours possibles. On imagine un fonctionnement de départ, pour voir, et toujours pour atteindre notre premier objectif.

2ÈME CONSEIL : S’AUTORISER TOUT, BIEN AU-DELÀ DE SA FICHE DE POSTE

L’équipe va vivre avec cette première organisation. Elle va vivre des succès, des échecs. Dans ce nouveau contexte d’auto-organisation, les gens vont pouvoir avoir de l’espace pour découvrir de nouvelles activités, appréhender leur métier différemment. Exemple : un développeur qui travaillait en cycle en V n’aura pas le même quotidien qu’un développeur dans une équipe agile. Apprendre sur eux-mêmes et sur les autres. Travailler en équipe pluridisciplinaire demande des compétences humaines fortes (ou soft skills). Ces apprentissages sont une chance qu’il faut accueillir, encourager, développer, discuter. S’interdire de faire du développement parce que ce n’est pas écrit dans sa fiche de poste est dommage. S’interdire de faciliter les conflits au sein de l’équipe parce que ce n’est pas écrit dans sa fiche… etc. Cette liberté à déborder de son périmètre dépend bien évidemment du contexte de l’entreprise. Je suis persuadée qu’au-delà des contrats entre client et prestataires, il faut essayer d’ouvrir au maximum les possibilités.

3ÈME CONSEIL (ON VA PARLER DU BA QUAND MÊME…) : ÊTRE POT DE COLLE

La définition de « business analyst » n’est pas toujours la même d’une entreprise à une autre, d’une équipe à une autre. Partons du principe qu’il s’agit d’un rôle en charge de décortiquer le besoin exprimé par le PO et d’aider l’équipe à le digérer, à le développer au mieux. J’ai connu des équipes dans lesquelles il n’y avait pas de BA. D’autres oui. Certains trouveront ce rôle de trop. Je pense que si l’équipe pense avoir ce besoin, pour x raison que ce soit, et bien cela a du sens. Et comme avec toute idée, process, rôle, il faut tester et voir ce que cela donne.
Donc dans un contexte où l’équipe a besoin de ce rôle, le BA a tout intérêt à être un vrai « pot de colle ». Pot de colle du PO, pour être toujours au fait de son besoin, de ses priorités. Pot de colle avec le reste de l’équipe. Pour ne pas laisser naître la moindre incompréhension, la moindre mauvaise interprétation. Pour aider à implémenter les tests au plus tôt. En gros, compenser un des effets négatifs du rôle en lui-même : être un intermédiaire.

4ÈME CONSEIL : S’AUTORISER ET DEMANDER DU FEEDBACK

Ce conseil est valable pour n’importe quel rôle de l’équipe. Mais je l’écris parce que je le considère très important et que c’est une pratique trop peu répandue dans nos entreprises françaises. Tu pourras difficilement éviter les écueils et les problèmes. En revanche, ils seront source d’apprentissage si les membres de l’équipe s’autorisent à se donner du feedback et à en recevoir. Du feedback sur l’équipe, sur sa production, mais aussi individuel. Il y a plein de façon de créer les conditions pour favoriser cette pratique : développer la confiance entre les membres, s’appuyer sur le scrum master, faire des rétrospectives, des points à deux personnes… C’est l’outil le plus puissant pour t’assurer que tu as la bonne attitude, la bonne méthode pour aider l’équipe à atteindre ses objectifs.

Ma grand-mère te dirait « bon courage »
Un ami mentor te dirait « amuse toi bien ! »