Hier, dans la première partie de cet article, nous sommes revenus aux sources de la pensée Lean, à un rappel très rapide des origines des méthodes agiles et nous avons analysé comment les secondes répondent aux questions posées par la première. Une fois cette cartographie faite, nous pouvons regarder en détail dans ce second article comment le Lean compléter les méthodes agiles …

4. Ce que le Lean apporte à l’agile

Le tableau de l’article précédent nous permet de rendre visibles quelques manquements dans le corpus agile. 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’œuvre 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 :

1. un travail avec l’équipe de support
2. 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 client, avec une préférence pour commencer à travailler avec l’équipe de support ou des réclamations. Nous allons pouvoir ainsi comprendre très précisément, selon ces 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 aussi aller voir le client pour observer comment il utilise le produit et voir les gaspillages que le produit lui impose.

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 for 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 stories 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 sur laquelle nous allons travailler sans cesse à l’amélioration avec l’outil voix du client (34).

Ce qui peut sembler n’être qu’un détail sémantique ou une subtilité est en fait 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 opérationnels de l’équipe 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. Retrospectives are not Continuous Improvement

Dans son excellent article Retrospectives 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 cœur 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 la mise en œuvre de l’agilité ? Nous avons même rencontré un directeur d’entité qui nous confessait que suite à cette mise en œuvre, 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’ont 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 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 le Lean est complètement opposé au Taylorisme. En se concentrant sur une dynamique d’amélioration continue, engageant chacune et chacun, 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). (Regarder à ce propos la présentation « Les managers, les oubliés de l’agilité » de Cédric Pourbaix)

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 ?	Travail sur Activité Support Voix du client Remontée du flux
Comment s’assurer que nos indicateurs opérationnels ont un sens pour le client ?	Nombre user stories Qualité Satisfaction Cclient
Comment s’assurer que la satisfaction client s’améliore ?	Entretiens voix du client Suivi de la satisfaction client
2. Qualité
Comment s’assurer que l’on améliore la qualité de façon continue ?	Bac Rouge Pareto PDCA
4. Amélioration Continue
Comment s’assurer que l’on s’améliore chaque jour ?	PDCA chaque jour
Comment coacher les personnes chaque jour dans le développement de leurs compétences ?	Standards Kata de management
Comment savoir qui doit apprendre quoi pour réussir et le faire travailler sur le bon problème ?	Rôle du manager (Kata de management) Matrice de compétences

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
22. Lean Software Development : deux fois plus vite et cinq fois mieux
23. Agile Estimating And Planning (Mike Cohn)
24. The Buena Social Software Club : interview with Tom & Mary Poppendieck
25. Retrospective are not Continuous Improvement (Leon Tranter)
26. Agile is Dead by Dave Thomas (Vidéo)
27. Antoine Contal et Régis Médina à Agile France 2011 (Vidéo)
28. An Interview With Hakan Forss (Vidéo)
29. Lean and Agile : Régis Médina at Lean IT Summit 2013 (Vidéo)
30. L’origine de la division du travail
31. Lean et QVT :les deux font la paire
32. The Lean IT Field Guide (Mike Orzen et al.)
33. Toyota Kata (Mike Rother)
34. Le meilleur des parcours client
35. Matrice de compétences