23 Fév 2014, 9:59
Défaut:
by

7 comments

Amélioration continue … et discontinue

Dans le développement logiciel, les démarches « Lean » inculquent une culture de l’amélioration continue qui s’articule autour de méthodes et d’outils, parmi lesquels : le kanban, la gestion des flux, le WIP, la taille des lots, la gestion des queues, l’intégration poussée des tests depuis les phases de spécifications, etc.

Mais je remarque que, outre les nombreuses vertus de ces démarches, elles peuvent avoir des effets anesthésiants sur le comportement des équipes et peuvent s’avérer néfastes si l’on n’y prend pas garde.

Car, à force de travailler à petit pas, à flux tendu et dans une perspective systémique ; à force d’être attentif aux petites corrections et optimisations, on devient aveugle aux aspects environnementaux et architecturaux qui rendent possible cette logique de l’amélioration continue.

Quel que soit le périmètre de la démarche Lean, celui-ci pré-suppose un environnement – disons une infrastructure et une architecture – sur la base duquel seulement les logiques d’amélioration continue peuvent oeuvrer.

Une démarche Lean tend,  à force de progresser de manière continue dans un périmètre donné, à vouloir étendre son périmètre aux activités amont et aval du développement.

En amont, on sensibilisera les Business Analysts et les Product Owner sur la nécessité de travailler également selon ces méthodes ; et en aval on tentera d’inculquer cette culture du développement agile et lean à ceux qui, traditionnellement, cherchent à stabiliser les environnement de mise en production du logiciel : les administrateurs systèmes. Contaminés par le virus du Lean, ils s’appellent à présent les DevOps. Mais il n’y a pas que les DevOps, le Lean se décline à toutes les sauces : Lean Architecture, Lean UX, Lean UI, Lean Analytics, Lean Start Up , etc.

Le Lean a une tendance à se propager sur toute la chaîne de valeur de l’entreprise, de proche en proche. Cette propagation de proche en proche a un nom technique : on parle de transduction (pensez au mécanisme de propagation des ondes).

*

Mais pourquoi se plaindre d’une telle propagation du Lean s’il y a des résultats et si, en plus, il est plus motivant de travailler dans cet environnement méthodologique ?

Le problème est que tout ne peut pas être résolu et traité par des améliorations continues : il faut aussi des améliorations discontinues. Ces améliorations discontinues sont celles qui font faire des bonds en avant et qui seules sont capables d’opérer des ruptures.

Ainsi, une équipe de développement focalisée sur le continuous delivery n’aura plus le réflexe de remettre en cause ses architectures parce qu’elle ne les perçoit plus, comme le poison d’Aristote qui ne voit pas l’eau dans laquelle il évolue.

Tout comme la fluidité du fleuve nécessite la relative permanence du lit et des berges pour s’écouler, toutes les activités en flux nécessitent un environnement stable pour opérer.

La nécessité de ces progrès discontinus, ou de rupture, peut se comprendre à l’image des mécanismes d’apprentissage et surtout de compréhension. Je suis convaincu que quand on comprend quelqu’un chose c’est toujours quelque chose comme un “saut quantique” qui se produit ; une étincelle qui embrase tout votre esprit et vous fait voir les choses de manière radicalement différente.

En matière d’apprentissage et de pédagogie, l’exercice, l’entraînement, la répétition, le rythme –  en tant que techniques d’amélioration continue – n’ont de sens que si, à un certain moment, l’apprenant fait un bond en avant en s’écriant : eureka !

Si les démarches d’amélioration continue, à force d’accumuler des succès, ne débouchent pas sur des logiques de rupture, c’est très probablement que le fruit des améliorations cumulées est anesthésiant plutôt que dynamisant : un potentiel homogène plutôt que disparate. Et chacun sait qu’il n’y a pas d’éclair sans une accumulation de potentiels disparates.

Une bonne démarche d’amélioration continue doit donc déboucher sur des ruptures qui, une fois franchies, permettent de repartir sur des démarches d’amélioration continue mais à un tout autre niveau et avec de nouveaux enjeux.

Je pourrai le dire plus vulgairement : une amélioration continue qui ne conduit pas à un changement qualitatif de l’environnement dans lequel elle opère, conduit à “enculer les mouches” : on tourne en rond et la valeur des features mises en production tend a stagner car on tend à maintenir artificiellement la variabilité, c’est à dire la métastabilité,  du système que l’on développe.

Le système de production est alors sur une tendance entropique, et seule une rupture et un changement de palier va pouvoir produire de la néguentropie et une relance de la production de valeur.

Les équipes de développement en mode Lean doivent pouvoir compter sur des architectes qui sont capables de proposer des ruptures : des changements de frameworks, de patterns, de composants applicatifs, etc. Cette activité d’architecture possède une forte composante créative ; à l’image des intermittents du spectacle, ils sont les intermittents du Lean développement : on ne peut pas évaluer leur productivité à l’image du temps passé ou des petites améliorations qu’ils peuvent mettre en place. On attend d’eux qu’il changent la donne et nous fassent passer à un autre niveau.

En ce sens, les architectes sont des ruminants ; je veux dire par là qu’ils doivent habiter le système et en cultiver une représentation mentale qu’ils arpentent continuellement dans l’espoir de trouver une rupture, qui est souvent un raccourci,  et qui va permettre au système d’accéder à un autre niveau de métastabilité.

Ces propos sont une critique du Lean qui, pourtant, est un Lean inspiré des thèses de Donald G. Reinersten (merci Dimitri pour le conseil) et qui a le mérite de penser la spécificité du Lean dans des environnements à forte variabilité comme le développement logiciel, et non pas à partir du Lean des industries de process (semiconducteur, industries chimiques et pharmaceutiques, etc.) ou des industries manufacturière telle que l’automobile. Mais, même dans les travaux de Reinersten la question de la rupture et du discontinue n’est pas traitée en tant que telle parce qu’elle est étouffée dans le  discours sur la variabilité (qui est lui même par ailleurs assez exceptionnel).

23 Fév 2014, 3:32
by Jean-Baptiste Potonnier

reply

Plutôt d’accord dans l’ensemble avec votre propos, une question subsiste : à votre avis, est-il possible, ou même souhaitable, qu’une même personne soit responsable de l’amélioration continue, et de l’amélioration discontinue.

Par exemple dans une équipe de développement ou l’amélioration continue est le mode de fonctionnement habituel, ne peut-on pas envisager d’aménager des plages de temps ou le développeur deviendrait architecte?

D’autre part, un architecte qui ne prend plus part au développement devient très vite non pertinent, et ses proposition seront difficilement acceptées par les développeurs (autrement que par autorité du management)

Sur un plan plus personnel, je ne conçoit pas mon métier de développeur sans la partie architecture. Abandonner l’une ou l’autre de ces activité serait me serait difficile.

Je pense que l’on peut aussi mettre en œuvre un changement d’architecture de manière continue. Par exemple déployer de manière continue des petits changement, dont le but est la mise en place d’une nouvelle architecture.

[Reply]

A vrai dire je n’ai aucune religion en la matière, a savoir est ce que c’est une ou plusieurs personnes, mais par contre cette pratique de la discontinuité doit s’exercer.

[Reply]

24 Fév 2014, 9:52
by Loup Cellard

reply

Merci pour ce billet !
Je suis étudiant dans le master Architecture de l’information de l’ENS de Lyon et j’aurai voulu en savoir plus parce que vous vous entendez par « Architecte » ? Dans cet article est-ce que vous parlez seulement d’architecte logiciel ou de la figure de l’architecte dans un sens plus large ? Je ne connais pas bien le métier d’architecte logiciel, mais votre définition de l’architecte semble pas très éloigné de la tradition des architectes de l’information qui vient plutôt de l’UX design et de la bibliothéconomie…

[Reply]

Je parle bien d’Architecte logiciel.

[Reply]

En fait cette question est très proche du paradoxe « exploitation vs exploration », qui est très présente dans la littérature en gestion, depuis JG March en 1991, je crois.

L’amélioration continue telle que vous l’analysez ici se confond avec l’exploitation : il s’agit de conserver des infrastructures et des architectures qui ont fait leur preuve et qui permettent des innovations incrémentales rapides. L’amélioration discontinue s’apparente alors à l’exploration : on réfléchit, on casse les lego et on essaie autre chose.

Pour les intéressés, cette littérature en management s’est penché sur certains moyens de réussir à mêler ces deux nécessités dans une même organisation : par séparation hiérarchique (des postes et des fonctions s’occupent de l’exploitation, d’autres de l’exploration), temporelle (une phase d’exploitation et une phase d’exploration), géographique, etc.

En revanche je trouve regrettable que la Lean startup soit naturellement associé à cette même idée (à cause du « lean »). En fait, d’après moi, la lean startup emprunte surtout au concept de just-in-time (nécessité d’avoir une demande en bout de chaine pour lancer le produit en particulier), et peu au concept d’élimination du gaspillage et d’efficience extrême. Le déploiement continu notamment est, selon moi, plutôt un outil destiné à rendre l’expérimentation la plus simple et occurrente que possible. Finalement, même dans un tel cadre, les expérimentations peuvent amener à des pivots, et à des innovations radicales, qui ne sont donc sans doute pas classables dans l’amélioration continue !

[Reply]

Merci Jérémie pour ce commentaire sur le paradoxe « exploitation vs exploration ». Par ailleurs, je trouve la remarque sur le Lean Startup très juste.

[Reply]

11 Mar 2014, 10:31
by Dimitri BAELI

reply

Dans une récente présentation à QCon London Katherine Kirk a présenté une vision très surprenante de l’amélioration continue, et très intéressante.
Si je m’aventure à synthétiser sa pensée : l’amélioration continue porte des ondes négatives car elle suggèrerait que quelque chose pose problème (besoin d’amélioration), et que c’est infini (continuité). De e fait il est important de sortir de cette terminologie pour la rendre plus vertueuse. Elle propose « Consistent Discovery Technique » je vous laisse découvrir les détails ici : http://www.slideshare.net/lkce/tue-kirk-lkcecontimrp2013 (version 2013), et en vidéo ici http://vimeo.com/80986187

C’est peut-être un moyen de réconcilier les améliorations continues et discontinues que de parler de découverte.

[Reply]

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.