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

Le Management Visuel, pour quoi faire ?

Le Management Visuel, pour quoi faire ?

Comme nous l’écrivions ici, le management visuel est une des techniques du Lean Management permettant aux équipes le pratiquant de s’auto-organiser autour du son triptyque Comprendre – Voir – Agir. Mais au-delà de cette transformation de l’équipe, ce management visuel, à quoi sert-il ?

Lire la suite « Le Management Visuel, pour quoi faire ? »

Comment une équipe a multiplié par 3 sa productivité grâce au flux

Trafic-bouchon-circulation-voitures-autoroutes

En Lean Management, le flux est tiré plutôt que poussé pour produire les pièces au rythme du client. Le flux tiré a plusieurs vertus : rendre visibles les difficultés rencontrées par l’équipe ; réduire progressivement le temps perdu dans la réalisation des pièces ; tendre progressivement vers le flux pièce à pièce pour fluidifier la production mais surtout pour apprendre très rapidement en cas de problème.

L’article suivant présente comment une équipe a multiplié par 3 (trois) sa productivité essentiellement grâce à la visualisation de son flux.

Lire la suite « Comment une équipe a multiplié par 3 sa productivité grâce au flux »