Grammaire de l’inaction et programmation fractale

Aujourd’hui je me propose de commenter deux petites contributions personnelles qui datent de plus de 10 ans, mais que je souhaite revisiter à l’aune du lean management, parce que le lean apporte un éclairage sur ces deux paradoxes.

La première contribution est une « grammaire de l’inaction », un générateur de plans de travail qui permettent de procrastiner, c’est-à-dire de parler de tout sauf de ce que l’on va faire. Cette construction ludique est une sorte de blague de potache « geek », une réaction de jeune collaborateur  face à des présentations de « consultants » que je trouvais fortement ennuyeuses à l’époque. Je suppose que je ne suis pas le seul à avoir assisté à une présentation d’un nouveau projet, d’un nouveau plan de transformation, d’une nouvelle démarche de changement et d’avoir trouvé que :

• Au bout de 30 slides, on ne sait toujours pas de quoi l’on parle,
• Le discours est un « discours méta », qui ne porte ni sur le problème et encore moins sur la solution, mais plutôt un « discours de la méthode », sur le « comment » et pas sur le « quoi »,
• Les même slides peuvent resservir d’un projet à l’autre, d’une entreprise à l’autre, elles sont complètement génériques (d’où l’expression « slides de consultants »).

J’avais construit la « grammaire de l’inaction » qui suit comme une abstraction qui permet de générer un plan de travail très riche, au point que  l’action (le ) se trouve noyé, ou n’a plus besoin d’être détaillé puisque la matière pour produire les « slides » est riche (l’application de l’aphorisme « noyer le poisson »). C’est une grammaire au sens informatique du terme, en format BNF, puisqu’il s’agit d’une plaisanterie de geek. Je l’ai utilisé une fois en présentant un jeu de slides sur une « nouvelle stratégie informatique » d’un consultant célèbre, Mr TerShiBul (à lire à l’envers) … et personne n’a détecté de supercherie, ce qui a été une grande leçon d’humilité sur mes propres slides !

  (do)   ::=     (pre-validate) (do)  |

                   (plan)  (do)  (followup) |

                   (explain) (do) (training) |

                   (instrument) (!—set up measure --) (do) (measures analysis) |
                   (set up success criteria) (do) (check) |

                   (small scale POC) (partial do) (do) |  (!-- partial: spatial/geographical/organizational  --)

                   (quick wins) (first step : 80/20) (do) |

                   (list all possible action paths) (do)  (!— the longer the list, the less content --)

(pre-validate) ::= (prototype) (feedback) | ( stakeholders opinion poll) | (build ROI case)

(plan) ::=  (benchmark) (plan) |

                   (study) (plan) |

                   (data collection from the field) (plan) (verification) (!—check against data--)

Note: J'ai abandonné l'idée d'utiliser des "brackets", d'ou le recours aux parenthèses (confusion HTML/BNF). Cette grammaire ne demande qu’à s’enrichir, je suis preneur de nouveaux « patterns » :

C’est une grammaire de l’inaction dans le sens où, au lieu de s’occuper de ce qu’il y a à faire (le ), on peut dériver une longue chaine de choses à faire autour du . Le délicieux paradoxe est que le lecteur avisé aura reconnu tous les principes du management de la qualité, certains principes de la gestion du changement et du pilotage de projets, bref, tout ce que je prône dans mon dernier livre. Cette tension entre ma perspective d’aujourd’hui – un chantre du TQM – et ma perspective d’hier – stop au baratin (le terme anglais qui me vient à l’esprit est moins ragoutant) - , est résolue par le lean management. Plus précisément, par les trois principes suivants :

1. On parle des vraies choses : on décrit les problèmes de façon pratique et systémique (grâce au management visuel), on parle des solutions concrètes.
2. Comme tout ceci n’est pas forcément simple, on va « sur le terrain » (gemba ) pour confronter la situation, le problème. Parler d’une solution « en situation » est la meilleure façon d’éviter d’être « à coté de la plaque ».
3. On évite les listes trop longues, on se concentre sur quelques actions, on les priorise, et on travaille sur une chose à la fois, puis on recommence.

Bref, le lean est radicalement opposé au « discours de la méthode », même s’il repose sur une méthode (on laisse le méta pour les discussions de salon et les livres, on pratique la résolution de problème).

J’en viens maintenant à mon deuxième sujet, la méthode de développement logiciel que j’ai utilisée au cours des années (en particulier lorsque j’étais au e-Lab), et que j’avais baptisée de « Fractal Programming » il y a dix ans. J’ai profité des vacances d’Aout 2011 pour me lancer dans un projet logiciel, « Systemic Simulation of Smart Grids », et j’ai instinctivement réappliqué les mêmes principes :

• Un programme est une résolution de problèmes emboîtés, de façon récursive (d’où le terme de fractal). La première étape est une approche top-down (qui correspond à une architecture fonctionnelle) qui décrit l’arborescence des problèmes à résoudre.
• Puisque j’utilise un langage fonctionnel de haut niveau d’abstraction, je produis directement du code (CLAIRE). Un des principes est de produire un programme qui est à la fois exécutable et sa propre description d’architecture.
•  J’utilise une approche « orientée-objet » qui fonctionne par raffinements successifs au fur et à mesure du développement du code (la structuration des données est une colonne vertébrale du code).
• En revanche, je commence par écrire le programme de test : cela donne le premier input pour les objets et valide les interfaces de l’architecture fonctionnelle.
• L’objectif est d’obtenir le plus rapidement possible un premier programme qui tourne. Le programme simple permet de valider les entrées/sorties avant que les erreurs soient cachées dans des fonctionnalités obscures. Le programme simple est également le « workbench » pour le développement des algorithmes qui vont suivre.A tout moment, je travaille sur un code exécutable avec des objets que je peux inspecter (un des avantages d'un outil qui descend de LISP).
•  Lorsqu’on commence à remplir le fractal, c’est-à-dire écrire des algorithmes qui résolvent des sous-problèmes, on commence par ce qui est le plus difficile, mais en appliquant une approche de raffinement successif. Chaque raffinement peut être testé contre son prédécesseur.

Cette notion de « Fractal Programming » n’est pas originale. On la retrouve sous plusieurs formes chez différents blogueurs. Il s’agit en quelque sorte d’une déclinaison de l’extreme programming pour une micro-équipe, voir un développeur isolé (ce qui est mon cas depuis 10 ans). Le terme est surtout utilisé pour décrire la génération de fractals par programme. 

En revanche, pendant je faisais mon jogging matinal, je me suis aperçu que mon expérience me permettait de réinterpréter ces principes avec une perspective de « lean management ». En particulier, le même proverbial « lecteur avisé » aura reconnu les principes suivants :

•  « fail faster to succed sooner », qui explique pourquoi il faut commencer par ce qui est difficile,
•  « produce a working piece of software as soon as possible »,  un des principes clés des méthodes agiles (dont SCRUM bien sur),
•   « test as early as possible », un autre principe clé du développement agile (commencer par les tests), qui est une des bases du livre de Eric Ries.
• La création d’algorithmes et de systèmes complexes se fait sur le terrain (ici, gemba = code), pas sur le papier. Ce qui n’empêche pas d’utiliser le tableau blanc, le meilleur outil de « management visuel » du programmeur ! 

Pour conclure, je vais citer le « pretotyping manifesto », qui n’existait pas il y a 15 ans, mais dont j’aurai pu m’inspirer (le lien avec Eric Ries est évident) :

• Innovators beat ideas
• Pretotypes beat productypes
• Building beats talking
• Simple beats complex
• Now beats later
• Commitment beats committees
• Data beats opinion

On est bien dans la philosophie lean : priorité aux femmes et aux hommes, priorité à l’action, priorité à ce qu’on peut faire tout de suite, priorité à ce qui est démontrable et factuel.