Quand un Kanban rencontre un ébéniste

Quand un Kanban rencontre un ébéniste

Une odeur de sciure, le bruit des machines, et des hommes qui s’agitent dans tous les sens ! Vous ne vous trompez pas, nous venons de pousser la porte d’une ébénisterie pas comme les autres… Une voix hurle dans l’atelier : « Il faut rattraper notre retard, les clients attendent ! ». C’est celle du fondateur et directeur de ces lieux. Cet homme n’est pas n’importe qui, il connaît mieux que personne cet art difficile où l’erreur n’est que gaspillage. Ayant affronté toutes les difficultés d’un jeune ébéniste qui s’installe :

Des machines obsolètes mais pas chères,

  • Des machines obsolètes mais pas chères
  • Des heures non comptées
  • Des salaires non versés,
  • Et de nombreux obstacles à traverser.

La volonté, la passion et la détermination vont faire que cette entreprise va vivre une belle aventure avec, à la clé, une réussite sans pareil.

C’est l’histoire que je vais vous raconter, celle d’un jeune ébéniste de l’école Boule de Paris qui va passer d’un garage de fortune sans chauffage à une belle et grande entreprise dont les œuvres vont s’exporter aux États-Unis pour le compte de stylistes et célébrités.

Lire la suite « Quand un Kanban rencontre un ébéniste »

Lean et agile : un Management Visuel adapté et adaptable

Lean et agile : un Management Visuel adapté et adaptable

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 »

Kanban IT, un serial killer de la Definition of Done ?

Kanban IT, un serial killer de la Definition of Done ?

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 ? »

Améliorer le Kanban ou ajuster la DoD ?

Améliorer le Kanban ou ajuster la DoD ?

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…

Lire la suite « Améliorer le Kanban ou ajuster la DoD ? »

Kanban, que la force soit avec toi !

Kanban, que la force soit avec toi !

Pour faire suite à l’article Le Management Visuel, pour quoi faire ?, je vous propose de voir plus en détails une des techniques du Management Visuel du Lean Management, le Kanban.

Le Kanban est un des éléments-clés du Just-In-time (JIT) du Toyota Production System (TPS) comme nous le rappelle l’article La magie du Kanban chez Toyota à Nagoya.

Pensé par Taiichi Ohno dès les années 1950 (lire Taiichi Ohno’s Workplace Management), le Kanban vise à atteindre l’idéal du one-piece flow (nommé également flux continu) tiré et rythmé (takt) par la demande du client.

Lire la suite « Kanban, que la force soit avec toi ! »

La magie du Kanban chez Toyota à Nagoya

toyota-lean-managementLe kanban représente l’outil central mis au service du Just in Time (JIT). A Nagoya, chez Toyota le JIT se définit par faire seulement ce qui est nécessaire, quand c’est nécessaire et dans la quantité nécessaire.

Qu’est-ce que le kanban dans le Lean ?

Le kanban désigne une carte qui contient un ensemble d’informations logistiques comme le nom du produit, son secteur de livraison, la date de livraison, le nombre de pièces par casier, le numéro de la carte etc. Dans l’usine de Nagoya, j’ai remarqué que les cartes utilisées étaient dotées d’un code barre et d’un code QRC pour être flashées électroniquement afin de faciliter la gestion des réassorts. Le kanban est un outil logistique qui contribue à maîtriser le flux des composants dans l’usine pour éviter les gaspillages de surproduction et d’attente. Lire la suite « La magie du Kanban chez Toyota à Nagoya »

Le kanban, un bitcoin explosif !

kanban-lean-operae-partners

Ce post fait suite à un autre texte “Le kanban est le bitcoin du Lean”. On y montrait pourquoi il est possible de considérer le kanban comme une monnaie virtuelle dans le monde de la production de biens ou de services, monnaie qui permet d’organiser le travail de chacun le long d’une chaine de valeur.

L’exemple utilisé était celui d’une petite chaine de développement informatique comprenant un spécifieur, un développeur et un testeur.

Ce nouveau post sort de la partie théorique du kanban et explore ce qui se passe dans la réalité, lorsqu’on essaie de le mettre en œuvre. En un mot comme en cent, ça explose !

Imaginons que le développeur n’arrive pas à terminer la commande que le testeur lui a passée :

 

kanban-lean-operae-partners-4 Lire la suite « Le kanban, un bitcoin explosif ! »