La banque et Scrum
Jusqu’à maintenant mes missions se sont toujours déroulées en banque de finance et d’investissement, dont la moitié d’entre elles en méthodologie Scrum. Dans cet article, je vais essayer de vous faire part de mon expérience sur le sujet, en partageant mes observations et réflexions, principalement suivant l’axe : pourquoi Scrum et la banque peuvent être compatibles, en tout cas d’après ce que j’ai pu observer dans les projets auxquels j’ai participé.
A priori on peut trouver des contextes de projets différents dans le domaine de la banque, et au contraire trouver des contextes similaires dans d’autres domaines, comme l’industrie, les télécoms et d’autres … Mais comme mes expériences se sont déroulées dans la banque, c’est ce dont je vais vous parler ici, en espérant que cela apporte des informations intéressantes pour ceux qui n’ont pas (encore) eu l’occasion d’y travailler.
Précision de vocabulaire : ici j’écris seulement « la banque » pour « banque de finance et d’investissement » (avec traders, sales, Front Office, Middle Office, Back Office …)
Des utilisateurs et des équipes de développement proches
Je pense qu’un des points en faveur de l’utilisation de Scrum, dans le contexte des projets auxquels j’ai participé, est que les utilisateurs et les développeurs me semblent relativement proches, ce qui favorise la collaboration telle que recommandé par Scrum. J’ai observé cette proximité suivant plusieurs axes :
Peu d’intermédiaires, voir un contact direct
Dans ces projets, il y avait plutôt peu d’intermédiaires : les utilisateurs exprimaient plus ou moins directement leurs besoins, et tout au long du projet : avant, pendant, après – ce qui a priori colle bien à la méthodologie Scrum.
Il pouvait y avoir par exemple un petit nombre d’intermédiaires : MOA, opérationnels … ou même un contact direct entre utilisateurs et développeurs, suivant les projets sur lesquels j’ai travaillés. Je pense que cela a aidé à ce que Scrum soit plutôt bien accueilli, même si la mise en place de Scrum a peut-être, dans certains cas, demandé une disponibilité un peu plus importante, et aussi de définir un Product Owner.
D’ailleurs je pense que c’est ce point, la définition et la désignation claire d’un Product Owner qui remplit bien tous les critères Scrum, qui a peut-être demandé le plus d’efforts et d’adaptations sur les projets Scrum auxquels j’ai participé, et à mon avis c’est peut-être là qu’on peut notamment trouver des axes d’amélioration.
Il n’en reste pas moins que j’ai trouvé qu’on avait un accès relativement aisé aux utilisateurs et à l’expression de leur besoin dans ces projets Scrum – d’après moi c’était peut-être plus simple que dans le cas de développements de systèmes et logiciels qui ne rencontreraient leurs utilisateurs réels qu’une fois prêts à être livrés par exemple. Là les utilisateurs collaboraient tout au long du projet, ce qui m’a semblé assez positif.
Un univers commun
Même si ce n’était peut-être pas le cas de tous, une grande partie des utilisateurs avec qui j’ai pu travailler a déjà une certaine expérience des systèmes d’information et il me semble qu’ils sont souvent assez conscients et sensibles aux points techniques, car cela touche directement leur activité : mode de récupération des prix, canaux de communication avec le marché et leur utilisation dans le système, workflow d’actions et de statuts Front Office – Middle Office – Back Office …
Dans les équipes dont j’ai fait partie, on ne discutait pas forcément des détails du framework .Net avec eux – en fait si, sur un des projets on avait des utilisateurs-développeurs … mais même sur les autres projets sans utilisateurs-développeurs, on pouvait aussi discuter de certaines problématiques concrètes.
Par exemple on a pu discuter de l’impact de leurs demandes sur les performances du système : telle donnée n’est pas liée directement à cet objet dans notre modèle, donc c’est assez coûteux de la récupérer à cet endroit là, mais par contre on peut vous proposer de l’afficher ici … et ces propositions et discussions m’ont parues être plutôt bien reçues par les utilisateurs, sans qu’ils ne perdent de vue leur besoin et la finalité de leurs demandes.
De leur côté les équipes dont j’ai fait partie comportaient souvent des personnes avec une certaine connaissance de la finance – parce qu’ils y venaient souvent par choix et par intérêt, ensuite parce qu’un socle de connaissances était souvent demandé pour ces missions, et aussi car comme les utilisateurs et les équipes de développement collaboraient souvent de manière assez proche, au fur et à mesure des missions les développeurs avaient pu accumuler un certain nombre de connaissances financières.
Donc sur ces projets, je pense qu’on avait à la fois des utilisateurs plutôt familiers et directement intéressés par les contraintes et les problématiques des systèmes, et aussi des équipes de développement avec un intérêt fort pour la finalité des systèmes développés. Je pense que cela peut être un contexte dans lequel l’adoption de Scrum peut être un choix pertinent, et peut notamment permettre de renforcer et d’améliorer encore cette collaboration.
Un cycle de vie itératif
Sur mes missions, il s’agissait de systèmes d’information existants, sur lesquels il y avait de la maintenance évolutive, mais aussi des projets de refonte, de nouvelles fonctionnalités, des adaptations aux nouvelles normes bancaires, passage à l’euro, fusions, Bâle I, II, III (… Bâle CCCLVI), des adaptations aux évolutions des fournisseurs de données de marchés … il y avait souvent plusieurs projets en cours, les produits ne semblaient pas être finis et figés.
Et d’après ce que j’ai pu voir, les enveloppes budget peuvent être régulièrement adaptées en cours d’année, afin de s’adapter au mieux à l’évolution du contexte – par exemple un projet, avec une enveloppe déterminée au début, est découpé en plusieurs lots, et la pertinence et le contenu de chaque lot peuvent être rediscutés et renégociés, ainsi que les ressources qui y sont affectées – avec éventuellement une adaptation de l’enveloppe globale.
Très concrètement c’est ce que j’ai pu voir dans certaines de mes missions : des besoins et demandes peuvent émerger en cours de projet, et être ensuite arbitrés par les sponsors, par exemple en ajoutant des ressources ou en dépriorisant un autre point.
Donc je pense que dans ces cas là on peut dire qu’on est près et prêts pour la méthodologie Scrum, avec une gestion itérative, des besoins continus qui évoluent et sont réévalués, et des ajustements des priorités et ressources.
Des besoins changeants
Les systèmes et applications que j’ai pu observés étaient plutôt complexes et interconnectés, avec notamment plusieurs types d’utilisateurs, ayant des contraintes et besoins propres – clients externes, Front Office, Middle Office et Back Office …
Ces différentes équipes, avec différents points de vue, contraintes et utilisations, avaient souvent plusieurs projets en cours – comme cité plus haut : réglementations, nouveaux produits financiers, évolutions des pratiques …
Donc on pouvait avoir des évolutions parallèles dans plusieurs parties du système global, et suivant les avancements d’un autre projet, un système pouvait être impacté et chercher à s’adapter, notamment en anticipation. En fonction des nouvelles informations, on pouvait donc avoir de nouvelles demandes et spécifications sur le projet en cours, ce qui rend d’après moi la méthode Scrum très adaptée, puisqu’on a alors à chaque sprint une réévaluation et un réajustement aux priorités et aux besoins.
Scrum peut donc selon moi fournir un cadre utile pour structurer le projet : dans un contexte de changements et de nouveautés relativement fréquents, cela peut permettre de bien réagir face au changement, et de l’accueillir, en aidant à l’organiser. D’après ce que j’ai pu voir sur les projets gérés avec Scrum, cela a pu amener une évolution positive dans la définition des besoins et spécifications, en essayant d’être dans un tempo optimisé : suffisamment en amont pour que les développements puissent commencer sereinement, et suffisamment fréquemment pour s’adapter aux évolutions.
Je pense que la méthode a pu nous permettre de mettre en avant ce type de tempo et je pense que dans les projets auxquels j’ai participé, ce rythme était un de nos objectifs. Je dirais aussi que cet objectif semblait être partagé par la Team des développeurs, le Product Owner et le management, les utilisateurs … je pense que Scrum peut être une bonne méthode pour favoriser ce travail d’équipe, avec une certaine organisation et une volonté partagée – en tout cas c’est le sentiment que j’ai eu en participant à ces projets.
Passage rapide du développement à l’utilisation
Suivant les projets, la fréquence de livraison en production était souvent de quelques semaines, même hors Scrum – ce n’est pas comme un logiciel sur lequel on sortirait une nouvelle version à des intervalles un peu plus grands j’imagine. Avec Scrum on avait des livraisons fréquentes – en tout cas des livrables fréquemment validés, même s’ils ne partaient pas immédiatement en production. Je pense que cela nous a permis d’insister sur le fait d’avoir un livrable prêt qui marche, et de resserrer les phases de tests et de validation – donc de trouver les bugs et problèmes plus rapidement et donc de les corriger à moindre coût. Je pense que la méthode s’adaptait bien au contexte, et apportait un vrai avantage de ce point de vue aussi.
De plus ces projets comprenaient souvent déjà des phases de validation utilisateurs sur des environnements dédiés avant de mettre en place Scrum : les démos de fin de sprint ont donc été plutôt bien accueillies et rapidement profitables d’après ce que j’ai pu voir, car les utilisateurs étaient déjà preneurs pour faire des retours rapidement, et les environnements étaient déjà disponibles.
Conclusion
J’espère que cet article a pu vous apporter des informations intéressantes sur une partie de ce qu’on peut trouver comme projets dans la banque et comment certains de ces projets peuvent, je pense, être bien adaptés et profiter de la méthodologie Scrum. De mon point de vue, cette méthodologie peut permettre de renforcer les points forts dans ce contexte de projets, et peut aussi permettre de répondre à certaines des problématiques rencontrées.
L’adoption et l’adhésion à l’ensemble de la méthode peut, je pense, demander quelques efforts et adaptations lors de sa mise en place, à la fois de la part des équipes et du management, mais je pense que ces efforts se sont avérés payants sur les projets auxquels j’ai participé, et ont pu même révéler un rôle intéressant pour le consultant : promouvoir la bonne pratique de Scrum, avec l’avantage de voir et de profiter de ces effets positifs.