jeudi, juin 30, 2016

Lean et Agile d'un point de vue métier


Le billet de ce jour est une réflexion personnelle sur les principes et valeurs qui sous-tendent les démarches lean et agile, indépendamment du domaine d’application, qu’il s’agisse de production, de service, de logiciel ou d’innovation. Tout comme le mot « lean » est souvent utilisé à contre-emploi pour désigner des politiques de réduction de coûts qui réduisent également les capacités d’apprentissage et de coopération, le mot « agile » est également mis à toutes les sauces, quelque fois sous forme de véritable contre-sens.
Je vais commencer par un rapide tour d’horizon de l’utilisation du lean dans les processus de ventes (lean sales). Lorsque j’ai écrit mon livre « Processus et Entreprise 2.0 – Innover par le lean et la collaboration » en 2010, j’ai été frappé par les résultats spectaculaires dans d’autres domaines, tels que le « lean healthcare » ou le « lean sales ». Je ne suis pas un spécialiste, donc je ferai juste un bref résumé des idées principales tirées de quelques lectures. Cela me conduira à une deuxième section sur les quelques principes fondamentaux, de mon point de vue, lorsque j’applique le lean au développement logiciel (Lean Software Factory) ou à l’innovation (Lean Startup).
La troisième section portera sur l’agilité, vue d’un point de vue métier. J’ai plusieurs fois raconté la visite de Spotify par l’équipe de direction de Bouygues Telecom il y a quelques années comme un moment pivot dans ma compréhension de l’agilité : le CEO nous a défini l’agilité comme une réaction adaptative à l’environnement, d’un point de vue stratégique. L’agilité informatique devient une conséquence de l’agilité métier, et non pas l’inverse. Je vais de la même façon décrire ma vision personnelle de l’agilité dans la section suivante, du point de vue des objectifs et de ce qu’il convient de mesurer – ou non – pour progresser.
Il y a un lien fort entre les deux parties : tels que je les définis, le lean et l’agile sont compatibles, complémentaires et se renforcent. Ce n’est pas forcément le cas si le lean est pris comme une volonté de contrôle et de réduction (qui se heurte à l’adaptabilité de l’approche agile) ni si l’agile est pris comme une méthode d’ubérisation du travail – dans une vision pseudo-moderne du travail fondée sur les nouvelles technologies de communication – qui se heurte à la dimension fondamentale de l’apprentissage collectif par équipe.

1 -  “Lean Sales”

Je commence par une photo du livre “Lean Thinking” car c’est la référence que l’on trouve dans tous les articles que je vais citer sur “Lean Sales”. Les deux livres de James Womack et Daniel Jones, « Lean Thinking » et « Lean Solutions » sont les premières étapes fondamentales pour comprendre le sujet que je vais évoquer brièvement. Il y a trois très bonnes raisons d’appliquer le lean à la vente : (1) il s’agit bien d’un processus, avec des étapes bien définies et qui est assez facile à mesurer – et cette pratique de la mesure est ancienne dans les équipes de vente (2) c’est un travail d’équipe – c’est plus ou moins visible selon l’activité et la forme de relation entre le client et le vendeur, mais c’est toujours le cas (3) la satisfaction du client est, par essence, au cœur du processus de vente – cela ne veut pas dire que ce soit l’objectif du processus, loin s’en faut ! Mais une grande partie des fondamentaux du lean – le centrage sur la valeur apportée au client – est depuis longtemps ce qui caractérise les « bons vendeurs » sur le long terme. Je ne vais pas donner les détails d’une approche lean sales, je vous renvoie par exemple au slideshare de David Brunt et John Kiff, mais souligner sept idées intéressantes de l’approche Lean Sales :
  • La première idée essentielle du lean est de se centrer sur la valeur fournie au client par le processus de vente. Il s’agit donc – sans surprise – de se mettre à la place du client. L’approche du « Value Stream Mapping » s’applique parfaitement au processus de vente (voir par exemple la formalisation dans l’article de Simon Elias et Richard Harrison). L’analyse passe bien sûr par l’écoute et l’observation des clients, avec des projets de type « Voice of the Customer (VoC) », un des classiques des approches Lean Six Sigma.
  • Une fois la valeur définie du point de vue du client, l’approche lean cherche à optimiser le processus en supprimant tout ce qui est inutile – le  « muda », en notant que gaspillage est une mauvaise traduction. En particulier, le lean s’intéresse à la suppression des temps morts (ceux qui n’apportent pas de valeur client), ce qui est remarquablement en ligne avec l’impératif du 21e siècle de traiter le temps du client comme la chose la plus précieuse.  Pour faire cette optimisation, le lean apporte tout un ensemble de techniques et de méthodes, depuis le kaizen sur lequel je vais revenir jusqu’à l’analyse des causes profondes avec la pratique des « Five Whys ». Je vous recommande le billet de Mark Preston, « My Top 10 Secrets of Lean Manufacturing Sales ».
  • Cet allègement du processus permet progressivement d’appliquer un autre principe lean, le « streamlining », ou l’optimisation du flot. Au-delà de la suppression du « muda », on cherche également la réduction de « mura » et « muri », c’est-à-dire la stabilisation du flot  -atténuer les irrégularités - et éviter les périodes de surcharge. Ici le lean sales se démarque d’un certain nombre de pratiques de ventes qui sont marquées par des fortes irrégularités amplifiées par le calendrier de l’entreprise (le « closing » de fin de période n’est pas une approche centrée sur le client). Ce sujet est abordé dans l’article de Brian Maskell, « Lean Sales & Marketing ». 
  • Une fois le processus « réorganisé par streamlining », on inverse la logique de déclenchement et on passe du « push » au « pull ». Autrement dit, les signaux pour passer d’une étape à une autre ne sont plus produits par la complétion d’une étape (vers la suivante), mais c’est le besoin d’une étape qui déclenche l’étape précédente. De la sorte la vie du processus n’est plus rythmée par la capacité de production, mais par la demande client, en tenant compte des capacités propres à chaque étape (à travers un kanban). C’est, à mon avis, une des raisons principales pour laquelle le Lean Sales va devenir de plus en plus populaire au 21e siècle, en particulier dans le monde digital. Je vous renvoie aux différents articles de ce blog sur « The Intention Economy » ou sur « Le Marketing Synchronisé ». Nous sommes entrés dans l’ère du « pull », lorsque l’entreprise écoute les besoins et les moments du client, et avons quitté – pour les entreprises avancées – l’ère du push publicitaire de masse.
  • Toutes ces étapes précédentes – ce qui constitue le lean sales - s’appuient sur une approche d’optimisation continue, fondée sur la mesure. Les mesures sont collectées et partagées de façon continue par les équipes, en utilisant des approches de management visuel.  Le travail d’amélioration est fait en pratiquant le kaizen, en équipe. Les chiffres sont ceux de l’équipe, ils servent à comprendre et améliorer les techniques de ventes. Il ne s’agit pas de supprimer les « objectifs de vente » qui sont consubstantiels à la profession, mais de comprendre que le « standard » appartient à l’équipe et qu’une partie des indicateurs ne sont pas de KPI, mais des outils de progrès  (je reviendrai sur ce point clé dans la Section 4).
  • Le lean est ancré dans une approche du management de la qualité totale, parce que Taiichi Ohno a été influencé par W.E. Deming. L’objectif d’un processus lean est d’être « Right on the first time, every time ». Cet objectif, lié au premier sujet de la satisfaction du client, alimente de façon constante le kaizen. Une fois de plus, il faut souligner l’importance du temps du client, qu’il faut donc mesurer pendant les différentes étapes du processus. Comme dans la plupart des sujets d’optimisation de processus de service, le temps d’attente est une des premières causes d’insatisfaction des clients ou prospects.
  • La dernière idée commune aux articles que je viens de citer – souvent exprimée dans leurs titres – est qu’il faut traiter l’ensemble du processus « Marketing & Vente » dans une démarche unifiée.  Pour travailler efficacement en kaizen, il faut que les différents acteurs du processus commun soient organisés en équipe. Je vous renvoie à l’article de Brian Haskell sur l’importance du kaizen et du travail d’équipe.   



2.                  Les fondations du « Lean Thinking » 




Je vais poursuivre cet exercice d’abstraction en soulignant 5 principes que l’on vient de voir dans la section précédente et qui sont commune aux démarches « lean software » et « lean startup ». Ce sont également des principes que j’applique dans le self lean et que j’ai retrouvé avec plaisir dans l’excellent livre « Personal Kanban » que je viens de terminer et que je vous recommande. A ce niveau de synthèse, il s’agit forcément d’un exercice très subjectif et très incomplet.


  • La satisfaction du client/utilisateur est le « true north » d’une démarche lean, c’est le but commun à toutes les équipes et le terrain d’entente pour arbitrer les différences d’opinion. Cette satisfaction se mesure – qualitativement et quantitativement – et la mesure est partagée par tous les acteurs.
  • L’organisation a pour objectif de fluidifier le processus, en relaxant les contraintes de ressources, en fragmentant la charge (les « petits lots »), réduisant les enchaînements pour avoir un fonctionnement le plus continu possible.
  • L’approche « pull », dirigée par la demande client, donne le tempo commun à l’ensemble de l’organisation. Le mode « pull », matérialisé par le kanban, suppose une simplification et une fluidification du processus, c’est un objectif de long terme. L’objectif systémique de cette approche est la résistance aux aléas, qui permet justement de s’adapter à son environnement.
  • Le fonctionnement fluide en flux tirés, tout comme la satisfaction totale du client, est un objectif asymptotique qui s’approche par amélioration continue, grâce au travail de kaizen d’équipes autonomes. Les équipes progressent et capitalisent grâce à une standardisation de leurs pratiques, mais c’est leur standard. Le kaizen est un outil pour apprendre à travailler ensemble via la résolution de problèmes.
  • Le lean est, en effet, une méthode pour l’apprentissage collectif de la complexité. C’est pour cela qu’il repose sur le management visuel, sur l’inspection en équipe de la réalité et qu’il se méfie de l’abstraction (cf. le genchi gembutsu). La pratique continue des 5 pourquoi (la recherche des causes profondes) est également une méthode de formation pratique à la systémique de l’environnement.


Tout ceci reste encore un peu long et compliqué :) Je vous propose ma vision globale comme résumé – et clin d’œil -  de l’ensemble de ce blog en trois points :

  • Le sujet clé des entreprises au 21e siècle est le conflit entre engagement et complexité. L’accroissement de la complexité est inexorable - car il vient de l’environnement - et produit du désengagement (remarquablement expliqué par Yves Morieux, mais globalement un fait incontestable).
  • La seule façon de retrouver de l’engagement est de favoriser la motivation intrinsèque, autour du triplet : autonomy / mastery /purpose (emprunté à Daniel Pink, mais également un résultat avéré)
  • Le lean est fondamentalement adapté au 21e siècle car il répond à ces trois besoins : le besoin de sens vient de la satisfaction client partagée avec tous les acteurs, le besoin de « mastery » (difficile à traduire, un mélange de maîtrise, de confiance en soi et de sentiment de progression) est obtenue par la pratique du kaizen, et enfin l’autonomie des équipes est valorisée par la priorité au terrain (gemba) et aux faits (mesures) sur le contrôle externe.

https://lh4.googleusercontent.com/-mnE-WpoSdq5cIxJM4_5v1t6Q0yqp-M4IO5kja3dP0M1OXZN2OPzGHzeFHEdB-C41fdhWRZQ-_dO3rmEoBor3PK3obRgIkJjZhqINYJNDwM-K5hTOgLxWv_QaiHDWCsVqKMfEr5O




3.                  Manifeste Agile et Contre-Manifeste Agile

     

Pour comprendre ce qu’est l’agilité, en tant que mode d’organisation, il faut remonter aux sources, c’est-à-dire au « agile manifesto » et son apparition dans le monde du logiciel il y a une vingtaine d’années. Le mouvement agile est une réaction systémique à l’inefficacité des projets informatiques confrontés à une complexité croissante, en particulier à cause du rôle de plus en plus important de l’utilisateur. Le mouvement agile prône quatre valeurs. La première est que dans un contexte complexe et changeant, les hommes et les femmes sont plus importants que les processus et les outils (« individuals over tools »).  Pour moi qui pratique l’informatique depuis longtemps, ce changement depuis l’unité d’œuvre banalisé (le jour-homme de développement) à la reconnaissance du talent est un changement majeur, indissociable du fonctionnement agile. La seconde valeur affirme la primauté de ce que l’on construit sur sa description (« working software over documentation »). Dans un monde complexe, il est souvent plus facile de faire que décrire; dans un monde changeant, la description est au service de la réalisation (pour la capitalisation, le partage, la maintenance, etc .) mais elle ne précède pas cette réalisation. La troisième valeur dit qu’il faut préférer la collaboration avec le client (« customer collaboration over contract »). Dans le contexte du manifeste agile, on parle du client « interne », mais ceci s’étend facilement au client utilisateur). La dernière valeur est celle qui justifie le terme d’agilité : il faut accueillir les changements à bras ouverts au lieu de vouloir suivre un plan fixé à l’avance (« responding to change over following a plan »).  L’objectif de l’organisation agile est de pouvoir répondre efficacement à ces changements pour s’adapter de façon continue à l’environnement, externe et interne.  Les changements continus du monde externe entrainent qu’il faut réviser de façon fréquente ce qu’on produit. Les changements internes viennent de la complexité de ce qu’on cherche à fabriquer (des expériences qui satisfont totalement l’utilisateur), et il convient par conséquent de s’adapter aux difficultés rencontrées. Pour cela, le manifeste agile (dans une version française empruntée ici) propose douze principes du fonctionnement agile :

  1. Satisfaire le client est la priorité
  2. Accueillir les demandes de changement « à bras ouverts »
  3. Livrer le plus souvent possible des versions opérationnelles de l’application
  4. Assurer une coopération permanente entre Client et Equipe projet
  5. Construire des projets autour d’individus motivés
  6. Privilégier la conversation en face à face
  7. Mesurer l’avancement du projet en termes de fonctionnalités de l’application
  8. Faire avancer le projet à un rythme soutenable et constant
  9. Porter une attention continue à l’excellence technique et à la conception
  10. Favoriser la simplicité
  11. Responsabiliser les équipes: les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
  12. Ajuster, à intervalles réguliers, son comportement, ses processus pour être plus efficace


Je ne m’intéresserai pas aujourd’hui à l’agilité dans le développement logiciel. Une grande partie de ces principes sont plus profonds et plus large que le simple domaine du développement logiciel. Comme je l’ai dit en introduction, la démarche agile est une adaptation systémique de l’organisation de l’entreprise à son environnement. Le point de départ de l’argument du CEO de Spotify  est que les technologies – compression audio, stockage, recommandation – changent à une vitesse élevée qui augmente constamment, mais surtout que les usages changent constamment. En particulier l’adoption de pratiques ou de nouveaux comportements numériques suit des lois sociologiques de réseaux, avec des phénomènes d’amplification non linéaires qui sont la signature des succès du monde numérique. Le succès de Spotify vient de sa capacité à « lire son environnement » de façon continue et à s’y adapter de façon constante, au moyen d’une organisation agile.  Je ne m’étends pas d’avantage sur la dimension systémique, je vous renvoie au livre de Jurgen Appelo « Management 3.0 - Leading Agile Developers, Developing Agile Leaders »  qui explique cela en détail. L’agilité est une méthode pour d’adapter à un besoin instable (soumis à des changements) et incertain (à cause de la complexité de l’environnement, il suffit de relire Taleb ).
Dans l’esprit de la section précédente, voici les cinq principes qui caractérisent, selon moi, un fonctionnement agile :

  • La satisfaction du client est le fondement d’une démarche de développement produit (Principe 1). Ce pilier est partagé avec le lean, c’est l’outil principal d’alignement d’équipes autonomes
  • Ceux qui construisent (un produit, un service, une expérience) doivent être responsable du processus de construction. C’est la conséquence de la complexité : l’expérience ne se délègue pas (d’où l’insistance sur le « gemba » dans le lean). Dans le monde logiciel, l’équipe de développement maîtrise son calendrier, même si le « quoi » est confié au « product owner » (Principe 4).
  • La communication personnelle, face à face, est le ciment de la méthode agile (Principe 6). D’une part, parce que les sujets sont complexes et que la formalisation écrite est coûteuse et imparfaite ; d’autre part, parce que la dimension corporelle de la communication est indispensable à la véritable synchronisation.
  • Les rituels d’équipes utilisent les tableaux et les murs pour favoriser la communication. Le maximum de chose est affiché, en utilisant la puissance du management visuel comme « radiateur d’information ».  Ce partage et autocontrôle de l’équipe assure le bon rythme de travail (Principe 8).
  • Les défis complexes requièrent des équipes cross-fonctionnelles qui travaillent ensemble, de façon synchronisée et itérative (Principe 11).


J’ai déjà évoqué dans ce blog différents travaux sur le futur du travail. Certains travaux du MIT ou de Digiwork décrivent un mode de travail éclaté sur des plateformes technologiques, de type Uber. Je vais ici caricaturer quelque peu, mais voici ce que le « travail de demain » pourrait proposer comme nouveau manifeste :
  • « Nous n’avons plus besoin de rencontres face à face, les outils de communication électroniques nous suffisent »
  • « les espaces physiques ne sont plus nécessaires, nous sommes des travailleurs nomades capables de travailler n’importe où »
  • « Nous n’avons pas besoin d’organisateurs, il nous suffit d’une plateforme électronique pour décomposer nos projets en tâches bien précises » (note : on hésite entre le triomphe d’Uber ou de Taylor)
  • « Nous avons aboli la contrainte du temps partagé, chacun travaille quand il veut, d’où il veut, selon son biorythme et en fonction de ses contraintes personnelles »
  • Nous exigeons une définition précise des rôles de chacun qui nous permet de digitaliser la collaboration – chacun de nous est un expert

Je ne vais pas répéter les arguments de mon billet précédent, mais il est facile de voir que cette approche constitue, pour moi, un manifeste anti-agile. Je recommande également la lecture de « How Google Works » de et Eric Schmidt et Jonathan Rosenberg.


4.                  Les fondations du “Agile Thinking”


Pour terminer, je vais essayer de répondre brièvement à la question : comment savoir et mesurer si on travaille de façon agile ? Appliquer des principes n’est clairement pas un objectif en soi. Le but de la démarche agile est de mieux travailler dans un environnement  complexe et incertain. Dans le cas contraire, lorsque les besoins sont clairs et stables, les méthodes  classiques et taylorisées (cycle en V par exemple) restent redoutablement efficaces. Mesurer la valeur produite par le développement logiciel a toujours été difficile, mais mesurer l’impact des aléas et de la complexité l’est encore plus. Définir une mesure de la valeur apportée par l’agilité n’est donc pas une chose simple, et cette démarche relève le plus souvent d’une démarche de conviction.

La première idée fondamentale est de bien traiter l’organisation agile comme un système, en incluant la demande (les équipes « métier »). Il reste encore des entreprises qui demandent à leur IT de « devenir agile » sans changer l’ensemble de l’organisation en général, et sans changer la gestion de la demande en particulier. Les résultats sont piètres (très faibles progrès en vélocité et flexibilité) lorsqu’ils ne sont pas inexistants (souvent les coûts augmentent pour une satisfaction client qui n’augmente pas). D’une part c’est l’ensemble métier + développement qui peut former un système véritablement agile qui s’adapter au changement, mais de plus une équipe de développement agile qui exécute dans le cadre classique de spécifications contractuelles part avec un gros handicap.

La deuxième idée que je retiens de mon expérience est qu’il est plus facile de caractériser la non-agilité que l’agilité. J’ai participé à plusieurs audits et évaluation des pratiques agiles, ce que les experts recherchent sont trois défauts qu’il est possible d’identifier et qui montre la faible adaptabilité au changement constant de la demande et à sa complexité : (a) le « rework », c’est-à-dire le nombre de fois ou le même fragment de code est repris/ re-codé, parce que la spécification n’est pas conforme au besoin, (b) le temps de déploiement trop long par rapport aux besoins du marché, malgré tous les efforts de priorisation  (c) le code non déployé, qui est un cas limite des deux précédents, et un bon indicateur de dysfonctionnement. Le code non-déployé est à la fois un gâchis de ressource et une véritable plaie pour le moral et l’engagement des équipes. C’est pourtant un problème fréquent des grandes organisations.


Mesurer l’efficacité d’une démarche agile peut se faire de façon globale – extrinsèque par rapport au processus de développement -, à partir de l’analyse de la valeur, ou de façon intrinsèque, en mesurant « le bon fonctionnement ». La mesure de la valeur est possible, mais c’est un sujet difficile que j’ai traité dans mon second livre et que je ne vais pas aborder ici. Ce n’est pas par simple paresse ou manque de temps, je pense que la complexité des métiers du 21e siècle rend l’analyse très complexe et demande une maturité difficilement atteignable. La valeur créée se mesure fort bien, mais elle s’analyse et se prédit difficilement, ce qui en fait un mauvais critère d’efficacité. Je préfère une approche plus globale centrée sur la satisfaction du client, dont la création de valeur – au sens financier du terme – devient un bénéfice collatéral et essentiel, mais pas l’outil de pilotage. Je n’ai pas le temps ici de développer d’avantage. Je vous renvoie à la lecture de « Joy Inc. – How we built a workplace people love » de Richard Sheridan pour comprendre l’intrication entre la méthode de travail agile et la création de valeur du point de vue métier.  La mesure de l’efficacité intrinsèque peut se faire au moyen des trois indicateurs évoqués plus haut :  la quantité de « rework » (j’ai découvert cette approche lors de mon premier audit en tant que DSI par CSC il y a 10 ans), la quantité de code non livré (qui est facile à mesurer lorsqu’on se place dans une approche de développement industriel de type « software factory »), et le TTM –time to market/to delivery, que l’on mesure comme le temps entre la rédaction d’une « user story » et le moment où cette expérience est livrée entre les mains des utilisateurs. Le TTM/TTD est fortement lié au cadencement du déploiement, c’est-à-dire le rythme des mises en production (le « takt time » du lean). La démarche DevOps vers le déploiement continu représente une transformation globale, de grande ampleur, de la chaine de développement.

La mesure de l’efficacité, lorsqu’on est en présence d’un système complexe – non-linéaire- de création de valeur est pleine de piège. Par exemple, il est judicieux de mesurer la rapidité sous forme de TTM d’une modification élémentaire. L’expression classique est le « temps qu’il faut pour déployer une modification de 10 lignes de code ». En revanche, la mesure de la vélocité (ratio du nombre de « user story » / « points »  par unité de temps) a rapidement un effet pervers, puisque la méthode agile repose sur l’auto-évaluation du poids des tâches par l’équipe elle-même pour obtenir un fonctionnement lissé (selon les principes lean évoqués plus haut). Faire de la vélocité un KPI (Key Performance Indicator) conduit à une dérive des estimations. La vélocité est un indicateur de fonctionnement, très utile à l’équipe pour évaluer ses propres axes de progrès. Je vous renvoie au chapitre deux de mon dernier livre sur la différence entre les KPI (qui sont globaux, compris de tous, et dont la recherche de l’amélioration est vertueuse par définition – comme par exemple la satisfaction client) avec les indicateurs de performance et de fonctionnement, qui permettent à une équipe de mieux évaluer son fonctionnement ou son efficacité, dans un contexte global où il convient de trouver un équilibre entre des indicateurs contradictoires (comme le célèbre compromis coût / délai). Pour prendre un autre exemple, le « rework » n’est pas un KPI : s’il est rendu trop visible, le rework disparait … il est trop facile de le maquiller. Pour qu’une équipe (globale, c’est-à-dire métier et IT) évite le rework, il faut en faire un indicateur « local » (dans l’esprit de la célèbre citation de Deming qui nous dit qu’il faut chérir ses erreurs pour progresser). Les « candidats KPI » sont de mon point de vue: la satisfaction client/utilisateur, la qualité (défauts par « user story »), le TTD et le temps moyen de déploiement des « user stories » validées. Ce dernier KPI a trois bénéfices : il évite le code jamais livré, il soutient la démarche DevOps vers le « continuous delivery » et il pousse les équipes à construire des « user stories » de taille modérée (dans l’esprit lean des « small batches »). En revanche, le « taux de rework », la vélocité, le taux d’automatisation des tests, le rythme des sprints sont des indicateurs internes qui sont plus utiles s’ils sont laissés au contrôle des équipes de façon autonome. Dans ces cas, l’objectif premier est la recherche du « mastery » - une tâche qui est confiée aux équipes et aux kaizen – et l’amélioration de la performance est une conséquence. Pour citer Francois Jullien une fois de plus : « ce n’est pas en tirant sur la tige qu’on fait pousser la plante plus vite ». Ceci me conduit pour terminer à vous proposer de prolonger la réflexion sur la mesure par la lecture de l’excellente édition n°19  de la revue de Kea Partners.



lundi, avril 25, 2016

Le SelfLean et l’art d’attendre



Le billet de ce jour est une réflexion personnelle sur l’efficacité du collaborateur dans l’entreprise, à travers le prisme des principes du lean management, dans la lignée des billets précédents : « SelfLean : l’efficacité systémique individuelle ». C’est un sujet personnel, car ma première source d’inspiration est l’analyse des causes de l’inefficacité du travail collaboratif dans les entreprises que je peux observer, à commencer par mon propre travail. Mon premier billet sur l’application des principes lean à la gestion des emails date de 2007, comprendre l’inefficacité systémique n’est pas une chose simple. Je parle de l’efficacité du « knowledge worker », que je pourrais aussi appeler « cerveau d’œuvre » en référence aux travaux sur l’iconomie (voir par exemple Michel Volle ou Jean-Pierre Corniou). Je vais commencer par un résumé des principes du « self lean » dans la première section.

Si je reprends la plume sur ce sujet à nouveau, c’est que je perçois une tension. D’une part, les principes du lean thinking sont très pertinents pour optimiser les processus collaboratifs et les flux de matière grise. Ce n’est pas par hasard si le processus d’innovation du Lean Startup fait référence au lean. Je suis même de plus en convaincu qu’il existe un véritable enjeu de qualité de vie, ce qui sera l’objet de ma seconde section. Travailler en mode lean, au sens du Toyota Way, réduit le stress (ce qui n’est évidemment pas le cas du « lean » mal compris comme élimination des marges de manœuvre). En revanche, et c’est la tension que j’évoquais, le cerveau d’œuvre est soumis à un flot stochastique, voire chaotique, de demandes, avec des caractéristiques profondément dynamiques (la priorité, le contenu, le contexte associé à chaque demande évoluent de façon continue). Cela invalide certaines pratiques et techniques du lean, tout du moins si on les prend de façon littérale. Ceci va être l’objet de la troisième section de ce billet. Je vais me tourner vers le Yield Management comme source d’inspiration, pour proposer une gestion de classes de services qui n’est pas sans rappeler le Heijunka. Un titre plus prétentieux pour ce billet aurait pu être « Self-Lean, Yield Management et Heijunka » - un bon sujet à explorer : la combinaison de « lean thinking » et « yield management » est très peu représentée sur le web.

J’ai préféré évoquer l’art d’attendre dans mon titre car il s’agit d’un autre débat, plus accessible, sur l’attente dans l’approche lean. Le lean propose une véritable dualité au sujet de l’attente : il proscrit les attentes inutiles pendant l’exécution, mais il propose – logiquement - de « partir » le plus tard possible, au « bon moment » dans un flux tiré. Le fait d’attendre « le dernier moment » pour démarrer est systématiquement utile dans un contexte très changeant. En revanche, la notion de « pause » semble antithétique avec le lean, je me souviens de débats houleux il y a une dizaine d’année avec des consultants lean. Pourtant, prendre le temps de s’arrêter pour réévaluer le contexte, obtenir un feedback, murir une intuition, n’est pas forcément un gaspillage (« muda »). En particulier, dans une processus d’innovation, il existe un temps long pour l’incubation des idées et la caractérisation des problèmes à résoudre, qui n’est pas incompatible avec le temps court et sans attente du développement du « Minimum Viable Product » du Lean Startup. Cette réconciliation du lean avec le temps long sera l’objet de la section 4.


1. Le «Toyota Way » appliqué au cerveau d’œuvre



Je vais commencer par rappeler brièvement les grandes idées du SelfLean, développées ailleurs dans ce blog, à commencer par un des premiers billets sur le sujet. Il s’agit simplement de réinterpréter les principes du Toyota Way dans le contexte du knowledge worker :
  • Eviter la décomposition avec attente pour aller au contraire vers le « streamlining », l’exécution en flux continu. Un des premiers principes lean est de maximiser le rapport « temps utile » / « temps total », il s’applique parfaitement pour le cerveau d’œuvre. L’exécution en flux continu apporte un double bénéfice : éviter des temps d’attentes inutiles et éviter des temps de « reprise de contexte », équivalents aux temps de changement d’outil dans une chaîne de production. Un temps d’attente est lui un double gaspillage (muda) : c’est une exposition aux aléas (plus on attend plus la probabilité d’une désynchronisation avec le contexte de la demande augmente) et une charge mentale inutile. La pratique de la visualisation du « work in process » sert précisément à alléger cette surcharge.
      
  • Utiliser le « pull » plutôt que le « push » : définir l’ordonnancement des tâches en fonction du consommateur et non pas du producteur. C’est probablement la révolution la plus importante pour un knowledge worker : apprendre à synchroniser sa production avec l’usage de ses consommateurs au lieu de se caler sur sa propre disponibilité. C’est un des apports clé du Kanban dans les processus de coopération, à commencer par la production logicielle. On retrouve toute l’importance de la synchronicité, par opposition au travail asynchrone qui n’a que le vernis de l’efficacité (précisément lorsque la complexité fait que les coûts de resynchronisation explosent les gains que l’asynchronisme permet du point de vue de l’ordonnancement).
      
  • Éliminer tout ce qui ne produit pas de valeur pour le client, le « muda ». Cette pratique est parfaitement transposable dans les activités du knowledge worker, au delà de la traque des temps d’attente que nous venons d’évoquer.  Les temps de recherche, de changement de format, de classement, sont des opportunités d’optimisation en utilisant des outils tels que les 5S (qui se transposent aussi bien dans le domaine du logiciel que du travail du cerveau d’œuvre).  On pourrait d’ailleurs étendre cette remarque sur les 5S à l’ensemble des pratiques de « management visuel individuel» qui trouvent également leur place chez les cerveaux d’œuvre – ainsi que la pratique des « cinq pourquoi » - pour les mêmes raisons : le besoin de maîtriser la complexité de l’environnement par l’apprentissage continu.
      
  • Pratiquer l’exigence « right on the first time » : le lean s’attache à éviter les erreurs, dont la correction coûte plus cher que la prévention. Une des plaies des projets informatiques ou de développement de produits est le « rework », lorsqu’on refait plusieurs fois la même chose. Ce n’est pas limité à l’informatique, le « rework » est un symptôme de la complexité des organisations. Une des principales erreurs lorsqu’on pratique les méthodes agiles est de confondre vitesse et précipitation : pour faire bien et vite, il faut faire peu (d’où l’importances des « small batches »). 
L’application de ces principes dans des processus de « matière grise » a été abordé de multiples fois dans ce blog. Lorsqu’il s’agit d’un processus d’innovation, on retrouve les fondations du Lean Startup. Lorsqu’il s’agit de développement logiciel, on retrouve certains principes élémentaires de la « Lean Software Factory ». Bien sûr, il s’agit d’une liste partielle puisqu’elle est concentrée sur l’individu, et qu’elle laisse de coté – volontairement - la dimension essentielle du lean, le travail d’équipe (le kaizen, l’apprentissage collectif, le management visuel collectif, etc.).

2. Le Self Lean et la qualité de vie


Les principes du lean sont avant tous des principes d’efficacité systémique, dont l’objectif est d’améliorer la performance de l’ensemble de l’entreprise, mesurée au travers de la satisfaction client. Il se trouve que ces principes améliorent grandement la qualité de vie des collaborateurs, d’un point de vue individuel. Une partie de cette appréciation est probablement subjective et personnelle … je ne vais pas trop détailler, la suite se trouve dans les classiques de l’efficacité personnelle, tels que le célèbre : « Getting Things Done » ou « The 7 Habits of Highly Effective People ». Je souhaite néanmoins souligner quatre bénéfices fondamentaux de la pratique du SelfLean pour le cerveau d’œuvre :
  • La pratique du SelfLean permet de rester agile, de savoir saisir une opportunité et de démarrer rapidement sur une nouvelle demande réellement importante. C’est la conséquence systémique d’un taux de charge sous contrôle. Je vous renvoie aux articles plus anciens pour faire le lien avec la théorie des files d’attentes ; ce qui m’importe ici au delà de l’efficacité collective, c’est le bien-être que procure la sensation d’être en contrôle de son agenda, par opposition à la situation de stress « de ne pas pouvoir faire face aux demandes » dont nous savons qu’elle constitue la cause première des « burn outs ». C’est, selon mon expérience, le premier bénéfice de la maîtrise visuelle du « WIP ».

  • L’utilisation du Kanban permet de retrouver le sens du travail coopératif, en s’assurant à la fois de la disponibilité, de la réactivité et de la synchronicité de son propre travail par rapport aux attentes des autres. La frustration de terminer dans l’urgence et dans l’effort un rapport qui n’est ensuite lu que fort tard, de façon partielle parce qu’il est trop long et par une petite partie des destinataires est malheureusement trop courante dans nos organisations Tayloristes. Je dois pour ma part à un déjeuner d’été lorsque j’étais DSI avec Philippe Montagner le moment ou j’ai pivoté : considérer son travail du point de vue de la valeur délivrée aux autres et non pas du point de vue de ce qui est produit change radicalement la définition du « knowledge worker ».

  • Si l’on prend au sérieux l’exigence « right on the first time » ainsi que l’exécution en flux continu, on retrouve très vite un des principes de Google « Do one thing really, really well ». Le cerveau d’œuvre travaille mieux lorsqu’il fait une seule chose en y affectant la totalité de son énergie. Il y a plein de bonnes raisons évidente pour promouvoir ce principe du point de vue de ce qui est produit, mais il y a un autre bénéfice non moins important : c’est une garantie contre la surcharge, et le stress qui en résulte. Il est frappant de voir que nous avons tous fait l’expérience d’un « off-site » pendant lequel la concentration sur un seul sujet a produit des miracles, alors que cette pratique est souvent immolée sur l’autel de « l’efficacité ».

  • Le lean promeut la décision et l’amélioration continue fondées sur la mesure, et donc l’auto-observation (évident dans le cas du Lean Startup ou du Lean Software). C’est ici que le « standard » (au sens de Michael Ballé – lien) prend tout son sens. Un des bénéfices systémiques du « standard » est de permettre la capitalisation et l’objectivation de l’amélioration continue. Du point de vue de l’individu, c’est également un formidable outil de réduction du stress. Le knowledge worker a souvent tendance à sous-estimer un certain nombre de ses tâches (en particulier la relecture, qui demande du temps et des efforts) et il se trouve logiquement dans une situation de sur-promesse. La combinaison du standard (savoir combien il faut de temps pour écrire le premier jet, terminer la rédaction, relire ou valider, un document de 1,3 ou 10 pages) et du « management visuel personnel » permet d’éviter les promesses non tenues et le stress qui en résulte (ou qui devrait en résulter … si ce n’est pas le cas, c’est qu’on est passé en mode bureaucratique chaotique).
C’est le bon moment pour répéter que la science est maintenant unanime sur l’inefficacité du multi-tasking. Il y ne devrait plus y avoir de débat sur l’utilité du troisième point de la liste précédente : « faire une chose à la fois et le faire du mieux possible ». A coté des études de l’université de Londres, que j’ai souvent citées dans ce blog puisqu’on y trouve l’exemple désormais célèbre qui montre que travailler en face de son Blackberry allumé fait perdre 10 points de QI, on trouve des résultats semblables dans des études plus récentes de Stanford. Le multi-tasking est carrément dangereux pour notre cerveau. Des recherches à l’Université de Sussex ont montré que les personnes qui font beaucoup de multi-tasking ont une plus faible densité d’une partie du cortex antérieur, une partie qui est associée à l’empathie et au contrôle cognitif.

3. Le Yield Management et l’optimisation stochastique des opportunités


On vient de voir qu’il y a des nombreux avantages à appliquer les principes du lean à des processus «de cerveau d’œuvre », qu’il s’agisse d’innovation ou de fabrication et diffusion de connaissance. Il y a également des limites importantes, à cause de la plus grande volatilité de la demande. Si l’on se réfère à un modèle de production de voiture façon Toyota, il faut imaginer des voitures dont la configuration requise change en temps réel, ainsi que le prix final, avec la possibilité pour le client d’annuler à tout moment, tandis que certaines pièces uniques prennent un temps de fabrication avec une très grande variabilité.

Le Yield Management  est précisément la discipline de gestion de demandes stochastiques que l’on utilise dans ces situations, qu’il s’agisse de remplir un avion ou un hôtel. Les fondamentaux du Yield Management sont qu’on ne connaît pas les opportunités qui vont arriver, mais qu’on dispose d’une certaine connaissance statistique de ce qui pourrait arriver, et que la valeur est très inégalement répartie. Il y a donc un double objectif de bien utiliser les capacités face à une demande aléatoire et d’optimiser l’allocation des ressources pour mieux servir les demandes les plus génératrices de valeur.

Ces deux dimensions stochastiques se retrouvent dans le travail de notre knowledge worker, illustré sommairement par le processus de la figure suivante. Un flux continu et aléatoire de demandes arrivent, qui se retrouvent regroupées dans un in-box (boite email, premier colonne d’un kanban, boite de tâches, etc.). La première tâche du cerveau d’œuvre est d’en prendre connaissance, et de faire une des 5 actions suivantes (si l’on est un adepte de GTD on va bien sûr s’assurer que ce travail de triage n’est fait qu’une seule fois : (1) exécuter – pour des tâches très simples (2) planifier pour une exécution ultérieure (3) planifier et fournir un accusé de réception en s’engageant à réaliser la demande (4) refuser la demande avec une réponse (5) ignorer la demande.  La deuxième catégorie de décisions du knowledge worker est liée à l’exécution des tâches : comment décomposer une tâche en sous-tâches (plus on décompose, plus on évolue vers du « multi-tasking », plus on augmente les opportunités de feedback mais plus en encourt des temps de « context switching ») et quand les exécuter (ordonnancement). On retrouve la dialectique connue : le push laisse plus de marge de manœuvre apparentes, mais expose au risque de changement des objectifs, tandis que le pull (« juste à temps ») demande une plus grande rigueur mais a le double avantage de délivrer « selon les conditions du moment » et « en ayant le contexte de la demande en tête au moment où l’on délivre ».
 
La première tension qui affecte le knowledge worker dans une entreprise de nos jours est la surcharge de demandes. Il lui faut donc trouver une discipline efficace pour le premier aiguillage (sort) afin de pouvoir tenir par la suite ses engagements. La deuxième tension est la grande variation dans la priorité, l’importance et le contenu des tâches, à la fois de façon globale et dans le temps. Une approche purement dynamique (la dernière tâche urgente et importante arrivée gèle les autres) conduit à deux défauts : le premier est une incapacité à tenir des délais pour des tâches simples d’importance moyenne  et le second est bien connu : ce qui est urgent chasse ce qui est important. La séparation entre ce qui est important et ce qui est urgent est l’embryon d’une approche par classe de services. Définir des classes de services consiste à regrouper des niveaux de priorité, d’urgence et de complexité semblables pour traiter ces groupes de façon fiable et reproductible (on se souvient que l’efficacité du knowledge worker est jugé par son environnement, et non pas par sa production), sous la forme de « promesses de service » (SLA). Les classes de services vont servir de support à une approche de type Yield Management, en réservant de la ressource (du temps « utile » du cerveau d’œuvre) à l’avance pour garder la capacité à faire ce qui est le plus utile. Un des premiers principes du SelfLean est de considérer son efficacité collective en priorité sur son efficacité individuelle. Ceci se traduit par l’importance de la « signalisation » (répondre rapidement qu’on peut ou ne peut pas prendre une demande) dans la figure précédente. Maintenir des bons SLAs collaboratifs dans un contexte de surcharge exige une notion de classe de service.        

La notion de classe de service trouve tout de suite sa place dans le processus d’aiguillage. Le SLA (service level agreement : promesse de niveau de service, ici le temps mis à accuser réception d’une demande) doit forcément être segmenté par classe de service, en particulier pour éviter que le ratio « temps de tri / temps de travail » ne devienne trop important (ceci n’est pas un problème théorique, avec plus de 100 emails entrants, de nombreux cerveaux d’œuvre perdent toute capacité de production propre). Une autre subtilité du contexte systémique du knowledge worker est que l’environnement s’adapte au SLA qu’il est capable de fournir. Un knowledge worker zélé qui cherche à fournir tout de suite un accusé de réception ou un refus documenté reçoit souvent un autre message, une autre demande ou une reformulation. Le SLA par classe de service permet également ralentir l’accélération chronophage rendue possible par les outils de communication modernes.

Une autre tension intéressante dans l’application du lean thinking au processus ci-dessus est le temps d’adaptation à un nouveau contexte, qui fait qu’il ne faut pas aller trop loin dans le principe lean des « petits batchs ». Morceler une tâche en nombreuses sous-tâches a de nombreux avantages systémiques (plus d’agilité, moins d’inertie, plus d’opportunité de feedback) mais un inconvénient majeur qui est que le « setup cost » est important pour passer d’une tâche à l’autre. On retrouve ici très précisément les arguments contre le multi-tasking et contre les interruptions. Le temps qu’il nous faut pour passer d’une tâche à une autre (switching) est important, et cela d’autant plus que la tâche est complexe, c’est-à-dire en liaison avec un environnement riche. Le chiffre communément admis est qu’il faut 25 minutes pour se remettre dans le contexte d’une tâche (une nouvelle tâche, ou la tâche précédente après une interruption).

La pratique du Yield Management repose sur la notion de prévision. Il y a donc une tension culturelle apparente avec les pratiques lean, telles que le « juste à temps », qui cherchent à obtenir l’agilité en s’affranchissant des prévisions, et celles du YM qui supposent que l’on peut prévoir. Si l’on regarde de plus près, certaines pratiques du lean, telles que le heijunka – le lissage de la charge au moyen de l’ordonnancement sélectif de différents types de tâches – s’appuient également sur une certaine connaissance de ce qui va probablement se passer en terme de charge. La plupart des articles sur le Heijunka cite la phrase suivante de Taiichi Ohno : « The slower but consistent tortoise causes less waste and is much more desirable than the speedy hare that races ahead and then stops occasionally to doze. The Toyota Production System can be realized only when all the workers become tortoises ». Le heijunka s’appuie sur une typologie des actions à réaliser, et utilise – entre autres – des ordonnancements pour lisser la charge ou la difficulté en réservant des positions pour certains types de tâches par rapport à d’autres, ce qui n’est pas sans rappeler une gestion de classes de service.

Néanmoins, il subsiste bien une tension entre le désir d’optimiser et planifier d’une part, et la nature fortement aléatoire de la charge, souvent marquée par des « crises » que l’on n’a pas vu venir. La pratique des classes de services, la limitation de la charge et le pilotage en flux tirés grâce au Kanban donnent des réponses systémiques pour rendre le cerveau d’œuvre adaptable. Mais puisque cette tension subsiste, les pratiques précédentes doivent être complémentées par la « réflexion » (prise de recul). Il faut régulièrement prendre du recul pour : (a) évaluer la réalité par rapport à ce qui est perçu (b) réévaluer constamment le travail en cours et ses priorisations. C’est précisément tout l’intérêt des outils de management visuels, de la simple représentation du WIP jusqu’au Kanban.

4. Eloge du temps long, l’art d’attendre


J’ai déjà abordé le sujet de la gestion des demandes dans un mode lean, qu’il s’agisse d’un knowledge worker face à sa boite email ou d’un système d’information piloté par ses SLA, dans le cadre de mes travaux sur l’OAI. La première contribution à cet éloge du temps long vient précisément de la théorie des files d’attentes. Traiter les demandes dans l’ordre dans lesquelles elles arrivent n’est pas robuste et ne se prête pas à la maximisation de la valeur. Dans les deux cas, on trouve facilement par l’analyse ou la simulation qu’il faut implémenter des classes de services et définir des stratégies de routage des flux de tâche qui tiennent compte de la priorité (de la valeur créée) et se rapproche d’un ordonnancement « juste à temps ».

On aboutit de la sorte à ce qu’on pourrait qualifier de « slow scheduling » : le Yield Management appliqué aux classes de services, qui construit un emploi du temps « calme » qui réserve des zones pour des futures opportunités (à haute valeur) et pour la gestion des aléas, ce qui est nécessaire pour tenir les SLA évoqués dans la section précédente. Le principe est simple : pour la plupart des demandes, il faut utiliser des classes de services pour faire un ordonnancement paresseux (au plus tard) qui évite de devoir ensuite déplacer des tâches de priorités moindre pour « faire de la place ». Un des grands principes de la vie en entreprise est que les changements de dernière minute sont fatigants et inefficaces. Ils engendrent un stress inutile pour le cerveau d’œuvre lui-même et sont dommageables du point de vue de l’efficacité collective (rupture des SLA qui rythme l’orchestration). Je vous recommande chaleureusement pour poursuivre sur ce thème la lecture du billet de Faisal Hoque « Five Ways Working More Slowly Can Boost Your Productivity ».
Il existe une autre raison pour recommander l’ordonnancement paresseux (le « slow scheduling »), c’est qu’il est plus conforme au temps long de la créativité. Je vous recommande ici vivement les exposés de Steven Johnson sur les « slow hunch ». La créativité repose sur une alternance de temps courts et longs – le « slow hunch » c’est le processus qui raffine progressivement l’intuition au fil du temps. Le temps de l’incubation des idées est un temps long. Avant qu’un lecteur ne m’oppose les principes du lean startup, la décomposition en phases de design thinking et de MVP permet justement de concilier temps court et temps long. Ce n’est pas par hasard si Ash Maurya insiste sur les efforts (longs) à faire pour caractériser le problème (et les « hypothèses ») avant de se lancer (rapidement) dans le MVP pour valider ou invalider ces hypothèses. Si vous n’avez pas le temps de regarder sa vidéo TED, lisez l’article suivant qui résume le livre de Steven Johnson, dont une des leçons est « World-changing ideas generally evolve over time as slow hunches rather than sudden breakthroughs ». Cet excellent article insiste également logiquement sur l’importance des réseaux et de la collaboration entre knowledge workers.

Tous ces arguments se combinent avec ceux des sections précédentes, puisque l’innovation est un processus éminemment coopératif. Pour reprendre les propos d’Yves Morieux : « coopérer c’est mettre ses marges de manœuvre au service des autres », donc, pour innover, il faut avoir des marges de manœuvre (slack time). Il faut également soigner sa qualité de vie (cf. section 2) et l’adéquation de son environnement. Si nous revenons à l’éloge de « l’art d’attendre », il s’agit bien de donner « du temps au temps » pour la transformation. Ce qui n’est nullement incompatible avec la rapidité de l’action. Le potentiel de situation se construit sur le temps long, mais la décision pour saisir l’opportunité doit être rapide et l’action agile. Pour simplifier, on peut dire qu’une forme de l’art d’attendre se retrouve dans la vision systémique des « cultivateurs » au sens de François Jullien, en particulier lors qu’il faut cultiver des apprentissages. On retrouve cette intuition dans une partie de l’article « How slow work make us more productive » du New York Times. Le temps long est compatible avec le Toyota Way – le lean ce n’est pas « que les cycles courts de l’amélioration continue ». Ce sujet déborde amplement le cadre du SelfLean. Je vous renvoie, par exemple, à ce que j’ai écrit sur la combinaison du lean thinking et de l’architecture