Il est des livres pour lesquels il nous arrive de nous demander pourquoi nous ne les avons pas lus plus tôt ! Le virage Lean de Art Byrne (Pearson, 2014 pour la version française) est l’un d’eux.
Lire la suite « Pourquoi faut-il lire «Le virage Lean» de Art Byrne ? »
J’accompagne aussi bien des équipes de développement – pratiquant ou non des techniques agiles – que des équipes dites de support (N1 à N3). Plusieurs fois, j’ai entendu au sein de celles-ci – y compris dans celles qui géraient à la fois du dev et des tickets d’incidents – des personnes exprimer leur refus de faire du support.
Les messages étaient parfois forts :
Essayons de comprendre pourquoi.
Le Management Visuel, en Lean Management et en agile, est un élément structurant des équipes qu’il convient de ne pas sous-estimer. C’est un lieu de cohésion, de partage, de compréhension, d’auto-organisation, de prise de challenge au quotidien.
Le premier mot qui vient à l’esprit quand on se demande à quoi sert le Management Visuel est «voir» ; ce qui est assez logique, vous en conviendrez. Pour autant, à quoi cela peut-il servir de voir sans savoir ce que l’on souhaite voir ?
Lire la suite « Lean et agile : un Management Visuel adapté et adaptable »
Il n’est pas rare, pour ne pas dire qu’il est fréquent, d’entendre ou de lire que le Lean Management c’est pour réduire les coûts. À force de considérer, par mauvaise compréhension, par simplicité ou par intention explicite de convaincre, que le Lean Management se borne à la réduction des gaspillages, nombre de personnes et d’entreprises se fourvoient dans sa mise en oeuvre. Ces démarches de réduction des coûts – qui, in fine, ne font qu’utiliser certains outils du Toyota Production System – ont une durée de vie limitée avec des conséquences souvent néfastes sur les collaborateurs et les entreprises elles-mêmes.
Non, le Lean Management, ce n’est pas pour réduire les coûts, mais pour résoudre les problèmes des clients (leurs attentes) tout en utilisant le système de production (TPS) et le système de management (Toyota Way) de Toyota pour développer les compétences techniques et de leadership des personnes.
Je lisais récemment le dernier livre de Stanislas Dehaene Apprendre ! sur les neurosciences, l’apprentissage du cerveau et l’IA. Ce livre est très intéressant à bien des égards, mais certains éléments tels que la curiosité, la motivation et l’apprentissage font écho à mon quotidien de coach en Lean Management.
Quelques éléments de réflexion.
Lire la suite « La résolution de problème, une histoire de curiosité ? »
En Lean Management nous aimons bien utiliser l’image du camion pour représenter les produits ou service délivrés par l’équipe chaque jour, que ce soit un dossier, une demande de service, une User Story… Le but est de remplir le camion pour le faire partir quotidiennement. Il matérialise la commande des clients, le rythme, la cadence, le takt time de la production.
L’équipe support N2 Commerce de la direction informatique (Digital and Data Factory) de Leroy Merlin qui a lancé une démarche Lean est passée d’un camion partant chaque jour quasi vide à un train routier australien (pour faire la comparaison) dix mois après la fin du coaching ! Entendons-nous bien «quasi vide» ne veut pas dire que l’équipe se tournait les pouces ; bien au contraire, elle essayait de s’en sortir dans ce contexte difficile ; elle n’avait pas les bons outils pour le faire.
Mais qu’a-t-elle de spécial, cette équipe ? Est-elle vraiment différente des autres équipes support pour réaliser de telles performances (détails dans l’article) ? Quelques éléments de réponse.
Lire la suite « Passer d’un camion quotidien presque vide au train routier avec le Lean »
Paul, tout jeune embauché et débutant sa vie active, se trouve assigné à une migration technologique pour plusieurs dizaines d’agence. Ses tâches consistent au référencement / configuration des matériels informatiques et, bien évidemment, il n’a pas le droit à l’erreur, car celle-ci pourrait avoir des conséquences non négligeables sur le fonctionnement de l’entreprise. Autant dire que Paul se retrouve avec de fortes responsabilités pour ses débuts.
Certes Paul a été briefé et bénéficie de l’aide de ses collègues de travail, mais il n’est pas confiant pour autant quand il doit valider une opération.
Comment le standard Lean pourrait aider Paul à trouver de la sérénité dans son travail ?
Lire la suite « Standard de travail Lean, pour former et stabiliser avant d’améliorer »
Nombre d’équipes pratiquant l’agilité utilisent la Definition of Done (souvent nommée DoD) qui permet de déterminer, sur la base de critères objectifs et partagés, si la User Story est bien terminée. Ces critères servent également de «contrat» entre l’équipe et le client.
Cette DoD se traduit régulièrement par une liste de points à contrôler et est, la plupart du temps, affichée sur un des murs du bureau de l’équipe. Lors de mes accompagnements, j’ai même rencontré une équipe qui utilisait une feuille Excel remplie par chaque développeur pour toute US réalisée… ce qui me faisait penser à la traçabilité du processus Verification (VER) du CMMI-DEV, mais c’est un autre sujet.
Mais, me direz-vous, que vient faire le Kanban Lean dans cette histoire de Definition of Done ?
Lire la suite « Kanban IT, un serial killer de la Definition of Done ? »
Dans l’IT, mais également dans d’autres activités, une multitude de documents est nommée standard : des modèles (template) de document, des procédures diverses et variées, des règles de développement, des processus d’entreprise (gestion des incidents, gestion des demandes)… Pour nombre d’entreprises, un standard est un ensemble de règles édictées par un groupe de personnes autorisées par la direction. Souvent, ces règles sont issues de «bonnes pratiques» vues dans quelques équipes et que les directions cherchent à répliquer partout. Ces standards – qui n’ont rien en commun avec celui du Lean – sont vus par les directions comme la Bible, les Tables de la Loi que chaque collaborateur doit connaître et appliquer le petit doigt sur la couture du pantalon.
Tout écart à ces standards doit être sanctionné et les coupables sont a minima rappelés à l’ordre, quand ce n’est pas un message diffusé à tous annonçant que c’est une erreur humaine (sic !) au sein de l’équipe X, ce qui ne fait qu’accentuer la stigmatisation et la recherche d’un coupable.
Lire la suite « Le standard de travail Lean, point d’entrée du Kaizen »
Lors de la rétrospective d’une équipe pratiquant l’agilité avec un tableau Kanban au sens Lean (lire l’article Kanban, que la force soit avec toi !), ses membres se penchèrent sur les pièces réalisées (livrées) au regard des pièces à produire (les fiches Kanban présentes dans le backlog) dans le sprint. Première étape, regarder dans les bacs rouges les défauts de qualité et faire les Pareto si besoin. Cet exercice fait, il s’avéra qu’à cause de 2 tests déclarés KO, 2 fonctionnalités n’avaient pas pu être livrées ; ce que le management visuel avait révélé puisque celles-ci étaient dans le bac rouge.
L’équipe, désireuse de comprendre, se lança dans un PDCA. Pour 2 malheureuses fonctionnalités, me direz-vous ? Eh bien oui, pour 2 malheureuses fonctionnalités. C’est un des principes du Lean Management – qui s’est probablement perdu quelque part dans les techniques agiles – que de s’arrêter au moindre problème. Dans le monde idéal Lean, l’équipe aurait dû s’arrêter lors de la survenance dudit problème pour en résoudre la cause ; ce que Toyota pratique depuis des décennies. Poursuivons…
Better, faster, together 