Conduire sa démarche agile du projet au produit

 

1. Introduction

Le billet de ce jour s’inscrit dans le thème des apports de l’approche lean aux méthodes agiles. Les livres de Mary et Tom Poppendieck ont été une de mes principales sources d’inspiration il y a dix ans, lorsque je me suis penché sur le « Lean Software Development » pour construire l’approche « lean software factory ». Une des idées clés de « Implementing Lean Software Development – From Concept to Cash » est le passage de l’approche projet à l’approche produit. L’approche produit est idéale pour bénéficier des apports du lean : elle permet de se replacer sur le temps long, elle conduit à itérer des releases suivant un processus itératif et répétitif (qui facilite l’apprentissage) et elle remet l’utilisateur (du produit) au centre. Dans l’article « Moving from Project to Product: What Does “Product Thinking” Actually Mean ? » les auteurs soulignent trois ruptures de l’approche produit : passer d’une chronologie fermée (avec un début et une fin) à une chronologie ouverte (sans fin), penser le produit comme un idéal jamais réalisé que l’on approche de façon itérative, et penser de façon systémique (le produit délivre une expérience à un utilisateur).

L’approche produit est plus qu’une idée forte, c’est un savoir-faire différentiant. Il ne s’agit pas simplement de processus et de méthodes, c’est une expertise qui s’apprend par la pratique. C’est pour cela que l’expérience compte, et que les entreprises qui pratiquent le mode produit depuis un certain temps construisent une capacité de différentiation. Tout comme l’excellence opérationnelle, la maîtrise du mode produit ne se copie pas simplement. Il ne suffit pas d’avoir lu l’excellent article de Sriram Narayan, « Products over Projects », il faut mettre en place un nouveau flux de travail et laisser aux équipes autonomes le temps d’apprendre à travailler autrement.

Ce billet est consacré au livre de Mik Kersten, « Project to Product », qui explique que la maîtrise de l’approche produit est essentielle à la compétitivité des entreprises du 21^e siècle. C’est une thèse forte, qui résonne avec les conclusions de mon dernier livre. Le logiciel dévore le monde, l’excellence logicielle crée des disruptions, et les entreprises qui dominent la scène digitale ont pris une longueur d’avance dans cette pratique de l’approche produit. Le sous-titre du livre, « How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework », illustre un des points essentiels que développe Mik Kersten : la nature VUCA de l’environnement des entreprises aujourd’hui, et l’importance de la transformation numérique du monde, font qu’il est vital pour la quasi-totalité des entreprises d’apprendre à développer leurs outils logiciels avec la même qualité et efficacité que les « Géants du Web ».    

La suite du billet est donc organisée autour de 7 idées essentielles sur le développement logiciel dans le monde moderne, centrées sur l’approche produit. J’ai beaucoup apprécié l’engagement de Mik Kersten, qui s’appuie sur sa propre expérience et sur les échecs qu’il a constaté en première ligne, pour expliquer le besoin d’enrichir les approches agiles. Certains d’entre vous pourraient me dire qu’une partie de ces idées sont maintenant parfaitement connues et intégrées, comme par exemple dans l’approche SAFe. L’intérêt du livre de Mik Kersten est d’aller au fond des choses et de donner de multiples exemples ; il devrait donc être une contribution éclairante même si le mot « produit » fait maintenant partie de toutes les bonnes méthodologies de développement logiciel. Ce livre peut irriter de temps à autre car l’auteur, CEO d’une entreprise qui vend des outils logiciels pour réussir le pilotage du mode produit, passe de temps en temps en mode « consultant commercial ». Il s’agit cependant d’un livre essentiel pour comprendre l’importance et l’urgence du passage au mode produit, comme le souligne Anthony Crain dans « Projects to Products : What it means, Why it matters ». Le livre contient une analyse comparative avec l’usine ultra-moderne de BMW, qui est passionnante et que je vous recommande de lire. Comme chaque fois dans ce blog, je vais me concentrer sur quelques aspects essentiels du livre, avec un choix éditorial personnel.

 

2.     Du Projet au Produit
 

2.1   La nécessité de changer la façon de développer les systèmes numériques

L’idée que la transformation digitale est difficile, et que de nombreuses entreprises peinent à réaliser leurs ambitions, n’est plus un secret honteux et se retrouve au grand jour dans de nombreux ouvrages. C’est par exemple l’angle d’attaque du livre récent, « The Digital Transformer’s Dilemma », sur lequel je reviendrai dans un autre billet. Mik Kersten partage cette analyse : « However, as we will learn in this chapter, the problem is that those transformations are failing. The main reasons for failure, according to Altimeter’s report “The 2017 State of Digital Transformation,” are a shortage of digital talent and expertise (31.4%), general culture issues (31%), and the treatment of digital transformation as a cost center instead of an investment (31%). None of these are root causes of transformation failure; rather, they are symptoms of a fundamental disconnect between business leaders and technologists that we will review throughout this book ».  Cette citation permet tout de suite de voir le point commun avec la thèse de ce blog : il ne suffit pas de penser sa transformation digitale, il faut avoir les moyens (compétences et technologies) de l’exécuter. L’excellence du développement logiciel (dans un monde où le mot développer signifie intégrer, créer, partager, réutiliser … au sein d’écosystèmes ouverts) est une nécessité pour les entreprises modernes. Bien sûr, cela passe par l’adoption de l’approche agile pour s’adapter à la variabilité du monde digital : « Manufacturing has a fixed, well-defined set of variations for what will emerge from the end of the line, whereas the design of software features is open ended. Manufacturing needs to minimize variability; software development needs to embrace it ». Mais, comme le souligne Mik Kersten, travailler en mode agile ne suffit pas : « I had a chance to witness the pitfalls of this trap firsthand. Working with Nokia, I noticed that management was measuring the success of its digital transformation by how many people were trained on Agile software development methodologies and were onboarded onto Agile tools ».

Nous allons voir progressivement, dans la suite de ce billet, ce qu’il est nécessaire de mettre en place pour développer cette excellence du développement logiciel agile, mais les lecteurs curieux pourront jeter un œil à cet article plus ancien de Mik Kersten, « How to garantee failure in your agile DevOps transformation». Il ne suffit pas d’appliquer les approches modernes de transformation des organisations de développement (digital ou IT), il faut « le faire de façon excellente, avec un profond intérêt pour le produit logiciel et les femmes et les hommes qui le construisent ». Les « anti-patterns » soulignés par Mik Fersten – toute ressemblance avec votre réalité serait fortuite – sont le contraire du respect des personnes (le pilier de l’approche lean) : « Push all tools top-down, limiting choice as much as possible ; Worry about integration later, your internal IT team can handle it ; Optimize your tool chain one silo at a time ; Forget about requirements and quality management ; Ignore Ops and ITIL, they ought to be out of scope; Put someone junior in charge of integrating the value stream; Don’t bother with metrics ».

 

2.2   Pour changer l’horizon du possible, il faut passer de l’approche projet à l’approche produit

Sans surprise, puisque c’est le titre du livre et de ce billet de blog, la plateforme pour construire l’excellence du développement logiciel au 21^e siècle est l’approche produit : « Project-oriented management frameworks work well for creating bridges and data centers, but they are woefully inadequate for surviving the Turning Point of the Age of Software ». Il ne faut pas oublier la première partie de la phrase, l’approche produit n’est pas le « silver bullet » qui devrait s’applique pour tous et partout. D’abord parce qu’elle est complexe et longue à mettre en place, mais aussi parce qu’elle correspond à des conditions d’application qui ne se retrouvent pas partout. L’approche produit est en premier lieu une « approche équipe », une philosophie du travail, qui suppose qu’on dispose d’équipes stables (« long lived ») qui vont pouvoir bénéficier de l’autonomie nécessaire pour construire leur apprentissage du mode produit. On retrouve directement l’influence de Daniel Pink sur l’importance de la motivation intrinsèque pour réaliser les apprentissages complexes : « Daniel Pink and others have demonstrated that happy and engaged staff produce better results when creative work is involved. Project-oriented management gets in the way of the autonomy, mastery, and purpose identified by Pink as key to job satisfaction, whereas product-oriented stability of work and teams promotes them ».

Là où l’approche projet crée de façon temporaire des équipes par assemblage de talents qui sont « déplacés » pour aller réaliser le projet (« bringing people to work ») , l’approche produit repose sur une équipe stable : « High-performing software organizations have already learned that “bringing work to people” is more effective. Long-lived teams allow for expertise (both individual and team) and relationships to build over time, improving both velocity and morale ». On retrouve ici les racines profondes du lean : donner aux collaborateurs les conditions de travail qui leur permettent d’apprendre en profondeur le système qu’ils construisent.

Ce qui fait de l’approche produit une plateforme pour l’excellence, c’est la capacité d’améliorer de façon continue et en même temps le produit et le processus qui construit le produit (ce qui est plus difficile en mode projet, car cela demande un « passage à l’abstraction » pour identifier les récurrences et les améliorations). Mik Kersten insiste sur le fait de travailler en premier avec des métriques métiers (associées à la satisfaction des clients et la création de valeur) qui représentent les objectifs, et de considérer les métriques techniques comme des outils qui représentent des moyens : « Quality metrics that are not visible to the customer, like defect aging and change success rate, can provide important leading indicators of quality problems. However, they should remain one level down, as the Flow Framework focuses on customer- and business-visible metrics ».

2.3   Les entreprises qui aspirent à une transformation digitale doivent s’inspirer des géants du Web

Développer ses compétences d’usine logicielle à produit, depuis l’outillage jusqu’aux pratiques en passant par les modèles mentaux, la culture et l’état d’esprit (tout ce que recouvre le mot galvaudé de « mindset ») est long et difficile. Mais c’est juste indispensable ; pour Mik Kersten, la différence de performance ne souffre aucune comparaison : « The result is that the software delivery efficiency of these companies is abysmal when compared to that of digital startups or the tech giants ». Comme le rappelle souvent Eric Chaniot, notre CDO chez Michelin, le changement du « mindset » est le point de départ essentiel. Ce que souligne Mik Kersten : « This mind-set has grave implications. If the current trajectory does not change, the incumbent companies that form the backbone of the world economy are at an inherent and significant disadvantage ».  L’approche qui est proposée dans ce livre ressemble beaucoup à ce qu’on trouve dans le livre de Nicole Forsgren et Jez Humble, « Accelerate », mais  Mik Kersten insiste plus fortement sur l’enjeu stratégique que constitue la réussite de cette transformation : « Organizations can and must change in order to create the software innovation engines that will ensure their competitiveness and survival. To do that, we need to learn from the history of previous technological revolutions instead of assuming that we are in a completely unique moment in time ». Mik Kersten fait ici référence aux travaux de Carlota Perez pour introduire deux âges de la transformation numérique : celui de l’installation (les décennies précédentes) et celui du déploiement dans lequel nous sommes entrés. La période d’installation est marquée par le foisonnement et l’expérimentation, celui du déploiement est marqué par l’efficacité et la rationalisation. Comme pour les révolutions industrielles précédentes, les acteurs dominants s’imposent par la maîtrise des nouveaux processus de production : « Once we reach the Deployment Period, companies that have not adapted to the new means of production will decline in relevance and market share ». Pour la transformation numérique, il s’agit de maîtriser les “nouvelles méthodes” du développement logiciel (de l’agile à DevOps) à l’égal des meilleurs : « Even with the combination of innovation and great products, Jawbone lost out to production-capital companies like Apple. The smartwatch innovator Pebble closed its doors in December 2016 for similar reasons ».  

Ce dont il est question ici n’est simplement la production de logiciel (qui n’est pas un but, mais un moyen), c’est la production d’un flux continu de valeur - qui est appelé « software value stream » dans le livre. Ce flux de valeur est porté partiellement par le développement logiciel, mais il s’agit bien de comprendre et d’optimiser l’expérience du client. Mik Kersten parle beaucoup de « end-to-end », dans un cadre plus vaste que le processus CICD : « In the context of a software value stream, the concept of “end-to-end” includes the entire process of value delivery to the customer. It encompasses functions ranging from business strategy and ideation all the way to instrumentation of usage to determine which values were most adopted by the customer base ».  Je vous renvoie également à l’excellent livre de Nathan Furr et Jeff Dyer, « The Innovator’s Method », qui décrit ce processus dans sa dimension « end-to-end ».

 

2.4   La cause racine de l’amélioration des performances est l’optimisation des flux

Un des principes fondamentaux de l’approche lean est le « streamlining » pour fonctionner en flux continus. Donald Reinersten fait de l’optimisation des flux une pierre angulaire du développement des produits, en constatant que le plus grand gaspillage constaté est le temps que les composants de produits attendent sans recevoir d’attention, entre deux étapes du process de développement. Ces temps d’attente sont les ennemis de l’agilité (ils augmentent la probabilité de rework parce que le monde évolue) et de l’efficacité (ils introduisent des ruptures de charge et de contexte). Ils sont aussi la cause première d’une autre forme de gaspillage : le temps d’attente des membres de l’équipe. Je me souviens encore d’un premier diagnostic lean effectué dans un job précédent il y a plus de 10 ans, qui avait conclu à trois diagnostics : « vous passez votre temps à vous attendre », « vous refaites plusieurs fois la même chose » et « une partie très importante du code produit n’est jamais mis entre les mains des utilisateurs ».

La méthode proposée par Mik Kersten est le « Flow Framework », une approche qui fait du flux de création de valeur le premier sujet d’attention. L’objectif de l’attention portée à ce flux est de s’assurer de la synchronicité entre le flux des demandes (besoins) et le flux de production (éléments logiciel) : « The Flow Framework is a new way of seeing and measuring delivery and aligning all of your IT investments according to value streams that define the set of activities for bringing business value to the market, via software products or software as a service (SaaS) ». Tout comme la réorganisation des usines Toyota par Taiichi Ohno était une rupture il y a 70 ans, repenser l’organisation – des équipes comme du système d’information, liés par la Loi de Conway  – est un changement de paradigme : « In contrast, the disconnect between the business and IT is massive, as are the disconnects within IT organizations. The common approach to enterprise architecture is wrong, as it tends to focus on the needs of the technologists and not on the flow of business value ».

L'attention portée à l’optimisation du flux doit se traduire dans l’automatisation (on retrouve ici DevOps) et les outils mis à disposition des développeurs. Le livre cite de nombreuses études qui montrent que le travail de développement de code n’est pas continu et subit de nombreuses ruptures : « A developer’s primary function and expertise is coding, yet studies summarized in this book have shown that developers spend more than half their time on manual processes due to disconnects in the Value Stream Network ». Qu’il s’agisse des développeurs comme des utilisateurs des systèmes réalisés par ces développeurs, l’expérience apprend que les entreprises accumulent des patchworks d’outils, mal connectés, et qui exigent beaucoup d’actions manuelles pour inter-opérer : « For example, after conducting an internal study on one bank’s software delivery practices, we determined that, on average, every developer and test practitioner was wasting a minimum of twenty minutes per day on duplicate data entry between two different Agile and issue-tracking tools ».

Construire des flux efficaces demande de la régularité (éliminer le mura dans le jargon lean), et cela passe par la création de buffers. Cela demande aussi d’éviter les pics de charge qui déséquilibre le flux : « Excessive flow load can be correlated to inefficiency. For example, Reinertsen states that excess utilization of a value stream dramatically affects velocity due to excess queue times ». Les observations de Reinertsen ne sont que les conséquences de ce que nous apprend la théorie des files d’attentes, et en particulier la formule de Pollaczek-Krinchine, que j’aime citer dans ce blog. Cette formule, qui met en avant à la fois l’importance de mura (régularité) et de muri (taux de charge) dans le temps de service, est un bijou de concision pour ceux qui aime voir le lean à travers un prisme systémique. C’est bien sûr ce qu’on observe dans la pratique : « As DeGrandis summarizes, the result of seeking full utilization is similarly problematic for software delivery as it is for manufacturing, having a negative effect on flow velocity and flow time ».

 

2.5     L’approche produit est une approche systémique tournée vers l’adaptation continue 

Mik Kersten explique fort bien pourquoi l’approche produit est bien adaptée à notre monde VUCA. En premier lieu, l’approche produit est itérative, sur une longue échelle de temps (toute approche agile itère des sprints, mais l’approche produit itère sur un temps ouvert). La démarche proposée dans ce livre permet de construire, de façon itérative, un équilibre entre trois exigences : fournir les fonctionnalités attendues par le client,  rendre le produit résistant et résilients aux risques – comme par exemple le risque de cyberattaque – et maintenir le produit dans un état d’adaptabilité constant, ce qui passe par la suppression continue de la dette technique : « technical debt reduction, which describes the need to perform work on the software and infrastructure codebase that, if not done, will result in the reduced ability to modify or maintain that code in the future ». On retrouve ici une idée que j’ai développée dans mes blogs : la dette technique est l’ennemi de l’agilité, tandis que le mode incrémental de développement produit structurellement de la dette technique. L’approche produit, parce qu’elle se place sur le temps long, est une solution pour résoudre ce paradoxe du développement agile.

En deuxième lieu, ce qui rend l’approche produit adaptative est son ancrage sur le client. C’est trop souvent implicite et cela mérite d’être souligné : on parle de produit parce qu’il y a un client (un utilisateur). C’est ce qui fait la différence entre un composant et un produit dans le système d’information : cette différence tient dans la culture et l’attitude (le « mindset ») bien plus que dans la technologie. C’est pour cela qu’on peut adapter une « approche produit » à des artefacts techniques comme des APIs de fourniture de données. Faire du client l’étoile polaire de l’équipe de développement est la meilleure façon de réaliser que le monde change constamment et que les attentes et usages des utilisateurs évoluent. Mik Kersten, par exemple, met en garde sur l’abus d’utilisation des processus, si l’on perd cette finalité de l’utilisateur : « A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right ».  Faire du client l’étoile polaire de l’approche produit conduit naturellement à faire le lien avec l’approche Lean Startup – ce qui est le socle de mon dernier livre : «  In contrast, Lean Startup and approaches such as minimum viable products (MVPs), are a key part of the product-oriented mind-set. In addition to reducing risk, the incremental product-oriented approach creates option value by allowing the business to pivot at regular checkpoints ».

Pour finir, ce qui augmente l’adaptabilité de l’approche produit est l’apprentissage long et continu de l’équipe (on retrouve l’importance des long-lived teams). C’est une des idées fondamentales du lean : construire des équipes dont chaque membre possède une compréhension correcte de l’ensemble des rôles, parce que cela facilite à la fois l’efficacité (réduction des coûts de transaction dans la collaboration entre membres de l’équipe parce qu’il existe un contexte partagé) et l’adaptabilité (l’équipe est plus « intégrée » et peut réagir plus vite pour changer plus profondément). La combinaison du temps long, des itérations et des équipes stables favorise cet apprentissage. Autrement dit, l’équipe doit développer les fameux « profils en T » (chaque membre a une expertise profonde sur son domaine propre, mais également une compréhension large du domaine collectif).  Mik Kersten cite à ce sujet « Team of Teams: New Rules of Engagement for a Complex World » du General Stanley McChrystal, qui donne plusieurs exemples pour comprendre que la trop grande spécialisation crée des « fault lines » (lignes de faiblesses) entre les différentes équipes.

 

2.6   Le passage à une approche produit est une démarche métier

La démarche produit s’appuie sur des équipes mixtes qui combinent la vision métier et la vision technique pour maximiser le flux de valeur apporté au client. Le flux de valeur que nous avons évoqué plus haut est à prendre dans un sens global : « Value Stream: The end-to-end set of activities performed to deliver value to a customer through a product or service  ».  Puisque la démarche est centrée sur la création de valeur, il faut à la fois un engagement complet du senior management de la « line of business », et la capacité à regrouper dans l’équipe produit l’ensemble des talents qui lui permette de travailler de façon la plus autonome possible, par opposition aux classiques « silos » : « Value streams are composed of all the activities, stakeholders, processes, and tools required to deliver business value to the customer. While this may sound obvious, my second epiphany was all about the fact that instead of creating abstractions around end-to-end value streams, organizations keep creating them within functional silos ». C’est ici le bon moment pour noter que l’insistance sur le value stream (qui est la colonne vertébrale du livre) témoigne de l’expérience B2B de l’auteur et son habitude de travailler sur des flux de demandes clients. Dans le monde B2C des services digitaux, il existe une part plus forte de risque et d’incertitude, qui rendent la démarche de création de valeur plus aléatoire (même avec une approche produit). Certains passages du livre me font penser à l’approche SAFe, en donnant la fausse impression qu’une approche centrée sur la valeur et la satisfaction client ne peut pas échouer.

Une des contributions essentielles de l’approche produit est de trouver de façon dynamique un équilibre entre l’ajout de fonctionnalité, la réduction des risques et la réduction de la dette technique : « Through the lens of the Flow Framework, we know that there is a zero-sum game in the number of features added, defects fixed, and risks mitigated ». Le point clé d’une équipe mixte métier/technique est d’éviter le clivage traditionnel « features pour le métier, réduction de dette pour satisfaire l’équipe technique », un clivage qui ne résiste pas longtemps si l’on prend un point de vue « centré client » qui sert de boussole à l’ensemble de l’équipe produit. Mik Fersten souligne également ce qui devrait être une évidence en 2020, mais qui n’est pas encore compris par tous, les leviers de l’agilité ne s’activent pleinement que si les principes sont compris et partagés par l’ensemble des parties prenantes : « all the specialists in IT are already starting to work in this new way by adopting Agile teams and DevOps automation, but these specialists lack the infrastructure and business buy-in to do so effectively ».

De la même façon, les principes lean tirés de l’optimisation des files d’attentes – la nécessité de piloter la charge, et de conserver des « buffers » pour maximiser la flexibilité – demandent une adhésion des acteurs métiers. L’auteur insiste sur le besoin, pour les responsables métiers d’aujourd’hui, de mieux comprendre les clés de l’efficacité du développement produit : « My key takeaway from that experience was that in the Age of Software, for wealth to be shared across the economy, we need this kind of strategic decision-making framework to be available to all business leaders ». Pour être plus précis il y a bien une double exigence,  celle de comprendre les principes de l’optimisation des flux de valeur et celle de comprendre la nature de l’activité de développement logiciel : « But everyone wanting to make sound decisions around IT and software investment must understand software delivery at the level of business value flow ».

 

2.7   Plus le logiciel dévore le monde, plus il faut des méthodes et des outils 

Dans ce passage à l’âge du déploiement, la recherche de l’automatisation et de l’excellence des pratiques s’impose. C’est précisément ce qui marque l’apparition des entreprises excellentes du domaine : elle profite du « first mover advantage » du monde numérique pour transformer un avantage de position en un avantage d’excellence opérationnelle, qui est plus difficile à rattraper. Un des thèmes du livre est, logiquement si l’on considère l’entreprise dont Mik Fersten est le CEO, l’utilisation de méthodes et d’outils pour éliminer les ruptures dans le flux de valeur : « Productivity declines and waste increases as software scales due to disconnects between the architecture and the value stream ». Plus généralement, le livre contient un plaidoyer pour l’automatisation, selon une approche DevOps, de tout ce qui peut l’être dans le processus d’intégration et de déploiement continu (CICD). L’objectif est bien d’automatiser ce qui est simple et répétitif pour se concentrer sur la création de valeur dans la partie créative du développement. L’accent sur l’automatisation ne signifie pas que le développement de produit logiciel est répétitif et industriel. Au contraire, le livre souligne la nature créative du développement logiciel : « Software delivery is, by its nature, creative work. Software specialists are skilled at automating repetitive processes when given the chance, leaving only the complex work and decision making that humans continue to excel at ».

Un des principes lean qui trouve toute sa place dans le développement logiciel est de rendre visible les choses invisibles, tels que les problèmes, le travail en cours, ou les composants qui attendent. Mik Fersten cite plusieurs fois le livre de Dominica DeGrandis, « Making Work Visible: Exposing Time Theft to Optimize Work & Flow », qui souligne, comme conséquence de l’optimisation des flux, l’importance de rendre le « work in progress » (WIP) visible pour mieux le maîtriser : « excess WIP is the enemy of productivity due to the negative effects that overutilization has on output ». La visualisation des flux est d’autant plus importante qu’il ne s’agit pas simplement du code ou des objets logiciels qui participent au produit, il d’agit également de tous les flux d’information qui contribuent à la définition et à la réalisation du produit. Le livre contient de nombreux exemples qui montrent à quel point les développeurs passent du temps à retrouver des informations nécessaires autour d’un contexte donné. Par exemple, il donne l’exemple du Boeing 787 pour lequel la traçabilité des exigences (un classique du développement produit) a joué un rôle important : « The story of the Boeing 787 brake software in Chapter 2 illustrates how critical traceability automation is to evolving and maintaining large-scale software ». Il s’agit donc à la fois d’une opportunité pour réduire des gaspillages (de temps) et d’améliorer le flux (streamlining).

 

3.     Conclusion

Pour conclure, je souhaite souligner que le fonctionnement en « mode produit » est un des principaux apports d’une approche lean aux méthodes agiles, un sujet que je développe dans mon dernier livre. Le livre de Mik Kersten est entièrement construit sur des concepts lean : value stream mapping, flow optimization, élimination des muda, mura et muri.  La rupture que représente le passage du mode projet au mode produit peut se résumer selon les quatre points suivants :

• Le passage au mode produit change l’horizon de temps. Il nécessite un engagement « long terme » du métier, ce qui permet d’engager la puissance d’une approche lean confiée à une équipe autonome. En particulier cette autonomie se traduit dans un mode de financement (Build & Run) qui permet à l’équipe de piloter le court et le long-terme, et de faire les arbitrages nécessaires à la satisfaction durable du client.
• L’approche produit est confiée à une équipe transverse, stable dans la durée. Le partage du même contexte et des mêmes objectifs par l’ensemble de l’équipe, technique et métier, est nécessaire pour libérer la capacité d’innovation.
• L’approche produit est itérative et adaptative (chaque itération influence la suivante). Elle utilise le plus possible l’automatisation du processus CICD pour se concentrer sur la valeur apportée au client. Dans un monde qui change constamment, cette satisfaction n’est jamais acquise et se gagne chaque jour.
•  L’approche produit permet de corriger de façon continue et adaptative les défauts propres à toute méthode itérative : l’équipe contrôle l’accumulation de la dette technique et ré-évalue régulièrement les risques et les réponses à y apporter.

 

 

L’approche lean pour la transformation digitale

 

1. Introduction

Mon quatrième livre chez Dunod, « L’approche lean pour la transformation digitale – Du client au code et du code au client » vient de sortir. Dans le monde numérique, l’idée importe peu, c’est avant tout son exécution qui compte. Ce qui caractérise une entreprise innovante, c’est sa compétence logicielle, c’est sa rapidité dans l’exécution, et sa capacité à mettre en place des itérations avec ses clients. Ce sont en effet les clients ou futurs clients qui savent le mieux de la valeur pour eux : c’est pourquoi l’approche lean de la transformation digitale place le client au centre de la construction des nouveaux produits et services. Les outils du monde numérique, depuis l’intelligence artificielle jusqu’à l’approche DevOps, nous donnent les moyens de cette cocréation, car ils permettent de formaliser, d’automatiser et d’accélérer ces itérations. C’est le sujet principal de ce livre, la boucle continue du client au code et du code au client. L’approche lean est le fil rouge qui relie les différents thèmes du livre : j’y parle de Lean Startup, de Lean Software, mais surtout d’équipes autonomes, d’apprentissage continu par la résolution de problèmes, de l’importance du développement des compétences comme stratégie d’adaptation, du respect des connaissances techniques et des gestes métiers, et surtout de la recherche de la satisfaction du client en tant qu’étoile polaire, déclinée et vécue par chaque équipe.

J’ai écrit ce livre pendant les grandes-vacances 2019. Je suis très reconnaissant à mon groupe de relecteurs qui m’a permis d’affiner le manuscrit pendant les six mois suivants, et moins à l’épidémie COVID qui aura produit plusieurs mois de décalage pour la sortie. Le mois de juillet est loin d’être idéal, vu qu’il ne s’agit pas d’une lecture de plage. Ce livre est le résultat d’un peu plus de 10 ans d’expérience dans le développement des services numériques, chez Bouygues Telecom puis chez Axa. C’est bien sûr une synthèse des différentes méthodes mises en place avec succès, la combinaison des lectures et multiples rencontres avec d’autres acteurs numérique innovants. Mais c’est encore plus un retour d’expérience nourri par ce qui n’a pas fonctionné, depuis les services qui n’ont pas rencontré leurs utilisateurs jusqu’à ceux que l’absence de  « maitrise digitale » n’a pas permis de produire avec succès. Toutes ces années, passées à comparer ce que nous faisions par rapport aux « best practices » des meilleurs entreprises numériques, depuis les géants du Web jusqu’au startups de la Silicon Valley, m’ont aidé à apprécier la difficulté qui existe pour importer des méthodes de travail développées à une échelle différente ou dans une autre culture. Le livre reprend le contenu de mes deux blogs, distillé sur une dizaine d’années, mais comme chaque fois, le travail d’écriture m’a permis d’avoir des idées plus claires,  mieux structurées et mieux « tissées ». L’écriture d’un livre est également l’occasion de travailler en profondeur, les références sont considérablement enrichies par une bibliographie conséquente et de multiples notes de bas de page.

J’ai écrit ce livre pendant une longue convalescence, à la sortie d’une grosse opération au cœur. Son écriture est un exemple pratique d’application des méthodes décrites dans mon billet sur l’efficacité personnelle et l’illustration de la pertinence de la citation de Jacques Brel : « le talent, c’est d’avoir envie ». La motivation fondamentale, que les lecteurs retrouveront dans la conclusion du livre, est que la conviction que la France en général, et les entreprises françaises en particulier, ont un déficit culturel pour appliquer les ressorts de la transformation digitale. Ce livre est un livre plutôt détaillé, voire technique, mais son ambition est de décrypter des mécanismes et des blocages au sujet d’une transformation qui est très globale : l’entreprise, son environnement, ses capacités, son organisation. C’est pour cela que je suis particulièrement heureux qu’Emmanuelle Duez m’ait fait l’amitié d’écrire la préface. Le monde se transforme rapidement sous nos yeux, et l’important est d’avoir les clés pour participer à cette transformation. 

2. Pourquoi ce livre

Ce livre, tout comme mon deuxième livre qui parle du système d’information,  est construit en réponse à des paradoxes, des situations de frustration et d’incompréhension que j’observe souvent. Voici les trois exemples que je cite en introduction, je pourrais les qualifier de « pain points » :

• Beaucoup de grandes entreprises se plaignent du faible retour sur investissements de leurs programmes de développement de services numériques. Après une période de fort engouement, lorsque l’on fait les comptes, on se rend compte que l’usage reste faible et que ces programmes n’ont généré qu’une faible partie de revenus additionnels. De plus, assez souvent, des acteurs récents et petits – des startups – se sont immiscés dans ce périmètre de services numérique, pour s’intermédier et prendre la place de la relation numérique avec le client. « Nous avons les moyens, les talents, les clients, la notoriété de la marque … et nous nous faisons dépasser par des startups ».
• Les discours sur la transformation digitale, la création de valeur par les données, la réinvention avec l’intelligence artificielles sont tellement nombreux et assourdissants qu’il n’existe pas une entreprise qui n’ai pas décidé d’adopter les « technologies exponentielles » : cloud, apprentissage automatique et data science, intelligence artificielle.  Pourtant, l’adoption de l’ambition « data-driven » est lente, et la création de valeur ne reproduit pas ce qu’on trouve chez les entreprises numériques leaders, celles que Salim Ismail appelle les « Exponential Organizations ». On trouve des POC partout (proof of concept) mais le passage à l’échelle est long et laborieux.
• L’engouement pour la transformation digitale a coïncidé avec une adoption massive des nouvelles organisations de développement de projets informatiques, autour des « méthodes agiles » qu’il s’agisse des directions digitales ou des DSI. Beaucoup d’entreprises ont espéré que ce changement de méthode les rapprocherait des performances logicielles des « Géants du Web », pourtant les progrès en termes de fiabilité, de vitesse de déploiement, et encore plus de vitesse d’adaptation au marché et aux concurrents (ce que les managers associent à « agile ») sont faibles et décevants. La création de nouvelles plateformes digitales n’a pas réussi à faire oublier la lenteur et les frustrations que nombre de managers expriment à propos de leurs services informatiques.

A côté de ces exemples imaginaires mais précis (toute ressemblance avec une situation ayant existé dans votre entreprise serait fortuite), il existe un « meta pain-point »  lié à la difficulté culturelle, pour nous Français, à adopter les postures et les comportements nécessaires pour cette transformation, parce qu’ils ne correspondent pas à nos modèles mentaux. Notre culture et notre éducation apporte un poids excessif à la conceptualisation. Plus que d’autres nations, nous avons tendance à confondre « la carte et le territoire ». Nous avons de plus besoin de « comprendre avant d’agir »,  alors que la nature VUCA de notre monde demande souvent « d’agir pour comprendre ». Notre culture du pouvoir et du rôle du chef ne favorise pas l’accession à l’autonomie et la responsabilisation des équipes. Ce livre n’a pas vocation à changer ce constat … mais d’en tenir compte et d’aller au fond des choses, d’appliquer la recherche des causes profondes, lorsqu’il explique ce que constitue la transformation digitale et les différentes capacités que les entreprises doivent développer, à la fois des capacités techniques et des capacités d’organisation.

Dans un billet precedent, j’ai parlé de l’excellent livre « Designed for Digital – How to architect your business for sustained success » de Jeanne W. Ross, Cynthia M. Beath, et Martin Mocker. Je partage l’ensemble du diagnostic sur la transformation digitale et sur les conditions pour la réussir. En particulier, il existe bien deux formes de transformation digitale : la transformation des processus existants – à la fois l’optimisation par les progrès numériques mais également la réinvention grâce aux capacité de transformation des technologies exponentielles – et la création de nouveaux « business models » qui exploitent la « transformation numérique du monde ». L’idée importante est qu’il ne faut pas les opposer : l’entreprise a besoin de construire son « digital backbone », qui lui permet de réaliser la première transformation, pour se mettre en capacité de penser à la seconde. Je vois « L’approche lean pour la transformation digitale » comme la suite de « Designed for Digital » : un livre plus technique et beaucoup plus précis, qui explique comment mettre en œuvre les recommandations du second.

 

3. Le contenu du livre

De façon simplifiée, on peut dire que le livre est organisé autour de trois contenus, qui sont trois capacités qui me semblent nécessaires pour réussir une transformation digitale :

• La première partie parle de l’approche « Lean Startup » pour cocréer des produits et des services avec ses utilisateurs. Je n’entre pas ici dans le détail, c’est un des sujets fréquents pour les billets de ce blog. Cette partie du livre propose une synthèse pour la mise en œuvre de l’approche Lean Startup dans une grande entreprise – ce qui est spécifique et différente d’une petite structure – dans une vision globale qui va du Design Thinking au Growth Hacking.
• La seconde partie du livre parle de la transformation du système d’information pour qu’il devienne un « système d’information exponentiel », c’est-à-dire une plateforme ouverte pour évoluer rapidement et absorber avec succès les vagues successives des évolutions technologiques, en particulier les progrès continus de l’intelligence artificielle. Cette partie est donc dédiée au « digital backbone », avec la conviction que la partie plus visible de la transformation digitale (création de nouvelles expériences, de nouveaux services et nouveaux produits) repose sur la transformation des « fondations » que représente le système d’information.
• La troisième partie du livre est consacrée aux capacités logicielles que l’entreprise doit maîtriser pour pouvoir « jouer dans la cour des grands » du monde numérique. La première capacité consiste à combiner qualité et rapidité en adoptant les pratiques DevOps de l’intégration et du déploiement continu. Il ne s’agit de rien de moins que de développer une excellence du développement logiciel, que je place naturellement dans une vision lean, en appliquant une approche « Lean Software Factory ». La seconde capacité est de savoir construire des plateformes digitales,  qui sont à la fois des modèles d’affaire, des modèles d’organisation – autour de communautés – et des modèles d’architecture.

Le titre du livre, « l’approche lean pour la transformation digitale », n’est pas simplement un trait d’union entre Lean Startup et Lean Software. L’approche lean est le modèle mental qui permet d’absorber les défis de complexité et de changement permanent qui caractérisent la transformation digitale. Je ne suis pas le premier à voir à quel point les principes lean sont bien adaptés aux défis du monde numérique,  mais ce livre va beaucoup plus loin que la simple constatation. L’approche lean est « tissée » dans chaque page du livre pour permette de construire un modèle d’organisation et de travail apprenant et responsabilisant. Au-delà des différents contenus que je viens d’évoquer, l’approche lean a pour objectif de nourrir trois thèmes qui sont essentiels dans la transformation digitale :

• Une véritable orientation client – La satisfaction des clients reste la seule « étoile polaire » du succès de l’entreprise et la transformation digitale est en premier lieu l’accélération de la proximité entre l’entreprise et ses clients.
• Une transformation vers une organisation adaptative – donc agile et distribuée – ce qui impose un « changement de modèle » en termes d’organisation et de management.
• Une orientation « logicielle » de l’entreprise, qui consiste à reconnaitre que « software is eating the world » et à embrasser le changement technologique en développant, selon les principes lean, le respect des compétences et de gestes associés.

 

4. A qui s’adresse ce livre

 

Ce livre a été écrit en pensant à trois types de lecteurs :

1. En premier lieu, ce livre s’adresse aux managers, pour leur permettre de mieux comprendre les enjeux de la transformation digitale. Il existe déjà de multiples livres sur le « comment » ; ce livre porte sur le « pourquoi » et le « pourquoi c’est difficile ». Comme je l’ai dit en introduction, ceci n’est pas un « livre de plage » ; mon ambition est d’offrir un outil pour déchiffrer la complexité du monde compétitif des services numériques. Je suis bien conscient, et ceci m’a déjà été signalé par des premiers lecteurs, que ce livre rentre dans des détails techniques qui peuvent surprendre des « managers généralistes ». Mon humble opinion est qu’il est nécessaire de comprendre un peu le fonctionnement de l’intérieur pour être mieux capable de saisir les opportunités que la révolution technologique entraine. Je fais mienne cette citation d’Aurélie Jean que je cite dans l’introduction : « les décideurs doivent s’initier au code pour devenir des leaders éclairés … il faut des décideurs éclairés et non éblouis par l’informatique »
2. Ce livre s’adresse également aux praticiens des systèmes informatiques, non pas comme un livre technique qui proposerait des solutions – je fais l’hypothèse que ces lecteurs en savent autant que moi – mais comme un outil de communication. Le rôle des praticiens dans la transformation digitale est essentiel : ils doivent être des passeurs de savoir. La transformation digitale est entre les mains des acteurs métiers, mais le terrain de jeu est défini par les capacités digitales. Mon objectif ici est de trouver des modèles mentaux commun qui facilite la communication entre ceux qui font et ceux qui veulent.
3. Je m’adresse également aux développeurs de services innovants, qui cherchent à implémenter une approche Lean Startup dans une grande entreprise. Même si ce n’est pas un livre sur l’innovation, elle tient une part importante dans le récit et ce livre devrait intéresser les responsables d’innovation, tout comme les « product managers » et « product owners ».

 

La figure suivante est tirée du troisième chapitre. C’est une forme de clin d’œil puisqu’elle illustre un principe général : permettre à ceux qui développent le code associé à des user stories de comprendre l’étoile polaire - les UVP (Unique Value Proposition) -  et l’observation des pain points qui ont conduit à cette étoile polaire. Ce schéma s’utilise habituellement sur des exemples de services concrets. Je milite depuis de nombreuses années sur la construction et la mise à jour de ce graphe de correspondance, car il est fréquent que les « user stories » évoluent pendant les allers-retours et les réunions (qui sont la marque de la taille de l’entreprise), et que le « sens » primitif se dilue. Mon expérience depuis plus de 10 ans est que la qualité du code produit est significativement meilleure lorsque le développeur connait les pain points – c’est évident, implicite et sans effort pour une startup ; dans une structure plus grande, cela se travaille. Je reproduis cette figure ici car elle résume le contenu de ce billet et la vocation du livre.

 

5. Du client au code et du code au client

 

Pour conclure, les lecteurs de ce blog auront reconnu l’illustration suivante, qui est la colonne vertébrale du livre et l’inspiration du sous-titre « du client au code et du code au client ».

 

Cette figure permet de reconnaitre les 3 contenus du livre évoqués plus haut :

• Du client au code : l’approche « lean startup », prise dans un sens large, avec un accent important sur le design et sur l’amélioration continue du produit après son lancement.
• Du code au client : l’approche « lean software factory », qui utilise le « lean software development » pour regrouper des pratiques agiles,  CICD et une approche « produit ».
• Une boucle perpétuelle et une organisation unique, en synergie, autour des produits (ou services) et des équipes qui construisent ces produits.  

 

 

 

 

Les habitudes de l’efficacité personnelle

1. Introduction

 

Ce billet est un billet d’été, une période favorable à la prise de recul et l’observation. J’ai décidé de revenir sur le sujet de l’efficacité personnelle, un sujet que j’aborde souvent dans ce blog sous le vocable de selfLean . Une de mes citations préférées est la phrase célèbre d’Aristote :  « Nous sommes ce que nous faisons de façon répétée, l’excellence est une habitude ». Je vais donc m’intéresser à l’efficacité personnelle, qui est une forme d’excellence, au travers des habitudes qui sont favorables à son développement. Sur le thème de l’importance des habitudes, il y a de nombreuses et excellentes ressources, mais je vous recommande le best-seller de James Clear, « Atomic Habits – An Easy & Proven Way to Build Good Habits and Break Bad Ones », que j’ai commenté ici. L’importances des pratiques et des habitudes pour implémenter l’amélioration continue, d’une personne comme d’une équipe, n’est plus à démontrer.

La deuxième référence que je peux faire ici à la pensée grecque est le fait de s’observer pour se connaitre : « Gnothi Seauton ». Mon intérêt prononcé pour le « quantified self » et le « self tracking », par exemple au travers de d’application Knomee, est dû à l’importance de l’observation à la fois pour mieux se comprendre et mettre en place des habitudes. Je peux citer ici Gretchen Rubin dans son livre célèbre « The Happiness Project » : « Current research underscores the wisdom of Benjamin Franklin chart keeping approach. People are more likely to make progress on goals that are broken into concrete, measurable actions, with some kind of structured accountability and positive reinforcement ». Pour développer son efficacité personnelle, il est essentiel de bien se connaitre. A l’inverse, les habitudes qui permettent de développer cette efficacité n’ont rien de révolutionnaire ou d’original. Elles sont connues depuis longtemps et ce qui est complexe, c’est la discipline pour les mettre en place et s’y tenir.

J’écoute un certain nombre de podcasts sur ce thème, comme le « Tim Ferris Show » ou « Le Gratin » de Pauline Laigneau. On retrouve dans les différents interviews, tout comme dans le livre de Bruce Daysley, beaucoup de thèmes communs et surtout de pratiques communes.  Dans cet esprit de « devenir une meilleure version de soi-même », ce billet se veut une synthèse des pratiques que j’essaye de transformer en habitudes pour augmenter mon efficacité personnelle, dans mon activité professionnelle et les différentes extensions, depuis l’écriture du blog (et des livres) jusqu’au développement (CLAIRE , GTES ou Knomee). Comme ce sont des sujets que j’ai déjà abordés, je vais rester synthétique et essayer d’avoir une vue en largeur plutôt qu’en profondeur. Je vais donc me limiter à une quinzaine de pratiques ou d’idées, sans trop essayer de vous convaincre.

Le billet est organisé comme suit. La section suivante commence par l’organisation des tâches, dans l’esprit de « Getting Things Done ». Si je marche clairement sur les pas de David Allen, j’y ajoute l’apport de l’approche lean au travers du « SelfLean » : organiser ses flux, réduire son WIP et rendre la complexité visible.  La section 3 s’intéresse plus en détail à la gestion du temps (ce qui est bien sûr un des aspects de la gestion des tâches). Toujours dans l’esprit lean, le plus important est de savoir maintenir l’ouverture aux opportunités, savoir « se hâter lentement » pour profiter d’un monde incertain et volatil. La section 4 traite de l’utilisation des lieux. Les lieux jouent un rôle important dans notre efficacité, à la fois d’un point de vue fonctionnel (il y a des lieux mieux adaptés que d’autres en fonction des activités) mais également d’un point de vue symbolique, comme ancrage de nos pratiques. Associer des pratiques à des lieux est un accélérateur de discipline. La dernière section porte sur la gestion de l’énergie, un sujet qui m’apparait de plus en plus fondamental en prenant de l’âge. C’est le sujet d’un autre best-seller, « The Power of Full Engagement », de Jim Loehr et Tony Schwartz, dont le sous-titre résume bien ce dont je vais parler : « Managing Energy, Not Time is the Key to High Performance and Personal Renewal ».

 

2. Bien gérer ses taches

La première pratique, la plus évidente à énoncer mais qui requiert beaucoup de discipline à exécuter, est de faire une chose (importante) à la fois, et de la faire vraiment bien. C’est le deuxième principe fondateur de Google: “Mieux vaut faire une seule chose et la faire bien ». Cette phrase seule mériterait un billet de blog; j’ai mis plus de 10 ans à comprendre sa profondeur. La première raison est l’inefficacité du multi-tasking, qui est aujourd’hui prouvé scientifiquement. La seconde raison est l’importance de l’impact pour maintenir notre engagement et notre énergie, j’y reviendrai. La troisième raison est l’importance de l’apprentissage, de l’amélioration continue pour développer notre « mastery », au sens de Daniel Pink. Il y a dans l’expression « la faire bien » une réflexivité nécessaire qui est la principale cause du dépassement de soi.

La deuxième pratique consiste à décharger son esprit de la charge mentale des choses à faire, et donc d’écrire des « to do » lists,  en suivant les recommandations de David Allen dans « Getting Things Done ». Je pratique depuis très longtemps les « to do », sur des échelles de temps variées (je vais y revenir), en mode « backlog » : le but est de vider mon esprit, pas de créer du stress supplémentaire avec des planning intenables. Tout ce qui est dans le backlog est noté pour ne pas être oublié (et libérer le cerveau de la tâche de s’en rappeler), mais une grande partie sera éliminée ensuite, selon les bonnes pratiques lean et agile (« choisir, c’est renoncer »). Je cherche à maximiser le flux de création de valeur, pas à faire le maximum de choses ni tenir le maximum d’engagements. La gestion du backlog a pour but de faire la bonne chose au bon moment, et donc de savoir attendre.

Si la ou les  « to do lists » sont des backlogs,  il faut utiliser d’autres solutions pour piloter son flux personnel de travail, et c’est ici que les outils lean de management visuel sont utiles. J’utilise depuis une dizaine d’année des « kanbans personnels » dont le premier but est de rendre visible la complexité/richesse du backlog pour m’aider à limiter mon « work in progress » et donc à faire des choix et renoncer. J’utilise par exemple le tableau (ou sa forme électronique) pour représenter chaque dossier (ou projet) en cours. Dans le type de jobs que j’occupe, le kanban est un outil essentiel pour mettre en œuvre la première pratique. Le kanban permet aussi de travailler le plus possible en mode pull, en fonction des consommateurs de ce que l’on produit. Un document qui n’est pas lu ne sert à rien, un mémo qui ne permet pas de conduire à une conversation ne libère, le plus souvent, que 10% de sa valeur potentielle.

3. Bien gérer son temps

L’outil qui me sert le plus est une structuration « fish eye » de mes horizons de temps, développée au cours des années. Cela me permet d’avoir une backlog pour un temps infini, avec des compartiments de même taille (en charge mentale) pour la journée qui vient, la semaine qui vient, le mois qui vient, l’année qui vient. Le principe de la vue fish-eye est d’avoir un bon niveau de détail pour ce qui est proche, et qui diminue pour ce qui est éloigné. Utiliser un planning multi-échelle avec cette contraction progressive du temps vers l’horizon permet une manipulation très facile de son backlog. On pourrait penser que la contraction du temps biaise la gestion de capacité, mais l’expérience montre au contraire que c’est une bonne pratique d’être d’autant plus restreint que l’horizon est lointain.

Je cite ici l’ouvrage de Bernard Leblanc-Halmos, « où trouver le temps ? » car c’est bien le sujet dont il s’agit ici, et cette lecture reste jubilatoire, même si le livre a 30 ans. Trouver le temps, c’est le préserver ; le rôle principal des outils de gestion du temps est de servir l’objectif de la section précédente – se donner le temps de bien faire ce que l’on fait ou l’éliminer de sa backlog – et, encore plus, se préserver l’agilité de pouvoir saisir les opportunités que l’on ne connait pas encore. Ce point est fondamental, il est à l’intersection de deux principes. Le premier principe « lean » veut que pour bien travailler, il faut se laisser des marges de manœuvre. Je parle très souvent de l’importance des « buffers » pour le travail d’équipe, mais cela s’applique également à l’efficacité personnelle, pour les mêmes raisons de complexité. Le second principe « agile » veut que chaque utilisation du temps soit comparée à sa valeur d’opportunité. C’est raisonnablement facile dans le présent (passer du backlog au kanban en faisant ses choix), c’est plus subtil lorsqu’il s’agit du futur que personne ne connait. Je vous renvoie ici à l’éloge de « festina lente » de Nassim Taleb dans Antifragile.

Une idée reçue veut que le temps soit fini, et qu’il soit le même pour tous. Pourtant, la perception du temps est relative et subjective. L’efficacité permet justement de dilater le temps, ou de compresser ce qui soit entrer dans une période de temps. C’est vrai pour le travail personnel, c’est également vrai pour la communication : une communication bien préparée est plus efficace et prend, ce que je constate années après années, moins de temps. Tout ceux qui travaillent avec moi savent que je suis un grand amateur de dessins, de schémas et d’illustrations. J’aime collaborer en dessinant au tableau, j’utilise des schémas pour expliquer, et cela marche beaucoup mieux en construisant le schéma pendant la conversation, ce que savent tous les enseignants. Collaborer exige de partager un contexte, utiliser les illustrations est une façon de « compresser le contexte » : plus le schéma est pertinent, moins il faut de temps pour se synchroniser sur ce contexte. De la même façon que la complexité de Kolmogorov lie l’intelligence à la compression, mon expérience est que le temps passé à construire ses arguments et représenter ses idées sous formes de dessins et schéma est un accélérateur d’efficacité, personnelle comme collective. C’est d’ailleurs le même argument qui me conduit à penser que l’utilisation des assistants cognitifs – qui se préparent pour les décennies à venir – vont être un formidable accélérateur de communication et de collaboration.

 

4. Bien gérer sa communication

Qu’il s’agisse d’email, de SMS ou de messages sur les différentes plateformes collaborative modernes, la communication asynchrone est un outil indispensable pour optimiser son efficacité, pour deux raisons évidentes :  le découplage temporel redonner la liberté d’optimiser son temps et l’efficacité de la lecture (on lit beaucoup plus vite que l’on n’écoute) permet de mieux gérer le problème de la surcharge des flux entrants. J’ai beaucoup écrit dans ce blog sur l’approche lean appliqué à la gestion des courriels (LEMM : Lean E-Mail Management), mais en me concentrant surtout sur le « système » émetteur-lecteur et les règles collectives d’usage. De façon plus personnelle, la pratique essentielle est de réduire le temps de traversée de sa boite mail, pour réduire le nombre (cf. la loi de Little), ce que je fais avec deux pratiques : éviter le rework (traiter chaque mail une seule fois) en utilisant des couleurs,  et traiter mes emails une fois par jour au moment que je choisis (matin) et de façon contrôlée (en exploitant sans remords la dimension asynchrone). Maintenir sa boite email dans un « état ordonné » est à la fois une application des principes précédents (réduire sa charge mentale) et la façon de résoudre un paradoxe : comment participer à l’accélération des flux (approche lean de l’efficacité collective) sans devenir un esclave de sa boite aux lettres. Si vous voulez plus de conseil sur la bonne façon de gérer le flux entrant désordonné de demandes, je vous conseille d’écouter Elizabeth Gilbert.

Une des idées les plus importantes de ce blog, tirée à la fois de mon expérience et de mes lectures, est que le travail dans un monde complexe exige la collaboration synchrone. Je vous renvoie au livre de Bruce Daisley, « The Joy of Work », que j’ai déjà commenté. La communication synchrone, qu’il s’agisse du standup meeting, du coup de fil, de la visio ou de la conversation devant un café, offre une « bandwidth », au sens de CMC,  beaucoup plus importante, c’est-à-dire la possibilité de construire des multiples boucles courtes de synchronisation, précisément. La communication synchrone est donc un bien précieux à protéger. D’une façon générale, je la réserve aux personnes avec qui je travaille et je renvoie les autres vers les canaux asynchrones. Pour être efficace, la communication synchrone demande un fort engagement, ce qui me conduit à réguler les plages de temps que je lui alloue, par exemple en ne répondant pas au téléphone lorsque je travaille. Pour être encore plus précis, j’utilise le synchrone pour le transport des informations complexe mais l’asynchrone pour la signalisation (la mise en place des flux synchrones). De façon plus générale, je souscris à 100% au besoin de chasser les interruptions, un point clé de Bruce Daisley qui correspond à plus de 20 ans de recherche scientifique. La suppression des notifications est un « must », cela ne me semble plus être un objet de débat.

Un cas particulier de la communication synchrone qui mérite beaucoup d’attention dans nos vies modernes est celui des réunions. Ici aussi, c’est un sujet dont j’ai beaucoup parlé dans ce blog, mais plutôt d’un point de vue systémique et collectif.  Du point de vue de l’efficacité personnelle,  je retiens deux principes. Le premier est de limiter constamment le temps passé dans les réunions planifiées pour garder du temps pour des réunions non planifiées, pour profiter de la sérendipité et augmenter son agilité. C’est très difficile, même avec beaucoup de discipline (j’utilise depuis 15 ans un tableau mensuel pour mesurer la charge des réunions planifiées) et cela ne doit pas faire oublier que plus l’organisation est large, plus la planification est nécessaire. Autrement dit il s’agit de faire le moins de réunions possible, mais pas moins que le nécessaire. Le second principe, encore plus exigeant du point de vue de la discipline, est de bien préparer chaque réunion. Une réunion est un « commun »,  dans le sens des économistes, il appartient à chacun d’en tirer le meilleur profit et évitant « la tragédie des communs ». Je m’étais proposé, il y a 15 ans, de ne pas participer aux réunions que je n’avais pas le temps de bien préparer, mais je ne suis jamais arrivé à me tenir à cette règle. En revanche, la version plus souple de ce principe, qui consiste à allouer du temps de préparation à chaque réunion au moment où elle est inscrite dans l’agenda, fonctionne très bien et augmente significativement l’efficacité personnelle.

L’application des principes de cette section peut conduire à un renforcement des « liens forts » et un renfermement sur son monde connu. C’est pour cela qu’il faut complémenter ces pratiques avec d’autres qui permettent de développer ses liens faibles. Développer ses liens faibles, c’est en premier lieu parler à « des gens que l’on ne connait pas », alors que tout est fait pour rester dans son « réseau personnel ». Depuis Mark Granovetter, nous connaissons la force des liens faibles. L’écriture de ce blog est un exemple de pratique qui correspond à ce principe. La même remarque s’applique bien sûr à la présence sur les réseaux sociaux. La pratique de l’écriture de billet de blog est à la fois un exercice de « compression » (écrire c’est mettre ses idées au clair) et une façon de constamment développer des liens faibles. Au bout de 15 ans de pratique (sous toutes ses formes, au-delà du blog), je peux témoigner de la grande contribution de mon « réseau faible » à mon efficacité personnelle. Bien sûr, cela ouvre la question de la surexposition à des flux entrants, mais une fois de plus, tout est question de discipline.  La meilleure pratique que je connaisse pour éviter d’être noyé sous les flux d’articles qui me sont poussés quotidiennement est de donner une solide préférence aux livres.

5. Bien gérer sa localisation

Je me suis considéré pendant de nombreuses années comme un « road warrior » capable de travailler n’importe où avec mon ordinateur, indépendamment du lieu ou du contexte. La raison principale étant de pouvoir grapiller toute occasion d’ouvrir le PC et de pouvoir coder, avec le sentiment d’une grande efficacité personnelle. Pourtant, même si la technologie donne des ailes à cette ambition ATAWAD (anywhere, anytime, any device), le lieu où l’on travaille compte, et il faut savoir en profiter pour développer son efficacité personnelle. Après deux mois de confinement lié à la COVID, nous avons pu constater que le télétravail à la maison fonctionne, mais que le bureau est souvent mieux adapté pour le travail collectif, lorsqu’il s’agit de cocréer, d’influencer ou d’expliquer. Il me semble d’ailleurs clair, comme le souligne Emmanuelle Duez dans cet interview, que ce que nous avons appris sur l’adéquation entre le lieu et le type de travail va nous conduire à réinterpréter le rôle des lieux collectifs. Cette importance du lieu s’applique également à l’échelle individuelle : même s’il est possible de faire « tout partout », il y a des lieux qui se prêtent mieux que d’autres à certaines activités : du silence pour se concentrer, de la vie pour « s’aérer les neurones », la capacité de bouger, la vue qui incite à la réflexion ou la distraction, etc.

La technologie et la numérisation sont les supports de cette capacité de pouvoir faire ce qu’on veut où l’on veut. En revanche, je reste un fervent partisan du papier et des tableaux blancs. Bien sûr, il est difficile de dissocier cette remarque de mon âge ou mon éducation, mais le tableau blanc, ou les feuilles (multiples) de papier, permettent à la fois un affichage concurrent d’une grande masse d’information (ce que Nicolas Lochet appelle un « radiateur d’information » : le support « émet » l’information, que vous le lui demandiez ou non ) et une capacité d’édition collaborative multi-échelle inégalée (la résolution d’un feutre au tableau permet de faire des annotations multiples, à des niveaux de détail différents, qui restent visibles de tous). Il y a les lieux sans tableaux, les lieux avec un tableau et les lieux avec des multiples tableaux (sur les murs ou à la place des murs) … et on ne travaille pas de la même façon, avec la même efficacité. Je parle souvent de stigmergie dans ce blog, la capacité d’utiliser les lieux pour communiquer, qu’il s’agisse des tableaux blancs, des murs pour le management visuels ou des différentes formes d’affichage sur les lieux de passage. C’est une des nombreuses composantes qui font des bureaux des outils collaboratifs indispensables. Comme le disent Eric Schmidt et Jonathan Rosenberg dans « How Google works », les projets ambitieux du monde complexe nécessite des lieux où les gens « work, eat and live together » : « Buildings should promote interactions between employees … This sort of serendipitous encounter will never happen when you are working at home ».

L’utilisation des lieux peut se faire d’une façon plus personnelle comme un support aux bonnes habitudes, aux pratiques que nous avons mentionnées.  Associer un type d’activité (lire, préparer ses réunions, répondre à ses mails, coder, annoter un document, etc.) à un lieu (une pièce de sa maison, un endroit sur son lieu de travail) est une façon de créer un ancrage. L’évolution nous a rendu très susceptibles à ce type d’ancrage, c’est donc un excellent outil pour développer des pratiques. Cela fonctionne dans les deux sens : le lieu peut devenir l’endroit où une bonne pratique se développe, mais également un rempart contre des mauvaises habitudes. J’ai évoqué – brièvement, c’est un autre sujet – l’importance de l’information overload. Utiliser les lieux peut signifier créer des « sanctuaires », des endroits où certains flux de sollicitation ne sont pas admis. Pour prendre la bonne habitude d’utiliser les livres comme principal vecteur d’apprentissage, les lieux sont très utiles (une fois l’habitude prise, elle devient facilement nomade). Le temps et l’espace sont également importants, il faut les associer pour construire ses habitudes. Faire une chose dans un lieu, c’est une façon d’éviter de céder à l’urgence, d’attendre son « rendez-vous avec soi-même », au bon moment et au bon endroit, pour faire quelque chose mieux, et plus tard.

6. Bien gérer son énergie

L’importance de la gestion de l’énergie est devenue un sujet de grande attention depuis une quinzaine d’année. Si vous ne connaissez pas ce domaine, je vous recommande l’article de Harvard Business Review, de Tony Schwartz et Catherine McCarthy : « Manage Your Energy, Not Your Time ». Le point fondamental est que les habitudes et rituels permettent de mieux gérer notre énergie : « energy can be systematically expanded and regularly renewed by establishing specific rituals – behaviors that are intentionally practiced and precisely scheduled, with the goal of making them unconscious and automatic as quickly as possible ». Les idées clés ne devraient pas vous surprendre : il s’agit de bien gérer son sommeil, de faire de l’exercice, de savoir prendre des pauses et de nourrir sa motivation. Il est important de savoir s’observer, d’apprendre les activités qui consomment de l’énergie et celles qui permettent de se « resourcer », pour construire, comme les athlètes, un programme de développement fractionné, par intervalles.  L’article de HBR parle de « ultradian sprints » qui sont des périodes de 90 à 120 minutes, séparées par de vraies pauses. Pour reprendre une idée clé du livre citée en introduction, l’énergie se perd (n’est pas utilisée avec l’efficacité maximale) lorsqu’on en utilise trop ou trop peu. Il faut penser sous forme d’alternance de sprints et de récupération, et pas une utilisation continue (ce qui n’est pas forcément intuitif). On retrouve dans les recommandations pour bien gérer son énergie des pratiques que nous avons déjà évoquées : éviter le multi-tasking, prendre des décisions rapide pour alléger la charge mentale, se fixer des zones et des limites.

L’outil fondamental de la gestion de l’énergie est l’auto-observation et la chrono-analyse. Je vous recommande ici la lecture du livre de Daniel Pink : « When – The scientific secrets of perfect timing ». Il faut savoir reconnaitre ses variations d’énergie et utilise les bons moments de la journée : « First, our cognitive abilities do not remain static over the course of a day. During the sixteen or so hours we’re awake, they change—often in a regular, foreseeable manner. We are smarter, faster, dimmer, slower, more creative, and less creative in some parts of the day than others ». J’utilise l’application Knomee pour “tracker” mon énergie et construire mes histogrammes, ce qui m’a permis de redécouvrir ce qu’explique Daniel Pink : nous avons des cycles semblables. On retrouve la même conviction dans l’article de Sebastien Martin « How to start managing your energy levels instead of your time”. Je pratique le conseil qu’il donne : « One important thing to do in high-energy times is to plan tasks for low energy. That is why I put “writing to-do lists” in the high-energy time: planning is much easier when you have an overview ».

Je suis de plus en plus persuadé que la gestion de l’énergie est le levier le plus central de l’efficacité personnelle. On retrouve d’ailleurs l’importance d’un des cycles fondamentaux de la biologie, celui de l’apprentissage, qui se résume de façon un peu caricaturale par : l’action réussie procure un plaisir qui engendre le désir qui conduit au plan qui entraine de nouveau l’action. Dans une boucle d’apprentissage, le plaisir lié au feedback et au sentiment d’impact, tout comme le désir qui nous relie au sens et alimente la motivation, sont essentiels. Pour développer son énergie, il faut cultiver sa motivation. Ce qui conditionne le succès, « c’est d’avoir envie ». On touche ici à une dimension personnelle, et je ne connais pas de pratiques ou de conseils qui s’appliqueraient à tous. C’est à chacun de savoir ce qui nous motive, ce qui nous donne le sentiment de progresser, ce qui nous rassure sur l’impact de nos activité (à l’exact opposé des fameux « bullshit jobs » sans impact). En revanche, ce que tous les articles et livres qui traitent de la gestion de l’énergie soulignent, c’est qu’il nous appartient de nous connaitre et d’inclure dans nos agendas les quantités nécessaires des activités qui nous ressourcent, soit simplement par le plaisir qu’elles procurent, soit parce qu’elles contribuent au sens que nous souhaitons donner à nos actions.

 

7. Conclusion

Ce billet se veut être un partage d’expérience, même si chacun bénéficie différemment des pratiques et des habitudes que je viens d’évoquer. D’un côté, les pratiques et les raisons scientifiques qui les soutiennent sont assez universelles, elles sont d’ailleurs en général connues depuis longtemps. D’un autre côté, l’impact sur l’efficacité personnelle de chacun est variable et surtout, l’effort nécessaire à mettre en place ces habitudes est très différent d’une personne à l’autre. Puisque les efforts varient selon l’invididu et les circonstances – exactement comme le télétravail –, le rapport coût/bénéfice reste à l’appréciation de chacun. De plus , les pratiques que j’ai évoquées ici ne sont pas forcément intuitives. Il ne faudrait pas d’ailleurs penser que je les adoptées facilement, suite à une lecture éclairante. Tout au contraire, sur la plupart de ces points, mes habitudes personnelles de départ étaient à l’opposé de ce que j’écris aujourd’hui. Il convient donc de prendre tout cela avec un grain de sel, comme une invitation à la réflexion. Je termine en soulignant que j’ai traité ici de l’efficacité personnelle, par opposition à l’efficacité collective, qui est le sujet de mon précédent livre « Processus et Entreprise 2.0 ». Les deux thèmes sont en fait fortement liés, à la fois sous forme de synergie – chacun alimente l’autre – et sous forme de contraintes systémiques. Certaines des pratiques que j’ai exposées ici sont indépendantes, chacun peut les appliquer ou non,  sans se préoccuper du système global. A l’inverse, certaines pratiques comme la bonne façon d’utiliser ses canaux de communication, ou de gérer ses réunions sont complètement couplées aux pratiques collectives de son organisation.