L’objectif de cet article est de décrire les deux pratiques en identifiant leurs ressemblances, leurs différences et l’histoire qui les relie.

Afin d’alléger le texte nous allons utiliser le mot Lean pour décrire la fabrication sans gaspillage et le mot agilité pour décrire l’agilité en développement logiciel.

Ce texte s’adresse autant aux lecteurs intéressés par l’agilité en développement logiciel qu’à ceux intéressés à la pensée Lean.

L’agilité couvre plus large que le développement logiciel mais cet article se concentrera sur cette dimension de l’agilité.

La pensée Lean touche plusieurs secteurs d’affaires, le développement de logiciel en est un. Il ne faut pas faire l’erreur de tout généraliser car chaque secteur d’affaire possède sa propre réalité qui lui fait développer une adhésion différente à la pensée Lean.

J’ai été impliqué depuis plusieurs dizaines d’années dans des projets de développement logiciel qui touchaient le milieu manufacturier. J’ai donc été mis régulièrement en contact avec des ingénieurs qualité qui préconisaient la pensée Lean. Ce texte reflète donc une réflexion sur une réalité acquise directement sur le terrain.

Définition du Lean

Pour une entreprise de production, le Lean est à l’origine de l’amélioration continue qui réévalue les résultats d’expérimentations de changements régulièrement. Cela permet une évolution dans la bonne direction et d’éliminer les pertes. Cette approche est née chez Toyota dans les années 50.

Voici, sans être exhaustif, les grands principes de la pensée Lean :

  1. La production se fait dans un environnement complexe. Nous devons donc regarder cet environnement de manière holistique et prendre les moyens pour le comprendre;
  2. Les personnes sont notre plus grande richesse;
  3. L’équipe de gestion permet à l’organisation de toujours livrer plus de valeur d’affaire aux clients;
  4. Le flot de valeur généré s’accélère en éliminant les pertes. On vise le « juste à temps » en réévaluant constamment nos manières de faire;
  5. Nous visons une constante amélioration de notre processus et de nos outils;
  6. Des indicateurs fiables nous permettent une évaluation juste de notre processus et de notre production;
  7. Nous utilisons l’approche du flux tiré.MaisonToyota

Définition de l’agilité en développement logiciel

L’agilité n’est pas un état, une qualité ou même un objectif, c’est l’évolution d’un système de production de valeur d’affaire qui amène une organisation à mieux livrer le logiciel que le client désire.

Pensée lean et Agilité

Pour détailler notre comparaison, nous allons maintenant reprendre chacun des sept éléments de la liste de la pensée Lean et les mettre en relation avec l’agilité en développement logiciel:

1.    La production se fait dans un environnement complexe. Nous devons donc regarder cet environnement de manière holistique et prendre les moyens pour le comprendre.

En pensée Lean on attribut l’évolution positive de l’organisation à la bonne gestion de tout le système. En agilité logiciel on tend à se concentrer sur un aspect à la fois et à se concentrer plus sur l’équipe que sur l’organisation globale. L’approche DAD (Disciplined Agile Delivery) recommande une approche plus globale que SCRUM comme exemple d’évolution dans le monde du logiciel.

En pensée Lean, le focus est mis sur le système global de production, les personnes doivent y trouver leur place. En agilité, les personnes comme les développeurs et les clients occupent le premier plan. On a même vu apparaître, ces dernières années, des approches qui tentaient de prendre plus soin de l’organisation. (ex. : SAFE, etc…). La réaction des pères d’Agile a été radicale. Non! Ce sont les individus qui sont importants.[1]

2.    Les personnes sont notre plus grande richesse

En agilité logicielle, les développeurs sont les premiers responsables de l’évolution positive des manières de faire. En pensé Lean, cela appartient d’abord aux gestionnaires qui, ensuite, impliquent les travailleurs de la base. Bien sûr, le gestionnaire Lean va consulter le travailleur sur le plancher mais c’est lui qui a la responsabilité de l’amélioration du processus.

3.    L’équipe de gestion permet à l’organisation de toujours livrer plus de valeur d’affaire aux clients

L’approche Lean ne préconise pas une hiérarchie de gestion « top-down » mais plutôt une responsabilisation de la couche moyenne de gestion. Ces gestionnaires doivent faire le lien entre ceux qui définissent les orientations de l’organisation et ceux qui exécutent le travail. Cette couche de gestion est aussi responsable de l’amélioration continue.

En agilité logicielle, en SCRUM par exemple, l’équipe est rendu responsable de son processus avec l’aide d’un SCRUM master qui n’est là que pour les guider. L’équipe SCRUM mature est autosuffisante. En Lean, l’équipe compte sur ses gestionnaires pour la guider vers ce qui a été convenu par la direction pour améliorer la qualité.

4.    le flot de valeur généré s’accélère en éliminant les pertes. On vise le « juste à temps » en se réévaluant constamment nos manières de faire.

Éliminer les délais dans le processus, de bonnes rétroactions sur les expériences est essentiel pour éliminer les pertes.

En agilité logicielle, on utilise le même concept. On désire trouver les erreurs de codage le plus tôt possible. On désire définir les requis le plus clairement possible la première fois pour éviter de trop nombreuses interactions pour les clarifier. On évite de faire du code au cas où on en aurait besoin, on ne code que l’essentiel et on vérifie le plus rapidement possible sa pertinence avec le client. L’approche de livraison en continue du logiciel confirme cette ressemblance.

5.    Nous visons une constante amélioration de notre processus et de nos outils.

C’est la base de la pensée Lean et, en agilité logiciel, on est plutôt allergique aux processus. Rappelons-nous cette phrase dans le manifeste agile :

« Les individus et leurs interactions plus que les processus et les outils »

Utilisons, encore, la méthodologie SCRUM pour comparer les deux. En SCRUM, le SCRUM master est responsable que l’équipe prenne soin de son processus et soit sensible à son amélioration. Il n’est pas là pour imposer un processus statique.

En pensée Lean, les responsables du processus vont l’analyser en détail avec l’aide des équipes. Ils vont l’optimiser, le définir en détail pour ensuite l’implanter dans l’organisation. En pensée Lean, on n’aime pas ce qui est floue, en agilité logicielle, certains leaders affirment même que la complexité qui s’approche du chaos est créatrice[2].

6.    Des indicateurs fiables nous permettent une évaluation juste de notre processus et de notre production.

Ici, les deux formes de pensée se rapprochent. En Lean on entend souvent parler de KPI (Key Performance Indicators). Les adeptes du Lean aiment se baser sur des indices concrets et précis pour évaluer et transformer leur processus.

En agilité logicielle, cette tendance tend à s’amplifier car de nouveaux outils aident à mesurer la complexité liée à ce domaine de création. Les développeurs sont de plus en plus sensibles au fait qu’une mesure qui n’est pas liée qu’à l’instinct peut les aider.

En agilité logicielle, le dialogue face à face est reconnu comme étant le meilleur moyen de recueillir l’information pertinente. Cette méthode moins structurée que les outils préconisés par la pensée Lean a pour intérêt d’être rapide, efficace et précise mais cette information doit être utilisée très rapidement.

7.    Nous utilisons l’approche du flux tiré

Le flux tiré est l’approche chouchou des adeptes du Lean manufacturier. L’agilité en développement de logiciel s’en inspire grandement en adoptant une approche où, à intervalles réguliers, lorsqu’on a terminé ce qu’on a à faire, on retourne voir le responsable de produit pour recharger la liste de travail à faire.

Comme dans la pensé Lean avec son système KANBAN, on tente de limiter le plus possible le nombre d’items à livrer et la durée pour les produire afin de régulariser le système le plus possible. Plus les listes d’item sont courtes et les délais de livraison rapide, moins on risque de générer du gaspillage.

Conclusion

Nous venons de présenter l’agilité logicielle en rapport avec son ancêtre la pensée Lean. Ce court texte effleure le domaine mais nous souhaitons qu’il ait généré chez le lecteur une réflexion qui permettra de mieux comprendre le lien entre les deux.

Rappelons-nous que la pensée Lean a été créée pour livrer des produits stables et relativement simples de manière répétitive dans un environnement complexe qu’est une usine alors que l’agilité logicielle a été créée pour livrer un produit complexe et changeant dans un environnement plus simple qu’une usine. Il y a des différences entre les deux approches mais les ressemblances restent fondamentales. On n’est pas Lean ou Agile, on n’est toujours les deux.

Si vous avez des commentaires, n’hésitez pas à nous en faire part car ce texte se veut agile; soit en constante recherche d’amélioration.

Quelques références :

http://martinfowler.com/bliki/AgileVersusLean.html

http://www.netobjectives.com/blogs/why-understanding-lean-essential-agile-transformation

[1] Ken Schwaber : https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/
« Keep the values, keep the principles, think for yourself.  A core premise of agile is that the people doing the work are the people who can best figure out how to do it. The job of management is to do anything to help them do so, not suffocate them with SAFe. »

[2] Jurgen Appello : « Researchers say that complexity – that interesting state between order and chaos – is the root of innovation, in physics, biology, psychology, and beyond. » Management 3.0, 2011,  page 53

Publicités