Brève histoire de l’Agile chez Renault

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 ….

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

Atelier Rugby

[Fort accent du sud-ouest] Bonjour, moi c’est Jean-Pierre, dit « Pépé ». Je vais vous expliquer l’atelier Rugby que j’ai construit et facilité avec Thierry pour une équipe de développeurs.

Objectif

L’atelier a été construit pour une équipe/communauté (appelée chapitre dans leur DSI) de développeurs. Le responsable de ce chapitre voulait à la fois créer une cohésion d’équipe (qui venait de se créer) et lancer les premières actions de la communauté. Chaque membre de ce chapitre étant affecté à une équipe produit et disposant de quelques heures à consacrer à des activités communautaires.

L’idée du rugby convenait au côté équipe incluant le capitaine (le responsable du chapitre), contenait un esprit collectif de bon aloi et me permettait de retravailler un atelier rugby, construit quelques mois auparavant et qui s’était révélé très perfectible.

L’atelier a été découpé en deux parties : la première avec les membres internes du chapitre (une dizaine de personnes) puis une deuxième partie avec les membres externes (prestataires) du chapitre. Ces deux parties ont eu lieu à une semaine d’intervalle.

Matériel

Les ballons

Les ballons sont le support de base de l’atelier. Ils sont fabriqués avec cette image de PixelMeetup : (https://www.flaticon.com/free-icon/rugby_902998)

Mettez en deux par feuille A4 puis imprimez et découpez (Il y a un peu de travail, si vous avez des enfants en maternelle ou en primaire, exploitez-les sans état d’âme !). Evidemment, c’est le dos du ballon qu’on utilise. Vous pouvez bien sûr utiliser ce que vous voulez comme ballon et comme format, il faut juste faire attention entre la taille du terrain et celle du ballon, sinon, les ballons débordent !

Pour écrire

Je me suis équipé d’une batterie de feutres Neuland pour pouvoir varier les couleurs et que les mots soient lisibles sur un ballon.

Les feuilles de passe

Pour la deuxième étape, il faut des feuilles de passe selon le modèle ci-dessous :

On colle le ballon (avec du scotch ou des gommettes ou de la patafix, bien entendu, c’est vous qui voyez!) en haut. La partie « détails » sert pour l’étape « Passe à trois » et la partie « Essai » en bas pour les parties « Essais » et « Transformation »

Le terrain

C’est le point crucial, car ce sera le support du livrable final (chose fondamentale que j’ai retenue de ma formation à la facilitation – merci Jean-Philippe Poupart @ FormaPart – le livrable final de l’atelier doit être directement exploitable sans nécessiter de reprise de la part du facilitateur, du commanditaire ou d’un participant).

Il ressemble à ca :

Il s’agit d’un demi-terrain, avec en bas, la ligne médiane, au dessus, la ligne des 22 mètres qui coupe en 2 le dessin à peu près. Puis en haut, la ligne d’en-but et les poteaux.

J’ai utilisé 4 grands post-it (63cm*76cm) pour en former un géant. Le tout était posé sur un tableau équipé d’aimants. Cela s’est avéré très pratique pour poser facilement les ballons et feuilles de passe sur le terrain. Sinon, bien sûr, avec du scotch tout est possible :-).

Etapes

La mêlée

C’est une étape classique de créativité où chacun écrit sur les ballons toutes les idées (une idée par ballon en très peu de mots) qui lui passe par la tête et les positionne dans le terrain de mêlée (entre la ligne médiane et la ligne des 22 mètres) en expliquant à haute voix aux autres ce qu’il vient d’écrire.

Les passes à trois

Cette deuxième étape consiste à regrouper les participants par 3 (ou 2 si nombre indivisible par 3). Surtout pas plus sinon, ca ralentira le rythme. Chaque équipe prend un ballon et une feuille de passe, colle le ballon en haut, et le « travaille », c’est à dire étudie l’idée et tente de la détailler dans la partie « Détails ». Chaque équipe peut dans le temps imparti « travailler » autant de ballon qu’elle le souhaite, mais un seul à la fois.

Une fois la feuille remplie, elle est déposée sur le terrain dans la partie « Passe à trois » dans les 22 mètres (entre la ligne des 22 mètres et la ligne d’en-but).

Les essais

Une fois le temps des essais venu, les feuilles de passe sont lues par tous puis prises les unes après les autres pour savoir qui veut marquer l' »essai ». L’enjeu est qu’un maximum de feuilles soient choisies. Celui qui marque l’essai écrit son nom dans la partie « Essai » de la feuille. Les feuilles avec « essai » étaient ensuite remontées en haut du terrain au-dessus de la ligne d’en-but.

C’est à cette étape que s’arrête la première partie de l’atelier. La deuxième partie a été faite en plus grand groupe : on passe de 10 à 40 personnes environ.

La transformation

Cette étape avait été précédée d’un IceBreaker et d’une version simplifiée du jeu Birde-Birdie qui avait permis de faire connaissance et de créer un état d’esprit détendu et ludique.

Pour cette étape, on s’est librement inspiré du World Café en créant un stand pour chaque membre du groupe de la première partie qui avait choisi des feuilles de passe (donc marqué des « essais »); ces participants devenant de fait des hôtes « engagés » de leur stand. Les feuilles non choisies ont été mises en trois groupes, les participants de la première partie n’ayant pas marqué d' »essai » devenant des hôtes « neutres » chargés d’expliquer les feuilles de passe de leur stand.

Les nouveaux participants étaient invités à faire le tour des différents stands avec un rythme le plus régulier possible afin d’avoir vu tous les stand en 30 à 40 minutes.

L’objectif de cette étape était pour les hôtes « engagés » de monter une équipe pour travailler le sujet choisi à plusieurs et pour les hôtes « neutres » de trouver qui voulait éventuellement marquer l’essai en s’inscrivant sur la feuille, constituant de fait une équipe de travail sur le sujet.

Une fois les feuilles complétées, chaque équipe devait ensuite choisir une date et heure de premier RDV pour commencer à travailler le sujet choisi. Cette date était reportée sur la feuille.

Bien sûr, si un nouveau participant le souhaitait, il pouvait ajouter un ballon et une feuille de passe et s’improviser hôte « engagé » pour monter une équipe de travail. Ou simplement marquer un « essai » en prenant une feuille de passe existante et aussi devenir hôte « engagé ».

Ainsi, après cette étape, le terrain se trouve complété des feuilles de passe avec les noms des équipiers et la date de leur 1er RDV. Ce qui permettra par la suite un suivi visuel de l’avancement, les éléments existants sur le terrain pouvant ensuite être utilisés dans les mêmes modalités que l’atelier en version simplifiée.

Découpage et durée

La première partie de l’atelier (donc avec un groupe d’une dizaine de personnes) avait ce déroulé pour une durée de 2h construits comme un match, l’échauffement étant un icebreaker :

Oui, il manque 5 minutes, c’est pour absorber les aléas et ralentissements.

La deuxième partie avec le World Café (et 40 personnes en plus) a durée 1 heure, le temps d’expliquer le fonctionnement à tous et bien faire tourner tout le monde sur les stands.

Photos

Voici quelques photos de l’atelier.

Au démarrage
 
Après une mêlée, les passes à trois sont en cours Après deux mêlées et deux passes à trois
Les essais sont marqués Essais transformés

Bonus

Cet atelier a été reproduit en version simplifiée pour le présenter à une rencontre de facilitateurs inter-entreprises chez Décathlon (merci à tous les participants).

[Fin du fort accent du sud-ouest]

Conclusion

La plupart des ateliers de facilitation que j’avais construit jusqu’à maintenant cherchait après une étape de divergence à converger vers une idée et à la travailler. Or, dans cet atelier, la convergence réside non pas dans les idées, mais dans les participants qui doivent s’impliquer sur les sujets/activités pour marquer des « essais » et les transformer.

Il faut donc bien prendre l’atelier comme un exemple et pas nécessairement le reproduire à l’identique. Mais comme visiblement il peut inspirer d’autres constructions d’ateliers, je suis heureux d’avoir pu le partager.

Petit détail : l’animation a été faite en prenant l’accent du sud-ouest pendant toute la durée de l’atelier. Pour une fois que je tombais sur une équipe qui ne me connaissait pas, j’en ai profité. Evidemment, cela aide un peu à mettre dans l’ambiance. Un peu de décoration rugby peut aussi être de bon aloi !

N’hésitez pas à commenter si vous avez des questions ou à utiliser le formulaire de contact du site pour avoir plus d’infos.

La transformation digitale, quezaco ?

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 ?

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.

risus id, Nullam tristique felis efficitur. elit.