Bienvenue dans l’ère du management inductif

1. Introduction

Le billet de ce jour est la combinaison de trois choses : mes notes de lectures sur le livre de Richard Sheridan « Joy, Inc : How We Built a Workplace People Love », une réflexion sur l’importance croissante du raisonnement inductif dans nos entreprises – que je soulignerai avec des références au livre « Les mots et les choses de l’entreprise » de Luc de Brabandere – et quelques réflexions dans la suite des billets précédents sur l’Entreprise 3.0 et le management de l’émergence.

J’ai consacré la conclusion de ma keynote au XEBICON 2015 au livre de Sheridan parce que je pense que c’est un des livres les plus importants de ces dernières années pour tous ceux qui managent des organisations ou équipes de développement logiciel. L’ensemble de la démonstration que j’ai essayé de faire – autour de la conviction partagée que « software is eating the world » conduit au besoin de revisiter profondément la façon de construire le logiciel, d’une part, ainsi que la culture et le management de ces organisations, d’autre part.

J’ai écrit de nombreux billets sur première partie sous l’ombrelle de la lean software factory. Le billet de ce jour est consacré à la seconde partie – culture & management -, en m’appuyant sur le livre de Sheridan et son retour d’expérience sur l’implémentation de l’Extreme Programming.

2. Manager c’est créer les conditions de la réussite de l’équipe

Le livre « Joy, Inc : How We Built a Workplace People Love » est un retour d’expérience (notez le passé dans « built ») sur la mise en place de l’extreme programming dans une entreprise de développement logiciel, Menlo. La « joie » dont parle Richard Sheridan est celle de construire des choses qui servent : « Joy is designing and building something that actually sees the light of day and is enjoyably used and widely adopted by the people for whom it was intended”. Cette citation qui fait écho aux propos de Ash Maurya dans “Runing Lean”: “Life is too short to build something that nobody wants”. La joie vient du plaisir de faire quelque chose d’utile, mais également de la fierté de le faire bien, comme l’explique Daniel Pink. Richard Sheridan cite également Deming : “All anyone asks for is a chance to work with pride”.  L’intérêt principal est d’être un récit détaillé, étape par étape, avec les joies et les peines, de la mise en œuvre d’une autre façon de travailler. L’exercice que je vais faire – relever quelques idées et citations clés qui résonnent avec les thèmes de ce blog – ne rend pas justice à la profondeur du livre. Je vous recommande sa lecture plus que chaleureusement.

1. Ce livre relate la mise en place d’un mode de développement agile « pour de vrai », depuis les rituels jusqu’au changement de culture, de valeurs et de reconnaissance. Je ne vais pas détailler – il faut lire le livre – mais on retrouve les rituels habituels, sur lesquels Sheridan insiste : « We have replaced rules, bureaucracy, and hierarchy with predictable rituals, ceremonies, and storytelling events ». Les lecteurs pratiquant le SCRUM retrouveront leur vocabulaire et usages courants, avec des sprints de deux semaines : « We were working in two-week cycles at the time, and every two weeks we would report our status in a fairly well-orchestrated event we came to call “Show & Tell.””.  J’ai aussi relevé sans surprise la pratique des stand-up meetings “In place of unproductive weekly status report meetings, we’ve instituted a daily standup ritual ». Le livre décrit également une pratique que nous avons commencée  à la Digital Agency d’ AXA avec beaucoup d’intérêt, le partage de connaissance sous formes de « présentation-déjeuners ». Ces échanges sont complètement informels et bien évidemment sur des sujets que chacun choisit de présenter – « Our Lunch ’n Learns have also become community affairs”.  Ce que je ne saurai pas résumer en quelques mots, c’est le l’intégration de ces pratiques et rituels dans une culture d’entreprise.  
      
2. La mise en place de l’Extreme Programming est une tâche difficile, une véritable transformation de l’entreprise qui s’accompagne de résistance. C’est bien sûr ce qui rend le livre si intéressant : « The experiment was fine for a week of training, but the implications of Extreme Programming as an everyday work style were more transformational than they were ready for”. Le fonctionnement agile en général, et le pair-programming de XP en particulier, demandent un vrai effort d’adoption et une discipline pour acquérir les « automatismes », c’est-à-dire la pratique continue. Sheridan insiste sur la rigueur, la joie ne s’obtient pas sans discipline : « Rigor and discipline are hard, and it’s always easy to say, “Tomorrow I will do better.” Tomorrow never comes—it is the actions we take today that make all the difference. If you can get your entire team into a disciplined routine of applying a rigorous approach you all believe in, and the effects become noticeable, morale soars even if the rigor is difficult.” En revanche, et c’est quelque chose que j’ai déjà observé personnellement, lorsque l’ensemble des pratiques est en place de façon rigoureuse on obtient à la fois le plaisir du travail bien fait et une amélioration sensible de la qualité du logiciel produit. Je cite : « The effect on quality is unparalleled. This rigor ensures that silly human mistakes are caught automatically without having to remember all the little things that can go wrong”.  
     
3. Ce livre donne une vision précise et très intéressante sur les outils et méthodes, et en particulier sur l’importance du design. Il contient de multiples exemples et anecdote, fidèle à l’idée que le « story-telling » est le premier outil de communication. L’importance du design n’est pas une surprise, c’est une constante chez toutes les entreprises qui ont du succès dans le monde numérique, à commencer par Apple : « Whatever you do for a living, design plays a role. A restaurant should have a great menu and customer experience”.  Menlo s’appuie sur le design thinking, et on retrouve dans le livre les différentes étapes d’observation, de formulation, de prototypage, de mise en réaction. Une grande importance est donnée à la réalisation rapide de prototypes simples qui permettent d’obtenir des premières réactions : « These paper-based, hand-drawn, user experience design prototypes are then tested against real-world users ». Tout cela s’exécute avec une véritable obsession de l’utilisateur et un travail approfondi sur les persona. Sheridan est un partisan du choix d’une persona, avec laquelle on cherche une grande intimité : « This is the most difficult question of all, not because there is a right answer, but because the answer is “Pick one.” At all costs, we must avoid letting our clients fall into the trap of not picking a persona”. Une des raisons est d’éviter l’abus de features, un des défauts classiques de l’innovation digitale, je vous renvoie au billet précédent. Citons plutôt Sheridan qui est très explicite : « In many projects, one of the deadliest challenge is scope creep. The easiest way to describe scope creep is that it’s the infamous addition of “It’s just one more little thing”, often brought up in the hallway conversation by people who don’t have to do the work”.  
      
4. Puisque l’approche de Richard Sheridan s’inscrit dans le design thinking, il a introduit le concept de High-Tech Antropology. L’idée fondamentale derrière ce terme est l’importance de l’observation : « Anthropology is the link. We need to study people in their native environment to figure out how to bring them utility and joy”; “We believe anthropology must be applied to software design”. Tout comme Steve Jobs, Richard Sheridan explique abondamment qu’il ne faut pas demander au client ce qu’il veut, mais l’observer. L’observer avant l’introduction de toute innovation pour comprendre les problèmes, l’observer face aux prototypes, puis aux produits, pour construire des innovations utiles de façon itérative. « High-Tech Anthropology starts with understanding the people who are going to use the software we are creating”; “And you can’t invite users into your office and ask them what they want, because they don’t actually know what they want”. La qualité principale des HTA, auxquels Sheridan attribue une grande partie du succès de Menlo, est l’observation, dont de nombreux spécialistes de l’innovation s’accordent à dire qu’il s’agit de la condition nécessaire par excellence. Voici le profil robot qu’il propose: “Great observation skills;  The ability to sit quietly at times;  A “make mistakes faster” attitude;  User interface design skills;  Ability to draw with crayons and markers;  Ability to use Post-it notes”.  
      
5. La culture de Menlo est selon Richard Sheridan, « both fun and driven ». Cette tension entre le plaisir est l’effort est une marque de fabrique des environnements efficace pour l’innovation numérique. Je l’avais déjà mentionné en résumant quelques idées clés de Koudetat. La recherche de la « joie de la satisfaction client » n’est pas un long fleuve tranquille : « At Menlo, we have fun, we laugh a lot, and there is almost always palpable energy—but we aren’t always happy. We have a shared belief system. We are focused and driven.” On retrouve ici cette importance de la discipline évoquée plus haut. L’atmosphère d’entreprise libérée qui se dégage de Menlo n’est pas détendue, elle est professionnelle, avec un haut niveau d’exigence adaptée à la compétition mondiale dans laquelle nous sommes tous engagés. Cette notion de « focus » et de discipline professionnelle s’accompagne de persévérance. Comme le souligne également Oussama Amar, le fait de faire des petites itérations et d’aller vite ne signifie pas qu’on trouve tout de suite et que l’effort n’est pas un marathon. Je cite Richard Sheridan :  « Most organizations give lip service to “Fail fast.” During early experiments when a team is testing their limits, it doesn’t take much to crush their spirit, and then, suddenly, experiments become all about being safe, not taking small risks. In a being safe culture, people choose to run safe experiments that they know will succeed, effectively exhausting the energy behind a change initiative”.
   
   
6. L’histoire de Menlo est édifiante car elle permet de comprendre l’effort et le temps pour construire le « potentiel de situation » au sens de François Jullien. Le point de départ, que je vous laisse découvrir en lisant le livre, est un ensemble d’expériences désagréables de projets échoués par désalignement entre action et réflexion : « These death marches often lead to the saddest story of all: projects canceled before they ever see the light of day. The programmers look back over the litter of their personal lives and wonder why they put in so much effort”.  Le principe fondateur de Menlo devient donc: “Get Results by Giving Your Team a Chance to Get Things Done ». Pour devenir agile et customer-centric, il faut deux choses: redonner le pouvoir et l’autonomie aux équipes pour favoriser l’innovation et laisser émerger « l’obsession du client » et donner le temps d’apprendre par l’action et l’expérimentation. Il faut également créer les conditions de la concentration et éviter des interruptions inutiles : « We have so many channels to interrupt us these days. Phone calls, e-mails, bosses stopping by to say, “How’s it going?,” meetings where new priorities are set without any consideration for yesterday’s commitments, and unplanned emergencies all distract us from our plan for the day. We want to believe we thrive on multitasking”.  
      
7. Un des thèmes principaux de ce livre en termes de culture de management est l’impérieuse nécessité de bannir la culture de la peur. Tuer cette peur et permettre à chacun de donner le meilleur de soi-même est une des idées clé qui traverse ce livre : « When management manufactures artificial fear as part of the management of its people, sunk-cost thinking acts like an amplifier to this manufactured fear”. Ce n’est pas une idée originale, on la trouve déjà par exemple dans « Good to Great » de Jim Collins, mais elle est illustrée et développée ici avec beaucoup de justesse, dans le cadre précis du développement logiciel. Comme toute activité complexe, le développement logiciel exige une culture de confiance. Dès que des utilisateurs humains sont impliqués, il existe une part d’incertitude. La peur du management rend l’efficacité impossible : « The real trouble is not with this organization, its goals, or its teachings, nor with the professionals it certifies. The manufactured fear of management they operate under is enough to wilt any capable individual, no matter how professional, knowledgeable, or experienced.” La culture de la peur produit des effets désastreux que ceux qui ont un peu d’expérience connaissent bien. Je termine en citant une description effrayante – mais réaliste ! - d’une expérience de Sheridan dans un tel environnement : “We shipped poor-quality products that offered mountains of trouble for the users” ; “When abundant problems did arrive as predicted, my bosses told me they never asked me to create such crappy products”.  
      
8. Pour conclure, et sans surprise, l’ingrédient principal du succès est la culture de la collaboration. La sélection des employés à Menlo se fait en premier lieu sur l’évaluation, collective et en situation, de la capacité à collaborer : « At Menlo we work in close collaboration. Therefore, our first interviewing imperative is, “Do you have good kindergarten skills?” Are you respectful? Do you play well with others? Do you share?”. Il y a beaucoup de réflexions intéressantes dans ce livre sur ce qui favorise la collaboration. On retrouve la plupart des thèmes évoqués dans ce blog. Par exemple, tout comme Yves Morieux, Sheridan explique qu’il faut laisser un peu de marge de manœuvre pour que la collaboration puisse fonctionner : « Lean manufacturing principles teach industrial operations engineers to build slack into their systems in order to operate at peak efficiency ». Sheridan insiste beaucoup, tout comme les auteurs de “ How Google works ?”, sur l’importance du travail en équipe, ensemble, co-localisé : « In my experience, there’s no replacement for a live, in-person company, with all members working in the same physical location”. Lorsque ce n’est pas possible, il donne quelques conseils sur l’utilisation des outils électroniques, tels que Google Hangouts, mais à la fin revient sur la nécessité du travail en face à face : « With our distant clients, we have established a practice of meeting in person at least once a month”.

3. Le management inductif

J’ai choisi d’intituler ce billet « sur le management inductif » car il me semble que ce qui caractérise le plus la transformation nécessaire du management, dont Joy offre un exemple parfait, c’est l’adaptation du monde des décisions déductives aux déductions inductives. Le raisonnement déductif s’appuie sur la logique et sur des règles qui se formalisent et se partagent aisément. En conséquence, il se prête très bien au management hiérarchique. Il est adapté aux situations compliquées, mais pas aux situations complexes, c’est très précisément le sens des livres de Nassim Taleb. Dans un monde complexe, la plupart des décisions sont prises de façon inductives, à partir des observations et des faits, sans qu’une logique particulière puisse être établie ou démontrée. C’est à la fois une source de faiblesse, je vous renvoie au « narrative fallacy » et aux ouvrages de Nassim Taleb. C’est également la raison de la plus grande applicabilité aux situations complexes, puisqu’il devient possible de décider sans comprendre – un énoncé qui peut faire peur, mais que Nassim Taleb nous invite à nous approprier. Notons que la prise de décision par raisonnement inductif est le fondement des usages majoritaires du  Big Data. Le management inductif, c’est le management lorsque les décisions sont prises majoritairement sur des raisonnements inductifs, fondés sur l’expérience et les données.

Une bonne façon de vous familiariser avec cette différence est de lire le livre « Les mots et les choses de l’entreprise » de Luc de Brabandere. Je ne vais pas faire de résumé pour plusieurs raisons. Tout d’abord le thème du livre est très vaste et dépasse de beaucoup le cadre de ce blog. Le mode rhétorique ne se prête pas non plus au résumé, tout comme Nassim Taleb qu’il cite, Luc de Brabandere propose une discussion, un fil à suivre. Pour finir, je ne partage pas les opinions de Luc de Brabandere sur l’Intelligence artificielle JJe cite ici ce livre que j’ai beaucoup aimé malgré quelques points de divergence parce qu’il s’articule précisément sur la distinction entre déduction et induction. A travers une courte histoire de la philosophie sur des sujets tels que la pensée et la décision, Luc de Branbandère aboutit à un schéma systémique – nous et notre modèle de conception face au monde que nous percevons – qui pose la différence entre l’induction, une synthèse heuristique de ce que nous percevons, et la déduction, qui est une production analytique, un algorithme, à partir de nos modèles conceptuels. Il cite Kant, pour qui « c’est le sujet qui construit sa vision du monde grâce aux concepts qu’il a en lui à priori : « Tu ne vois pas le monde tel qu’il est, tu le vois tel que tu es » ». Cette citation me semble s’appliquer parfaitement au monde du management scientifique du 20^e siècle, Taylorisé et hiérarchique. Cette séparation entre perception et conception lui permet d’emprunter à l’école de Palo Alto cette constatation que « changer, c’est changer deux fois » : la réalité ne change que si la perception change également. Cette distinction se traduit également pour séparer l’innovation qui est un changement de la réalité, et la créativité qui est un changement de la perception. Cela nous ramène logiquement au rôle fondamental de l’observation dans le design thinking pour provoquer l’innovation.

Si nous revenons maintenant au « nouveau management inductif », il est clair que le mode de raisonnement inductif provoque quelques changements dans la capacité à déléguer. La décision par induction est une décision fondée sur l’expérience. Comme le remarquait brillamment Mintzberg dans « Managing », cette expérience ne se déplace pas. Il faut aller voir la situation « sur place » et il faut écouter « ceux qui vivent avec cette situation ». Contrairement au mode de raisonnement déductif, il est difficile d’encapsuler le raisonnement sous la forme d’un Powerpoint qui pourra parcourir la hiérarchie des comités de décision. Une forme classique de ce paradoxe est le recours à l’expert. Dans un mode déductif, l’expert peut expliquer sa décision, donc on peut faire une fausse délégation : on demande l’avis de l’expert, mais puisque l'on « comprend ses explications », le vrai pouvoir de décision reste chez celui qui pose la question. Dans le cas d’un mode de décision inductif, qu’il s’agisse d’un contexte complexe ou de 10 ans d’expérience, l’expert ne peut pas forcément justifier son avis avec suffisamment  de « logique » pour que le demandeur puisse s’approprier cette expertise. Autrement dit, le monde complexe exige une véritable délégation, une idée fondamentale du Toyota Way ou du livre de Mintzberg, pour ne prendre que deux des sources sur un thème abondamment traité dans ce blog.

Pour les lecteurs qui se demanderaient ce qui justifie la juxtaposition de ces deux sections (Joy & management de l’induction), la première section est l’application pratique de la transformation exprimée dans la seconde.  Ce qui caractérise l’organisation de Menlo, tout comme ce qui caractérise l’entreprise 3.0 ou l’entreprise libéré, c’est que la prise de décision est adapté au raisonnement inductif, fondé sur l’expérience et les données.

4. Conclusion 

On retrouve alors un des thèmes favoris de ce blog : le rôle de manager est un rôle de jardinier, au sens de François Jullien, puisqu’il s’agit de développer un potentiel de situation. Le manager est celui qui optimise le cadre de travail des équipes pour leur permettre de travailler avec la meilleure efficacité possible, au service d’une stratégie commune et claire dont le manager est le garant. Le manager cultive l'émergence de l'efficacité de l'équipe. On retrouve ici bien sûr les principes d’organisation de l’entreprise 3.0. Ce qu’il ne faut pas sous-estimer, c’est l’ampleur du changement qui caractérise la transition depuis des décisions déductives vers des déductions inductives. L’idée qu’il faut « décider sur des faits, des données, des mesures » est très populaire, même parmi les entreprises les plus conservatives. En revanche, l’idée que la capacité à interpréter et comprendre les faits ne se partage pas forcément de façon simple, quoi qu’en dise Boileau (« ce qui se conçoit bien s’énonce  clairement »),  est plus difficile à admettre. C’est d’ailleurs une des raisons de l’intérêt des « serious games » pour éduquer les managers à la complexité.

Il existe une règle simple qui résume bien cette nouvelle philosophie du management, cette reconnaissance de la complexité du 21^e siècle, cette nécessité de raisonner par induction – et donc de déléguer et décentraliser la prise de décision à ceux qui qui ont à la fois l’histoire (l’expérience) et le contexte (les faits détailler). Cette règle consiste à ne jamais prioriser les actions des opérationnels (les mythiques « doers ») mais seulement leurs buts.  En effet, dans un modèle déductif, le manager croit bien faire en aidant l’équipe à prioriser leurs actions, puisqu’il connait mieux les buts (ce qui est vrai). La déduction relie les actions aux buts, le contrôle et l’assistance ont du sens. Dans un monde complexe, dans un système piloté par des raisonnements inductifs, ce n’est plus vrai. Le manager n’est pas à même de prioriser les actions ; s’il le fait, c’est doublement contre-productif : il dégrade le sentiment d’autonomie dont nous savons qu’il est fondamental pour la motivation intrinsèque et il est souvent à contretemps car le manager ne comprend pas les problèmes que traite son équipe aussi bien qu’il le pense. Pour les amateurs de systèmes complexes, je vous renvoie à ce billet sur l’holomorphisme et sur l’importance du pilotage par les buts pour construire des systèmes distribués intelligents.

La dimension temporelle de préparation du potentiel de situation est essentielle : il faut du temps pour construire les capacités, qu’il s’agisse de design, de développement agile ou d’intégration continue. J’ai souvent entendu, dans les dernières années, des appels velléitaires pour accélérer l’action,  par ce que nous sommes dans un monde qui va vite, de plus en plus vite (ce qui est vrai). Dans un monde qui va vite, il faut réagir vite et réajuster constamment. Agir trop vite n’est pas un gage d’efficacité. La capacité à être agile est un potentiel de situation, il se construit en « bottom-up », en jardinant les compétences et laissant les équipes apprendre par l’action. Il y a deux temps qu’il convient d’accélérer : le temps de prise de décision et la fréquence à laquelle on réévalue son cap (le principe premier de l’agilité). En revanche, comme nous le rappelle François Jullien,  « ce n’est pas en tirant sur la tige qu’on fait grandir la plante plus vite ».