Présentation de Lean chez Zenika

Zenika organisait ce soir une soirée de présentation sur les concepts et la méthodologie Lean. En quelques mots, Zenika c’est 16 personnes, des consultants Java/J2EE et surtout, un nom qui cherche ses racines dans les concepts de Lean. En effet Zenika est l’anagramme de Kaizen. « Kai » signifie « changement » et « Zen » signifie « bon ». J’ai croisé quelques têtes connues, Olivier Croisier qui a rejoint Zenika à la fin de l’année 2008, Thomas Queste, Florent Ramière, Thomas Parle, Pascal Thivent, et d’autres personnes du French Scrum User Group… Bref environ 110 personnes, ce qui représente une belle assemblée pour écouter Pascal Van Cauwenberghe, consultant Agile basé à Bruxelles et fondateur des XP Days Benelux.

La méthode Lean tire ses racines du constructeur automobile Toyota. Celui-ci applique des principes depuis une dizaine d’années, ce que l’on appelle The Toyota Way. Pascal nous propose simplement de dérouler et d’expliquer les 14 principes clés de Lean…
Là je te sens sceptique lecteur. Tu te dis : super, on part pour 14 chapitres, je vais m’arrêter là.
Grave erreur.
Reste jusqu’à la fin, tu ne seras pas déçu. Sur les conseils de Thomas, j’ai bien saupoudré cet article d’exemple et de petites phrase afin de faire fonctionner tes muscles du sourire, et que le message passe, comme Pascal l’a fait ce soir.

14 points pour faire simple

Les principes de la méthode se découpent en 4 chapitres :
– les processus
– les personnes
– l’amélioration
– la philosophie

1) Les processus

Dans un premier temps, Pascal commence par expliquer que les bases de Lean sont de définir des processus exacts et justes, afin de produire le résultat attendu. Si votre développement dans votre équipe n’est pas guidé par des règles, le résultat ne peut pas être à la hauteur des espérances.

1.1 Le débit

Visualisez votre méthode de production de logiciel. Retirez les temps d’attentes et de latences et donnez un rythme, des repères de temps. L’idée est de créer un mouvement, de donner des contraintes de temps. La sortie d’une nouvelle version prend 4 heures. Je passe 1h pour créer une branche, 2h pour le packaging et les tests, 1h pour l’installation. Je gagne du temps en m’assurant que les problèmes surgissent très rapidement afin de les résoudre. J’essaye d’éviter le « Muda » ou gachis. Pour cela je réduis l’attente, le transport d’un point à un autre et les mouvements excessifs. En clair : je supprime les étapes qui dépendent lors de ma release d’une approbation d’un email. Je réduis le transport en supprimant un upload FTP et en compilant le produit sur la machine d’intégration. Je supprime les mouvements excessifs en mettant en place des scripts d’intégration afin d’éviter de devoir faire trop d’opérations pour sortir ma release…
L’objectif est de réduire le temps d’attente entre la commande du client et la livraison de sa demande. Cycle itératif court, livraison au fil de l’eau si possible plutôt que par paquet de 10… Pourquoi pas ?

1.2 Basculer vers un système où le client « tire » la production

L’idée est de produire (donc de développer) uniquement selon la demande des clients. Pascal utilise l’image d’un rayon de supermarché : tant que le client n’a pas pris d’articles sur le rayon, on ne produit plus. Dès qu’il « consomme » un article, on lance alors l’approvisionnement.
Rapporté à mon travail à la BNP, cela revient donc à dire que tant que l’utilisateur final n’a pas validé, commencé à utiliser ma superbe fonction, je ne m’embarque pas dans des développements. Cela a du sens.
On évite ainsi la surproduction, le gâchis, et surtout d’avoir des fonctions jamais utilisées dans un logiciel.
Pascal parle alors des cartes Kanban qui sont utilisés par Toyota afin de suivre la production. Voir aussi un article écrit l’an passé sur le sujet.

1.3 Lissez la charge de travail/la production dans le temps

Appelé « Heijunka » en japonais, ce concept vise à éviter l’épuisement des personnes (« Muri ») en s’assurant que la charge de travail soit constante, avec un rythme soutenu mais soutenable. Lorsque les équipes sont surchargées, elles peuvent certes répondre très ponctuellement à une demande. Si la situation perdure, on rentre alors dans un cycle d’épuisement, de démotivation et la chute est encore plus brutale.
Pascal raconte l’histoire d’un développeur qui refuse de quitter son poste. Le premier soir, il lui demande de partir, le développeur répond qu’il doit encore terminer une tâche. Le deuxième soir, même chose. Le troisième soir, le développeur est encore là. Le lendemain, le coach le rencontre en entretien, et se rend compte alors d’un problème dans le logiciel dont le développeur ne souhaitait pas parler.

Il est aussi important d’éviter le « Mura ». En Français : coup de bourre. Dans la mesure du possible, si le cycle de travail de la personne n’est pas lissé, celle-ci va alors s’épuiser très rapidement. De plus, les temps d’arrêt et de redémarrage coutent chers. Amusez vous à interrompre un développeur toutes les 30 minutes, vous verrez à la fin de la journée la tête du bonhomme.

1.4 Mettez en place une culture pour arrêter de résoudre les problèmes, car ceux-ci n’arrivent pas

Oooh que j’aime cette idée. Au lieu d’utiliser de l’énergie pour résoudre un problème, arrangez-vous pour qu’il n’arrive pas. Pascal explique qu’en 1924, un inventeur Japonais mets au point le premier métier à tisser qui s’arrête en cas de problèmes. Avant cela, il fallait employer à plein temps une personne pour surveiller le métier à tisser et dire « … jusqu’ici tout va bien » afin d’arrêter la machine en cas d’erreur…
La qualité n’est pas une option. Les tests unitaires ne sont pas un gadget, ce n’est pas négociable. Pensez votre logiciel afin qu’en cas d’erreur, celui-ci soit capable de se rendre compte que quelque chose cloche et qu’il s’arrête d’envoyer des messages JMS par exemple…
Mettez une grosse lumière rouge dans votre open-space. Lorsque l’intégration continue explose, il faut que toute l’équipe se mobilise, il faut que le leader en soit informé. Pensez à réduire le nombre de fonctions que vous livrez, afin d’en livrer moins mais de meilleures qualités. Vous gagnerez du temps, et finalement vous pourrez en livrer plus, contrairement à ce que vous pensez au départ.

1.5 Les tâches standardisées mais avec de l’humain

Toyota utilise des robots pour construire ses voitures. Les robots sont utilisés pour les tâches pénibles et dangereuses, mais pas pour tout. Un humain a un cerveau, il sait s’adapter. Il faut donc conserver le pouvoir et le donner aux employés, au développeur.
Enfin quelque soit le standard, celui-ci doit être amélioré en permanence. La personne qui fait de la production a le droit et le devoir d’améliorer le processus, chaque jour. Le gachis est de ne pas utiliser l’énergie des gens. Pour cette raison, Toyota a mis en place des boîtes à idées et récompense les ouvriers qui ont des idées, ce qui est le cas de tout le monde. Les experts sont les ouvriers, pas les managers.

1.6 Utilisez le contrôle visuel, afin que les problèmes ne soient pas cachés

Le principe ici est de mettre en place des indicateurs que toute l’équipe voit, ainsi que les managers et les clients. Concrètement, mettez au mur une feuille blanche, prenez des post-its de couleur, mettez une colonne « incidents en cours » ou « bugs urgent » et marquez les problèmes sur ces post-its. Oui vous pensez faire des loisirs créatifs, mais réfléchissez à l’utilité de ce genre d’indicateur. Un tableau se voit tout le temps. Les post-its représentent une quantité de problèmes à résoudre. Les clients voient au mur que votre équipe est surchargée. Vous pouvez aussi faire un suivi du temps de résolution. Il suffit de déplacer le post-it dans une colonne « Terminé » et d’indiquer le temps perdu sur la tâche.
Pascal va encore plus loin en montrant la photo d’un urinoir. Au dessus de celui-ci on peut lire « 11 bugs de Sev1, je sais que j’ai ton attention, alors au boulot ! ». Pas mal non ?
Les indicateurs visuels chez Toyota c’est un panneau lumineux placé sur la chaîne qui indique aussi les facteurs de productivité, les objectifs à atteindre, les problèmes en cours…

1.7 Utilisez des technologies fiables, éprouvées et testées qui aident vos clients et vos développeurs

Certainement le point qui fait le plus mal… Arrêtons 5 minutes avec nos frameworks de double-inversion de contrôle où tu configures en XML ce que tu faisais en Java… Revenons sur Terre 2 minutes, prenons des outils qui ont fait leurs preuves et arrêtons de nous faire plaisir, avec ce framework « jante alliage » qui aura disparu dans 6 mois, ou cette superbe librairie de parsing pour lire un fichier texte de 3 lignes…
Il faut stimuler la recherche selon 3 étapes, de la plus facile à mettre en place à la plus révolutionnaire :
– conserver la solution existante
– améliorer par incrément
– faire une percée radicale
Il y a souvent peu de problèmes de personnes, bien plus souvent un problème de processus.
N’hésitez pas à investir du temps pour réaliser un prototype si vous souhaitez prendre une nouvelle technologie. Rejetez aussi les technologies qui ne sont pas compatibles avec votre culture, et encouragez les développeurs à toujours regarder ce qu’il se passe sur le marché, afin d’éviter de tomber dans un cul-de-sac technique… Et surtout, pensez à vous outiller. Je vous parlerai prochainement de SpringFuse, le produit de Jaxio. Il est temps d’arrêter de jouer aux Legos et de passer à des jeux un peu plus industriel.

2) Les personnes

La force d’une entreprise c’est son patrimoine humain. Sortons un instant de Lean. Regardez les cabinets de consultants sur Paris. Ce qui fait la valeur d’une entreprise c’est ses équipes. Pas son logiciel, pas ses méthodes. Non, juste ses équipes. Le secret des cabinets de consultant (SSII) qui marchent, c’est l’investissement dans les valeurs humaines. Le ticket d’entrée est plus cher, le retour sur investissement est bien plus important.

2.1 Fait grandir des leaders

Pascal explique que l’idée est de faire grandir des leaders en prenant des personnes du vivier de l’entreprise. Rien de pire qu’un manager parachuté à la tête d’une équipe d’après son expérience. Il explique que les leaders doivent servir de modèle pour les arrivant, et qu’un bon leader doit connaître les processus de son équipe en les ayant pratiqué. J’ai eu en tête le responsable du MacDo à côté de chez moi. Le gars a commencé il y a 7 ans comme équipier. Il gère aujourd’hui une équipe de 21 personnes… Et il n’a que 26 ans…

2.2 Développe des gens exceptionnels et des équipes qui suivent la philosophie de ton entreprise

Pascal explique qu’il est plutôt souhaitable de faire en sorte que les équipiers ne soient pas trop spécialisés dans une équipe de développeur. Pour cela, il faut mettre en place une dynamique et faire en sorte que le brassage des développements soit une réalité. Je suis un peu plus sceptique sur ce point, mais je comprends l’idée.

2.3 Le respect est une valeur essentielle

Tout d’abord respectez vos clients, mais aussi vos fournisseurs. Toyota rapproche géographiquement ses fournisseurs et montre toujours un respect important. L’exemple que Pascal utilise est le suivant : un constructeur automobile va voir un fournisseur de moteur. Il demande 5% de réduction, sinon c’est la fin du contrat… Aucuns respects du client.
Toyota va voir le même fournisseur et propose de prêter 3 de ses ingénieurs afin de réduire les coûts de développement de 10%, et donc d’obtenir 5% de réduction aussi. Sauf que Toyota ne sera alors que le seul à bénéficier de cette réduction. Respect et intelligence…

3) L’amélioration

L’amélioration en permanence nous aide à résoudre les problèmes au fur et à mesure. En s’introspectant après chaque itération, une équipe de développement qui fait du Scrum s’autocritique et s’améliore. Pascal insiste sur le fait que l’introspection est peut-être le concept le plus important de Lean. Je pense à cet instant dans ma tête que chez mon client en ce moment, c’est le point que nous ne traitons pas. Il est temps de remettre en place ce processus d’urgence.

3.1 Allez voir par soi-même les sources des problèmes « Genchi Genbutsu »

Pour améliorer la production, Toyota préconise aux managers de descendre et d’aller sur la chaîne afin d’observer et de regarder en situation ce qu’il se passe. Il faut que le manager aille voir la production et qu’il identifie les problèmes. Pascal raconte l’histoire de la Poste Belge qui perdait du temps pour traiter l’envoi de colis internationaux à cause d’un mur (un vrai avec des briques) entre le quai de déchargement des camions et la pesée, obligatoire pour les envois et la facturation. En détruisant le mur, la productivité a augmenté.
Il faut que votre chef passe un peu de temps avec vous afin de comprendre ce qu’il se passe.

3.2 Prenez des décisions avec un consensus et le plus tard possible

Dans un premier temps, listez toutes les options possibles. La Toyota Prius avait ainsi 80 projets de moteur différent au départ. Dessinez un rétro-planning en partant de la date de sortie souhaitée. Revenez en arrière et représentez à chaque fois la date limite où il faudra prendre une décision (Spring ou EJB 3.1 ?). Ne prenez la décision qu’au dernier moment, pas au début.
En cas de problèmes, discutez avec toutes les personnes impliquées afin de prendre l’avis de tout le monde, et qu’une énergie commune fasse que les choses changent (« Nemawashi »).
Le consensus prend peut-être du temps mais vous donnera un résultat de meilleur qualité. Le planning poker pour estimer le temps de développement d’une tâche est un exemple de consensus.

3.3 Réflexions et améliorations

La réflexion (« Hansei ») et l’amélioration continue (« Kaizen ») sont deux facteurs clés de la méthode Lean. Préparez des processus métiers qui ne demandent pas beaucoup de travail d’inventaire. Cela forcera les équipes à s’améliorer en permanence.
Lorsqu’un process est stable mais qu’un problème survient, pensez à demander 5 fois « Pourquoi » à votre développeur.
– « Je ne peux pas corriger ce problème car je n’ai pas le temps »
– Pourquoi n’as-tu pas le temps ?
– Je suis occupé par une tâche de production que je dois faire, je dois envoyer un nouveau mot de passe à un utilisateur
– Pourquoi dois-tu envoyer un nouveau mot de passe ?
– Parce que le système ne sait pas le faire
– Pourquoi ne sait-il pas le faire ?
– Nous n’avons pas développé de fonction « me renvoyer un nouveau mot de passe » sur la page d’accueil
– Pourquoi ?
– Parce que nous avons oublié de le marquer dans le Product Backlog et que nous n’avons pas écouté le chef de projet. La prochaine fois nous le marquerons dans le product backlog et nous ferons en sorte de l’implémenter.

4) La philosophie

Pascal Van Cauwenberghe termine par le point le plus important pour lui : la philosophie à long terme.
Basez vos décisions de manager sur du long terme, même si le coût à payer à court terme est important..
Pour cela il évoque Toyota qui fait la promesse d’offrir un emploi à vie à ses salariés. En raison de la crise il se demande si cette philosophie pourra perdurer. Il explique que Toyota en accord avec ce principe, tente de former les gens en ce moment au lieu de les faire travailler sur des chaînes, afin que lorsque la crise sera passée, ils soient encore meilleurs… C’est beau…

Conclusion et réflexions

Après vous avoir présenté Lean tel que je l’ai vu ce soir, j’ai quelques réflexions.
Tout d’abord je visualise maintenant mieux comment une méthode comme Lean est compatible avec Scrum ou XP. Pour tout vous dire, je vois Lean comme des jalons et des repères pour travailler mieux. Ensuite Scrum apporte un framework qui aide à piloter le cycle de développement d’un logiciel. Enfin XP est pour moi maintenant dans les habitudes des développeurs, et je pense par contre que vouloir caler ses 13 principes reste assez difficile.
Donc on a un escalier avec 3 marches, la marche la plus haute étant XP, et la première étant Lean.
Qu’en pensez-vous ?

Merci à Zenika qui a organisé une soirée très riche. A la sortie, remise d’un résumé de Lean, apéritif, accueil sympathique.. rien à redire. Bravo à eux.
Zenika est sponsor du Paris Java User Group, ainsi que sponsor des XP Days le 25 et 26 mai 2009.

Enfin j’ai appris aussi comme Olivier un peu au dernier moment que le 3ème Java Barcamp aura lieu samedi 31 janvier toute la journée, cette fois-ci organisé par Eric Lefevre Ardant et Anthony Dahanne de Valtech. Plus d’information : http://barcamp.org/JavaCampParis3.
Le BarCamp se déroulera le samedi chez SUN au Sun Customer Briefing Center, 42 avenue de Iéna, 75016 Paris. Superbes locaux où j’ai travaillé deux mois pour une mission (soupir…).
Moi je suis déjà pris, donc ce sera sans moi.

Articles similaires:

Soirée mercredi 21 janvier chez Zenika sur Lean Soirée Wicket chez Zenika Devoxx : présentation sur les estimations du temps de dév Zenika