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 »).
(plan) (do) (followup) |
(explain)
(do) (training) |
(instrument)
(!—set up measure --) (do) (measures
analysis) |
(set up success criteria) (do) (check) |
(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 :
- 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.
- 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 ».
- 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.