Je ne prétendrai pas raconter toute l’histoire de l’agile chez Renault si on considère que l’agile peut avoir existé avant le manifeste sous différentes formes et pas seulement celles du Lean. L’idée de faire passer le client en premier et de s’organiser en fonction de cet objectif n’est pas nouveau dans les entreprises, on le retrouve même dans les propos de deux PDG de Renault, Pierre Lefaucheux (PDG de 1945 à 1955) : « Nous avons le contrôleur le plus efficace, il s’appelle le client. C’est lui qui juge de la qualité de nos véhicules, de leur prix, de leur aptitude à le satisfaire » et Georges Besse (PDG de 1985 à 1986) : “ Notre métier est tout simplement de gagner de l’argent en vendant des voitures de qualité et qui plaisent à nos clients”.
Est-ce à dire qu’on a été agile chez Renault avant ces dernières années ? Oui, sûrement ! L’histoire de la première Twingo, racontée dans le livre de Christophe Midler L’auto qui n’existait pas , fait inévitablement sourire l’agiliste qui reconnait dans ce projet des années 90 des pratiques et des postures que les coachs agiles recommandent régulièrement aux équipes en ce moment.
En fait, cette brève histoire dont je parle dans le titre, c’est la mienne. A l’heure où Renault lance un programme de transformation de grande envergure impliquant entre autres les principes agiles, je constate que depuis 10 ans, le sujet n’a fait que grandir en suivant mes pas ou l’inverse ! Je ne prétends pas être à l’origine de la transformation agile de Renault, loin de là, j’ai juste contribué à ce que le sujet existe un peu plus et je vais vous raconter cette histoire, ma petite histoire de l’agile chez Renault.
Un service (25 personnes)
Tout commence en 2008, quand les responsables du service de développement rapide de la DSI, Gaston et Sylvain, se proposent d’utiliser l’agile et en particulier le cadre SCRUM pour la trentaine de projets menés par les équipes chaque année. La méthode en place dans les équipes est itérative et rigoureuse, permettant une bonne qualité et des délais de livraison corrects pour les utilisateurs, mais le turn-over interne et la diversité des clients du service obligent à ré-expliquer systématiquement la méthode et tous ses arcanes. Adopter le SCRUM permettra d’avoir une « méthode » connue, simple à expliquer et pour laquelle il est plus facile de trouver en prestation des personnes déjà formées.
Ceci créé tout de même une petite révolution, notamment par l’utilisation des rôles de Product Owner et de Scrum Master, qui font disparaître les rôles de chef de projet et de Maitre d’Ouvrage. Attention, ceci reste local et ne concerne que quelques personnes sur les mille collaborateurs de la DSI. Et je fais partie de celles-là ! A partir de 2009, je fais partie d’équipes SCRUM qui écrivent des User Stories, font des sprints et des démos. Je découvre pourquoi je n’étais pas très à l’aise avec le job de chef de projet et constate que le rôle de Scrum Master me va comme un gant. Ce n’est pas le cas de tout le monde et quelques-uns quittent le service pour d’autres aventures.
Après quelques essais sur des projets précis, une fois que tout le monde a été formé, les équipes projets (2 à 5 personnes par équipe) adoptent systématiquement SCRUM et quelques adaptations (SCRUM-Buts ! ) locales qui permettent de faire fonctionner l’équipe dans le cadre global de la DSI !
L’activité du service s’étant aussi installée en Inde, dans le centre informatique de l’Alliance, il faut aussi imaginer comment s’organiser avec des équipes moitié en France, moitié en Inde ! A cette occasion et parce que la simple idée de mettre un backlog dans Excel me révulse, je me mets à développer Kados, un outil de gestion de backlog web (avec des postits virtuels) qui nous permettra de mieux travailler entre la France et l’Inde. Soutenu et testé par l’équipe, cet outil s’améliore pour finir par être adopté par tous les membres du service en France ou en Inde. L’ayant réalisé le soir et les week-ends, j’en garde la propriété et c’est ce qui permet d’en faire un logiciel libre en 2012 (https://kados.info).
Un programme (150 personnes)
En 2014, je quitte l’équipe de développement rapide pour un programme centré sur la relation client, notamment appuyé sur le progiciel SalesForce. Certaines équipes, inspirées aussi par le SCRUM ou l’itératif avaient mis en place des mécaniques plus ou moins agiles et l’un des managers avait besoin de mon aide pour y voir plus clair. Afin de n’être pas tout seul, je récupère Laure, Scrum Master, formée elle aussi dans le service de développement rapide et à nous deux, nous nous attaquons à ce programme de plus d’une centaine de personnes, réparties en 6 à 8 équipes selon les moments et en interaction avec de nombreuses autres. Pour commencer, et afin de mettre tout le monde au même niveau de compréhension de l’agile, nous fabriquons une formation fin 2014, formation qui existe encore aujourd’hui (sous une forme évoluée, bien entendue, rétrospectives obligent !).
Cette formation et la mise en place d’une mécanique de releases synchronisées régulières 6 fois par an contribuent à l’appropriation d’une bonne partie des principes agiles, chaque équipe étant libre de s’organiser selon ses règles tant qu’elle respecte les points de synchronisation. Plus tard, un coach agile externe nous expliquera que l’on a fait du Safe sans le savoir. Avec le recul, je suis bien content de ne pas avoir fait du Safe, mais plutôt du spécifique adapté aux contraintes et aspirations des équipes.
Pendant l’année 2015, nous essayons, Laure et moi, d’aider les équipes de ce programme à entretenir leur efficacité et installer l’amélioration continue autant que possible pour que la mécanique ne se grippe pas. Parallèlement, notre formation, grâce au soutien appuyé de Denis, responsable des formations informatiques, devient une formation référencée et proposée à toute la DSI.
Nous avions pris les devants, car le DSI et son comité commençaient par ailleurs à s’intéresser à l’Agile, qui est vu comme un moyen d’améliorer le time to market des différentes applications développées par la direction. Fin 2015, dans le cadre du plan de transformation régulier de la DSI (qui faisait un peu d’agile sans le savoir donc !), un chantier agile est lancé parmi la dizaine de chantiers de transformation portant sur l’ensemble des activités et capacités de la DSI.
Thierry, en charge de ce chantier, me recrute assez vite, la direction n’étant pas très dotée en agiliste (certains, notamment les précurseurs, étant partis vers d’autres horizons en interne).
La DSI (900 personnes)
Début 2016, me voilà dans l’équipe de transformation de la DSI en charge du déploiement agile pour la direction. Ca a l’air pompeux dit comme ça, mais c’est assez modeste, car nous ne serons principalement que trois pour oeuvrer, Thierry, Laure (qui s’est rapatriée dans notre équipe) et moi. Pendant quelques mois, nous aurons l’aide précieuse et les conseils de Christophe, Romain et Issame d’Octo Technologies pour améliorer notre modèle et nos pratiques.
L’idée majeure est de propager l’esprit agile, notamment via les formations et des essais proposés à quelques équipes de développement (nos chers « early adopters »). En parallèle, une équipe Devops cherchera à améliorer les outils techniques, les méthodes et les relations entre Devs et Ops !
Le DSI de l’époque, Philippe, apporte un soutien efficace à l’équipe de transformation et c’est nécessaire car les équipes sont bloquées par quelques verrous internes majeurs : avoir accès à des serveurs de développement prend quelques semaines et à des serveurs de production, parfois quelques mois; les capacités du cloud sont peu utilisées; l’accès à des compétences externes expérimentés en agile est soumis aux contrats de prestation existants qui à leur création ne comportaient pas cette exigence; un dogme ancien contraint les équipes à ne livrer à leurs utilisateurs qu’une fois par an au mieux; le métier du développeur est peu valorisé et quelques autres du même genre.
Il faudra toute l’année 2016 pour faire sauter ces verrous, le plus rapide à faire disparaître étant le dogme de la livraison annuelle. Une simple discussion avec l’équipe supposée entretenir ce dogme (« euh, non, c’est pas nous on pensait que c’étaient les autres… ») amène à le faire disparaître quasi du jour au lendemain, ce qui a permis à une trentaine d’équipe en 2016 d’adopter des rythmes de livraison plus courts (2 à 4 mois) tenant compte de leurs capacités de développement, de la capacité d’absorption des nouveautés par les utilisateurs et des enjeux métiers de ces mêmes utilisateurs.
L’amélioration de l’accès à l’infrastructure est elle aussi assez rapide car il s’avère qu’un dossier permettant une infra « capacitaire » est en attente de validation depuis pas mal d’années ! La cohésion de l’équipe de transformation (Infra, Agile et DevOps) et la volonté du DSI de changer les choses fera rapidement débloquer le sujet.
Mais la réussite dont je suis le plus fier, c’est la mise en place de contrats de prestation dit « agiles » car elle a nécessité la collaboration d’une petite équipe regroupant achats, gestion de contrats informatique, transformation et expertise agile, chacune de ces 4 compétences étant représentée dans notre équipe de sourcing agile (épaulée par quelques experts du sujet).
C’est la plus longue des étapes de transformation que j’ai vécue à cette époque car il a fallu 6 mois pour aboutir à un contrat cadre de quelques pages passé avec 6 sociétés capables de fournir en moins de 4 semaines une équipe agile ou un complément d’équipe (à une équipe interne), compétente sur les technologies majeures utilisées par la DSI.
Cela n’a pas été sans quelques difficultés, mais grâce au soutien de la responsable des relations fournisseurs informatique (merci Sandra !), notre équipe de sourcing agile (Nicolas, Thierry, Jean-Yves et moi) avons pu fin 2016 contribuer à simplifier l’accès à des compétences techniques et agiles répondant aux attentes des domaines de la DSI.
C’est à cette période (début 2017) que Renault créé une nouvelle filiale, baptisée Renault Digital, pour accompagner la transformation digitale du Groupe Renault. Cette organisation doit être digitale et agile « native » et est construite (de manière assez surprenante) en collaboration avec un cabinet de conseil en stratégie (et non en nouvelles technologies et digital, comme on aurait pu l’imaginer). L’idée n’est pas pour les consultants de rester en place, mais d’aider au démarrage. En effet, au bout de quelques mois, les consultants laissent la place à des salariés Renault Digital et les équipes s’étoffent pour prendre en charge des projets Web, Mobiles, Big Data, etc…
La création de cette filiale a, à mon sens, contribué à mettre en avant certains enjeux digitaux, souligné l’importance pour Renault de s’intéresser à ses données, voire ses « Big Data » et valorisé le développement informatique : la reconnaissance du métier de développeur, l’utilité de l’UX et de l’UI design, et (pour ma pomme), l’intérêt du DevOps et de l’agilité, notamment en recrutant un certain nombre de Scrum Masters et de coachs Agile !
En revanche, le fait que ce soit une filiale, sa faible intégration initiale avec la DSI et sa création par des consultants externes parfois déconnectés des réalités ont installés des relations compliquées et ambigües entre Renault Digital et la DSI, voire l’ensemble de Renault.
Ayant pu recruter quelques coachs agiles par ailleurs à la DSI, je découvre le travail en équipe d’agilistes à 5, là où nous n’étions que deux auparavant (Laure m’ayant accompagné dans l’équipe transformation DSI avant d’être recrutée par … Renault Digital peu après sa création!). Le programme de transformation est un peu en stand-by, notamment pour tenir compte de la création de Renault Digital (devenu RD dans le langage courant) et mettre en place les relations entre les deux entités.
J’entre en contact avec les premiers agilistes installés chez RD et rencontre les premiers nouveaux coachs. La cohabitation est plutôt intéressante (ce n’est pas toujours simple, mais la confrontation a du bon), chacun étant sur un périmètre différent : d’une part, notre petite équipe à la DSI, qui continue à aider les équipes de l’informatique à s’améliorer avec l’aide des PMO complétée de l’équipe de transformation encore en place et d’autre part, chez RD, une équipe plus nombreuse et qui s’étoffe régulièrement pour aider les équipes RD et Renault lancés sur de nouveaux projets digitaux à fort enjeu.
Au bout de quelques mois, une réorganisation de la DSI se produit et effet secondaire, les deux équipes d’agilistes dont je viens de parler sont regroupées en un pôle agile comme on en voit dans pas mal d’entreprises, chacun restant dans sa structure d’origine. Ainsi tous les Scrum Masters et Coachs Agiles du Groupe sont virtuellement rassemblés dans la même entité. Ce pôle s’organise pour faire face à sa mission pour la DSI et RD, mais commence aussi à envisager sa contribution à la diffusion des pratiques agiles au-delà de l’informatique.
En effet depuis plusieurs mois, je constate que l’agile intéresse d’autres secteurs de l’entreprise et que les participants aux formations agiles que j’anime régulièrement viennent de tous les horizons : achats, RH, Ingénierie, Logistique, etc… On entend d’ailleurs par-ci par-là, parler de transformation agile pour Renault.
Le projet de nouvelle transformation de la DSI se révélant incompatible avec ma vision, je me dis qu’il est temps de changer et j’effectue un saut vers le cœur de la conception des véhicules Renault : l’ingénierie au Technocentre ! Bien que le programme de transformation agile ne soit pas tout à fait lancé, certaines directions n’ont pas attendu pour imaginer leur transformation et l’adaptation de leurs méthodes de travail afin de relever les nouveaux défis de la construction automobile. L’agilité étant un élément de cet élan de transformation, je n’ai pas de mal à trouver une direction toute prête à m’accueillir pour de nouvelles aventures !
L’entreprise (des milliers de personnes)
Et quel défi pour un agiliste ! Défi de devoir comprendre comment aider les équipes de conception des véhicules à s’améliorer en utilisant entres autres les valeurs et principes de l’agile ! Se contenter de mettre en place du Scrum ou les pratiques qui ont eu un certain succès auprès d’équipes de développement informatique n’est pas une option honnête ! Non, il faut a priori faire preuve d’observation, d’humilité, d’imagination, de pédagogie, d’inventivité et de compréhension !
Et je reprends à mon compte le slogan de la première Twingo dont je parlais en début d’article : « A vous d’inventer la vie qui va avec ! »
Mais cette étape, c’est une autre histoire ! A suivre donc …
Pour illustrer mon article, voici un sketch-note, excellemment réalisé par Manon Baëlen à l’occasion d’un Retour d’Expérience sur mes 10 d’Agile chez Renault que j’ai fait récemment à mes collègues de RCI Bank. Vous pouvez le diffuser, mais, s’il vous plaît, ne dénaturez pas son travail (et mes propos) et renvoyez vers le dessin complet si vous en utilisez un extrait. Et merci à l’équipe agile de la CARMA de GRDF qui m’a donné l’idée de cet article à l’occasion d’un safari/échange entre nos deux entités.
