Retour sur le Webinar IIBA « Agile Business Analysis »
La présentation annoncée Webinar IIBA « Agile Business Analysis » vient de terminer et pour tous ceux qui n’ont pas eu l’occasion de le suivre je vous présente le review agile business analysis dans DAD – Disciplined Agile Delivery.
Disciplined Agile Delivery
Environ la moitié du webinar a été consacré à la présentation de DAD – Disciplined Agile Delivery.
Comme déjà détaillé dans l’article précédent, DAD reprend les phases du processus unifié (UP) et fait un mappage des pratiques agiles sur les différentes phases.Cette approche passe certainement très bien dans les grandes organisations, parce qu’elle s’appuie sur des thermes déjà connus.
Dans une introduction de DAD dans un environnement UP, cela peut présenter un grand risque, car le changement n’est pas apparent. Le risque n’est pas plus grand qu’avec UP, mais on risque de ne pas profiter de l’agilité tout court. Dans mon expérience, concrètement cela mène à l’exécution « scrumifé » des itérations, du waterscrum ou du scrumfall…
Scrum inclus
Dans la phase de construction, sur ses slides, Scott Ambler présente Scrum comme framework d’implémentation. DAD se positionne donc spécifiquement dans le domaine hors scrum – « the things Scum doesn’t care about ». Le thème de la distribution des rôles vient un peu plus tard.
L’apport du Business Analyst
La seconde partie de webinar était consacrée à l’apport du Business Analyst dans le processus global.
Scott a souligné que le travail du business analyste en amont de l’exécution du projet est absolument crucial pour le succès de l’ensemble. Il y a plusieurs manières de lancer un projet :
– basées sur un objectif global (« we go to the moon by the end of this decade… »),
– démarrant d’une expression de besoins ou
– après la production d’exigences précises.
Le choix de la forme dépend de l’organisation et de l’environnement légal. D’un point de vue agilité, la première version est certainement la préférée.
Avec l’agilité, le Business Analyst doit changer sa manière d’apporter de la valeur.Une des questions à la fin posée dans le Webinar était « mais comment peut-on prouver que quelqu’un m’a fourni une exigence, si je n’ai pas de document ? » Cette question nous montre clairement qu’il existe un problème de vision et de la compréhension des valeurs de l’agilité.
Les lignes directrices de la business analyse – détaillées dans l’article Review Agile Extension to the BABoK – sont essentielles pour le BA dans le contexte de DAD. L’aspect de la livraison rapide remplace en grande partie les besoins documentaires et la gestion du risque du processus.
Pour revenir brièvement sur la question citée, la réponse est « Non, on ne peut pas+ – Il n’y a pas besoin de le faire. La communication se fait entre présents. Ainsi, la livraison rapide, soutenue par le client sur site, permet de valider immédiatement le résultat. Si le résultat n’est pas ce que l’on attend, il faut améliorer la communication et encore raccourcir le cycle.
Le rôle du Business Analyst dans Scrum
Si on utilise Scrum dans la phase construction, Scott voit le business analyst principalement dans le rôle du Product Owner. Nous avons déja évoqué les défis du rôle du BA comme PO dans Scrum. En effet, le facteur critique pour un Product Owner efficace, est la capacité de prise de décision, et de pouvoir faire avancer le projet sur le plan tactique d’une manière autonome.
Malheureusement, force est de constater que dans les grandes entreprises, le Product Owner n’est souvent pas habilité à prendre de telles décisions. Scott va jusqu’à nommer ce Business Analyst dans le rôle du Product Owner « Proxy Stakeholder », ce qui signifie l’intermédiaire des parties prenantes, mais sans autorité, sans pouvoir. Or cela va à l’encontre du rôle même du Product Owner dans Scrum. Oui, le Product Owner réalise les besoins des stakeholders, mais il prend part activement et avec autorité dans le projet et n’est pas uniquement le relais d’informations.
Dans DAD, Scott reconnait aussi la valeur du Business Analyst dans l’équipe de réalisation (Development Team) . Il souligne le besoin de personnes polyvalentes dans l’équipe de développement: un Business Analyste qui sait (un peu) programmer, tester, un développeur qui sait analyser, faire de l’architecture etc.
Webinar IIBA « Agile Business Analysis »
très intéressant et à revoir
Malgré la longue partie sur Disciplined Agile Delivery en général – car comme bons business analyst que vous êtes et en suivant nos derniers blogs vous étiez certainement bien préparés et informés sur les principes DAD 🙂 – c’était un bon résumé du rôle important de l’analyse dans l’agilité. Il a bien mis en évidence qu’un projet n’est pas seulement de développer un système, mais que le travail en amont est aussi la clé pour le succès de l’ensemble.
