Une montée à l’échelle de l’agilité au sein de la 89C3 factory

6 octobre 2020

Retour d’expérience sur la mise en œuvre de l’agilité à l’échelle au sein des programmes  89C3, par Frédéric Veillepeau.

 

Lorsque le Groupe BPCE a décidé de créer une direction digitale, 89C3, et de s’appuyer sur les compétences informatiques internes pour construire sa 89C3 Factory , celle-ci s’est naturellement tournée vers les méthodes agiles, et en particulier vers la méthologie Scrum, pour l’organisation de ses équipes. Naturellement parce qu’il s’agit de l’approche la plus déployée aujourd’hui dans l’informatique bancaire, mais aussi et surtout parce qu’elle est particulièrement adaptée à un environnement en changement permanent comme le digital. 

Limites, frustrations, comme un besoin de plus d’agilité 

Et si cette approche a plutôt bien fonctionné, permettant à des équipes diverses de travailler ensemble et d’assurer les premières livraisons, il a bien fallu faire le constat au bout d’un an que certains programmes 89C3 n’évitaient pas les difficultés et écueils des grands projets informatiques : difficultés à livrer des applications complexes, fonctionnement en urgence permanente, manque de visibilité sur l’évolution des produits à moyen terme et donc perte de sens pour les équipes. 
A ces difficultés se sont ajoutées des problématiques spécifiques à notre approche de l’agilité :

  • Quel sens pour la méthodologie Scrum lorsqu’on ne fait que traiter des tickets (demandes d’évolutions) qui arrivent au fil de l’eau ?
  • Quel sens pour un backlog (liste de tâches priorisées définissant les caractéristiques d’un produit) qui se résume à ces tickets, sans visibilité sur les travaux au-delà de la prochaine version à sortir absolument ?
  • Comment concilier le principe d’équipe autonome et auto-organisée avec une organisation qui demande à faire collaborer des équipes nombreuses et ayant chacun leur patrimoine produit ? 

L’agilité à l’échelle, ça vous parle ? 

C’est dans ce contexte qu’il a été décidé d’expérimenter l’agilité à l’échelle sur un premier programme, en allant s’inspirer des approches du marché. Précisons que l’expérimentation a été menée dans une démarche conjointe entre le métier bancaire et l’informatique, tant le changement d’approche dont il est question ne pouvait se limiter à une question d’organisation des développements. C’est en particulier SAFe qui a servi de source d’inspiration. Au-delà de l’approche marketing tout-en-un de SAFe, ce sont bien ses démarches et pratiques qui ont retenu notre attention. L’idée n’a jamais été de prendre le framework pour l’appliquer de A à Z, mais de comprendre son sens, et de voir ce qui peut s’appliquer à notre contexte. 

Avec quelques années de recul, je résume aujourd’hui l’approche de SAFe à deux axes : 

  • la collaboration entre équipes ; 
  • la démarche incrémentale.

C’est bien sûr réducteur, mais cela me semble être un bon point de départ pour comprendre la philosophie qui est mise en avant par SAFe. Et pour reprendre une expression familière, on est venu à SAFe pour la collaboration, on y est resté pour l’approche incrémentale. 

La collaboration entre équipes 

C’est généralement LA raison pour laquelle une organisation se tourne vers l’agilité à l’échelle : comment faire en sorte que ses équipes – que la méthodologie Scrum préconise autonomes – puissent travailler ensemble efficacement. 
Et c’est souvent le début de l’incompréhension avec la démarche agile. Car disons-le tout de suite : une équipe autonome, de taille raisonnable, pouvant traiter seule l’ensemble des problèmes de son périmètre sera immanquablement plus efficace que plusieurs équipes qui doivent collaborer ensemble. Autrement dit, la réponse la plus efficace à la problématique de collaboration reste de ne pas avoir à faire de collaboration entre équipes (mais de privilégier une équipe unique, autonome, colocalisée). 
Ceci étant dit, dans le cadre de la 89C3 Factory, cet idéal est rarement atteignable. Mettre en place une solution de souscription en ligne de crédit, par exemple, qui servira à la fois aux Banques Populaires et aux Caisses d’Epargne, demande la collaboration des développeurs du digital (sites en lignes et applis mobiles) et de spécialistes du crédit de deux systèmes d’informations (celui des Banques Populaires et celui des Caisses d’Epargne). On dépasse très vite la taille maximale d’une équipe, et la colocalisation tient de l’utopie dans un groupe mutualiste avec des sites dans la France entière. 
 
Face à cette problématique, SAFe préconise une approche, celle de partager au maximum l’information entre tous les intervenants (oui, oui, développeurs compris), et trois rituels (ici encore, je simplifie) : 

  • le PI Planning ;
  • le Scrum of Scrum ;
  • la démo commune.
     
    Le PI  (Program Increment) Planning est le rituel emblématique de SAFe. Tous les trois mois, il regroupe tous les intervenants du programme (métier, développeurs, architectes, managers, exploitants, experts sécurité, …) pour construire en deux jours le planning des trois mois à venir. Il permet à tous d’avoir le même niveau d’information sur les objectifs, les priorités, et d’échanger pour comprendre les contraintes des autres et arriver au meilleur planning possible. 

 
Le Scrum of Scrum est lui un rituel de pilotage opérationnel hebdomadaire qui regroupe les Scrum Master & Product Owner de chaque équipe autour des pilotes du programme (Release Train Engineer & Product Manager) pour partager l’avancement des travaux et les difficultés rencontrées. En s’appuyant sur le planning issu du PI Planning et en se concentrant sur les dépendances entre équipes, il permet de mettre le focus sur les risques qui peuvent avoir un impact sur plusieurs équipes, tout en laissant l’autonomie de fonctionnement à chacune. 
La démo commune, enfin, est un temps fort pour partager régulièrement (deux fois par trimestre en moyenne) les réalisations du programme. Là où le PI Planning a amené les équipes à prendre des engagements sur les réalisations à venir, la démo commune permet de partager la réalité des choses avec toutes les équipes, avec le management et (idéalement) les clients. C’est un temps très fort pour que chacun prenne conscience de la capacité collective à réaliser des applications qui apportent de la valeur à leurs utilisateurs.

 La démarche incrémentale 

La méthologie Scrum promeut l’approche itérative, avec des sprints de deux à quatre semaines, mais il nous a toujours été difficile de donner un vrai sens à ce rythme. La plupart du temps, il est resté comme un rythme de fonctionnement interne de l’équipe, une « obligation » de Scrum. 
SAFe propose, au-dessus de ces sprints, la notion d’incréments d’une durée d’un trimestre (environ). Cette durée a tout de suite eu beaucoup plus de sens pour nous. En trois mois, on peut réaliser des évolutions complexes (multi-équipes) qui apportent de la valeur. On peut réaliser une nouvelle architecture. On peut mettre en œuvre les fonctionnalités les plus urgentes à réaliser. Et on peut faire le point au bout de trois mois pour se confronter à la réalité de ce qu’on a pu faire. 

Le pilotage par la valeur, ça vous parle ?

En fait, en se lançant dans cette démarche incrémentale par trimestre, on a accepté de changer fondamentalement notre approche. Plutôt que de partir sur un périmètre défini pour un an (ou deux) avec un engagement difficile à tenir, on a basculé dans une approche de priorisation par la valeur : qu’est-ce qu’il est le plus utile de faire aujourd’hui et pour les trois mois à venir ?
Cette approche fait perdre l’engagement de long terme (dix-huit mois en moyenne pour nos projets informatiques) pour préférer des engagements de court terme beaucoup plus fiables (parce qu’il est plus facile de s’engager sur ce qu’on saura faire en trois mois qu’en deux ans, avec moins d’incertitudes, mais aussi parce qu’on fera le bilan de cet engagement plus tôt et qu’on s’améliorera donc plus tôt). 
Elle permet aussi de garder de la liberté sur les travaux à réaliser par les équipes : plutôt que d’avoir des équipes dédiées à un projet et donc un périmètre sur le long terme (et qu’il faudra démobiliser si le projet s’arrête ou si d’autres priorités émergent), nous avons des équipes qui travaillent sur le programme, et qui traitent le périmètre prioritaire tel qu’il est défini tous les trimestres. Cela laisse beaucoup plus de flexibilité pour prendre en compte les changements de priorités, mais aussi pour se reposer la question lorsqu’on rencontre des difficultés (lorsqu’on découvre qu’une évolution va prendre beaucoup plus de temps que prévu, on se repose la question en PI Planning de voir si ça vaut le coup et le coût de continuer, ou s’il faut pivoter). 
C’est toute cette approche, à laquelle nous avons goûté presque par hasard en essayant SAFe, que nous regroupons derrière la terminologie de pilotage par la valeur

Un seul juge, l’utilisateur 

Pour fonctionner, cette approche se base sur une logique qui était assez éloignée de nos projets informatiques : la mesure du retour sur investissement. 
Historiquement, à partir d’une idée, on lançait un projet informatique avec une promesse de retour sur investissement, tout en sachant qu’on ne saura s’il est réellement utile qu’au bout de deux ans. Autrement dit, cette promesse n’engageait que ceux qui y croyaient. 
Dans une approche incrémentale, la démarche est différente. A partir d’une idée, l’objectif est d’identifier comment on peut, au plus tôt, mesurer si elle marche vraiment. Cela va donner lieu à des fonctionnalités qui doivent être réalisables en un incrément au plus, et que l’on va ouvrir à nos utilisateurs le plus vite possible pour mesurer si elles marchent ou pas. Plutôt que de rester sur une promesse, on cherche à se soumettre au seul juge pertinent qu’est l’utilisateur. Et en cadeau bonus, on commence à avoir un retour sur investissement (même s’il est limité aux premières fonctionnalités priorisées) au bout de trois mois. 
Et, soyons honnêtes, nous n’avions pas l’habitude de fonctionner comme cela. C’est un changement d’approche, de schéma mental, qui demande du temps et de l’accompagnement. De la formation et du partage, aussi. On n’a pas l’habitude de chercher à identifier les facteurs clés de succès qu’on doit valider au plus vite. Ni de découper nos projets en fonctionnalités réalisables en trois mois au plus. 
Mais c’est une approche qui permet d’investir nos budgets informatiques de manière beaucoup moins risquée, puisqu’on valide le plus tôt possible l’intérêt de ce qu’on réalise. Et on réoriente nos travaux au fur et à mesure en fonction de ce qu’on aura appris sur l’utilisation de nos applications par nos clients. 

DevOps anyone ? 

Pour que cette approche ait vraiment du sens et ne se limite pas à une vue de l’esprit, il nous a fallu investir dans nos filières d’ingénierie. C’est bien beau de construire des fonctionnalités utiles en moins de trois mois, mais s’il faut six mois pour les livrer à nos utilisateurs, on ne sera pas plus avancés… 
Nous avons mené un très important chantier DevOps pour automatiser nos filières de développement jusqu’à la production. Au bout de 2 ans, quelques-uns de nos acquis (pas forcément encore pour toutes les filières, malheureusement) : 

  • Un développeur est capable de mettre à disposition de son Product Owner en quelques minutes toute nouvelle fonctionnalité qu’il a développée et testée. Ce qui veut dire que le PO pourra valider au fil de l’eau la fonctionnalité, pas au sprint suivant ou à la prochaine version. 
  • La qualité est mesurée et pilotée par notre chaine d’intégration continue. 
  • L’installation dans tous les environnements (y compris la production) est automatisée. 
  • Nous disposons de créneaux d’installations hebdomadaires. Sur un périmètre applicatif donné, nous avons fait 40 installations de nouvelles fonctionnalités en production dans l’année. 

Culture de la mesure en production 

Le pendant de cette démarche technologique, c’est le développement d’une culture de la mesure en production. Non seulement pour s’assurer du bon fonctionnement et de la qualité de service, mais aussi et surtout pour savoir comment nos utilisateurs s’approprient nos applications. 
C’est au cœur de la démarche métier : il ne sert à rien de développer une fonctionnalité si on n’est pas capable de mesurer si elle sera utilisée. Ici aussi, le pilotage par la valeur est passé par des travaux techniques et surtout par une revue des priorités. Le calcul des indicateurs ne peut plus être le parent pauvre de nos développements. 
Et en mettant ces indicateurs sur l’utilisation en production (idéalement temps réel) à disposition de tous, nous bouclons la boucle. Chacun voit à quoi servent ses travaux car il voit leur utilisation « dans la vraie vie ». 

Petite synthèse 

En prenant du recul après deux ans et demi de mise en œuvre, le bilan est très clairement positif, même si du chemin reste à parcourir : 

  • on travaille moins dans l’urgence (mais encore un peu);
  • on livre régulièrement des fonctionnalités et on sait qu’elles sont utiles (même si tout marche rarement du premier coup);
  • les équipes comprennent mieux pourquoi elles interviennent (même si cela demande encore et toujours un travail d’embarquement du management métier et informatique);
  • l’amélioration collective de l’organisation se fait au fil des incréments au service de l’efficacité opérationnelle et par les acteurs eux-mêmes (et elle n’est jamais terminée).

 
Ma conviction est qu’on a trouvé des solutions permettant de s’inscrire dans une démarche agile au-delà des frontières de l’équipe, et ce pour le plus grand bénéfice de nos utilisateurs. Cela nous a permis de trouver des réponses systémiques à des difficultés de grands projets, et ainsi de libérer les équipes qui se retrouvaient à devoir gérer des problématiques sans les outils associés. Mais cela reste une aventure collaborative, sa forme dépend du contexte et des personnes, et restera donc toujours à adapter, améliorer, réinventer… 
Aujourd’hui, nos réflexions se portent sur un barreau un peu plus élevé de l’échelle : comment gouverner ce genre de programmes pour en profiter à plein ? 

Mais ce sera pour un autre billet. ..