J’ai découvert le travail d’Alexis Monville lors d’une conférence Agile Tour à Bordeaux en 2011. Il y animait le fameux “Jeu des billes rouges” de Deming. J’avais beaucoup aimé son animation (son interprétation m’avait beaucoup fait rire) dans ce jeu qui rend visible le système absurde auquel on soumet nos équipes.
J’ai depuis suivi de loin son parcours remarquable et son engagement pour le monde du logiciel libre et l’agilité. Alexis fait ainsi partie de cette communauté internationale qui parcours les sept continents pour porter la bonne parole des petits lots, cycles courts et équipe auto-organisées. Venant du monde de l’industrie et de la production automobile, Alexis a très tôt été formé au Lean et a conservé ce regard très perçant sur la dynamique opérationnelle des équipes.
Son ouvrage “Changing Your Team From The Inside“, qu’il vient de publier, est à son image : simple, clair, engagé et humble. Le style est particulièrement sobre (on pense à Jason Fried) et il y fait de très nombreuses références à la littérature managériale et/ou comportementale. Comme il le reconnaît dans un des chapitres, une idée exprimée par une personne n’a pas le même poids que si elle est exprimée par la Harvard Business Review. Les grincheux pourront y voir un étalage de culture, je préfère y voir une volonté de partage de découvertes et d’idées qui lui ont permis d’avancer dans ces recherches.
Il y a deux points spécifiques que j’ai beaucoup apprécié dans cet essai. Le premier est qu’il démarre par un recentrage sur soi car le changement démarre par soi-même, comme le dit le vieil et noble adage. C’est une belle idée qui nous invite à l’introspection et nous rappelle que nous devons sans cesse nous questionner. Car la collaboration commence par une réflexion sur soi, sa posture et une grande lucidité sur sa propre contribution à la dynamique collaborative. Il est très facile de se laisser emporter par un ou deux succès et penser que ça y est nous maîtrisons le sujet. Cette lecture m’a fait le plus grand bien, d’autant que cela résonnait avec un article admirable de Christian Ignace qui identifie l’hubris comme un des périls majeurs du coach. Le livre est ensuite structuré autour de ronds concentriques, partant de soi vers ses collaborateurs, ce que l’on veut réussir pour finir avec l’équipe de dirigeants. Un parti pris de rédaction superbement fluide, qui donne un écho singulier au livre.
Le second point est que chacun des chapitres se conclut sur un petit exercice qu’Alexis nous invite à faire. Alexis est un maître de la facilitation et il connaît toutes les ficelles psychologiques et comportementales pour restaurer et entretenir une bonne dynamique collaborative. Ces exercices sont d’excellentes mises en pratique de l’ouvrage.
Deux points cependant me gênent un peu. Le premier est, comme bien souvent dans ce genre d’essais, le caractère un peu générique des grands principes et valeurs. On retrouve ces grands principes dans biens des ouvrages : il ne s’agit bien souvent que de déclarations d’intentions, peu suivies d’actes et cela en dilue leur richesse. Ma conviction est que le vrai sujet de l’appropriation de l’agilité relève moins de l’ouverture intellectuelle pour en accepter les principes que de la rigueur et de la discipline nécessaires pour l’incarner au quotidien. L’approche inductive du lean me semble bien plus riche d’enseignements : on étudie une situation spécifique dans le détail pour en déconstruire la mécanique théorique.
Le second est que, là encore comme bien souvent, ce livre parle beaucoup d’apprentissage mais reste à un niveau implicite et un peu superficiel, sans en expliquer précisément la mécanique. Ainsi on ne répond pas à la question selon moi la plus importante de la société de la connaissance, que seule la littérature lean traite de front : comment cette personne sait-elle qu’elle a appris ? Cette dimension spécifique me manque très souvent dans la littérature managériale classique et me fait bien souvent tomber les livres des mains.
Mais ce n’est pas le cas ici. Pour les raisons citées plus haut mais aussi parce qu’Alexis est une belle personne dont je sais qu’il “walk the talk” depuis une vingtaine d’années : il pratique au quotidien ce qu’il prêche. Il ne s’agit pas là d’un ouvrage d’un consultant qui fait la synthèse d’autres ouvrages sur une thématique avant de passer à une autre – un travail nécessaire mais qui m’intéresse peu. Le savoir apporté ici est de première main. Alexis met cela en perspective avec une connaissance managériale étoffée et une belle éthique du travail, ce qui rend la lecture de ce livre enrichissante.
Il a eu la gentillesse de m’allouer du temps pour parler de son livre que j’ai pu récupérer lors de son intervention à l’Agile Day de Sopra Steria, journée, soit dit en passant, organisée de main de maître par mon collègue, l’impeccable Antoine Lancesseur.
Une entretien fleuve passionnant, comme #hypertextual les affectionne [compter 15 minutes de lecture]
o o o
Tu as un parcours assez particulier. Tu as commencé ta carrière dans le monde de l’industrie automobile. Dans quelle mesure avoir exercé dans cette industrie contribue à la singularité de ton regard au sein de la communauté agile ?
C’est une bonne question. Il y a deux grandes raisons. Dans cette industrie, j’ai été exposé très tôt à la nécessité de vraiment comprendre ce qu’était la maîtrise des procédés. J’y ai découvert deux styles de management radicalement différents, en oeuvre au sein de la même entreprise.
J’ai démarré ma carrière d’ingénieurs en 1991. Un contexte charnière au nieau de la théorie managériale : Takeushi et Nonaka avaient publié l’article sur le New New Product Development Game en 86 dans la Harvard Business Review et Womack, Jones et Roos ont publié The Machine That Changed the World en 90. L’occident s’interrogeait sur le miracle japonais et leurs méthodes pour produire des produits avec un tel niveau de qualité. D’où cette étude du HBR (Takeushi et Nonaka) et l’étude du MIT (Womack, Jones). Ce qui est amusant est que tout a démarré parce que Edward Deming a formé les entreprise Japonaises à l’approche statistique de maîtrise de procédés, le SPC.
C’est dur a comprendre quand on est un jeune ingénieur. On ne comprend pas pourquoi on arrête la ligne de production quand il y a 7 pièces au dessus de la moyenne tant cela semble négligeable et largement au dessus du niveau de qualité attendu. Les plus anciens voyaient là que je n’avais pas compris la maîtrise des procédés. Nous fabriquions des ABS pour la première auto à avoir proposé le système en série, la Ford Mondéo. Nous étions dans un autre mode que la chaîne de production standard : cabine extra propre, légère surpression, formation aux outils et aux procédés, on mesure tout. Un environnement de production moderne. Cela change ta façon de voir les choses. Nous avions une traçabilité produit et procédé complète. J’avais rejoint l’équipe pour mettre en route le système informatique gérant la traçabilité. L’informatique en deuxième compétence était très utile. Cela a changé mon approche du management. On a été parmi les premier à mettre en place le Six Sigma et le créateur de la démarche est venu nous former.
La production de Drancy a été déplacée dans une usine à Moulins qui était spécialisée dans les maître-cylindre les servo-freins, des pièces de toute autre nature. Les modes de management n’y étaient pas du tout les mêmes. A Drancy je me suis senti très vite à l’aise avec mon manager qui était quelqu’un qui m’a laissé beaucoup d’autonomie. J’en étais presque inquiet et je lui posais des questions. Un jour il m’a répondu qu’il me fallait apprendre à ne plus poser toutes ces questions. Que j’allais faire des erreurs et que j’allais apprendre. Je devais comprendre de façon autonome comment tout marche en m’appuyant sur les autres collaborateurs plutôt que demander au chef. Cela a été très formateur.
A l’usine de Moulins en revanche, tout était très hiérarchique, très Command & Control. Notre centre de production ABS était comme une bulle à part. On voyait bien les deux différents modes de management juxtaposés dans cette usine. Cela a changé mon regard et j’ai compris combien les modes de management étaient importants et l’impact qu’ils pouvaient avoir en termes d’autonomie de confiance, etc.
Le jeune ingénieur qui m’a remplacé m’a demandé si je me rendais compte que je perdais au moins une heure trente par jour à faire le tour pour dire bonjour : l’équipe du matin, l’équipe du soir et une ou deux fois par semaine l’équipe de nuit. Mais pour moi c’était un moyen de connaître tout le monde, de savoir comment ils allaient. Avoir ce contact quotidien me tenait informé en direct sans avoir le filtre des managers de proximité. Comme ils savaient que je passais il me posaient leur questions ce qui me faisaient apprendre de nombreuses choses sur l’opérationnel. Et cela était surtout moins intimidant quand je faisais le speech hebdo devant 150 ou 200 personnes car je connaissais les gens, c’était plus facile.
Lorsque je suis retourné dans l’informatique, co-fondant une entreprise du Web en 1995, cela m’a permis de voir que l’on avait des tas de processus mais qu’on ne comprenait pas grand chose à ce qu’il se passait. A l’époque, dans cette industrie, on fait beaucoup de choses à l’arrache. On ne contrôle pas la qualité, on ne teste pas, on en sait pas ce qu’il se passe vraiment. Les personnes te parlent d’utilisation CPU, d’utilisation mémoire et ils ne comprennent pas les causes de ces problèmes. Ils n’ont pas l’habitude qu’on leur pose des questions de cette nature : pourquoi avons nous ce problème, que s’est-il passé, quelle est la cause, quel est le standard ? Bien souvent, ils n’ont pas de données. Dans l’industrie face à ce type de problèmes techniques, on avait l’habitude d’investiguer grâce aux infos dont on disposait. J’arrivais dans un environnement dans lequel on ne savait rien.
(Alexis présentant son livre à Agile Tour Grenoble 2019)
Ton ouvrage propose une perspective assez surprenante et très pertinente : le travail en équipe commence par un travail sur soi. Pourquoi penses-tu qu’il est essentiel de démarrer par ce travail introspectif ?
La question que l’on peut se poser est : est-ce qu’on peut changer les gens ? Intuitivement, les gens à qui on pose cette question on tendance à répondre non. Mais si tu leur donnes des éléments ils peuvent évoluer dans cette perspective Un exemple que j’aime bien utiliser pour leur montrer est de sourire. Une façon de faire sourire les gens c’est de leur sourire. Et hop, vous avez changé le comportement et l’attitude de la personne. C’est un exemple simple mais qui donne quelques éléments.
Il est nécessaire de se changer soi pour prendre conscience de ce que l’on génère par notre propre comportement. Un exemple dans le contexte du travail : faire confiance aux gens et leur donner l’information. Si mon comportement sous-tend que je ne vous fais pas confiance et que je vais vous dire ce que vous devez faire, cela n’induit pas du tout le même comportement. En tant que manager, membre d’équipe, c’est pour cela que c’est important. Les valeurs et principes de l’agilité sont simples mais cela génère des changements radicaux. Et ce n’est pas si facilement à mettre en oeuvre. Typiquement j’aime beaucoup le douzième principe mais qu’est-ce que cela veut vraiment dire ? Que cela signifie vraiment de remettre en cause notre mode de travail ? Est-on vraiment prêt à le faire ? Dans quelle mesure cela nous touche, nous intrigue. Cela peut sembler simple mais ce n’est pas évident.
Que cela signifie vraiment de remettre en cause notre mode de travail ? Est-on vraiment prêt à le faire ? Dans quelle mesure cela nous touche, nous intrigue. Cela peut sembler simple mais ce n’est pas évident.
Comment expliques-tu la très grande popularité de l’agilité dans les entreprises aujourd’hui alors qu’il y a 10 d’années, lorsque nous nous sommes rencontrés, ces mêmes organisations jugeaient cela inapplicables et non pertinent ? Que s’est-il passé selon toi pour obtenir un tel revirement de perspective ?
Oui c’est quand même assez fascinant. Si on retrace l’histoire : en 2001 il y a le manifeste. La première décennie, on voit des gens intéressés par la théorie mais frileux sur la pratique. Ils sont parfois intéressés en raison de fausses promesses telle que celle de Sutherland de livrer deux fois plus en deux fois moins de temps. Des gens vont aller vers l’agile à cause de ces promesses. Le mot agile sonnait bien dans ce contexte avec plus d’incertitudes, la capacité de faire plus de choses qui vont plus vite. “Ah ouais, on doit être agile », ca sonne bien. On voit cela comme plus de flexibilité et d’adaptabilité. Mais est-ce vraiment le même genre d’adaptation ? A un moment donné cela a eu l’air évident qu’il fallait faire de l’agile. Mais quel genre? Les modes de mise en oeuvre que l’on voit aujourd’hui sont-ils si agiles ? Je me questionne.
À ce sujet dans ton livre on retrouve très peu de références directes à l’agilité et je ne suis même pas sûr que tu emploies le terme. Il s’agit d’un partie pris rédactionnel important. Quelles raisons expliquent cette absence très visible pour le coup ?
Il me semble que j’évoque le Manifeste. Je ne parle pas des méthodes car dans l’environnement où j’évolue, j’ai introduit beaucoup de collaboration. Beaucoup de personnes ne voulaient pas faire de l’agile, ce n’était pas possible. J’en ai fait sans dire que j’en faisait. J’appliquais des pratiques de XP, de Crystal, de Scrum sans faire référence au framework méthodologique que j’utilisais. J’utilisais des choses qui étaient utiles sur le moment. Le but n’est pas de faire de l’agile mais d’avoir une équipe qui fonctionne bien, une équipe capable de livrer ce qui est important pour ses utilisateurs et ses clients. Que les gens soient satisfaits par ce qu’ils font : voilà le but. L’agile en tant que tel n’est pas le but mais le moyen. Mais ta question m’intrigue, il va falloir que je regarde à nouveau dans le livre (rires).
Tu proposes toujours des principes basés sur la proximité, et une vision organisée autour de l’équipe. Quel regard portes-tu sur le très gros succès aujourd’hui de SAFe et de cette déclinaison complexe et organisationnelle de l’entreprise agile ?
C’est quelque chose qui m’intrigue et me fait un peu peur. Quand j’ai travaillé avec différents clients, à différentes échelles, souvent les dirigeants me demandaient quelle était la cible organisationnelle. Je refusais de répondre car lorsqu’on lance une telle démarche, on construit quelque chose qui correspond aux personnes qui sont là, pour les clients et l’entreprise et son contexte business. L’organisation ne sera pas figée car on va la faire évoluer avec le temps. Cela les frustrait et ils me disaient “Tu dis ça pour me vendre la démarche mais tu sais bien où tu veux nous amener”. Je leur dessinait alors une cible qui correspondait aux principes mais pas nécessairement ce qu’on allait avoir.
Avec SAFe on a une cible, qui se simplifie tout de même avec les versions – et où finalement avec la V5 le client a enfin trouvé sa place [voir cette hilarante discussion Twitter lancée par John Cutler à ce sujet]. Avec SAFe j’ai le sentiment qu’on se fiche un peu de savoir d’où part l’entreprise. Quelque soient les organisations où j’ai travaillé, elles avaient une organisation propre, qui était la leur, on partait d’un point différent, on n’était pas au même point. L’endroit d’où on part a son importance pour décrire la trajectoire. Et surtout, avec SAFe la destination est la même pour tous et cela m’impressionne car j’ai toujours eu des équipes qui avançaient a un rythme différent et je n’étais pas sûr qu’elles avait besoin d’un standard.
Ce que j’ai besoin de comprendre quand j’accompagne une équipe est comment fonctionne son temps de synchronisation. On voit où on est par rapport à l’objectif, les obstacles, ce qu’on doit faire ensemble pour les supprimer etc … Si je suis avec une équipe colocalisée, le moyen de synchronisation c’est se parler, avec un management visuel. Cela ressemble très fort à un Daily Scrum. Si je suis une équipe distribuée sur 15 Time Zones, ce moyen de synchro ne va pas fonctionner. Je pense à cette équipe qui avait 2 meetings pour passer les infos à toutes les équipes. D’autres ont un fichier partagé pour se synchroniser, fichier texte qu’ils partagent. Si cela leur convient, ça me convient, et la façon dont ils le font m’importe peu. Du coup il n’y a pas de standard ni de destination identique pour tous. SAFe m’épate car je n’ai jamais éprouvé le besoin d’un tel niveau de standardisation.
Ce que j’ai besoin de comprendre quand j’accompagne une équipe est comment fonctionne son temps de synchronisation (…) et son temps de focalisation.
Ton livre est un excellent guide pour développer une meilleure collaboration au sein de l’équipe. Que réponds-tu aux personnes qui reprochent aux agilistes de ne voir l’opérationnel qu’au travers le prisme de l’équipe en oubliant parfois le client ?
Cela m’inquiète car cela veut dire que ce sont des équipes qui ne respectent pas les principes du manifeste agile. J’ai du mal à comprendre qu’on ne puisse pas s’organiser avec le client. Si on fait de l’agilité on ne peut pas oublier le client, c’est un point central. J’aime beaucoup utiliser l’Impact Mapping. On identifie des personas et on réfléchit à l’impact des fonctionnalités sur les personas. On est alors obligé de penser aux clients, celui qui paye et celui qui l’utilise. C’est intéressant de distinguer ces personas pour comprendre les critères de succès de notre projet et c’est central pour ce que l’on va faire. J’ai du mal à voir comment on peut oublier le client, si je ne connais pas le client, je ne peux pas travailler. Ca m’amuse car cela me fait penser à un des piliers du succès de l’Open Source. Les développeurs des premiers logiciels Open Source en étaient les premiers utilisateurs. Ces logiciels ont eu du succès car ce sont les utilisateurs qui les ont créés. Cela permet de rendre la boucle la plus immédiate possible. Chaque fois que tu t’éloignes de cette connaissance du client, tu fais des choses qui vont frustrer le client.
Que penses-tu des approches de collaboration asynchrone pour les équipes distribuées qui travaille beaucoup par écrit et moins en présentiel (exemple de start-up telles que Basecamp ou WordPress) ? Es-tu parvenu à mettre en oeuvre ces pratiques avec ce type d’équipes qui ne sont pas co-localisées ?
En fait c’est vraiment top. Je l’évoquais avec le temps de synchro. Quand on est une équipe distribuée, on doit faire des choix pour se synchroniser. Choix qui passent par l’écrit et c’est une vraie bonne chose. Et puis tu as ces temps de focalisation durant lesquels tu ne peux ne pas être interrompu [Ce que Jason Fried appelle être “In The Zone”]. J’ai des équipes qui le font par tranches horaires ou journées entières, ils font tous comme ils veulent. Il sont super productifs et satisfaits car non interrompus. A l’inverse quand vous n’avez pas cet espace de temps protégé, vous faites des tas de choses mais vous ne pouvez pas avancer. C’est très frustrant, vous vous épuisez en courant d’un sujet à l‘autre. Il faut pouvoir se dire : cette prochaine heure j’enlève les interruptions. Les équipes distribuées ont plus de facilité à collaborer grâce à cet espace là. Si on est dans la même pièce il faut s’équiper d’écouteurs avec notre musique, il faudrait presque des oeillères pour ne pas se laisser distraire, il est très difficile de se concentrer. Ayant ces espaces de focalisation, il est paradoxalement plus facile et plus fructueux de collaborer à distance.
Le deuxième point est lié à l’écrit. Quand tu essayes d’écrire ce que tu as à l’esprit, tu te rends vite compte de la faiblesse de ton idée. Alors que quand tu expliques ton idée en Sprint Planning, tu répètes inlassablement la même chose avec davantage l’objectif de convaincre que d’apporter de la valeur au produit. L’idée est moins préparée et donc claire et tout le monde va faire un effort pour comprendre.
Quand tu essayes d’écrire ce que tu as à l’esprit, tu te rends vite compte de la faiblesse de ton idée. Alors que quand tu expliques ton idée en Sprint Planning, tu répètes inlassablement la même chose avec davantage l’objectif de convaincre que d’apporter de la valeur au produit.
Aussi, lorsqu’on demande aux personnes de structurer leurs idées à l’écrit, cela permet d’élaborer des idées plus intéressantes, au travers de documents partagés, mieux formalisées et la qualité des échanges est plus riche. On peut alors échanger pour enrichir ces idées, c’est plus facile. On comprend mieux, le niveau d’échange est de meilleure qualité à partir de cette formalisation écrite. Bien évidemment, les discussions informelles sur un chat ne comptent pas dans cette formalisation. [On retrouve cette idée forte de l’importance de la qualité de l’écrit dans la collaboration à distance dans The Year Without Pants de Scott Berkun – Scott explique sa stratégie de scribe pour montrer à l’équipe qu’il apportait de la valeur en tant que manager avec ce travail de capitalisation et de formalisation]
Dans les organisations dans lesquelles on met en place l’agilité et donc les valeurs « équipe » et « communauté » les managers ont parfois du mal à se situer et trouver leur rôle. Comment les accompagnes-tu à ce sujet ?
Ce que j’aime faire lorsque j’accompagne les managers est leur montrer à quel point ils sont utiles pour créer les conditions de la collaboration, qui font que nous sommes une équipe et pas simplement une collection d’individus. Parfois les managers pensent que leur rôle est de distribuer le travail et de s’assurer qu’il a été fait. Mais en faisant ainsi on n’a toujours pas d’équipe et on perd le sens de l’initiative. Je caricature un peu bien sûr mais les faire passer du mode où on distribue le travail à celui où on crée les conditions de la collaboration est essentiel pour que les collaborateurs puissent transmettre du savoir, améliorer la façon de travailler, aider l’équipe à améliorer sa façon de travailler. Cela se rapproche des notions de Servant Leadership ou de Stewardship.
Il y a d’autres éléments essentiels tels que vraiment comprendre le business et l’éco-système, les partenaires, les concurrents, comment on gagne de l’argent, où est la valeur client dans notre produit et nos services. Ceci pour pouvoir aligner les objectifs de l’équipe dans cette vision, avec ce contexte. On fournit alors le contexte pour comprendre l’objectif et faire comprendre à chacun comment il ou elle peut mieux contribuer a cet objectif.
Le manager doit vraiment comprendre le business et l’éco-système, les partenaires, les concurrents, comment on gagne de l’argent, où est la valeur client dans notre produit et nos services. Ceci pour pouvoir aligner les objectifs de l’équipe dans cette vision, avec ce contexte.
Le troisième point évident est de développer les personnes avec le coaching et le mentoring croisé dans l’équipe avec d’autres personnes. Il y a une très grosse part de social learning.
Tu parles aussi beaucoup de la nécessité de créer les conditions de l’auto-organisation. Je partage tout à fait ce point là. Si je suis manager, je commence par quoi lundi pour commencer à créer ces conditions ?
En identifiant les freins à la collaboration et à l’auto-organisation. Si je suis dans la caricature de tout à l’heure où c’est moi qui prend la charge d’avoir le flux de travail et d’information, où tout passe par moi et où je le filtre et le distille, il me faut alors prendre conscience et me demander comment faire autrement pour ne pas être sur le chemin critique. Il me faut donc me poser cette question : qu’est-ce qui passe par moi et pas par moi ?
Pour illustrer : nous avons créé une adresse e-mail pour l’équipe avec une équipe de Product Managers. Avant cela, tout passait par le responsable de l’équipe qui était saturé – ce qui n’est pas surprenant. La consigne donnée au responsable a été de dire à ses interlocuteurs de ne plus lui écrire sur sa boîte mail personnelle mais à l’équipe. Bien évidemment, au début, tout le monde continuait de lui écrire. Il rappelait alors la nouvelle consigne en mettant en copie l’adresse mail de l’équipe. L’équipe a ensuite mis en place un Dispatcher (rôle tournant) qui répondait ou identifiait qui pouvait répondre. Cela a eu deux effets de bord. Tout d’abord, le manager n’était plus débordé. Ensuite, les membres de l’équipe ont eu l’opportunité de mieux comprendre la nature des demandes et ont étendu un peu leur domaine de connaissance et cela a complété leur spécialisation. En étant Dispatcher chacun leur tour ils ont appris des choses sur d’autre aspects du produit ce qui a permis de faire grandir toute l’équipe de façon organique.
Tu évoques dans le livre la notion de Growth Mindset de Carol Dweck. Comment fais-tu pour recruter des personnes ayant cet état d’esprit ? Quelle nature de questions leur poses-tu pour identifier cette prédisposition ?
Cela se voit relativement facilement. On le voit parce qu’il y a des gens qui aiment bien apprendre et des gens qui aiment bien savoir. Ce n’est pas du tout la même dynamique. Les questions qu’ils te posent eux vont te donner des indications. Si cela les intéresse d’apprendre plein de choses, ils sont aussi prêts à te dire ce qu’ils ne savent pas. Les personnes avec un Fixed Mindset : te montre les preuves de leur réussite dans le passé, ils ne s’aventurent pas trop sur le terrain du futur où ils pourraient se retrouver dans une situation où ils ne savent pas. C’est assez amusant de voir la différence entre les deux. Il faut les laisser parler.
Il y a des gens qui aiment bien apprendre et des gens qui aiment bien savoir. Ce n’est pas du tout la même dynamique. Les questions qu’ils te posent eux vont te donner des indications. Si cela les intéresse d’apprendre plein de choses, ils sont aussi prêts à te dire ce qu’ils ne savent pas.
Cependant il y a une chose à laquelle je crois : on peut développer leur Growth Mindset en valorisant l’apprentissage qu’ils ont fait, pour qu’ils soient à l’aise. Des cultures d’organisation le favorisent plus facilement que d’autres. J’essaye de m’attacher à faire attention à ne pas favoriser l’inverse (le savoir plutôt que l’apprentissage), ce qui est malheureusement assez facile.
Tu insistes dans un chapitre entier sur l’utilité des jeux pour mieux construire l’équipe : partager la vision, construire les rôles, rendre visible les obstacles etc … Que t’inspire l’attaque frontale de Julia de Funes et Nicolas Bouzou dans La Comédie Inhumaine(ouvrage de management qui a eu un vrai succès l’an dernier) sur ces approches qu’ils trouvent infantilisantes et inappropriées pour le monde de l’entreprise?
Je trouve les jeux très intéressants lorsque l’on comprend tous pourquoi on joue. Si on est tous d’accord qu’on doit voir les choses qu’on doit apprendre. Et pour les apprendre, il faut être exposé à des situations, dans un contexte sécurisé. Si on est d’accord qu’on peut utiliser le jeu pour simuler l’exposition à cette situation pour voir comment on réagit et comment on pourrait agir autrement alors les jeux sont parfaitement applicables. Ce n’est pas infantilisant dans ce contexte car cela nous permet de voir qu’il y a des choses qui sont difficiles à apprendre. Le jeu est un bon cadre de simulation pour apprendre quelque chose sur nous en tant qu’individus mais aussi et surtout en tant qu’équipe.
J’apprécie aussi les jeux courts qui permettent de couper la journée pour faire autre chose. On veut ramener 10 personnes ensemble pour créer un moment de convivialité. Des petits jeux qui sont des energizers. On va prendre 5, 10 ou 15 minutes pour avoir cette activité ensemble, pour faire cette coupure. J’aime bien les jeux plutôt drôles. Je ne vais pas choisir de choses qui nous infantilisent.
J’imagine qu’on peut arriver à des jeux dans de grandes organisations et avec de nombreuses personnes qui pourraient amener a ce côté infantilisant. L’implémentation doit se faire au service de l’équipe, au moment ou elle doit apprendre quelque chose. On peut jouer mille fois à lego for scrum et ce sera toujours différent.
Tu accompagnes depuis plusieurs années l’équipe dirigeant l’engineering de Red Hat en tant que coach et facilitateur. Basé sur cette expérience, tu proposes dans ton livre d’utiliser une approche similaire à celle du développement de la collaboration des équipes pour développer les conditions de la collaboration au sein d’une équipe de dirigeants. Quelles sont pour toi les différences notables entre les deux exercices et les points de vigilance particuliers dans ce dernier cas ?
Le premier point délicat : une équipe de direction n’est généralement pas une équipe. Ce sont juste des gens qui reportent au CEO ou au dirigeant d’une des Business Unit. Ce n’est pas une équipe car ils ne travaillent pas ensemble. Par endroit ils peuvent même être en compétition. Par exemple pour le Budget, ou pour être le successeur du boss. Certains dirigeants sont très forts pour exciter cette compétition. Si on veut passer de “gens qui reportent à un chef” à “une équipe”, c’est le rôle du dirigeant de l’expliquer. Deuxième question : quelle est leur équipe ? Très souvent ils vont répondre celle qu’ils dirigent eux. Et bien non : ton équipe c’est l’équipe de direction. Pour passer de l’un à l’autre cela prend du temps, des efforts et pas mal de discussions pour certaines personnes qui ont du mal à l’accepter. Ce que cela va générer : ils ne sont pas responsable de l’équipe qu’ils dirigent mais de l’ensemble de l’organisation, en tant qu’équipe dirigeante. Quand on arrive à ça, ces cadres ne vont plus se battre pour avoir le budget mais pour le réallouer là ou c’est vraiment important. Cela génère aussi une bien meilleure collaboration de l’ensemble de l’organisation, car les collaborateurs qui sont dans leurs équipes ont alors le droit de collaborer. Car la tension au niveau de dirigeants se retrouve obligatoirement dans les équipes. Et c’est la même chose pour une bonne collaboration
Tu as fait de nombreuses conférences autour de l’entreprise libérée il y a 4 ou 5 ans. J’ai été étonné de voir que tu y faisais que très peu référence dans ton ouvrage. Comment l’expliques-tu ?
Pour moi l’entreprise libérée c’est l’auto organisation à tous les niveaux. Des collaborateurs qui comprennent le business, l’industrie, leur client, l’éco-système, les partenaires les compétiteurs [on retrouve ici la notion de smart creatives chère à Eric Schmidt et à Google]. Pour être dans l’entreprise libérée, il faut s’intéresser à tout cela pour être en mesure d’identifier des opportunités. Pour moi cela me semble tellement évident que c’est peut être sous-jacent et implicite dans le livre. Ce n’est donc pas intentionnel de ne pas le mentionner.
Si on fait de l’agilité et qu’on ne parle pas du client ou si on a un framework rigide qui ne bouge plus fait-on encore de l’agile ?
Après le formidable succès de l’agilité qui est mis en oeuvre dans un grand nombre d’organisations, le retour de bâton est inévitable. En effet, de nombreuses implémentation n’apportent pas les résultats attendus (bien souvent pour des raisons évidentes de manque de constance aux quotidien aux valeurs et principes) et on commence à parler de « l’après-agile ». Quel sera-t-il selon toi ?
C’est un sujet intéressant. Il y a l’avant manifeste (avant 2001) : on se pose la question sur les méthodes qui ne fonctionnent pas et des gens essayent de développer des méthodes légères, ils commencent à voir les points communs et écrivent le manifeste. On a ensuite fabriqué des produits et des services pour vendre l’agilité. Toutes ces promesses ne sont pas vraiment tenues. Si on fait de l’agilité et qu’on ne parle pas du client ou si on a un framework rigide qui ne bouge plus fait-on encore de l’agile ?
De nombreuses personnes ont réalisé que leur implémentation n’étaient pas sur les valeurs et principes. S’il y a un après-agile, peut-être sera-ce alors de revenir aux sources : être ouvert, avoir un objectif clair et partagé, avoir ce sentiment d’appartenir à un équipe ou une communauté, ce qui nous amène ensuite par extension sur cette idée d’ouverture, à tous les domaines [on retrouve ici l’idée de Clean Agile : Back to Basics le nouvel ouvrage de “Uncle” Bob Martin]. On a pas mal de chance de le voir arriver surtout si on y contribue. Ce serait dommage de se dire que c’est mort, les valeurs et les principes sont toujours là. Peut-être faut-il changer d’approche. On sait comment il ne faut pas faire essayons d’autres chose !
Quels sont tes prochains projets ?
Je vais annoncer pour Mai 2020 la sortie d’un nouveau livre co-écrit avec Michael Doyle, “I am a Software Engineer and I am in Charge: The book that helps increase your impact and satisfaction at work.”
Inscrivez-vous pour être les premiers à en savoir plus: https://iamincharge.club/
Merci Alexis !
Suivez ce lien pour les autres conférences données par Alexis : https://alexis.monville.com/en/speaking/
#hypertextual 
2 Comments