Scrum Hard : Scrum en BI

Scrum Hard : Scrum en BI

Introduction

On entend souvent dire à propos de Scrum, que bien appliquée, cette méthode de travail peut convenir à n’importe quel projet dans n’importe quel domaine fonctionnel. Est-ce bien vrai ?

Les rares exemples de Scrum BI que j’ai pu trouver dans les recherches sur le net n’apportent finalement que peu de solutions quant à la mise en place de la méthodologie sur ce domaine fonctionnel, et pour cause, il est vaste et complexe, et varie énormément selon la technologie utilisée.

Il faut savoir que mon équipe travaillait avec BO, Génio et des bases oracles, avec Tibco en principal filtre en amont, récupérant des données de SAP. Les spécialistes BI savent, mais pour les autres, il faut préciser que c’est du système à 1-million-dollar-licence, ce qui n’est clairement pas une configuration que l’on peut trouver partout. Mon discours va donc en être quelque peu imprégné.

Pour contextualiser un peu cet article, mon but était de faire un essai de la mise en place de la méthodologie Scrum sur l’équipe BI en perte de vitesse et de motivation.

Les raisons du choix de la méthodologie étaient multiples : clients mécontents, pas de planning, pas de visibilité courts et moyens termes, peu de réactivité, peu de communication, qualité médiocre, des livraisons trop irrégulières.

Persos1

Petit aparté sur cet article : Je ne vais pas faire de la redite sur des sujets classiques sur lesquels je n’ai pas apporté quoi que ce soit et qui selon moi n’ont pas vraiment de différence avec une équipe de développement classique. Je parle bien sur des différents Meetups agiles démo / rétro / sprint planning / backlog grooming sur lesquels je n’ai rien changé de ce qu’on peut trouver ailleurs.

 

Le démarrage

Le Sprint 0 : Définition du produit livrable

Points forts : None

Point faibles : multi-client, multi-canal d’arrivée, multi-pays, complexité du produit final

Solutions :

  • Mise en place d’un PO bien défini au sein de l’équipe, communiqué à tous les clients pour filtrer les demandes.
  • Définition de Jira comme seul détenteur du planning et de la gestion projet en lieu et place des mails et des fichiers excels.
  • Définition des différents produits gérés par l’équipe BI. Mutualisation des tâches communes.

 

Il y a un grand nombre de besoins différents dans le monde de la BI. Rapport, extraction, gestion de la 
qualité des données, processus de chargement… Tous ces types de demandes peuvent émaner de plusieurs clients différents (équipe Marketing, Commerciale, Projets, etc.). Il faut donc prendre le temps de définir les différents produits que gère l’équipe, ainsi que les différents canaux d’arrivée des fonctionnalités. Cela doit permettre de déclencher des actions différentes selon les cas : mise en production différentes selon l’équipe qui en fait la demande, communication spécifique, invitation à la démonstration filtrée.

 

Le Sprint 0 : Définition des Users Stories

Points forts : Un chef de projet compétent, grand connaisseur du métier

Point faibles : produit complexe et un peu flou.

Solutions :

  • Formatage simpliste des US.
  • Définition des US démontrables.
  • Création des Epics selon les logiques métiers BI (Extract, Report, Loading, POC, Quality)

L’avantage de la BI sur le développement, c’est la connaissance métier. Pour gérer un projet correctement en BI il faut connaitre tous les processus métiers sur les bouts des doigts. Je n’ai jamais vu un chef d’équipe, ou chef de projet BI, qui ne connaisse rien au métier de l’entreprise, et, je pense que c’est un grand avantage quand il s’agit de trouver un PO pour Scrum.

Pour le Sprint 0, il faut se forcer à faire les choses bien, même si cela coûte du temps.

Une User Story en BI n’est pas forcément chose aisée à écrire. Surtout au format classique *En tant que … je veux … pour faire …* car les plupart des stories ne sont que très peu visibles par l’utilisateur final. La majeure partie de mon temps a été consacré à trouver des choses à montrer aux utilisateurs finaux lors des démonstrations. Le reste, ce sont des chargements de tables, des corrections de données et de règles. En somme, des éléments pas forcément très démontrables. Il faut donc se concentrer la plupart du temps sur les rapports et les extractions de données mis en forme et utilisés par le client final, mais aussi sur les éventuels nouveaux outils de gestion des données, qui sont le nerf de la guerre de l’équipe BI, toujours à la pointe de la technologie lorsqu’il s’agit de la restituer.

 

Le Sprint 0 : Définition du planning

Points forts : Un planning dépendant des plannings extra-projets existants.

Point faibles : Un planning non engageant. Des dates trop peu précises.

Solutions :

  • Première estimation des 40 premières US. Livraison d’un planning à 3 mois.
  • Communication officielle du planning BI avec les différents Clients.
  • La bonne idée du Workshop.

 

Le planning en BI est relativement complexe à mettre en place, surtout quand on part de zéro. Nous nous sommes donc lancés sur des échéances à 2 semaines, permettant la réactivité sur le planning, un raccourcissement des délais de réponses, et suffisamment de temps pour avancer sur des sujets plus massifs. Les premières estimations n’étant que très peu fiables, il a fallu faire le saut de l’ange : communiquer sur un premier planning au client, en espérant être plus ou moins dans les clous selon les estimations des développeurs. La méthodologie est axée sur l’amélioration continue, mais les clients eux ne le voient / comprennent pas forcément.

Un des plus gros problèmes récurrents fut l’incapacité de l’équipe à donner une estimation précise sur certaines tâches. Estimant que selon l’analyse, on pouvait passer du simple au triple, mettant le sprint en péril. La mise en place du Workshop a permis de pallier à ce problème. L’anticipation nous permettant de faire un ou plusieurs Workshops d’analyse dans le Sprint précédent la Story faisant vraiment la fonctionnalité. Ainsi en arrivant au Sprint planning suivant, tout doute était écarté. La Story avait la solution adéquate et le bon chiffrage.

 

 

Le Sprint 0 : Définition de la priorisation

Points forts : None.

Point faibles : Une priorisation selon celui qui crie le plus fort.

Solutions :

  • Mise en place d’une échelle de priorisation en mixant la culture interne de l’entreprise et la
    méthodologie.

 

La priorisation du backlog a été fortement influencée par la culture d’entreprise interne, très conventionnelle. Les demandes les plus urgentes étaient donc celles venant du plus haut de la hiérarchie en premier. Puis venaient dans l’ordre classique : les problèmes de PROD, les impacts des lois, la qualité des données, les échéances d’évolution communiquées aux clients. C’est assez classique dans les entreprises aussi grandes, pas forcément très logique selon les demandes malheureusement. Fort heureusement, les trois premiers ne survenant que rarement, nous avons pu nous concentrer sur les autres, bien plus importants selon moi.

  1. VIP
  2. Bug PROD
  3. Lois
  4. Qualité
  5. MEP externe
  6. Evolution

Il n’y a rien de plus énervant qu’un directeur qui se croit tout permis, éclater le planning d’une équipe juste parce qu’il veut que sa demande soit traitée *tout de suite, maintenant*. Il faut savoir esquiver en disant que c’est pris en compte, sans préciser de date sans analyse préalable. Cela permet de gagner le temps nécessaire à la planification de sa demande en dépriorisant autre chose si besoin est. Attention à ceci d’ailleurs. La dépriorisation de fonctionnalités est vraiment à prendre avec des pincettes quand on traite avec autant de clients qu’une équipe BI. Il faut avertir du nouveau planning si celui-ci a bougé et bien expliquer pourquoi.

 

Le Sprint 0 : Définition du processus de création de valeur

Points forts : Une façon de travailler assez proche du monde du développement.

Point faibles : Des tests en BI pas forcément simples à automatiser.

Solutions :

  • Mise en place d’un processus simple pour commencer avec l’étape Doing + TU, et Testing PO. *Simpler is better*

Les compétences techniques étant réduites au spof dans l’équipe pour la plupart (ce que je ne vous souhaite pas, cela crée encore plus de soucis), il a fallu se concentrer sur un processus de création de valeur assez simple.

Persos4

kanban board

Disparue la validation technique par un pair, faute de pair. Mais par contre, mis en avant du Testing à cause de la qualité bancale des données, et, de part ce fait, le mécontentement des clients. Cette étape a évolué au cours du temps (j’en parle dans la partie Implication Métier plus loin). L’idée de base était d’assurer une vérification systématique des nouvelles règles de gestion et des nouveaux rapports par le PO. Le sujet de l’automatisation des tests était dans la liste des choses à faire au moment où ma mission s’est arrêtée, je ne pourrais donc pas l’aborder.

 

Le day-to-day

La qualité : Gestion des tests

Points forts : Le cœur de métier c’est la donnée : simple à contrôler, pour peu qu’on ait de bonnes règles de gestion.

Point faibles : Des tests en BI pas forcément simples à automatiser.

Solutions :

  • Testing systématique par le développeur sur environnement Dev.
  • Testing systématique par le PO sur environnement de Test.
  • Mise en place d’un rapport de contrôle récupérant toutes les sorties de Batch envoyé par mail.
  • Mise en place de copie de données journalière.
  • Mise en place d’une supervision visuelle.

 

La qualité est une des raisons majeures pour laquelle on a dû changer de méthode de travail. Il a donc fallu mettre en place des choses afin d’améliorer le contrôle des données. Tout d’abord, il a fallu imposer aux membres de l’équipe de tester systématiquement leurs modifications sur leurs propres environnements. Une deuxième étape de test, effectué par le PO sur un environnement distant dédié est, elle aussi, obligatoire. Elle a demandé beaucoup de matériel, étant donné que la mise en place d’un environnement complet de test nécessite tous les environnements en amont et en aval afin de faire des tests d’intégration probants. Nous avions un ESB en amont, et des bases de données en aval, qu’il a fallu répliquer. Des frais, largement compensé par la sécurisation qu’apportait un tel dispositif auprès des utilisateurs.

 

L’implication métier : InTeam et OutTeam

Points forts : Des interactions au jour-le-jour dans le monde BI adéquats.

Point faibles : Pas de planning partagé, pas de levier. Trop de clients BI, trop de questions !

Solutions :

  • Ouverture de Jira au client avec mise en place d’une étape de validation dédiée après le Test PO.

 

Le Client a voulu interagir plus finement avec l’équipe afin d’avoir plus de réactivité, et de souplesse. Le PO n’avait pas toute l’autorité nécessaire pour valider à leur place. Nous avons donc décidé de leur laisser l’accès à l’outil collaboratif, en les formant au passage. C’est ce que j’appelle le “InTeam” :  l’implication au jour le jour du client au-delà du PO. Premier problème qui s’est posé, et le pire, le planning partagé : pas de possibilité de les impliquer dans les Daily stand ups; aucune visibilité sur leur planning du jour. Pas de levier pour les obliger à valider au plus tôt. D’un côté, le but était atteint : ils avaient une vision hyper détaillée du planning et pouvait valider. Mais d’un autre côté, les sprints avançaient selon le bon vouloir de la validation des stories, et le PO était harcelé de toute part (plusieurs clients je vous le rappelle) pour comprendre les choix de priorisation.

Devant l’échec de plusieurs sprints, nous sommes donc revenus à un mode classique OutTeam, le client final ne validant que lors des démonstrations de fin de Sprint, laissant tout de même l’accès aux outils collaboratifs.

 

Le suivi : La gestion évidente des KPI’s

Points forts : Beaucoup de possibilité de mesurer la progression de l’équipe BI.

Point faibles : Attention à ne sélectionner que quelques points d’avancement fort. Eviter le superflu.

Solutions :

  • Mise en place de métriques de qualité
  • Mise en place de métriques d’avancement projet.

 

Il est facile de faire des comparaisons au jour le jour sur le nombre de batchs qui ont tourné, combien de temps, combien de succès et d’échecs; surtout avec une bonne supervision en place. Je pense que 5 métriques qualités suffisent. Au-delà, on ne les regarde plus. Idem pour les métriques d’avancement projet :

  • Burndown
  • Nombre de Bugs
  • Nombre de Blocages
  • Nombre d’Item dans l’Impediment Box
  • Nombre d’évolutions

Ce sont des exemples concrets mis en place sur mon projet, à chaque projet de trouver les mieux adaptés.

 

La gestion d’équipes externes : Fort ensemble ou inutile isolé ?

Points forts : L’hyper-dépendance fait partie de l’ADN du monde des collaborateurs BI et n’est donc pas un frein à la mise en place de Scrum.

Point faibles : Hyper-dépendance avec d’autres équipes est évidemment le point d’attention fort. Les autres équipes ne sont pas du tout en Agile. Être bien discipliné sur la gestion des Impediments. Interruptions très fréquentes.

Solutions :

  • Daily Scrum serait le meilleur moyen de suivre l’avancement sur ces interactions sur le papier. Mais trop peu adéquat dans ma réalité. Cela ressemble presque à des obstacles. Mise en place d’Atelier (Workshop) dans le Sprint Planning afin de prévoir ce temps dans la disponibilité d’équipe.
  • Avoir une Impediment Box.
  • Mise en place d’un Buffer précis.

 

Une équipe BI est pour la plupart du temps une équipe qui ne fait pas partie de la base fondatrice du SI d’une entreprise. Elle est là pour récupérer, traiter, exploiter et rendre des données générées par d’autres outils. La coordination avec ces équipes est donc primordiale. Afin de suivre l’avancement de ces points de façon fluide, privilégiant d’abord le contact direct avec les personnes de l’Open Space, il m’a fallu mettre en place des ateliers d’une heure maximum afin de faire état de l’avancement des différentes parties. Garder une trace sur un outil collaboratif (ici Confluence lié à Jira est assez utile) avec des actions associées à des gens et doubler sur le board physique afin de le garder toujours à vue de notre côté, pour savoir ce qu’il en est au Daily.

Plus une équipe doit récupérer des informations dans des systèmes différents, plus la dépendance deviendra une hyper-dépendance. Ajoutant encore plus de complexité au niveau des interactions avec l’équipe BI, et de la même façon, ajoutant de la rigueur afin de bien planifier le Sprint.

 

Plusieurs questions à se poser :

1°) Peut-on intégrer une personne de l’équipe externe à notre équipe ?

2°) Peut-on mettre en place un Daily commun ?

3°) Peut-on mettre en place des ateliers ?

4°) Peut-on mettre en place des outils communs ?

 

L’Impediment Box est un Must-Have dans une équipe BI en Scrum. Cela permet de suivre l’avancement des tâches impactantes dans les équipes voisines de la BI. Une boite physique sur le board pour en discuter à chaque Daily. Et dans un outil collaboratif afin de tracer les échanges.

event box

 

Comme le montre cet Event Box, les interruptions font partie de la vie courante de l’équipe. Plutôt que d’essayer de les éviter (en vrai, j’ai d’abord essayé de les réduire avant de me rendre compte que c’était encore plus improductif.), j’ai mis en place un Buffer de temps libre, par membre de l’équipe, afin de réguler toutes ces interruptions sur la durée du sprint, ajustant à chaque sprint si le besoin s’en faisait sentir.

Et après ?

Une remotivation de l’équipe flagrante suite à un changement de dynamique.

Une amélioration globale de la reconnaissance du travail de l’équipe au sein de la DSI et de la part des clients.

Une place nouvelle laissée à la force des idées, à la prise de risque, redonnant de l’implication à chacun.

Globalement, une très bonne initiative et des résultats concrets de la réussite de la mise en place de la méthodologie sur cette équipe BI.

Mais une hiérarchie encore trop conservatrice sur ce domaine, plafonnant la bonne marche de la méthodologie, parfois.

 

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *