Le brin d’ADN

Charles Santucci Ateliers, Facilitation 0 commentaire

Voici un petit exercice pour démarrer un atelier : le Brin d’ADN. Non, ce n’est pas un brise-glace, il n’y a rien à casser.

Il a été essayé pour la première fois début juin par une équipe d’une dizaine de personnes de la Software République, ce qui m’a permis de l’ajuster.

Nous l’utilisons en ce moment avec mon collègue Olivier à grande échelle pour une série de 50 ateliers dans notre direction. Les 10 premières sessions avec des équipes de 10 à 15 personnes ont démontré que ca fonctionnait !

Enfin, grâce à une rencontre de facilitateurs chez Formapart le 15 juin dernier, nous avons pu l’essayer avec une trentaine de personnes, pour voir ce que ca donne avec un grand groupe !

Comment ca marche ?

Il vous faut préparer des petites cartes (format A7, type carte de visite) sur lesquelles vous écrivez un morceau de la chanson « J’suis pas bien portant » de Gaston Ouvrard en « cassant les rimes ».

Première carte :
« J´ai le foie »

Deuxième carte :
« Qu´est pas droit
 J´ai le ventre »

Troisième carte :
« Qui se rentre
J´ai l´pylore »

etc… en utilisant toute la chanson si vous voulez !

Voici 4 planches A4 à imprimer pour avoir 32 cartes (sur du carton de couleur, c’est plus agréable !)

Evitez de commencer par « J’ai la rate… », cette rime est trop connue et indique plus rapidement quelle est la chanson.

Fabriquez autant de cartes que vous voulez en veillant à bien respecter un enchainement des rimes entre les cartes. A priori, avec une trentaine de personnes, ca commence à devenir un peu infernal, donc je recommande de ne pas dépasser ce nombre de participants (maximum 35 pour que ca reste faisable en un temps assez court).

Une fois que vous avez vos cartes, prélevez le nombre nécessaire selon les participants en gardant l’ordre de la chanson, puis mélangez-les avant de les distribuer, une par personne.

Le discours que vous pouvez avoir : « J’avais préparé un exercice, mais les cartes se sont mélangées dans mon sac, est-ce que vous pouvez les remettre dans l’ordre ? » ou en version moins claire : « j’ai trouvé ces cartes dans mon grenier, elles semblent avoir un sens, mais je ne sais pas lequel, vous pouvez m’aider ? » ou autre instruction encore plus absconse.

Il y a deux règles à bien faire appliquer : chacun doit garder sa carte et il est interdit d’utiliser son smartphone. Tout le reste est autorisé .

Et qu’est-ce qui s’passe alors ?

Une fois lancés, les participants peuvent s’organiser comme ils veulent. A priori, soit ils discutent tous ensemble (quand ils sont moins de 10), soit ils se scindent en petits groupes, pour finir par se rassemblent assez rapidement mais seulement dans le cas où ils sont moins d’une quinzaine !

En revanche, au-delà d’une vingtaine de participants, on observe une difficulté pour reformer toute la chanson. Dans un premier temps, tout le monde essaye de parler et trouver le sens des paroles. Certains ont compris et tentent de se faire entendre, ce qui n’est pas facile. D’autres forment des petits groupes pour essayer de comprendre à petite échelle ce qu’il y a sur les cartes. Après une période de chaos initial, ces petits groupes réussissent à créer un « brin » à 5 ou 6 et essayent ensuite de trouver avec qui se raccrocher.

La difficulté pour assembler ces brins est qu’il y a encore des « trous » dans la logique des cartes car certains sont un peu perdus et errent de groupe en groupe en essayant de trouver leur place. Par ailleurs, les groupes qui forment un « brin » essayent de se connecter aux autres en restant alignés, ce qui n’est pas simple car il faut déplacer plusieurs personnes de concert ! Et tout le monde n’est pas nécessairement très discipliné.

Bref, ca finit par fonctionner plus ou moins rapidement selon le nombre : quelques minutes en dessous de 15 personnes, et jusqu’à une vingtaine de minutes pour un groupe de 30.

Au-delà de l’aspect ludique et collectif, on peut constater qu’il est assez facile de s’auto-organiser à une douzaine, mais que ca devient plus difficile à 30 (ce n’est pas nouveau mais c’est l’occasion de le mettre en valeur !). En effet, dans ce cas, de petits groupes se forment assez facilement, mais la coordination de ces petits groupes est délicate : soit tout le monde veut coordonner, soit personne ne veut le faire. Trouver le bon rythme de travail en groupe et un moment pour se synchroniser entre groupes relève du défi alpin !

Evidemment, le groupe va reconstituer le brin complet, mais il y a plusieurs périodes de chaos qui feront facilement dire à certains : « c’est le bazar, c’est trop long, il faut un manager ou un responsable pour organiser ca … ».

Erreur fatale !
Je ne l’ai pas essayé sur cet exercice, mais vous pouvez utiliser le jeu du « noeud humain » pour le faire constater : avec un organisateur nommé qui est le seul à décider de qui fait quoi, on va moins vite et ca déresponsabilise tout le monde. Certes, il n’y a pas visiblement de chaos, mais il y a peu d’engagement et d’apprentissage de la collaboration ! Et on arrive moins vite au résultat.

Voilà ! A bientôt pour de nouvelles aventures…

Les Zanimaux ou comment démarrer votre atelier dans un zoo !

Charles Santucci Ateliers, Facilitation, Trucs 0 commentaire

Quand je démarre un atelier, j’aime bien que l’exercice (appelez-le brise-glace si vous voulez, je reviendrai dessus dans un autre article) initial soit ludique et agréable mais qu’il mette aussi les participants dans le thème qui va être traité ou au moins un de ses aspects.

D’où ca sort ?

Les Zanimaux a été conçu pour lancer un atelier dans lequel différentes directions devaient se mettre d’accord sur un mode de fonctionnement dont la construction nécessitait la collaboration de tous. L’enjeu était d’éviter que chacun pense qu’il détenait la vérité et qu’il pourrait s’en sortir sans les autres.

Comment ca fonctionne ?

Pour apporter cette compréhension aux participants, l’exercice débute en présentant le zoo, c’est à dire des images d’animaux numérotés de 1 à 24 (pas n’importe lesquelles, elles sont choisies dans un but précis)

Ensuite, chaque participant doit « piocher » une carte bleue sur le site suivant : http://animaux.ludik.ovh/cartes1. Pour piocher, il suffit de cliquer sur une des lettres, peu importe laquelle.

Demandez ensuite à chacun de « Trouver le bon animal ». Chaque carte contient une description succincte d’un animal en trois éléments. A priori, ce ne sera pas le même animal pour tous, ça dépend de leur choix de carte. Mais l’ambiguité de l’instruction est volontaire pour que chacun imagine qu’il doit trouver seul un animal.

Quand vous avez pioché une carte, il n’est pas possible d’en piocher une autre, même en rechargeant la page :-). Ceci dit, j’ai installé un petit truc pour pouvoir repiocher, mais ca ne doit pas être fourni aux participants, c’est seulement si vous en avez besoin pour lire les cartes http://animaux.ludik.ovh/reinit.

Ensuite, donnez la même instruction que précédemment – « Trouvez le bon animal ! » – mais en leur demandant de piocher une carte orange sur cette page : http://animaux.ludik.ovh/cartes2. Cette fois-ci, chaque carte ne contient qu’une seule information (il y a 6 paires de cartes, chaque paire de cartes contient la même information) et les participants doivent s’organiser pour trouver un seul animal, mais surtout ne leur dites pas ! Dans un premier temps, ils peuvent croire qu’ils doivent à nouveau trouver seul un animal.

En quelques minutes en général, ils auront collectivement trouvé le bon animal (avec ces informations : je suis gris, je vis dans la savane, j’ai des dents pointues, je suis fort, j’ai de grandes oreilles).

En ce qui concerne les règles, il n’y a aucune interdiction, ils font ce qu’ils veulent ! Donnez le minimum d’instructions et répondez aux questions quand elles sont posées, mais n’anticipez pas !

L’exercice peut aussi fonctionner sur place, en affichant les animaux au mur, et avec de vraies cartes ou en utilisant des QR Codes et les smartphones. La proximité va simplifier le partage d’informations, donc ce sera moins efficace qu’à distance, probablement.

Si vous voulez jouer en anglais, utilisez pour la première étape le lien suivant : http://animaux.ludik.ovh/cards1. Et http://animaux.ludik.ovh/cards2 pour le deuxième lien.

Morale de l’histoire ?

Il y a un petit enjeu d’auto-organisation, surtout à distance, qui est assez amusant !

La morale principale est que personne ne détient toute la vérité mais seulement une partie et qu’il faut collaborer pour réussir. Ca parait évident mais il faut régulièrement le rappeler dans les structures élaborées qui fabriquent des produits complexes utilisant de très nombreuses compétences !

Les gommettes silencieuses

Charles Santucci Ateliers, Facilitation, Trucs 2 commentaires

Dans la série des « brise-glace » ou mises en jambes, il y en a un que j’utilise souvent : les gommettes silencieuses !

Il possède quatre qualités majeures. Il est très simple, créé un moment de calme au milieu d’un atelier ou séminaire, permet de constituer des équipes si on a besoin et, pour les agilistes notamment, met en valeur un principe d’auto-organisation. Nous y reviendrons.

Voilà déjà comment il se passe.

Munissez-vous de gommettes de couleurs différentes, une pour chaque participant. Si vous cherchez à constituer des équipes, il vous faudra autant de couleurs que d’équipes souhaitées. Vous pouvez aussi jouer sur la forme des gommettes.

Faites mettre les participants en cercle (ou à peu près), chacun étant tourné vers l’extérieur, et demandez-leur de fermer les yeux (ce n’est pas totalement indispensable, mais ça créé un petit effet et ça permet qu’ils ne voient pas la couleur des gommettes).

Collez sur le front de chacun une gommette en variant les couleurs selon un ordre aléatoire (vous verrez pourquoi).

Une fois que vous avez collé toutes les gommettes, demandez-leur d’ouvrir les yeux et de retrouver ceux qui ont la même couleur de gommettes qu’eux, sans parler ni faire de grognements ou de bruits. Ils peuvent bien sûr se déplacer et faire ce qu’ils veulent, tout sauf parler ou faire du bruit ! (C’est aussi pour ca qu’il faut coller les couleurs de manière aléatoire car certains esprits vifs identifient le cycle avec lequel vous avez collé les gommettes et devinent d’un coup d’oeil qui est avec qui!)

En quelques minutes, les groupes se sont retrouvés et vous pouvez passer à la suite ou débriefer un peu.

Le principe d’auto-organisation qui est mis en valeur concerne le « servant leadership », terme à la mode et qui ne me plait qu’à moitié. Je le remplacerai simplement par le sens du service et je l’illustrerai avec cette citation de Saint-Louis : « Détenir le pouvoir, c’est d’abord servir » que certains ont adapté au management : « Manager, c’est servir ». C’est vrai mais c’est réducteur, car ce n’est pas réservé au management !

Bref, vous observez que pour reconstituer les groupes et que deux personnes se « retrouvent », il faut qu’un troisième leur indique qu’ils ont la même gommette. Ce troisième le fait de manière désintéressée, oubliant un moment sa propre préoccupation de retrouver ses propres « camarades » de groupe. Selon l’état d’esprit des participants, dont certains seront un peu sidérés et se demanderont comment faire, une partie des participants va se mettre au service des autres et refaire les groupes.

Remarquez que s’il y a trop de gens au service des autres, ça devient difficile de former les groupes. Il faut aussi savoir parfois suivre le mouvement et ne pas guider les autres car s’il y a trop de guides, on ne sait plus où on va.

Parfois, l’un de ceux qui a aidé se retrouve seul au milieu des autres alors que tout le monde a trouvé son groupe et il faut quelques secondes pour qu’il soit guidé vers son équipe.

Il doit être possible d’en tirer de nombreuses morales, mais celle-ci me convient ! Si vous en trouvez d’autres, commentez cet article !

Je précise que l’exercice n’est pas de moi. Je l’ai découvert au cours d’une formation appelée « LeaderShift », mais je ne me souviens plus de la société qui organisait les sessions :-(.

T’as pas 100 balles ?

Charles Santucci Ateliers, Formations 2 commentaires

Cet atelier a été créé en 2016 comme un défi : comment faire passer certaines notions agiles à un amphi de plus de 100 personnes ? La plupart des ateliers/jeux sont plutôt destinés à de petits groupes. J’en utilise beaucoup en formation pour une vingtaine de personnes, mais c’est rarement « scalable » comme on dit. On voit de temps en temps des témoignages sur certains ateliers menés à grande échelle, le Ball Point Game par exemple, mais mon idée était plutôt d’adapter le Penny Game que j’utilisais souvent en formation pour valoriser la collaboration, le time-boxing, les itérations et la priorisation par la valeur.

L’atelier a été utilisé pour la première fois à Agile Tour Paris 2016 comme atelier de conclusion, avec en effet une morale proche de celle du Penny Game. Je l’ai ensuite régulièrement utilisé chez Renault et il a évolué aussi bien dans son déroulé que dans sa conclusion grâce à divers feedbacks et mes propres expérimentations pour arriver à la version que voici. Ces dernières semaines, il a été joué dans un amphi de 400 personnes (donc 400 balles) chez Renault au Technocentre (c’est moi ) et 100 personnes (200 balles) chez Orange (c’est ma femme ) !
Ce fut un joyeux bazar, selon les dires de certains ! Et c’est ce qui m’amène à le partager largement, le nombre d’itérations et de feedback l’ayant fait atteindre, à mon avis, sa maturité (à vous de le faire évoluer).

Déroulement

Pour démarrer, il faut distribuer à chaque participant une ou deux balles (type balle de piscine à balle) de 4 couleurs différentes (je prends en général : violet, vert, bleu et orange) en proportions à peu près équivalentes. Il est possible (et même conseillé) d’ajouter quelques balles d’une 5ème couleur, jaune par exemple et une ou deux balles blanches, type balle en mousse ainsi qu’une ou deux balles noires d’une forme différente, en ballon de rugby par exemple (ces ajouts sont récents, liés à mon activité nouvelle à l’ingénierie qui est d’une complexité d’organisation et de produits supérieure à la DSI).

Ensuite l’animateur se place sur l’estrade (ou équivalent si c’est un amphi) ou au milieu des participants (si c’est une salle). L’enjeu est que certains participants soit tout près de l’animateur et d’autres le plus loin possible.

L’animateur place à côté de lui soit une mini-piscine d’enfant soit un carton ou équivalent qui sera la cible et le réceptacle pour les balles.

En terme de story-telling, ca commence ainsi : Le client est un enfant qui veut une piscine remplie de balles de 4 couleurs en proportions équivalentes.

Pour avoir un enfant à montrer, vous pouvez utiliser la présentation suivante ou inventer la vôtre (ou le faire sans présentation) : tas pas 100 balles (j’utilise habituellement des photos de mes enfants, mais ici je les ai remplacé par des photos neutres , ce n’est pas que je n’ai pas confiance en vous, mais Google n’est pas mon ami !)

Les règles sont les suivantes pour les participants :

  • Ils peuvent être debout ou assis (s’il y a des chaises)
  • Ils ne doivent pas se déplacer
  • Les balles doivent être lancées et non passées de la main à la main
  • Les balles tombées à terre y restent et ne sont pas ramassées

Ensuite l’animateur fait lancer les balles en séquence, couleur après couleur, chaque couleur ayant sa règle du jeu (vous pouvez essayer de tout lancer en même temps, mais j’ai peur que ce soit le fouillis et que tout le monde se mélange les pinceaux ) :

  • Première couleur, par exemple violet : les participants sont considérés comme des héros et n’ont besoin de personne. Ils lancent directement leur balle dans la cible.
  • Deuxième couleur, par exemple vert : les participants sont plus coopératifs et ils ont droit de lancer leur balle à un autre participant qui n’a pas de balle, qui lui/elle pourra lancer la balle sur la cible.
  • Troisième couleur, par exemple bleu : les participants ont deux relais et les relais peuvent avoir une autre balle dans les mains (mais une seule).
  • Quatrième couleur, par exemple orange : idem troisième couleur, mais trois relais sont possibles et les relais peuvent avoir autant de balles qu’ils veulent en même temps. Il est aussi possible que pour cette couleur, il y ait des valeurs écrites sur les balles. Alors le défi est de mettre dans la cible le maximum de valeur en 30 secondes à 2 minutes selon le nombre de balles (il faut en général 4 à 8 secondes pour amener une balle vers la cible, à moduler selon la disposition et la taille de la salle). Mais vous faites comme vous voulez !

A la fin de l’atelier, vous devriez trouver dans la cible ou piscine peu de balles violettes, une bonne partie des balles vertes, la plupart des balles bleues et globalement pas mal de balles orange, avec plus ou moins de grands chiffres (si les balles étaient numérotées)

Conclusion

La morale principale est que nous sommes bardés de mauvais réflexes ! En voici quelques exemples.

Réflexe 1
La collaboration des lancers avec relais se révèle plus efficace que l’héroïsme du premier lancer sans relais. Il vaut mieux collaborer que travailler dans son coin. Ce n’est pas nouveau, les êtres humains travaillent naturellement ensemble, mais comme ce n’est pas toujours le cas dans les entreprises. L’organisation doit favoriser la collaboration plutôt que laisser le travail en silo s’installer insidieusement.

Réflexe 2
Le culte des héros : celui qui lance à plusieurs mètres réussit, on le loue, mais celui qui rate à 1 mètre est considéré comme mauvais, sans tenir compte de leur compétence de lancer et de leur entrainement. Il est bon d’avoir quelques héros, mais miser sur leur existence et les « task forces » pour sauver tous les projets est une belle erreur.

Réflexe 3
En cas de relais, le 1er n’a qu’une opération : lancer. Chaque personne qui suit comme relais a deux opérations, recevoir et lancer, c’est donc plus difficile. Le dernier relais a aussi ces deux opérations mais le lancer est plus difficile car sa cible est fixe, mais inerte, elle ne pourra pas compenser un lancer imprécis. Les lancers sont collectifs sauf le dernier.
Même si le collaboratif doit être valorisé, cela ne doit pas non plus devenir un dogme, il y a des activités qui doivent être menées seul et d’autres dont la responsabilité restera individuelle.

Réflexe 4
Chaque partie de la salle ou amphi va trouver un processus de circulation des balles qui lui est propre. Il n’est pas toujours nécessaire d’avoir un seul processus pour la même activité quand elle est menée par différentes équipes. Avoir un seul processus pour certaines activités est profitable, mais pas nécessairement pour tous les sujets, notamment ceux qui sont pris en charge par des équipes. Vouloir rationaliser les processus et les organisations est un reste malheureux du taylorisme à tout crin.

Réflexe 5
Dans les amphis où j’ai animé ce jeu, les managers sont souvent en bas, donc au plus près de la piscine. Si les balles représentent des problèmes, on a là une simulation où tout le monde envoie tous ses problèmes en escalade au chef donc il est débordé et il ne sait pas déterminer ceux qui sont les plus importants, ou en tout cas, ca lui prend beaucoup de temps.

Réflexe 6
Par rapport aux balles orange si elles ont des valeurs : il n’est pas facile d’identifier les plus grandes valeurs s’il y a du monde dans la salle ou l’amphi, vu la pression du temps. Il faut laisser du temps aux équipes pour s’organiser un minimum, en interne et entre elles. Le chaos initial généré par une proposition d’auto-organisation est normal, il faut savoir le laisser passer et ensuite peut-être donner un coup de pouce aux équipes pour s’organiser entre elles, mais un coup de pouce, pas un coup de bâton !

Réflexe 7
Les balles jaunes, non lancées : elles représentent les compétences inutiles sur ce projets, elles n’ont pas servi, mais on les avait fait venir au cas où, vieux réflexe de ceinture, bretelles et parachute !
Il arrive aussi que ces personnes, pour ne pas se sentir désœuvrées voire soupçonnées de glandouiller, génèrent involontairement du délai en s’impliquant malgré tout dans le projet au lieu de dire : « Je ne sers à rien, donc je m’en vais voir ailleurs si mes compétences peuvent être utiles à d’autres ». La « loi des 2 pieds » ou de la mobilité bien connue des facilitateurs a de beaux jours devant elle.

Réflexe 8
Les balles blanches et noires : elles représentent les interfaces avec les équipes noires et blanches qui sont externes ou en soutien de notre équipe dans la salle ou l’amphi. Finalement comme ce sont des interfaces, les solliciter prend du temps et de l’énergie, il faut rédiger des cahiers de charges ou équivalent, on finit par ne pas les utiliser, on se débrouille en interne. L’interface a intérêt à ne pas trop fluidifier le travail sinon son job risque de disparaître, donc au lieu de faire de la liaison, elle fait de l’interfaçage où les équipes ne se parlent jamais en direct. Le travail est donc souvent fait en double. Il faut éviter ces interfaces et établir des relations d’équipe à équipe pour que la collaboration soit facile et efficace.

Réflexe 9
Balles orange : il faut donner de la valeur aux sujets si on veut motiver les équipes !

Réflexe 10
Le bouc émissaire : dans une chaîne, si un des lanceurs échoue, il sera pris comme bouc émissaire et les autres maillons de la chaîne, plutôt que de l’aider ou de trouver comment améliorer leur chaine, le désigneront comme responsable de l’échec.

Réflexe 11
La pression est mise sur une petite partie des participants, ceux qui sont près de la cible, qui ont beaucoup plus de boulot que les autres !
Du genre : « Ma stratégie est parfaite, c’est votre exécution, vous les petits, qui est nulle ! » Là encore un reste peu glorieux du taylorisme et de la séparation cols blancs/bleus.
On peut y voir aussi la notion « d’armée mexicaine » si vous voulez : un qui bosse, quinze qui donnent des ordres, pardon qui « managent » !

Et vous en trouverez certainement pleins d’autres ! Amusez-vous bien.

Cet article, les images et les documents associés sont publiés sous licence Creative Commons ShareAlike CC BY-SA

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

Atelier Rugby

Charles Santucci Ateliers, Facilitation 0 commentaire

[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 ?

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.