Il existe une indéniable familiarité entre les pratiques du management lean et celles liées aux méthodes agiles de développement logiciel.
Si les premières se sont développées de façon organique et systémique au sein d’une seule entreprise, sous la conduite déterminée de Taiichi Ohno (1), les méthodes agiles ont vécu un développement plus opportuniste et distribué – un mode “par percolation” dirait l’éminent Serge Soudoplatoff (2).
J’observe qu’un grand nombre de spécialistes de l’agile s’orientent ensuite dans le cadre de leur exploration vers la pensée Lean. Mon hypothèse, basée sur une quinzaine d’années d’expérience en agile et une demi-douzaine en lean, est qu’ils choisissent cette direction parce que la pensée Lean complémente les méthodes agiles. Et voici pourquoi …
1. La Pensée Lean
Comme l’explique volontiers Marie-Pia Ignace, directrice de l’Institut lean France (3) , le lean est 1/ un système de production et 2/ un système de management. Une définition générale qui me semble une parfaite introduction.
Les 5 questions
Le lean c’est aussi une pensée : rappelons nous l’intitulé de l’ouvrage classique de Womack & Jones : Lean Thinking (4). Cela peut sembler un peu ronflant et présomptueux mais c’est en fait très précis. Car on sait depuis Socrate que le moteur de la pensée est le questionnement, et le système Lean s’est construit graduellement à mesure qu’il répondait aux questions suivantes :
- Comment mettre le client au coeur de chacune de nos opérations et comment supprimer les gaspillages qui empêchent l’équipe de créer davantage de valeur pour le client ?
- Comment produire de la qualité à chaque étape de nos processus ?
- Comment créer un flux continu de valeur, tiré par la demande client ?
- Comment responsabiliser nos équipes pour les inscrire dans une démarche d’amélioration continue ?
- Comment stabiliser nos processus et notre organisation pour éviter la surcharge ?
À ces cinq questions historiques se rajoute une sixième question apparue au tournant des années 1990 : Comment produire davantage de valeur en préservant les ressources naturelles, dans une démarche de développement durable ? Question à laquelle le véhicule hybride Prius a été une des premières réponses de l’entreprise Toyota qui n’a plus cesser depuis de creuser le sujet avec des résultats remarquables comme l’a montré Steve Hope au Lean Green Day 2017 (5) à Paris en Septembre.
La dimension systémique du lean provient du fait que l’entreprise essaye de répondre à ces six questions en même temps et en permanence. On ne pourra pas favoriser un indicateur au détriment d’un autre. Il s’agit d’une tension féconde qui va challenger les équipes et les amener à développer davantage leurs compétences alors qu’elles y répondent.
Une approche empirique
À mesure que le Toyota Production System (6) se développait à partir des années 1950, ces cinq questions ont été déclinées en de nombreuses autres questions encore plus précises mais toujours très opérationnelles.
Ces cinq questions originelles sont souvent représentées sous la forme de la maison Toyota (7). Le système de management officiel Toyota (le Toyota Way (8)) n’a lui été formalisé que bien plus tard (2001) avec ses 5 dimensions : Gemba, Challenge, Kaizen, Team Work, Respect. Le point principal ici est que les pratiques de production et les pratiques de management se sont développées de façon empirique, selon ces cinq questions. Dans son dernier ouvrage The Lean Strategy (10) Michael Ballé explique que le système de production Toyota est à ce titre un système d’apprentissage selon ces cinq axes.
L’esprit classique
Le développement de cette approche au sein des multiples entités du constructeur japonais a été conduit par Ohno avec la même ligne directrice à l’esprit : ce développement se fera avec la contribution de chacun. Le rôle du management y est donc de coacher par le questionnement chaque employé pour qu’il trouve sa propre solution aux problèmes opérationnels posés et développe ainsi, avec la pensée lean en action, des compétences plus profondes. Une approche rigoureuse, étroite, résolue et implacable écrirait Donna Tartt (9) ; éminemment classique, une approche que n’aurait pas désavouée Socrate.
Une approche toutefois extrêmement efficace en ce qu’elle permet d’analyser des situations dans tout type d’industries. Ce que j’ai pu constater alors que j’accompagnais des équipes dans des activités aussi diverses que le back-office de services financiers, le recouvrement, la vente à distance, le digital marketing, le service à la personne, les services en électricité etc …
2. Les Méthodes Agiles
Trois évènements
Il y a eu trois évènements fondateurs dans l’histoire des méthodes agiles. Le premier a été la prise en main par Kent Beck du projet de paiement C3 chez Chrysler (11) à partir de 1994. De cette expérience Kent en formalisera les pratiques d’ingénierie logicielle Extreme Programming (12). Le second est la publication par Ken Schwaber et Jeff Sutherland d’un article sur le framework Scrum présenté en 1995 à la conférence OOPSLA. Le troisième sera la fameuse réunion d’experts (dont Kent Beck, Ken Schwaber, Jeff Sutherland et Dave Thomas) en Utah en février 2001 qui donnera naissance au manifeste agile (13).
Le rapprochement Agile / Lean se fera grâce aux travaux de Tom & Mary Poppendieck avec la publication de l’ouvrage Lean Software Development en 2003.
Une pensée moderne
Les agilistes sont très souvent des ingénieurs curieux et enclins à tester les nouvelles technologies, librairies, framework etc … Ils adoptent donc avec les outils méthodologiques la même approche qu’au niveau technologique : ils ne cessent d’enrichir leur palette (même si, parfois, cela peut déraper un peu entre les praticiens de différentes paroisses – que Mike Orzen qualifient de tribal agilist). Une approche résolument moderne et inclusive, avec un sens de l’exploration horizontal, qui cherche à développer une familiarité avec une grande variété d’outils.
Si cette pensée ce développe au sein d’une communauté très riche, à l’esprit ouvert et plutôt bienveillant, nous sommes cependant éloignés du classicisme résolu de Ohno et du lean où prime une exploration verticale : la quête insatiable du geste parfait (14), ce que Deming appelle le développement du System of Profound Knowledge (15).
Une approche prescriptive …
Dans son livre Kanban Vs Scrum (16), le très pédagogue Henrik Kniberg explique que plus une approche impose d’outils, plus elle est prescriptive. Le corpus agile / Scrum peut ainsi être catalogué de prescriptif. Les rôles (Product Owner, Scrum Master, développeur, tests, opérations), le processus (Backlog Roaming, Sprint Planning, Sprint, Sprint Demo, rétrospective), les pièces (User Stories), les pratiques d’ingénierie (TDD, intégration continue, pair programming, team code ownership, …) sont ainsi tous bien définis et “prêts à l’emploi”.
… et très efficace
Cela présente toutefois un avantage remarquable : lorsque l’on lance une initiative lean avec une équipe de développement logiciel, nous n’avons plus besoin de questionner l’équipe pour l’amener vers les bonnes pratiques : le corpus de connaissance agiles, devenu un standard accepté et universel dans l’industrie, nous fait ainsi gagner en temps précieux : nous sommes tout de suite sur les bons sujets.
3. Questions Lean et outils agiles
En regardant de plus près on peut constater que, spontanément, les méthodes agiles ont répondu à un grand nombre des questions opérationnelles posées par la pensée lean.
Le tableau ci-dessous en propose une cartographie :
| Questions Lean | Outils Agiles |
| 1. Valeur Client | |
| Comment s’assurer que la pièce que l’on livre représente de la valeur pour le client ? |
|
| Comment livrer le mix produit qui répond aux attentes du client ? |
|
| Comment travailler au plus près du client pour mieux comprendre ses attentes ? | ??? |
| Comment s’assurer que ce qu’on livre répond aux attentes du client ? |
|
| Comment savoir que nos indicateurs opérationnels ont un sens pour le client ? | ??? |
| Comment s’assurer que la satisfaction client s’améliore ? | ??? |
| Élimination des Gaspillages | |
| Comment éviter la surproduction ? |
|
| Comment éviter les gestes inutiles ? |
|
| Comment supprimer les attentes ? |
|
| Comment ne pas créer de stocks intermédiaires ? |
|
| 2. Qualité | |
| Comment ne pas passer de la non qualité à la prochaine étape du processus ? |
|
| Comment protéger le client de la non qualité ? |
|
| Comment améliorer la qualité de façon continue ? | ??? |
| 3. Flux | |
| Comment livrer en petits lots ? |
|
| Comment créer un flux continu de valeur pour le client ? |
|
| Comment créer un flux continu de valeur tiré par la demande client ? |
|
| 4. Amélioration Continue | |
| Comment s’améliorer de façon régulière ? |
|
| Comment s’améliorer chaque jour ? | ??? |
| Comment coacher les personnes chaque jour dans le développement de leurs compétences ? | ??? |
| Comment savoir qui doit apprendre quoi pour réussir et la faire travailler sur le bon problème ? | ??? |
| Comment former les personnes sur le poste de travail ? |
|
| Management de la production et de la performance | |
| Comment atteindre nos objectifs de performance ? |
|
| Comment atteindre nos objectifs de production ? |
|
| Comment rendre visible les problèmes ? |
|
| 5. Stabilité | |
| Comment stabiliser nos équipes ? |
|
| Comment capitaliser sur nos savoir-faire ? |
|
| Comment construire la capacité des équipes ? |
|
Le corpus des méthodes agiles est un outil formidable pour améliorer de façon significative une DSI ou une équipe de développement en ce qu’il aide à, enfin, sortir quelque chose. Toutefois, on constate dans ce tableau mais aussi et surtout chez nos clients, qu’il reste encore des questions Lean auxquelles les méthodes agiles ne savent pas encore répondre.
4. Ce que le Lean apporte à l’agile
Le tableau précédent nous permet de rendre visible quelques manquements dans le corpus agiles. Il s’agit là d’angles morts que le Lean peut aider à combler, ce que nous proposons ci-dessous.
Le client
Les équipes agiles se sont construites dans un rejet de l’approche Command & Control à l’oeuvre dans les grandes DSI ou chez les éditeurs : on peut les comprendre. Le résultat est que les équipes peuvent avoir tendance à être auto-centrées : l’équipe de développement produit devient alors le centre d’attention principal. Ce qui présente de nombreuses vertus dont celle d’être un terreau fertile à la collaboration.
Malheureusement cela présente aussi le risque que l’on peut avoir tendance à perdre de vue le client et aller à l’encontre du premier principe agile (13) : “Customer satisfaction by early and continuous delivery of valuable software.”
Dans ce contexte le lean apporte deux choses très précises, deux axes d’apprentissages et de développement de l’équipe :
- un travail au plus près du client, avec l’équipe de support
- des indicateurs qui font du sens pour le client
1. Travail avec l’équipe de support
Le lean nous apprend que le travail d’amélioration démarre toujours au plus près du cient, avec une préférence pour commencer à travailler avec l’équipe de support ou des réclamations. C’est en effet à cet endroit précis que nous sommes au contact du client. Nous allons pouvoir ainsi comprendre très précisément, selon ses mots, les problèmes qu’il rencontre alors qu’il utilise notre produit. L’idéal est bien sûr d’aller voir le client pour observer comment il utilise le produit et voir les gaspillages que le produit lui impose. Cela étant souvent très difficile le travail avec le support représente une excellente alternative.
Il s’agit d’éléments factuels qui peuvent entrer en dissonance avec une vision de nos Product Owners ou encore de nos développeurs. Un bon moyen pour que l’équipe apprenne que le client va ainsi préférer la qualité à “l’innovation” et des temps de réponse réduits à un large scope fonctionnel.
Nous allons ainsi aller comprendre la nature des points remontés par le client et réfléchir à ce que cela nous apprend sur nos choix d’ingénierie.
Ensuite, nous allons réfléchir à comment réduire le volume des tickets en entrée : cela va induire une réflexion transverse qui va impliquer l’ensemble de l’organisation : le client va ainsi tirer les problèmes à traiter au niveau de l’organisation. En démarrant la réflexion au plus près du client nous allons pouvoir remonter la chaîne de valeur en comprenant mieux les conséquences des problèmes opérationnels que nous allons rencontrer en amont.
2. Indicateurs opérationnels
Le second axe lié au client est la mise en place d’indicateurs opérationnels qui font du sens depuis la perspective du client. Il s’agit d’un point de friction que j’entretiens avec mes amis agilistes : leur indicateur opérationnel principal est souvent la vélocité. Il s’agit du nombre de Story Points livrés par itération, le Story Point étant une unité abstraite et relative (utilisant souvent l’échelle de Fibonacci) représentant la complexité d’une User Story.
Si cet indicateur est un outil performant pour aider l’équipe à construire sa prédictibilité et sa capacité de production, comme l’explique très bien Mike Cohn dans Agile Estimating and Planning (23) (et comme me le rappelait fort justement mon collègue Cédric Pourbaix), en revanche il n’a aucun sens pour le client.
C’est pour cela que nous lui préférons le nombre de User Story livrées. À cet indicateur, nous ajoutons la qualité, avec le nombre de bugs, sur lequel nous allons travailler à l’amélioration permanente avec les outils Bac Rouge, Pareto, PDCA et standards. Nous allons aussi ajouter la Satisfaction Client à l’amélioration de laquelle nous allons travailler avec l’outil Voix du Client (34).
Cela peut sembler un détail sémantique ou d’une subtilité mais il s’agit dans les faits d’un point essentiel : comment voulez-vous aligner l’ensemble de l’organisation pour répondre au premier principe agile (livrer de la valeur au client) si les indicateurs de l’équipe opérationnels ne font pas sens pour le client ? Comme nous le rappelle Mary Poppendieck dans son entretien #hypertextual (24), les indicateurs opérationnels sont un levier très puissant pour orienter les décisions des équipes – et, à ce titre, un formidable outil d’alignement.
Measuring performance is the strongest mean of governance. If you measure the wrong indicators you will just make big mistakes in governance.
L’amélioration Continue
1. Retrospective are not Continuous Improvement
Dans son excellent article Retrospective are not Continuous Improvement (25) Leon Tranter explique bien la différence entre les deux pratiques.
There is a problem with the fundamental structure and format of retrospectives. They are distanced from the problems, in space and in time. This drastically reduces their effectiveness. Continuous improvement happens everywhere, with everyone, all the time. It is a change in how people do work and function in an organisation. Not a special meeting you have once a fortnight.
L’amélioration Continue dans le lean devenant une pratique quotidienne, cela change la façon de penser. C’est un mindset dirait l’expert Dave Thomas qui, s’éloignant des dogmes méthodologiques, définit ainsi aujourd’hui l’essence de l’Agile (26). Cette notion de rétrospective continue est aussi celle présentée par Antoine Contal et Régis Médina à Agile France 2011 (27).
Là encore, cela peut sembler être un détail sémantique ou organisationnel mais, il s’agit d’une différence très profonde. Après avoir mené avec succès une transformation agile sur une R&D de 70 personnes (22) je me suis rendu compte que les méthodes agiles étaient des outils formidables pour récolter les fruits mûrs de l’amélioration dans une usine logicielle. Comment mieux collaborer pour enfin livrer avec une meilleure qualité etc ….
Mais une fois ceux-ci recueillis, on a alors du mal à avancer pour résoudre les problèmes plus complexes. La raison est que l’outil d’amélioration mis à disposition pour les approches agiles (la rétrospective) est trop superficiel. Il ne permet pas d’explorer en profondeur les problèmes.
Ce que nous permet de faire le moteur de l’amélioration continue : le PDCA. Nous sommes ici au coeur du réacteur du lean. C’est grâce à la pratique résolue et obstinée de ce meta-outil, cette approche classique préférée à l’approche moderne (exploration des multiples outils proposés pour la rétrospective), que l’équipe va pouvoir indéfiniment s’améliorer. Pour cette raison que Hakan Forss présente le Lean comme un “puits intarissable de connaissance” dans son interview #hypertextual (28).
C’est aussi pour cette raison que l’on peut voir l’Agile comme un système de production et le lean comme est un système d’apprentissage (Régis Médina Lean IT Summit 2013 (29)). Ou comme le dit mon collègue Philippe Fenot : l’agile comme une approche permettant d’aller vite alors que le lean permet d’accélérer.
2. Le Rôle du manager
Nos clients, quelle que soit leur nature (éditeurs, ESN, DSI, startups), nous remontent souvent la même question : que deviennent les managers avec le mise en oeuvre de l’agilité ? Nous avons même rencontré un directeur d’entité qui nous confessait que suite à cette mise en oeuvre, deux de ces middle managers étaient partis en dépression. On retrouve ici un travers du caractère très auto-centré des équipes agiles : une tyrannie (équipes) en remplace une autre (manager et Command & Control).
Même si cela peut être compris (la maltraitance qu’a subi les équipes dans des DSI toutes puissantes où le métier de développement était souvent ramené à “pisser du code”) il n’en reste pas moins que l’on a le droit de penser que cette mouvance, aux avant-postes de laquelle on retrouve l’entreprise “libérée”, se trompe de cible. Ce dont on veut se débarrasser ce n’est pas des managers (des personnes) ou du management (une activité). Ce dont on veut se débarrasser c’est du Taylorisme, une culture organisationnelle héritée de la division du travail (30) selon laquelle on sépare celui qui pense (la personne intelligente ou qui décide – souvent la même depuis la perspective tayloriste) et celui qui fait (l’exécutant qui n’a pas le droit de penser).
En ce sens précis, le Lean est complètement opposé au Taylorisme. En se concentrant sur une dynamique d’amélioration continue, engageant chacune et chacun chaque jour, sur son poste de travail, pour améliorer les processus et les conditions de travail, le Lean est un élément majeur d’amélioration de la qualité de vie au travail (31). Et dans ce cadre le manager à un rôle double et essentiel :
- décliner les objectifs stratégiques d’amélioration en amélioration au niveau de son activité – le manager Lean a ainsi un sujet complexe d’amélioration à traiter personnellement. Lire à ce sujet The Lean IT Field Guide de Mike Orzen (32),
- coacher chacune et chacun dans la résolution de problèmes pour développer les compétences de son équipe sur le poste de travail (qualité) et dans la collaboration avec les autres (flux) – lire à ce sujet l’excellent Toyota Kata de Mike Rother (33). Le niveau de compétences de chacun sur toutes les compétences requises au sein de l’équipe sera suivi avec la matrice de compétences (35).
5. Outils Lean pour méthodes agiles
Universel (s’appliquant à tous les domaines d’activités), héritier d’une certaine sagesse orientale (séparer l’observation de l’analyse, se délester du jugement, challenger ses propres idées fausses), prônant la maïeutique et le questionnement comme mode d’encadrement, le Lean incarne un management, vertueux, diablement efficace et parfaitement complémentaire d’une démarche agile. C’est ainsi qu’il répond aux manques de l’agilité :
| Questions Lean | Outils Lean pour méthodes agiles |
| 1. Valeur Client | |
| Comment travailler au plus près du client pour mieux comprendre ses attentes ? |
|
| Comment s’assurer que nos indicateurs opérationnels ont un sens pour le client ? |
|
| Comment s’assurer que la satisfaction client s’améliore ? |
|
| 2. Qualité | |
| Comment s’assurer que l’on améliore la qualité de façon continue ? |
|
| 4. Amélioration Continue | |
| Comment s’assurer que l’on s’améliore chaque jour ? |
|
| Comment coacher les personnes chaque jour dans le développement de leurs compétences ? |
|
| Comment savoir qui doit apprendre quoi pour réussir et la faire travailler sur le bon problème ? |
|
Ressources
- Workplace Management by Taiichi Ohno
- Les vraies ruptures d’internet : Serge Soudoplatoff
- Institut Lean France
- Lean Thinking by Womack and Jones
- Steve Hope (Toyota Motors europe) at Lean Green Day
- Toyota Production System
- Toyota Way
- TPS or the Toyota Way by Michael Ballé
- Donna Tartt et l’esprit classique
- The Lean Strategy by Michael Ballé et al.
- Chrysler Comprehensive Compensation System (Wikipedia)
- Extreme Programming (Wikipedia)
- Agile Manifesto
- La beauté du geste : Craquer le code du savoir-faire
- System of Profound Knowledge (Wikipedia)
- Kanban Vs Scrum (Henrik Kniberg)
- Eloge de la User Story (slideshare)
- YAGNI : You Aint Gonna Need It (Martin Fowler)
- Behavior Driven Development (Wikipedia)
- INVEST (Wikipedia)
- DevOps en 2017 : les vrais enjeux et bénéfices
- Lean Software Development : deux fois plus vite et cinq fois mieux
- Agile Estimating And Planning (Mike Cohn)
- The Buena Social Software Club : interview with Tom & Mary Poppendieck
- Retrospective are not Continuous Improvement (Leon Tranter)
- Agile is Dead by Dave Thomas (Vidéo)
- Antoine Contal et Régis Médina à Agile France 2011 (Vidéo)
- An Interview With Hakan Forss (Vidéo)
- Lean and Agile : Régis Médina at Lean IT Summit 2013 (Vidéo)
- L’origine de la division du travail
- Lean et QVT :les deux font la paire
- The Lean IT Field Guide (Mike Orzen et al.)
- Toyota Kata (Mike Rother)
- Le meilleur des parcours client
- Matrice de compétences
Cet article est extrait de l’ouvrage #hyperlean en action – pratiques du management à l’ère du numérique
#hypertextual 
Sur le volet “Client”, XP précise explicitement que le client fait parti de l’équipe (“on site customer”) : http://www.extremeprogramming.org/rules/customer.html Et Dieu sait à quel point cette pratique fut difficile. Toujours pour cette relation équipe client, XP cherche une métaphore pour échanger sur le logiciel : http://www.extremeprogramming.org/rules/metaphor.html Ce fut longtemps une pratique complexe au sein d’une équipe XP (c’était avant que Scrum emporte tout).
Super contenu !
Ca fait plusieurs fois que j’essaie de formaliser comment la stratégie Lean et la méthode projet Agile se combinent plutôt qu’elles s’opposent.
Mon intuition, et la manière dont j’ai découvert le Lean c’est que mettre la pensée Lean en Tower Contrôle des activités Agiles, ça permet de faire de la véritable agilité là où dans l’immense majorité des cas, quand on parle d'”Agile” c’est juste le cache sexe d’un bordel organisationnelle et d’une absence de vision stratégique.