Lean et Agile : Ancêtres et cousins

Le Manifeste Agile a été écrit en 2001. Le système de production de Toyota a commencé à évoluer dans les années 1940. La pensée Lean précède l'agile de plus d'un demi-siècle.

Cela compte parce que les pratiques Agile n'ont souvent de sens qu'à la lumière des principes Lean. Pourquoi favorisons-nous « un logiciel fonctionnel plutôt qu'une documentation exhaustive »? Parce que la documentation avant le codage est de l'inventaire — une forme de gaspillage. Pourquoi voulons-nous « réagir au changement plutôt que suivre un plan »? Parce que les plans à long terme sont de la spéculation, et la spéculation produit du gaspillage quand la réalité diffère.

Beaucoup de difficultés agiles viennent d'équipes qui adoptent des pratiques sans comprendre les principes sous-jacents. Elles font des mêlées quotidiennes parce que Scrum le dit, pas parce qu'elles comprennent comment cela réduit le gaspillage de coordination. Elles limitent les sprints dans le temps parce que c'est le cadre, pas parce qu'elles comprennent comment les petits lots réduisent le risque.

Quand vous comprenez Lean, les pratiques Agile deviennent évidentes. Quand vous ne comprenez pas, elles semblent être des rituels arbitraires.

Scrum a adopté plusieurs concepts Lean :

• La limitation dans le temps comme contrainte de taille de lot
• Les équipes interfonctionnelles pour réduire les transferts
• Les rétrospectives pour l'amélioration continue
• L'auto-organisation comme respect des personnes
• Un logiciel fonctionnel à chaque sprint (livraison juste-à-temps)

Extreme Programming (XP) est encore plus explicitement Lean :

• La programmation en binôme réduit les défauts (intégrer la qualité)
• L'intégration continue empêche l'inventaire (petits lots)
• Le développement piloté par les tests détecte les bogues tôt (Jidoka)
• La conception simple évite le gaspillage (YAGNI)
• Le rythme soutenable respecte les personnes

Kanban est la méthode la plus directement dérivée de Lean. David Anderson a explicitement adapté les concepts du TPS : systèmes de flux tiré, limites de travail en cours, visualisation du flux, amélioration continue. Si Scrum a emprunté la philosophie de Lean, Kanban a emprunté ses mécanismes.

Aucune de ces méthodes ne nécessite que vous compreniez Lean pour les utiliser. Mais comprendre Lean vous aide à :

• Savoir quand enfreindre les règles
• Adapter les pratiques à votre contexte
• Diagnostiquer pourquoi les choses ne fonctionnent pas
• Combiner les pratiques de manière cohérente

Bien que Lean fournisse la fondation, Agile a ajouté des éléments importants pour le travail intellectuel :

Embrasser l'incertitude : Le Lean manufacturier optimisait des processus connus. Le développement logiciel fait face à une incertitude fondamentale — nous ne savons souvent pas quoi construire ou comment le construire jusqu'à ce que nous essayions. Agile intègre explicitement des mécanismes de découverte : itérations, rétroaction des utilisateurs, pivots.

Limites de temps : Le TPS n'avait pas besoin de sprints — la production était continue. Agile a introduit les limites de temps comme fonction de forçage pour les équipes logicielles peu habituées au flux continu. La limite de temps crée un rythme, limite la dérive de la portée et force la livraison régulière.

Cérémonies : Rétrospectives, mêlées quotidiennes, revues — ce sont des mécanismes pour les boucles de rétroaction que Lean exige, adaptés aux équipes de travail intellectuel. Ils ne sont pas uniques à Agile (Toyota avait des pratiques similaires), mais Agile les a codifiés pour le logiciel.

L'élément humain : Bien que le pilier « Respect des personnes » de Lean soit profond, Agile l'a rendu plus explicite pour le travail intellectuel. « Les individus et leurs interactions plus que les processus et les outils » du Manifeste et le « rythme soutenable » de XP soulignent que le travail intellectuel nécessite une motivation intrinsèque, pas seulement l'efficacité des processus.

Ni Lean ni Agile n'est complet seul. Lean fournit les principes et la théorie. Agile fournit des pratiques spécifiques pour le logiciel. Les meilleures équipes puisent dans les deux.