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 que s’ils choisissent cette direction c’est parce que la pensée Lean complète les méthodes agiles.

Dans ce premier article nous revenons aux sources de la pensée Lean, à un rappel très rapide des origines des méthodes agiles et analysons comment les secondes répondent aux questions posées par la première. Une fois cette cartographie faite, nous verrons en détail dans un second article comment le Lean complète les méthodes agiles …

1. La Pensée Lean

Comme l’explique volontiers Marie-Pia Ignace, présidente 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 :

1. Comment mettre le client au cœur 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 ?
2. Comment produire de la qualité à chaque étape de nos processus ?
3. Comment créer un flux continu de valeur, tiré par la demande client ?
4. Comment responsabiliser nos équipes pour les inscrire dans une démarche d’amélioration continue ?
5. 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 cessé 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). 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é Socrate.

Une approche toutefois extrêmement efficace en ce qu’elle permet d’analyser des situations dans tout type d’industrie. 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).

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 qualifie de tribal agilist). Une approche résolument moderne et inclusive, avec un sens de l’exploration horizontale, qui cherche à développer une familiarité avec une grande variété d’outils.

Si cette pensée se 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 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 ?	User Story (17)
Comment livrer le mix produit qui répond aux attentes du client ?	Sprint Planning
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 ?	Sprint Démo
Comment savoir que nos indicateurs opérationnels ont un sens pour le client ?	???
Comment améliorer la satisfaction client s’améliore ?	???
Élimination des Gaspillages
Comment éviter la surproduction ?	Sprint Planning Spécifications détaillées limitées à ce qui va être développé sur ce sprint Développement limité à ce qui va être testé sur ce sprint Test et validation limité à qui va être mis en production sur cette itération YAGNI (18)
Comment éviter les gestes inutiles ?	Automatisation du processus de Release
Comment supprimer les attentes ?	Animation quotidienne Équipes trans-disciplinaires et co-localisées (Feature Teams) Team Leader au service de l’équipe avec pour objectif de supprimer ses obstacles Des équipes en support, à la disposition des Feature Teams pour supprimer au plus vite les obstacles
Comment ne créer de stocks intermédiaires ?	Sprint Planning User Story Done Limite du WiP
2. Qualité
Comment ne pas passer de la non qualité à la prochaine étape du processus ?	En phase d’analyse fonctionnelle : User Story Ready To Dev En phase de développement unitaire : Tests Unitaires En phase de développement d’une User Story : Critères d’acceptation Behavior Driven Development (19)
Comment protéger le client de la non qualité ?	Intégration Continue
Comment améliorer la qualité de façon continue ?	???
3. Flux
Comment livrer en petits lots ?	Des Itérations courtes Des User Story INVEST (20) Des livraisons en continu (DevOps)
Comment créer un flux continu de valeur pour le client ?	Continuous Delivery (21)
Comment créer un flux continu de valeur tiré par la demande client ?	Kanban IT avec Limite du WiP
4. Amélioration Continue
Comment s’améliorer de façon régulière ?	Rétrospective
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 ?	Coding Dojo Pair Programming
Management de la production et de la performance
Comment atteindre nos objectifs de performance ?	Mélée quotidienne Burndown chart
Comment atteindre nos objectifs de production ?	Mélée quotidienne Scrum board
Comment rendre visible les problèmes ?	Scrum board Burndown chart
5. Stabilité
Comment stabiliser nos équipes ?	Feature Teams stables dans le temps Des équipes dédiées à un projet donné
Comment capitaliser sur nos savoir-faire ?	Wiki bonnes pratiques Capitalisation sur les pratiques lors de la rétrospective
Comment construire la capacité des équipes ?	Suivi de la vélocité / nombre de User Stories livrées sur les différentes itérations

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.

Ressources

1. Workplace Management by Taiichi Ohno
2. Les vraies ruptures d’internet : Serge Soudoplatoff
3. Institut Lean France
4. Lean Thinking by Womack and Jones
5. Steve Hope (Toyota Motors europe) at Lean Green Day
6. Toyota Production System
7. Toyota Way
8. TPS or the Toyota Way by Michael Ballé
9. Donna Tartt et l’esprit classique
10. The Lean Strategy by Michael Ballé et al.
11. Chrysler Comprehensive Compensation System (Wikipedia)
12. Extreme Programming (Wikipedia)
13. Agile Manifesto
14. La beauté du geste : Craquer le code du savoir-faire
15. System of Profound Knowledge (Wikipedia)
16. Kanban Vs Scrum (Henrik Kniberg)
17. Eloge de la User Story (slideshare)
18. YAGNI : You Aint Gonna Need It (Martin Fowler)
19. Behavior Driven Development (Wikipedia)
20. INVEST (Wikipedia)
21. DevOps en 2017 : les vrais enjeux et bénéfices