Contexte

Jusqu’à présent, mes expériences Scrum tournaient autour des technologies Web. La BI m’est inconnue et me voici amené à être Scrum Master sur un projet décisionnel.
C’est pourquoi j’ai eu cette réflexion sur la manière d’appliquer Scrum dans ce contexte. Je vous présente ici, mon expérience sur ce projet mais également les retours que j’ai pu avoir des différents experts BI que j’ai pu côtoyés.

BI et Scrum, est-ce compatible?

Avant d’arriver sur ce projet, la seule inquiétude que j’avais, était de monter en compétence sur la BI mais rapidement certaines personnes m’ont fait part de leur scepticisme sur l’application de Scrum. J’ai recherché de la documentation sur ce sujet, et je n’ai rien trouvé qui me satisfaisait, la plupart des articles trouvés décrivent la méthodologie Scrum sans vraiment entrer dans les spécificités de la BI.

Avec du recul, ça paraît normal qu’il n’y ait pas beaucoup de documentation sur ce sujet car Scrum est une méthodologie qui s’applique indépendamment des technologies. C’est le contexte du projet qui compte.

Scrum peut s’appliquer à la BI et je vais expliquer progressivement mes différents points de blocage qui se sont peu à peu résolus.

Je ne connais rien en BI, est-ce grave?

J’avais pour habitude de faire quelques tâches de développements sur tous mes projets. J’aime garder un œil sur la technique mais sur un projet BI, j’ai du m’abstenir.

En théorie, le Scrum Master n’est pas obligé de faire du développement mais j’appréhendais cette nouvelle expérience car ça me semblait logique qu’un Scrum Master ait un bagage technique.

Quelques notions s’avèrent tout de même utiles à la compréhension d’un projet BI : modèle en étoile, dimension, mesure, fait… Un peu de lecture permet de combler rapidement ces manques, sans besoin de rentrer dans le détail.

Finalement, sur ce projet, nous avons un PO et des développeurs qui respectent bien leur rôle. Il n’y a aucune raison pour que je n’arrive pas à assumer mon rôle de Scrum master. Le maintient de la méthodologie se fait sans problème même si je ne développe pas.

Longueur des sprints et sprint review

Au démarrage de notre projet, il a fallu mettre en place l’intégration des premiers fichiers sources, la base de stagging, l’entrepôt de données, le cube et sharepoint pour enfin afficher nos premiers rapports.

Pour les premières fonctionnalités, il a donc fallu faire beaucoup de développements pour avoir de quoi montrer quelque chose au client.

C’est pourquoi, on s’est posé plusieurs fois la question de passer à des sprints de un mois au lieu de 2 semaines. Ce n’est pas interdit par Scrum mais j’aime bien les sprints de 2 semaines, d’une part car ça plait au métier d’avoir des retours si rapidement et d’autre part, ça donne une cadence qui rythme les développements.
Mais est-ce faisable techniquement? pouvons-nous livrer des fonctionnalités toutes les 2 semaines? C’est là que je vois la particularité de la BI. On n’a pas forcément des fonctionnalités visuelles à livrer sur les premiers sprints. Alors que montre-t-on lors de la démo au client? On peut par exemple, montrer le modèle de données. Il peut y avoir un sprint de conception car en BI, la technique reste proche du fonctionnel. Les échanges avec le métier sur le modèle du cube peuvent s’avérer enrichissants et donner lieu aux premières modifications du besoin initial.

On peut également montrer les rapports d’intégration de fichiers. Nous avons découpé certaines user stories en plusieurs. Par exemple, la mise en place d’une mesure initialement prévue en une user story a été découpée 2 :
– Une user story d’intégration des fichiers sources : « En tant qu’utilisateur A, je souhaite que les fichiers sources du système X soient intégrés afin de pouvoir effectuer des analyses sur ces données ». Les critères d’acceptation sont de visualiser un report d’intégration et des alertes en cas d’erreur d’intégration.
– Une autre qui portait sur le besoin d’analyse : « En tant qu’utilisateur A, je souhaite accéder aux mesures X et Z, afin d’y effectuer des analyses ».
Ainsi, nous avions de quoi montrer notre avancement au métier dès les premiers sprints.

Développement incrémental

Sur mes expériences de projets Web, la plupart des développeurs avaient déjà expérimenté Scrum. Alors que parmi les développeurs BI que j’ai côtoyés, peu d’entre eux avaient expérimenté cette méthodologie, même s’ils la connaisse vaguement.
Mais, dans la pratique, le développement incrémental fait surgir quelques réticences. Certains développeurs veulent tout développer d’un coup et le métier pense qu’il ne changera pas d’avis et donc n’y voit pas d’intérêt. Mais lors de l’enchaînement des sprints chacun prend ses repères et tout le monde y voit des avantages :

– les développeurs comprennent que s’ils avaient tout développé d’un coup, certains développements auraient dû être mis à la poubelle car le métier à changé de position sur certaines fonctionnalités. Ce qui peut démoraliser.

– le métier comprend qu’il peut changer d’avis sur ses fonctionnalités tant que ce n’est pas pris sur un sprint.

Conclusion

Peu importe les technologies employées, si on a les bonnes personnes qui assument les bons rôles, Scrum s’applique sans problème.
Je conseille vivement de tenter l’expérience si ce n’est pas déjà fait. Les réticences ou appréhensions rencontrées venaient surtout du manque de connaissance et d’expérience sur Scrum. Tout comme, moi, j’appréhendais faire de la BI. Rien ne vaut une démonstration pour convaincre 🙂