Agile, Lean, Scrum et informations diverses
icône RSS icône Emai icône Accueil
  • Lean vs Agile

    Posté le avril 1st, 2009 Alexandre Boutin 7 commentaires

    james-suttonLors de la conférence Adacore sur le Lean et l’Agilité pour les logiciels critiques, James Sutton nous a fait une présentation particulièrement pertinente sur l’approche Lean et le différences principales d’approches entre le Lean et l’Agilité.

    Outre le fait que James est un bon orateur, qui plus est particulièrement sympathique comme les discussions d’après conférence m’ont permis de réaliser, il est encore plutôt rare d’assister à des présentations Lean en France alors je vous propose de partager mon plaisir en vous donnant les grandes lignes dans cet article.

    La présentation a été filmée et sera mise en ligne prochainement par Adacore … je vous tiendrais au courant :)

    James nous a d’abord fait une présentation rapide du Lean, du travail de W. Edwards Deming, de la notion de « Profound knowledge » et de la vision système propre au Lean. Puis James nous a donné des résultats comparatifs des différentes approches en termes de productivite et de qualité (y compris l’externalisation dont la qualité est particulièrement faible comparée aux autres approches), pour conclure que le Lean est bien plus productif que toutes les autres approches, et l’Agilité est en 2ème place … mais assez loin :)

    Pour ce qui est de la comparaison entre Lean et Agilité, James identifie 5 points :

    • Optimisation :
      • Le Lean requiert de construire une « Profound Knowledge » pour garantir la réalisation d’un système oprtimisé (Domain Design, Change-Driven Design)
      • Agile considère que la conception émergera de la réalisation et que l’optimisation sera faite dans une seconde étape (Refactoring)
    • Level of Focus
      • Le Lean se positionne au niveau de l’entreprise et considère des systèmes de systèmes (Hoshin Kanri, QFD)
      • Agile est au niveau projet et considère un unique système (Extreme Modeling, Scrul Teams, Scrum of Scrums, Business participation)
    • Vérification/Validation
      • Le Lean préconise de faire les choses bien du premier coup et ensuite d’évoluer vers quelquechose d’encore mieux (Poka Yoke, Jidoka, Autonomation, Cleanroom, Formal Methods)
      • Agile démarre de rien pour évoluer vers la bonne solution (Test Driven Development, Refactoring)
    • Variation
      • Le Lean considère le business comme un processsus, et comme tout processus ses variations doivent être analysées pour identifier celles qui sont communes de celles qui sont spécifiques (Control Chart)
      • Agile ne mentionne pas de concepts de variations différentes
    • Prédiction
      • Le Lean impose la prédiction systématique basée sur des hypothèses (PDSA, TRIZ, Change-Driven Design)
      • Agile considère que le futur est inconnu et que l’approche empirique permet d’accumuler de la connaissance pour se rapprocher de l’objectif (Emergent Behavior, Short Development Cycles, Customer Involvment)

    En conclusion, James considère que les approches Lean ou/et Agile sont pertinentes, bien plus que les approches traditionnelles, mais que les bénéfices apportés par le Lean sont à la hauteur de la difficulté d’implémentation. Les bénéfices de l’Agilité sont moindres mais l’implémentation est relativement facile.

    A vous de faire votre choix !

     

    7 réponses à “Lean vs Agile”

    1. Alex, sur cette phrase : « Le Lean préconise de faire les choses bien du premier coup… »

      On gagne sans doute beaucoup à suivre cette préconisation dans la création d’un chaine de montage ou dans le BTP, tant le coût de l’erreur est grand.

      Mais si on l’applique au logiciel, on travaille de façon sub-optimal parce qu’on passe à côté d’un caractéristique fondamentale du génie logiciel, qui permet à tout instant de « déplacer tout l’immeuble d’un cm » à coût quasi nul.

    2. L’architecture agile est toujours un sujet qui fait débat :)

      Si je me mets du coté client, quel est la plus value apportée par le temps passé à déplacer l’immeuble d’1 cm même pour un coût faible ?

      Je pense qu’il faut trouver un équilibre et que l’on peut mixer les 2 approches, le Lean qui préconise de concevoir un logiciel tolérant aux changements (donc avec une étape préalable d’analyse du système et de ses interactions) et l’agilité qui propose de faire quelque chose rapidement, prendre le feedback, et améliorer ce qui a été fait.

    3. Hello,
      lors de sa présentation, Jim a résumé le comparatif des 2 démarches à cette petite formule:
      Lean: « Get prepared! »
      Agile: « Get started! »

    4. Yann Picard de Muller

      Hello,

      On arrive à un point intéressant maintenant, celui où nous pouvons commencer à mesurer non seulement en quoi agile et lean sont comparables, mais aussi ce en quoi il sont différents…

      Ceci écrit le « agile » décrit dans ce comparatif ne semble pas correspondre à une méthode publiée (toutes débordes sur au moins un des points mentionnés vers le lean)…

      Pour ce qui est de l’architecture, globalement les méthodologies représentées lors de l’écriture du manifeste agile ne laissent pas l’architecture de côté…
      … d’où le principe : « Une attention continue portée à l’excellence technique et à la qualité de la conception améliore l’agilité »

      Trois exemples :
      - XP : 2 heures de conception par jour, sans compter ses origines dans la communauté des patterns, et quelques figures « de proue » de l’architecture (Martin Fowler, Eric Evans)
      - FDD : on commence par la modélisation du domaine, on fait une revue de conception avant de procéder à la réalisation de la fonctionnalité, …
      - Crystal : on utilise la stratégie du « squelette ambulant » qu’on va étoffer…

      En gros l’idée initiale était que ce n’est pas parce qu’on est réactif que cela nous dispense d’être pro-actif…
      … je me demande quand cela s’est perdu ?

      Merci pour ce billet !

    5. Salut Alex,
      J’ai beau lire et relire la partie « Vérification/Validation » ne passe pas.
      Le TDD permet de faire émerger l’architecture et donc que le code est bien fait. La notion de « Vérification/Validation » (le code fait bien ce qu’il doit faire et pas autre chose) est introduite par les spécifications exécutables que ça soit au travers du BDD ou de l’ATDD.
      Le TDD n’est qu’une méthode pour faire émerger l’architecture cependant il ne se suffit pas à lui même s’il n’y a pas eu réflexion en amont pour définir un modèle de domaine (cf. Eric Evans et le DDD). Dan North précise bien que la notion de BDD vient en complément du DDD (qu’il valide) et du TDD (qui lui valide l’implémentation du modèle de domaine).
      Lors du dojo sur le mastermind on a bien vu que l’absence de définition d’un modèle de domaine et d’un langage propre au domaine (ici le jeu mastermind) a fini par nous poser des problèmes car plus personne n’arrivait à communiquer.

    6. Je suis d’accord avec toi et je pense que le DDD est une façon de fusionner agilité et lean.

      Il est important de préciser que James pour autant qu’il soit convaincu par le Lean n’est absolument pas un adversaire de l’Agile.

    7. Bonjour Agilex,
      merci pour ce billet, d’accord avec la teneur des commentaires, à mon humble avis :
      i) optimisation: non, c’est pas « la conception émergera » c’est « la conception émerge » ; sur ce point, le débat de fond est peut-être conception hardware vs software. Dans Lean software y’a « Lean », mais y’a aussi **software** ; et cette incompréhension rejaillit ensuite sur l’aspect qualité

      ii) Level of focus, mouais.. si dans les méthodes de soft (RUP, scrum xp..) la « figure » du client est en gros le résumé coté métier, utilisateurs, il reste qd même que le 1er principe agile est directement lié à la V.A. pour l’entreprise. Autre point: pourquoi « projet » ; il me semble que en agilité, on se concentre plus sur **l’appli** que sur le projet

      iii) ver & val: alors là, je suis choqué :-) , comme d’autres commentateurs, ce qui est cité c’est le contraire de l’agile

      iv) variation: là encore, on retrouve effectivement le côté simplificateur de l’agile: la figure du Client ou PO qui gère cet aspect, sachant quand même que, côté outil informatique, on « accueille les changements » (ah, le fameux embrace change de Kent B.)

      v) prédiction: ok, mais là aussi, je me demande si la différence fondamentale entre hard et soft est vraiment prise en compte.

      ça me rappelle, y’a bien des années (ah.. je fais mon ancien combattant maintenant..) une histoire que l’on racontait à propos de chefs de chantier du batiment, grand professionnels, qui se moquaient de ces informaticiens infoutus de tenir un planning et qui s’étaient eux aussi cassés les dents…
      On fait un métier formidable quand même :)

    Laisser une réponse