Risques protéiformes, exigences mouvantes, scandales financiers à répétition… Les projets Compliance s’insèrent chaque jour dans un environnement de plus en plus complexe.
Cette matière qui a évolué progressivement au fil des ans, pour passer d’une fonction technique et normative à un véritable levier de la gouvernance d’entreprise, fait aujourd’hui face à des attentes fortes en termes d’agilité.
Plusieurs facteurs sont à ce titre en cause :
- La prise en compte de plus en plus nécessaire des impacts opérationnels et commerciaux des dispositifs (concurrence avec de nouveaux acteurs, nécessité de fluidifier les processus et de réduire les irritants pour une meilleure expérience client)
- La collaboration croissante entre des équipes multidisciplinaires (experts, commerciaux, superviseurs, change manager, PMO, MOA/MOE, marketing, équipes digitales, etc.)
- Le besoin d’insuffler du rythme et de la résilience face au changement permanent (évolution des textes, des pratiques et des risques sociétaux)
- La nécessité de maîtriser la performance et de prioriser les thématiques face aux multiples projets (éviter l’effet tunnel, les glissements de planning et les dépassements de budget)
- Ou encore la transition technologique dans la mise en œuvre des diligences (des dispositifs de contrôle devant faire davantage appel au développement d’outils performants)
Face à ces enjeux et ce besoin de renouveau, le cadre « Scrum », se révèle être un outil prometteur pour un déploiement optimisé des projets Compliance…
Qu’est-ce que Scrum ?
Scrum est un cadre de travail Agile, s’appuyant sur une approche empirique (se basant sur l’expérience), non hiérarchique et collaborative de la mise en œuvre d’un projet.
En misant sur l’auto-organisation, l’amélioration continue et la valorisation des équipes, Scrum intègre les principes fondamentaux de l’état d’esprit Agile tout en définissant un cadre précis.
Codifié dans les années 90, ce cadre a été formalisé pour la première fois en 2010 par Jeff Sutherland et Ken Schwaber avec le « Guide Scrum » qui définit un ensemble de principes à respecter : piliers, valeurs, rôles, artefacts, événements…
Il encourage ainsi les équipes à s’adapter naturellement aux exigences et priorités changeantes en communiquant, coopérant et en produisant le plus de valeur possible sur des cycles de livraison courts (appelés Sprint).
SCRUM est en quelque sorte l’antithèse de la conduite du projet autoritaire et rigide suivant une feuille de route figée et préétablie.
Utilisé majoritairement à sa conception pour le développement de projets informatiques, ce cadre est aujourd’hui étendu à des domaines de plus en plus transverses en raison du niveau de performances qu’il permet d’atteindre.
Les principes fondamentaux du Scrum :
Les règles du cadre Scrum ont parfois tendance à être déclinées de manière hybride en fonction du contexte et de l’environnement du projet. Même si ce cadre peut paraître singulier de prime abord pour un projet Compliance, il est conseillé d’intégrer au maximum les principes fondamentaux suivants du Guide Scrum pour assurer un déploiement efficace en mode Agile :
Les 3 piliers :
Les trois piliers suivants sont à considérer comme des supports à la mise en œuvre de l’approche empirique :
- La transparence : Une communication claire, partagée et bienveillante de l’ensemble des informations du projet aux membres de l’équipe et aux parties prenantes
- L’inspection : La vérification régulière du respect des objectifs et des attendus du projet
- L’adaptation : La réactivité face au changement et la capacité à moduler la démarche
Les 5 valeurs :
Les valeurs suivantes sont des facteurs clés de succès pour la mise en œuvre des piliers cités plus haut :
- Engagement : Un engagement des équipes à produire en autonomie
- Courage : Le courage d’apprendre en faisant et en ne redoutant pas l’échec
- Focus : La mise en œuvre du projet en étant focus sur les objectifs à atteindre
- Ouverture : Une ouverture d’esprit pour une meilleure collaboration et une communication en toute transparence
- Respect : Le respect pour prendre en compte les opinions de chacun, s’entraider et partager une vision commune
Les 3 rôles :
Le Guide Scrum définit par ailleurs 3 rôles clés formant la “Scrum Team” et s’articulant autour de responsabilités spécifiques pour le déploiement du Projet :
- Le Product Owner (ou framework owner voir notre article sur ce sujet) qui est responsable de la vision métier du process à créer. Il va tenir compte des exigences réglementaires et des attentes des utilisateurs finaux.
- Le Scrum Master qui est Garant du cadre, qui s’assure du bon fonctionnement de l’équipe et de la bonne application des règles Scrum. En faisant preuve de pédagogie, il coache l’équipe en cas d’obstacles pour identifier des solutions adaptées. Il est également responsable de l’animation des différentes réunions.
- L‘équipe développement : Ils produisent en autonomie, tout en suivant le cadre donné par le Scrum Master.
Il est important de préciser ici que les équipes Scrum ne désignent pas de Chef de Projet, chaque membre devant se sentir engagé et autonome pour réaliser les tâches qui lui incombent.
Les 5 étapes pour le déploiement en mode Scrum
Etape 0 : Diagnostic réglementaire
Cette étape est une phase préalable à la mise en œuvre de tout projet d’évolution du cadre de conformité et doit être menée en continue par le product owner. Elle consiste en l’analyse de capteurs (kpi, kri, veille réglementaire, résultats de contrôle…) afin d’identifier de nouveaux attendus, des écarts quant à l’existant, et les impacts sur les piliers standards d’un Dispositif Conformité, exemple :
- Gouvernance & Pilotage : Comitologie / Rôles et Responsabilités / Processus Décisionnaire / Reporting
- Procédures : Politique / Modes opératoires / Guide méthodologique
- Contrôle permanent : Plan de contrôle de 1er et 2ème niveau
- Outils : Gestion des données / Détection des situations à risques / Mise en œuvre des diligences
- Gestion du changement : Animation d’ateliers pédagogiques / Campagnes de sensibilisation / Formation aux nouveautés
Etape 1 : Création du Backlog
Le Backlog est une liste ordonnée de livrables (ou de fonctionnalités) à créer. Il est maintenu par le Product Owner tout au long du projet sachant que son périmètre est évolutif et qu’il doit être affiné régulièrement.
C’est le Product Owner qui, en se basant sur les travaux de la phase préalable, va :
- Traduire chaque exigence réglementaire / impact en livrable. Il devra pour cela tenir compte au maximum des attentes des utilisateurs finaux du dispositif pour définir des livrables adaptés (ex : formaliser un mode opératoire pédagogique et didactique sur les nouveaux contrôles à mettre en œuvre à destination des équipes commerciales — Pour + d’efficacité cette étape peut être combiner avec la méthodologie Design Thinking)
- Prioriser de la manière la plus fine les livrables. La priorisation pourra s’effectuer en fonction de l’urgence, de la valeur pouvant être apportée au Dispositif et du risque de ne pas faire
Cette étape doit être assez courte sachant que le Product Backlog n’est pas figé et que l’objectif est de se lancer rapidement dans la mise en œuvre (à l’inverse d’un projet dit “classique” requérant une longue phase de cadrage).
Etape 2 : Planification de Sprint
Les membres de l’équipe Scrum vont se réunir pour le Sprint Planning, une réunion qui va permettre de définir :
- La durée du Sprint (2 à 4 semaines maximum)
- L’objectif du Sprint (en sélectionnant parmi les livrables prioritaires du Product Backlog, ceux devant être traités lors du Sprint)
- La division de chaque livrable en tâches à effectuer lors du Sprint (analyse, draft, revue etc.). Ces tâches devant chacune apporter de la valeur de manière indépendante
- La définition des responsables parmi les experts sur chaque livrable
- La clarification des attendus sur chaque livrable pour pouvoir le considérer comme finalisée
L’ensemble des tâches à réaliser sur le Sprint est alors appelé le Backlog de Sprint, et les experts doivent s’engager sur sa livraison.
Etape 3 : Création d’un Kanban
Les experts vont ensuite traduire le Backlog Sprint sous la forme d’un tableau, appelé Kanban, qui est un inventaire de l’ensemble des tâches à réaliser sur les livrables présélectionnés pour le Sprint.
Cet outil collaboratif va permettre de contrôler de manière visuelle l’avancement du Sprint. En divisant le processus de réalisation en colonnes, il permet en un coup d’œil d’effectuer un état des lieux des tâches prévues (ex : A faire, En cours, A Valider, Fait).
Etape 4 : Lancement du Sprint rythmé par le Daily Meeting
Durant le Sprint, les experts se concentrent sur l’objectif du Sprint et sur la réalisation des tâches du Kanban.
Ils se réuniront quotidiennement lors du Daily Meeting (accompagnée du Scrum Master et en option du Product Owner), une réunion d’une durée max. de 15 min à un créneau et un lieu fixe, pour que chaque experts répondent à 3 questions :
- Qu’ai-je fait hier pour permettre à l’équipe d’atteindre l’objectif du Sprint ?
- Que vais-je faire aujourd’hui pour permettre à l’équipe d’atteindre l’objectif du Sprint ?
- Est-ce que je rencontre des obstacles pouvant empêcher l’équipe d’atteindre l’objectif du Sprint ? (le Scrum Master recensera les obstacles rencontrés et devra coacher l’équipe à l’issue du meeting pour l’aider à lever ces obstacles)
Etape 5 : Revue de Sprint et Rétrospective
A la fin de chaque Sprint, les développeurs présentent à minima au Product Owner les livrables réalisés lors de la Revue de Sprint.
Il pose alors des questions et donne son feedback avec d’éventuelles demandes de changements.
La liste des livrables considérés comme finalisés est alors établie et le Product Owner met à jour en conséquence le Product Backlog. Cette étape permet ainsi de faire un état des lieux global sur l’avancement du projet.
A l’issu de la Revue de Sprint, le Scrum Master va animer la rétrospective de Sprint, réunion ayant pour objectif d’échanger avec les développeurs sur les obstacles méthodologiques et organisationnels qui ont pu être rencontrés lors du Sprint. L’idée étant de tirer le plus d’enseignements possibles pour mieux entamer les travaux pour la suite.
Conclusion :
En mettant en avant les besoins des utilisateurs du dispositif Conformité,
En fortifiant la collaboration entre les équipes,
En misant sur la transparence dans l’avancement des travaux,
En rythmant la réalisation des travaux par des Sprints,
En permettant une amélioration continue du process d’exécution,
En responsabilisant les équipes,
Le cadre Scrum répond en beaucoup de points aux attentes et enjeux existants sur le déploiement d‘un Projet Compliance.
Ce cadre reste toutefois récent dans ce type de Projet et nécessite en amont de former les équipes et de prévoir un véritable accompagnement au changement sur la méthodologie et l’état d’esprit Scrum.
