Le livre L’approche Lean pour la transformation digitale d’Yves Caseau (2020, Dunod) est très intéressant à plus d’un titre. Il a l’avantage d’être à la portée de tous les acteurs de l’IT, que l’on soit DSI, directeur de projet / programme, membre d’une équipe de développement, PO, responsable métier, coach…
Il a également de mérite de rapprocher plusieurs écoles qui ont souvent tendance à s’opposer alors que sur le terrain, elles visent la même finalité : l’agilité de l’entreprise pour satisfaire complètement les clients. Je fais référence ici à l’Agile, au Lean et à DevOps, qui sont complémentaires et étroitement liées. Mais surtout, Lean et Agile ne se décrètent pas ! Bref, un livre à lire !
J’ai choisi de m’intéresser plus particulièrement au texte surligné dans l’image en tête de cet article et que je reprends ci-dessous :
Pour obtenir efficacement le résultat attendu, à savoir la satisfaction des clients et utilisateurs, il faut garantir à l’équipe un accès régulier et facile aux utilisateurs. L’efficacité et la satisfaction d’une équipe lean et agile ne se décrètent pas, elle n’est pas le résultat d’un contrôle “top-down”, mais le résultat émergent et bottom-up de la collaboration et de l’efficacité individuelle. L’équipe développe son produit ou son service en utilisant la satisfaction des utilisateurs ou des clients comme boussole, ce qui exige de pouvoir organiser facilement la « boucle de retour » sous forme de tests, de démonstrations ou d’enquête terrain. Cette règle est plus complexe qu’il n’y paraît car de nombreuses entreprises ont taylorisé cette boucle de retour : ceux qui parlent au client, ceux qui comprennent ce que veut le client, ceux qui spécifient les besoins du client et ceux qui réalisent. L’approche lean & agile exige à la fois un product owner fort et autonome, et un accès régulier pour l’ensemble de l’équipe à la voix du client. Plus le système est grand, plus il est décomposé en équipes multiples, en vertu de la règle qui veut qu’une squad (équipe) agile puisse être nourrie avec “deux pizzas”. Or plus le système est grand, plus la voix du client est un élément essentiel d’alignement.»
Source : L’approche Lean pour la transformation digitale, Yves Caseau, Dunod, 2020
Lean et Agile ne se décrètent pas !
Avant de parler d’efficacité et de satisfaction d’une équipe qui ne se décrètent pas, regardons comment l’agilité est déployée au sein des entreprises. Trop souvent dans mon expérience, je découvre des équipes à qui il a été dit « Il faut faire de l’agile » ou « On doit être agile » (bien évidemment, on peut remplacer agile par Lean).
Quand j’essaie de comprendre pour quelle raison on leur a demandé ça, la réponse est quasi toujours la même « On ne sait pas ; on n’a pas bien compris ». Au mieux, on me répond qu’elle doit augmenter la valeur produite ; ok, c’est déjà un début…
Je creuse un peu plus en essayant de savoir si l’équipe à été formée (ce qui est le début, mais très loin d’être suffisant). Dans le meilleur des cas, une personne a été formée au rôle de Scrum Master. Les Product Owner (PO) – qui est un rôle stratégique – sont rarement formés. Ce n’est pas parce qu’une personne a l’habitude de rédiger des spécifications qu’elle peut devenir PO en un claquement de doigt !
Ce qui est encore plus rare, c’est d’avoir une équipe entière formée. Comment voulez-vous que des développeurs s’inscrivent dans l’agilité s’ils ne sont pas un minimum formés ? Comment voulez-vous que l’équipe se comprenne et qu’elle trouve un sens commun ?
Ma dernière question porte sur le management pour savoir si ce dernier essaie (au moins) de donner les moyens à l’équipe de réussir. J’entends très rarement que le management s’occupe de l’équipe, sauf pour les entretiens annuels (dans lesquels le responsable d’équipe a dû avoir comme objectif de faire de son équipe une équipe agile). La pire réponse que j’ai eue est « Je n’ai jamais vu mon manageur, alors que je suis dans la boîte depuis six mois » ; c’est juste terrible !
En effet, Lean et Agile ne se décrètent pas, car ce n’est pas une finalité. C’est une véritable transformation des personnes, mais également du management et de la culture d’entreprise.
Du sens et l’engagement du management
Si la direction – ou ne serait-ce que la DSI – ne donne pas le sens, c’est-à-dire le Why selon le cercle d’or de Simon Sinek (se reporter au livre Commercer par pourquoi de Simon Sinek, Performance Edition, 2009), il est fort probable que cette transformation ne soit perçue comme une nième qui ne changera pas grand chose. On reste alors dans un management classique, comme l’écrit si bien Art Byrne dans Le virage Lean : « donner des ordres, engager un spécialiste si nécessaire, et se tenir à l’écart des réalités quotidiennes. »
On trouve les mêmes problèmes avec les démarches OKR rendues populaires par le livre Mesurez ce qui compte (Pearson, 2019) de John Doerr. Si le management ne s’implique pas dès le départ et s’il n’aide pas les équipes à réussir, rien ne changera. Intel a réussi (en son temps, car on peut aujourd’hui avoir un doute raisonnable puisque Apple a abandonné Intel pour utiliser ses propres puces M1), Google a réussi, mais rien ne dit que vous allez réussir.
« Je peux vous enseigner les principes du TPS [ou de l’agile ou des OKR], je peux même vous montrer concrètement comment il fonctionne. Mais je parie que vous ne réussirez pas à l’appliquer chez vous. », selon Yoshiki Iwata cité dans Le virage Lean de Art Byrne.
Intel a commencé à travailler avec les OKR dans les années 1970 et Google à partir de 1999 quand John Doerr a investi dans la société de Larry Page et Sergey Brin. Être ambitieux en voulant faire comme eux, oui. Mais l’entreprise ne peut pas être présomptueuse et péremptoire au point d’exiger de ses salariés d’atteindre le même niveaux en trois ans, surtout sans implication du management (lire OKR, n’oubliez surtout pas le rôle du management !).
Oui, l’Agile, le Lean et les OKR ont des supers pouvoirs (référence au livre de John Doerr) ; encore faut-il les appliquer correctement si l’entreprise ne veut pas faire pire que l’existant.
Pour soutenir les propos d’ Yves Caseau, je vais me référer, comme je le fais souvent (se reporter à l’article Pourquoi lire Le virage Lean de Art Byrne ? pour comprendre), au livre de Art Byrne, Le virage Lean :
Si la volonté d’aboutir fait défaut et si le PDG ne s’implique pas suffisamment la transformation de l’entreprise reste morte.»
Premièrement, il vous faudra plusieurs années d’efforts [NDLR on n’accède pas à l’agilité de Toyota en trois ans] pour transformer la structure existante […] en configuration Lean [ou Agile] qui permet de voir et d’éliminer les gaspillages. Deuxièmement, vous vous heurterez à une résistance à tous les niveaux de la hiérarchie. Dans ces conditions, il est évident que la transformation par le Lean [ou l’Agile] ne se délègue pas. Sans un leadership fort qui impose à chacun de contribuer à améliorer les processus pour atteindre les objectifs financiers, rien ne bouge.
[…] vous n’obtiendrez ce résultat que si vous considérez le Lean [NDLR ou l’Agile] comme une stratégie à part entière – comme l’élément fondateur de toutes vos actions –, c’est la condition de votre réussite.»
Source : Le virage Lean, Art Byrne, Pearson, 2013
Une stratégie
La stratégie, c’est exactement ce que soutient Yves Caseau :
Ce qui transforme une entreprise n’est pas d’adopter une méthode agile pour le développement de ses plateformes numériques ou son système d’information, c’est d’adopter l’agilité comme démarche stratégique.»
Source : L’approche Lean pour la transformation digitale, Yves Caseau, Dunod, 2020
Au final, que se passe-t-il ? Quelques équipes, qu’on a l’habitude d’appeler early adopter, tentent autant que faire se peut de changer leur modèle. Pour les autres, la plupart sont perdues et elles se raccrochent à ce qu’elles connaissent depuis des années.
Il m’est arrivé de croiser des coachs (internes et prestataires) qui avaient pour seule mission de mettre en pratique l’agilité au sein des équipes… mais pour quoi faire ? Dans quel but ? Une fois le coach partit, les équipes reprennent leurs anciennes habitudes. Elles n’ont pas compris le sens ni l’intérêt et n’ont pas perçu leurs améliorations puisqu’il n’y a aucune mesure de la situation avant et après.
Ce qui devait arriver arriva… la transformation est globalement considérée comme un échec dans les trois ans qui suivent l’injonction. Les équipes vont être cataloguées pour n’avoir pas suivi les décisions et les conclusions de la direction seront à l’emporte-pièce « Le Lean / Agile, ça ne fonctionne pas ! »
Pour insister sur cette exemplarité et l’implication du management, référons-nous à un autre livre tout aussi important La Stratégie Lean :
Diriger à partir du terrain signifie diriger l’exploration de la stratégie depuis « la production » (terme générique englobant les fonctions support qu’elles soient en usine ou au bureau) en étudiant à fond les données factuelles et en reliant les points pour dessiner une nouvelle vision stratégique, plutôt que de plaquer ses propres idées préconçues à la réalité de l’activité. Diriger à partir du terrain n’est pas un processus aléatoire. C’est une démarche volontariste d’amélioration (du travail, des produits, de l’information), de mise au jour des entraves aux flux et de « pourquoi ? » posés sans relâche pour comprendre avec les équipes de terrain ce que sont les véritables problèmes. C’est un acte de leadership car cette exploration est rarement aisée ou intuitive.»
Source : La Stratégie Lean, M. Ballé, D. Jones, J. Chaize, O. Fiume, Eyrolles, 2017
Le client, ce grand oublié !
Yves Caseau insiste, à juste titre, sur l’importante de la voix du client. Il est impensable de mettre en oeuvre des pratiques Agile, Lean (ou même OKR) sans s’intéresser à ses clients alors que c’est au coeur des démarches. Et pourtant…
Une nouvelle fois, je vais citer Art Byrne : « Preuve, s’il en est, que nous continuons à vivre selon ces préceptes dépassés, nous passons tous une bonne partie de notre temps à tenter de convaincre nos clients d’accepter nos façons de procéder au lieu d’essayer de répondre à leurs attentes. »
J’écrivais plus haut que nombre de PO ne sont pas formés alors que c’est un rôle-clé dans la démarche Agile. Il permet en effet de faire le lien direct entre les équipes qui réalisent et le client. Le PO, dans sa maîtrise des besoins du client / des utilisateurs, dans sa capacité à comprendre la valeur des fonctionnalités et à valider via les démos les incréments de valeurs, est probablement la pièce maîtresse d’une équipe agile.
Je vois régulièrement des équipes dites agiles qui ont comme PO un membre de l’équipe sans contact avec le client ou les utilisateurs réels. Il faut un PO, alors on met un PO ! Logique implacable. Comment ce PO peut-il maîtriser le backlog de sprint ? Je ne parle même pas du backlog produit. Fait-il des ateliers Story Mapping (se référer au livre Le story mapping de Jeff Patton, Dunod, 2015) tout seul ? Détermine-t-il la priorité tout seul ? On est clairement soit dans une DSI à l’ancienne (« Nous savons mieux que les clients / utilisateurs ce dont ils ont besoin. »), soit avec une équipe qui n’a pas été formée et qui n’a pas pu comprendre les changements qu’imposent les pratiques de l’Agile.
Yves Caseau nous rappelle dans son livre que la principale rupture de la transformation digitale est de « rendre le contrôle au client et construire des éléments de valeur modulaires et composables » et que « la voix du client s’invite dans le cycle de développement produit, cette voix est amplifiée par le pouvoir des foules et des communautés ».
Il est donc indispensable de se confronter aux clients, aux utilisateurs si l’on souhaite produire le meilleur système pour lui et dans les meilleurs délais (cela ne veut pas dire tout faire pour demain). Une pratique Lean qui vient renforcer la connaissance du client par les équipes pratiquant l’Agile est la voix du client (ou VOC : Voice of Customer) qui doit être précédée par la détermination des clients de l’équipe, que j’ai l’habitude de pratiquer via un SIPOC (Supplier, Input, Process, Output, Customer) et un atelier avec l’équipe (d’ailleurs, assez révélateur du manque de connaissance de ses clients).
La voix du client doit être affichée sur les murs, sous des formes multiples allant des statistiques d’utilisation, des verbatims collectés – pendant les tests, les démos ou les enquêtes de satisfaction – et le traitement des plaintes et incidents sévères.»
Source : L’approche Lean pour la transformation digitale, Yves Caseau, Dunod, 2020
Les techniques UX (User Experience) permettent également d’avoir des retours utilisateurs très appréciables et fiables pour améliorer son système. On y trouve par exemple la technique des UJM (User Journey Map nommée également Customer Journey Map) qui permet de comprendre les difficultés et les émotions des clients dans leur parcours utilisateur. Une mine d’informations pour qui veut s’améliorer. Yves Caseau y fait référence :
Cette construction [Customer journey] se formalise par un experience map qui positionne les « points de contacts » (touchpoints), les transitions, les intentions supposées et les réactions attendues. Le plan d’expérience est une forme structurée de l’« histoire » que l’expérience raconte. Il est essentiel de penser en termes d’une « histoire qui se raconte » (story-telling) pour capturer les émotions et profiter de la richesse des motifs narratifs que l’expérience peut convoquer.»
Source : L’approche Lean pour la transformation digitale, Yves Caseau, Dunod, 2020
En conclusion, si votre transformation Agile ou Lean ou Agile & Lean ne fonctionne pas, posez-vous les bonnes questions et continuez de tester, tout en impliquant le management et en donnant à vos équipes les moyens de réussir. Et je vous invite à lire ce livre d’Yves Caseau ; il vous apportera des clés.
P.S. : certains trouveront que je dresse un tableau bien noir, mais c’est la réalité. En tant que praticien du Lean Management, je n’ai pas pour habitude de masquer les choses 😉 Pour autant, je sais très bien que dans certaines entreprises – j’en connais –, ces transformations évoluent bien, et tant mieux.
3 commentaires sur « Lean et Agile ne se décrètent pas ! »