Agilité chez Axa France : mélange entre le modèle Spotify et Safe

Axa France a décidé de se lancer dans une grande transformation agile ; cette transformation passe par des inspirations venant de Spotify et de Safe. Nous allons voir dans cet article en quoi consiste l’agilité chez Axa France que deux coachs agiles sont venus présenter lors de l’Agile en Seine édition 2017.

Agilité chez Axa France

La transformation agile d’Axa a démarré en 2011 et continue encore aujourd’hui. D’après les coachs agiles d’Axa France, la transformation avait atteint les 50% en 2015 soit 4 ans plus tard.

Le groupe a validé la mise en place de cette transformation Agile sur l’ensemble de la DSI en 2016 après avoir validé sur une partie de la DSI que cela fonctionnait correctement (concept de pilote).

Il est évident que cette transformation prendrait beaucoup de temps sachant que la DSI principal acteur concerné comporte 2000 personnes. La transformation agile d’Axa concerne principalement la DSI.

Cette DSI est séparée en 5 sous DSI qui sont chacune responsable d’un périmètre fonctionnel spécifique. Il faut savoir qu’Axa fonctionne avec des équipes à Paris, à Lille mais aussi au Vietnam ; nous ne traiterons pas ce sujet d’offshore au sein de cet article.

Scrumban à votre service

Sachant que le Scrum est parfois trop contraignant et que le Kanban pouvait apporter beaucoup, ils ont décidé de basculer l’ensemble des équipes en Scrumban.

Pour ma part je ne suis pas vraiment d’accord avec ce type d’imposition où je pense que chaque équipe doit fonctionner avec la méthode de travail qui lui semble la plus adaptée ; mais il est vrai aussi qu’au début les équipes n’ont pas forcément une culture agile assez forte pour avoir cette capacité d’autonomie.

N’étant pas d’Axa, il m’est difficile de connaitre l’environnement et le contexte autour de ce type de décision mais je n’ai aucun doute qu’il y ait de vraies raisons derrière ces choix. Rappelons que ces choix ont été fait par de très bons coachs agiles.

Axa France a alors décidé de définir 5 points comme référentiel commun des pratiques agiles autour de ce Scrumban : les rôles, le management visuel, le flux continue, la prédictibilité et les rituels. Rien d’anormal, on est bien dans une culture agile.

Agilité à grande échelle

Axa France a décidé de mettre en place une agilité à grande échelle proche de celle mise en place dans le passé par Spotify. Nous retrouvons les concepts de Squad, de Tribus, de Chapter et de Guilde comme le présente le schéma ci-dessous :

Axa présente des rôles concrets pour alimenter son modèle d’agilité et ajoute une couche « domaine » qui n’existe pas au sein du modèle Spotify.

Article : L’agilité à grande échelle avec le modèle Spotify

On peut d’ailleurs constaté qu’Axa est un modèle Spotify qui impose plus de choses avec des rôles concrets, bien déterminés ; on est plus dans la mise en place d’un framework tel que Safe que dans la mise en place d’une organisation.

Les tribus

Chaque sous-DSI concentre environ 5 tribus différentes qui se partagent différents domaines fonctionnels. Ces tribus sont constituées au maximum de 100 personnes.

Les domaines

Chaque tribu va se diviser en sous-domaine fonctionnel comme par exemple l’assurance voiture ou l’assurance habitation. Il faut rappeler qu’Axa concentre un grand nombre d’activités différentes.

Ce découpage par domaine n’existe pas dans le modèle Spotify mais reste tout a fait dans la même philosophie d’agilité à grande échelle. Axa a su adapter le modèle pour qu’il soit plus adapté à son contexte.

Les squads

Les squads chez Axa France sont des features teams de 7 ingénieurs (avec plus ou moins 2) qui travaillent ensemble en Scrumban et qui ont chacune un Product Owner associé.

Ces Squads fonctionnent en autonomie et sont stables sur le temps afin de les rendre les plus efficaces possibles. Axa a volontairement fait en sorte que les membres des squads restent au sein de leur squad le plus longtemps possible (les prestataires restent si possible les 2 ans de leur présence).

C’est le Product Manager du domaine qui répartira les travaux à réaliser entre les différentes squads.

Un expert métier peut-être associé à une ou plusieurs squad selon les besoins. Axa insiste sur le fait que le métier doit toujours être proche du produit même en cours de réalisation ce qui est une très bonne chose.

Les guildes

Les guildes venant du modèle Spotify ont été mise en place pour combler la transformation de silo techniques en silo fonctionnel. La disparition des silos techniques peuvent être problématique dans le partage entre corps de métier.

Mal géré, on se retrouve avec des squad qui ne se parlent jamais ce qui apporte son lot de complication comme le double travail, la multiplication de pratiques…

Les guildes sont donc l’organisation matricielle permettant de rassembler les corps de métiers entre eux. Nous pourrions avoir par exemple une guilde Agile UX, une guilde architecture (rassemblant tous les devs et devops), tests.

Les guildes se rassemblent sur l’ensemble des sous-DSI et ne sont pas enfermées entre tribus.

Les chapters

Chaque métier se rassemble sous forme de chapter dans ce modèle matriciel. Ils pourront ensemble se retrouver de temps en temps pour partager sur des sujets communs, monter en compétence ensemble voire pour s’aligner sur des pratiques. Nous pourrions avoir comme chapter par exemple  : les développeurs front, les développeurs back, les webmasters…

Il serait bien dommage de voir des personnes ayant les mêmes rôles faire un travail plusieurs fois. Ces chapters par contre ne se retrouvent qu’entre chapter d’une même tribu car les partage inter-tribu se fait déjà par l’intermédiaire des guildes.

Changement de comportements

La DSI d’Axa connaissait une importante hiérarchie pyramidale et a eu beaucoup de mal à transformer les managers qui avaient des hommes et un périmètre en véritable facilitateur garant du produit.

Cette transformation des comportements a pris beaucoup de temps mais était essentielle pour le bon fonctionnement de ce type de framework. Les managers se sont transformés en servant leader.

Il y a une co-responsabilité mise en place entre l’IT et les métiers. Au plus haut niveau le sponsor métier et le DSI décident ensemble des projets et au niveau inférieur des tribus les responsables tribus et responsables métiers décident ensembles.

Chez Axa il y a un Backlog à 3 niveaux très particulier qui mérite qu’on s’y arrête quelques secondes. Il y a des Epics, découpées en MMF (terme très mal utilisé), découpées en US.

Les Epics chez Axa sont les réponses opérationnelles des équipes IT à un ou plusieurs enjeux business. Ils sont le résultat de ce travail en collaboration entre les responsables de tribus et les responsables métiers.

Les MMF sont des ensembles fonctionnels cohérents livrables en moins d’un mois. Ces MMF sont gérées horizontalement soient qu’elles traversent le parcours client intégralement. Ce sont les PM et les Business Owners qui sont responsables de celles-ci.

Les scénarios de tests sont de bases mis sur celles-ci et non sur les US.

Les US sont classiquement gérées par le Product Owner et l’expert métier directement associé à ce produit.

Voici un schéma représentant l’ensemble :

Vous pourrez y voir des boards directement inspiré du Safe comme le board de Delivery présent en bas à gauche.

Conclusion

La transformation agile d’Axa France ressemble beaucoup au modèle Spotify avec des pratiques plus proches du Safe comme le board du Delivery voire certains rôles. Les termes utilisés ne sont pas toujours les mêmes mais on y retrouve beaucoup d’idée.

On ne peut que féliciter le travail réalisé dans cette transformation agile qui semble solide même si on pourrait rediscuter certains points. Il est évident que ce modèle évoluera selon l’évolution du contexte et les retours d’expérience.

Ce modèle pourra vous être utile si un jour vous attaquez une grosse transformation agile à grande échelle. Axa n’a pas tenté de réinventer la roue mais s’est globalement inspiré de modèles existants qui fonctionnent.