Réflexions

Brève histoire de l’Agile chez Renault

Charles Santucci Réflexions , 2 commentaires

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.

Merci de ….

Charles Santucci Langage et expressions, Réflexions 2 commentaires

N’avez-vous pas déjà lu, au détour d’un courriel, l’expression « Merci de bien vouloir faire ceci ou cela … » ?
C’est agaçant, n’est-ce pas ? Avez-vous trouvé cela normal ou avez-vous eu l’impression d’être pris(e) pour une marionnette ?

Dans le premier cas, mon propos vous paraîtra peut-être excessif, mais lisez-le quand même ! Dans le dernier cas, vous avez bien raison, j’ai le même ressenti à chaque fois que je lis cette expression.

Et que répondre à une telle injonction ? Je dirai tout simplement … « Non » !

Pourquoi ?

Pour la simple raison que sous couvert d’être aimable et d’utiliser une formule de politesse, cette manière de demander de réaliser une action est tout sauf polie et cohérente avec une relation de travail équilibrée .

A votre avis, d’où peut venir cette affreuse manière de demander les choses ?

Certainement de la simplification des échanges apportés par le « tout courriel », maladie courante des entreprises contemporaines où tout se traite par un courriel et non un échange réel.
La première dégradation consistait à glisser un « Merci d’avance » suite à une demande polie contenant une formule type « s’il vous plaît/s’il te plaît », puis finalement pourquoi s’embêter à demander gentiment, autant transformer le « Merci » en injonction et enlever le « s’il vous plaît/s’il te plaît ».

Or, ces mots « s’il vous plaît/s’il te plaît » (que l’on tente d’apprendre aux enfants, comme c’est étrange) contiennent le cœur de l’équilibre d’une relation, puisqu’ils laissent le choix au récepteur de la demande de faire ou de ne pas faire, et d’en discuter.
Et dans les cours de philosophie de Terminale, il me semble que le choix était au cœur d’un sujet longuement débattu en classe de philosophie mais aussi partout dans le monde : la liberté !

Ensuite, je ne me rappelle pas avoir entendu cette expression dans le langage parlé; elle reste donc l’apanage de l’écrit et en particulier du courriel, support aussi chaleureux qu’efficace pour discuter avec ses collègues. Dans les nombreux courriels de prises de contact que j’ai reçus, cette formule n’apparaît jamais, preuve que pour construire une relation il est de plus élégantes expressions.

Enfin, en tant que coach agile, je considère cette expression en contradiction avec une des valeurs de l’Agile que je défends : « Individus et interactions ». Elle instaure une distanciation et une hiérarchie très déplaisante et n’incite pas à la collaboration.

Alors, s’il vous plaît, pour demander à un collègue de vous aider, n’utilisez plus cette expression et préférez un coup de fil, un échange autour d’un café ou quelque tournure élégante et poétique dans un courriel !

L’image d’illustration est de Dooder / Freepik

La transformation digitale, quezaco ?

Charles Santucci Réflexions 1 commentaire

Le « DIGITAL » ! Impossible d’ouvrir le moindre journal ou de lire le moindre article sur internet sans qu’au détour d’une phrase, le mot fatal apparaisse ! Avec, bien entendu, aucune explication sur ce qu’il signifie.
Le plus amusant (ou déprimant, c’est selon l’humeur), c’est quand il est associé au mot « transformation », on atteint alors le comble du sublime poussé au paroxysme de l’intemporel (merci Elie Kakou, grand visionnaire des choses étranges)

Réfléchissons deux secondes au sens des mots. Faut-il y voir une transformation de nos doigts ? Il est vrai que les jeux vidéos puis les smartphones ont fait apparaître de surprenantes maladies des pouces, mais est-ce là la signification de « Transformation digitale », tant aimé des patrons contemporains, trouvant là un souffle épique équivalent à la révolution industrielle du 19ème siècle ?

Soyons sérieux deux minutes (deux, pas plus), le digital, anglicisme qui désigne les activités numériques, liées à l’apparition des smartphones puis des smartphones tactiles et en particulier des smartphones tactiles capacitifs (genre généralisé par Apple avec l’Iphone, valorisant les doigts qui courent sur une surface vitrée réactive, comme dans un film de science-fiction), le digital donc a tellement modifié la relation entre les individus et les entreprises, qu’on imagine qu’il lui faut sa transformation.

En réalité, la transformation digitale est la transformation que doivent opérer les entreprises pour s’adapter à un nouveau monde qui les prend un peu de cours, elles qui pensaient que ca ne concernaient que les entreprises telecoms et informatiques se rendent compte qu’un développeur à l’autre bout de la planète peut depuis son garage démarrer une activité qui menace la leur ou qui la menacera un jour prochain.

Face à cette prise de conscience, les entreprises, constatent que « tout va plus vite », sauf bien sûr les battements du coeur, la vitesse de rotation de la planète, le rythme des marées, la fabrication du miel dans une ruche et autres phénomènes qui ont méprisé l’accélération du digital, ce qui les rend un peu suspects aux yeux de certains.

Devant ce constat, il est temps d’agir et les entreprises utilisent l’arme absolue : augmenter la productivité ! Laquelle productivité a déjà bien été poussée dans ses derniers retranchements ces dernières années puisqu’en l’absence de transformation épique, il fallait bien occuper le management des entreprises à quelque chose.

Hélas, augmenter la productivité, c’est à dire, pressurer un peu plus les organisations et les gens est vite apparu difficile, car déjà fait, voire dangereux, l’épuisement étant proche.

Heureusement pour les entreprises, le graal a vite été trouvé : puisqu’on ne peut pas pousser les gens, changeons la méthode. C’est vrai, cela faisait longtemps qu’on n’avait pas changé la méthode. Que nous disent donc les consultants hors de prix que l’on paie très cher à nous dire des choses qu’on sait déjà et que disent aussi quelques hurluberlus dans nos équipes ? La méthode Agile, bien sûr !

C’est beau, c’est chic, c’est moderne ! Parfait, soyons agile, ca au moins c’est concret, il y a des références (un manifeste pondu par 17 geeks il y a plus de 10 ans, des guides, des méthodes, des outils, tout plein de consultants compétents,…), on peut déployer ! Les gens n’ont qu’à apprendre cette nouvelle recette de cuisine et tout reprendra sa place et continuera comme avant. Ouf, on a eu chaud !

On cherche donc les spécialistes du sujet : des coachs agiles, cela s’appelle, parait-il. On les débauche, on se les arrache ! Dingue! La dernière fois qu’on s’est arraché des spécialistes de la méthode, c’était… euh, attendez-donc, laissez-moi réfléchir, euh, en fait, jamais !

Mais que nous disent-ils ces coachs ? Que l’agilité n’est pas une méthode, mais un état d’esprit, qu’on en résout pas tout en déployant, qu’il faut se poser de multiples questions sur les compétences, les équipes, la motivation, la collaboration, le management 3.0, l’autonomie, l’auto-organisation, le servant leadership, le leadership, j’en passe et des meilleures !

Mon dieu, qu’avons nous fait ? Horreur et putréfaction !

Oui, il faut bien se rendre à l’évidence, la transformation digitale, c’est surtout une REVOLUTION !

Pourquoi l’agilité est-elle aussi difficile à expliquer ?

Charles Santucci Réflexions 0 commentaire

Dans mon travail de coach, je constate souvent qu’expliquer le manifeste agile est assez facile, mais qu’après, on se heurte à beaucoup d’incompréhensions et que l’agilité n’est pas perçue comme un état d’esprit, mais comme une recette de cuisine.

Je ne veux pas présenter l’agilité ou les méthodes qui s’en inspirent comme des recettes de cuisine, mais force est de constater que c’est souvent comme cela qu’elles ont utilisées. J’essaie donc souvent de trouver un compromis en présentant l’agilité comme une mécanique efficace de gestion de risques.

Et là, étonnement, ca fait flop ! Mais pourquoi donc ?

Parce que la gestion de risques a été oubliée. Les organisations en général et les managers en particulier pensent que la gestion des risques d’un projet consiste à nommer un chef de projet qui s’occupera de tout et garantira que le triptyque QCD (Qualité, Coût, Délai) est tenu ou que le fournisseur le tiendra.

C’est juste oublier que le cœur de la gestion de projet, c’est l’évaluation des risques et la gestion des problèmes et que tout cela amène à des décisions soit par le chef de projet, soit par sa hiérarchie ou ses clients pour continuer à progresser vers ce que doit produire le projet.

A force de se focaliser sur sa gestion et non sur le projet lui-même, les organisations ont oublié que les projets avaient un objectif et que l’intelligence utilisée pour gérer le projet résidait dans le réajustement des moyens pour atteindre cet objectif. La continuation d’un projet signifiant que l’objectif était accessible avec les moyens disponibles et qu’il était rentable. L’arrêt du projet signifiant que l’objectif était inaccessible avec des moyens raisonnables même augmentés, et qu’il n’était plus rentable.

Le projet était devenu non le moyen d’atteindre un objectif, mais l’objectif lui-même. Or, l’agilité remet l’objectif au centre de l’activité : réaliser un produit pour des utilisateurs. Et propose d’autres moyens de pilotage pour l’atteinte de cet objectif.

C’est pour cela qu’elle déstabilise les organisations, car celles-ci s’étaient habituées à voir les projets comme une fin, et non comme un moyen. Comme l’agilité change assez fondamentalement la notion de projet, les organisations sont perdues et leur hiérarchie aussi. Ainsi les gens qui gardaient à l’esprit que l’enjeu était l’objectif du projet et non le projet lui-même sont plus à l’aise que ceux qui s’occupaient de gérer le projet, mais les premiers sont peu nombreux, car les organisations ont favorisés et récompensés les seconds.

L’agilité, quand elle se déploie réellement, est la revanche des gens cohérents avec leur métier et fidèles à leurs compétences plutôt qu’à leur plan de carrière et à leur hiérarchie.