KANBAN KANBAN POUR L’POUR L’ITIT

Une nouvelle méthode pour améliorer les processus

de développement

Laurent MorisseauCoach/formateur Scrum et Kanban,

fondateur de Morisseau Consulting

Préface de David J. Anderson

Morisseau_I-II.indd IMorisseau_I-II.indd I 30/05/12 09:2030/05/12 09:20

© Dunod, Paris, 2012ISBN 978-2-10-057867-2

Illustration de couverture : © Tilio & Paolo – Fotolia.com

ScrumLe guide pratique de la méthode agile la plus populaire2e éditionClaude Aubry304 pagesDunod, 2011

Morisseau_I-II.indd IIMorisseau_I-II.indd II 30/05/12 09:2030/05/12 09:20

Préface

En 2004, je cherchais une nouvelle façon d’aborder le changement dans les orga-nisations de développement de logiciel. Je voulais améliorer l’agilité, améliorer lesméthodes que nous utilisions et faire cela sans rencontrer de résistance de la part deséquipes réalisant le travail. J’étais féru des cinq étapes du ciblage de la théorie descontraintes d’Eli Goldratt. Le concept est simple : trouver le goulet d’étranglement etl’éliminer. Le goulet suivant émerge alors et peut être traité. Le processus est itératifet incrémental. Résoudre un problème à la fois.

Il était nécessaire, pour utiliser l’approche de Goldratt, de pouvoir modéliser ledéveloppement logiciel comme un problème de flux et d’être capable de visualiserl’invisible travail intellectuel du développement logiciel. J’avais montré commentfaire cela dans mon précédent livre, Agile Management for Software Engineering. J’avaisété inspiré par mon travail sur la méthode Feature Driven Development1 et par celui deDonald Reinertsen.

La théorie semblait simple : visualiser le travail invisible ; laisser les gens voir le flux(ou l’absence de celui-ci) ; et avec cette perception d’un problème autrement invisible,impalpable, les personnes impliquées parviendraient à un consensus sur ce qui doit êtrefait pour s’améliorer ; des changements seraient apportés – un goulet d’étranglementéliminé ; les choses seraient améliorées et le goulet d’étranglement suivant apparaîtraitalors aux yeux de tous ; et le processus se répéterait. Cela apporterait une approcheitérative et incrémentale à l’amélioration des processus de développement logiciel –une façon réellement agile d’améliorer l’agilité. Son appel était irrésistible.

Dans le même temps, j’étais inquiet que nos méthodes traditionnelles de gestion deprojet nous conduisent souvent à l’échec. On nous demandait de tenir des promessesd’engagements fermes sur le périmètre et sur le calendrier malgré beaucoup de risqueset d’incertitudes. L’engagement sur le périmètre, le prix et la date de livraison créait,de mon point de vue, plus de problèmes qu’il n’en résolvait. Je voulais basculer surune approche de prestation de service avec la promesse d’un niveau de service plutôtqu’une prise d’engagement ferme sur chaque livrable. Agréger les risques sur l’ensembledes demandes de service d’une période de temps améliorerait la gestion de risques.

1. Développement Dirigé par les Fonctionnalités, une des premières méthodes agilesD

unod

–To

ute

repr

oduc

tion

non

auto

risé

ees

tun

délit

.

IV Kanban pour l’IT

Cela nous permettrait d’aller vers une prestation de service prévisible sans chercher àprédire précisément la livraison d’un quelconque élément. L’utilisation d’un systèmetiré était parfaitement adaptée à cette approche. J’étais également convaincu queles gens du métier et les clients apprécieraient davantage cette approche que celle àlaquelle les autres fournisseurs les avaient habitués avec leurs contrats de prestationde service. Les services informatiques ayant des contrats de projets étaient, pour laplupart, l’exception plutôt que la règle.

En 2005, Donald Reinersten a eu, une fois de plus, une influence considérable sur ladirection de mon travail et l’émergence de ce que nous connaissons aujourd’hui commeétant la méthode Kanban. Don a observé qu’il y avait tellement de variation de causecommune dans la nature de notre travail qu’identifier de manière fiable les gouletsd’étranglement avait probablement peu d’effet de levier. J’avais eu essentiellementde la chance lors de ma première tentative d’utilisation des cinq étapes du ciblage.Je savais intuitivement que ce qu’il me disait était correct. J’en suis venu à réaliserque souvent la variabilité de cause commune est suffisamment importante pour quel’identification fiable d’un goulet d’étranglement ne soit possible que dans seulementdix pour cent des cas. Plutôt que d’utiliser le système Drum-Buffer-Rope de la théoriedes contraintes pour gérer les goulets d’étranglement, Don conseillait d’utiliserl’effet de levier plus important d’un système kanban tiré issu de Toyota pour gérerla variabilité. Le bénéfice serait d’améliorer la prédictibilité. Les systèmes kanban,comme tous les systèmes tirés, éliminent la surcharge et créent de la disponibilité. Ilscontrôlent également la variabilité et rendent le flux plus prévisible. J’ai donc décidéde faire évoluer mon approche itérative et incrémentale d’amélioration de processusen utilisant des systèmes kanban plutôt que Drum-Buffer-Rope. En décembre 2006,mon équipe, au sein d’une entreprise de Seattle, aux États-Unis, a mis en œuvre pourla première fois un système kanban tel que nous le connaissons aujourd’hui. Ce quis’est passé ensuite n’aurait pu être facilement prédit.

Kanban a dépassé mes espérances. Il a en effet permis de rendre prévisiblela prestation de service grâce à l’innovation des classes de service, non connuesdes systèmes kanban Toyota. Il a également permis des changements itératifs etincrémentaux des processus avec une résistance minimale des personnes impliquées.Mais plus que cela, Kanban se révèle être une approche évolutive conduisant à desaméliorations émergentes des processus ne pouvant être prévues à l’avance. Ainsi lesrisques sont mieux gérés et une meilleure compréhension est partagée par toutes lesparties impliquées - travailleurs, managers, clients, gens du métier, auditeurs, et autresparties prenantes.

Depuis 2007, Kanban a fait écho à tous ceux qui ont fait l’expérience de larésistance à l’adoption de nouvelles méthodes, et tous ceux qui ont fait l’expériencedémoralisante de savoir qu’un plan de projet les conduit à l’échec. Une communautégrandissante, internationale s’est formée. Le mot s’est diffusé. Kanban a été adopté pardes entreprises partout dans le monde. Beaucoup ont réalisé des bénéfices significatifs.

Cela me fait donc grand plaisir qu’un membre éminent de cette communautéinternationale tel que Laurent rédige ce livre et introduise Kanban à un publicfrancophone dans sa langue maternelle. Je connais Laurent depuis quelques années et

Préface V

j’ai le plus grand respect pour sa connaissance et sa maîtrise de Kanban. Avec cettecouverture très complète et clairement expliquée de la méthode, j’espère que vousaussi allez apprendre à mettre en œuvre Kanban et profiter des bénéfices que nousl’avons vu apporter à d’autres.

David J. ANDERSON

Seattle, États-Unis, le 26 février 2012

Fondateur de David J. Anderson & Associates,du Lean Software & Systems Consortium et du Lean-Kanban University

Auteur du livre Kanban, Successful Evolutionary Cchange for your Technology Business,Blue Hole Press, 2010

Table des matières

Préface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

Première partie – Les concepts de la méthode Kanban

Chapitre 1 – Qu’est-ce que le Kanban ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 Un peu d’histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Définir les termes du Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Définir l’objectif du Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 L’objectif d’un système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.2 La capacité d’un système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 La méthode Kanban. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1 Les fondations de la méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.2 Les cinq pratiques de la méthode Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.3 Kanban, une méthode non prescriptive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 Le développement en flux tiré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5.1 Développer en flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5.2 Système « tiré » et système « poussé » ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5.3 Développer en flux tiré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

D

unod

–To

ute

repr

oduc

tion

non

auto

risé

ees

tun

délit

.

VIII Kanban pour l’IT

Chapitre 2 – La place du Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Kanban et les autres méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 L’anticipation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.2 La maîtrise opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.3 L’amélioration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.4 La position de la méthode Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.5 Kanban et cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.6 Kanban, une nouvelle méthode agile ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 L’éligibilité de la méthode Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 La conduite de projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 La maintenance applicative de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.3 L’activité de support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapitre 3 – Une démarche pour la méthode Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Le modèle PDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Les phases d’une démarche Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 La phase « Concevoir » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 La phase « Mettre en œuvre » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.3 La phase « Étudier » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.4 La phase « Améliorer » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.5 Les cycles d’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Deuxième partie – Le noyau de la méthode Kanban

Chapitre 4 – Définir le cadre du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 MyProjectStuff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Scrum express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Définir le cadre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.1 Les éléments constitutifs du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.2 La portée du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.3 Les objectifs du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Table des matières IX

Chapitre 5 – Analyser la nature de la demande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1 Définir les éléments de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.1 Catégoriser les types d’éléments de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.2 Définir l’élément de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.3 Définir la bonne granularité de l’élément de travail . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.4 Définir la bonne taille de l’élément de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.5 Cas aux limites des tailles d’éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Définir le flux de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.1 Cartographier le processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.2 Processus générique vs processus spécifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.3 Cas des processus trop compliqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapitre 6 – Définir les règles du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1 Définir les règles aux interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 Définir les règles internes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.3 Qui applique les règles et s’assure de leur suivi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapitre 7 – Visualiser le système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.1 Le management visuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1.1 Définir le management visuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1.2 Les leçons apprises de l’agilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.2 Visualiser les éléments par des cartes kanban. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.3 Visualiser le flux de travail par un tableau kanban . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3.1 Le tableau kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3.2 Les contrôles visuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.3.3 Faire vivre le tableau kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapitre 8 – Définir les limites du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.1 Limiter le travail en cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.1.1 Le passage aux limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.1.2 La carte kanban dans l’industrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.1.3 La carte kanban dans l’IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.1.4 La mécanique des limites hautes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.1.5 La mécanique des limites basses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66D

unod

–To

ute

repr

oduc

tion

non

auto

risé

ees

tun

délit

.

X Kanban pour l’IT

8.1.6 Visualiser les limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8.1.7 Où mettre les limites hautes ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8.1.8 Définir les limites hautes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.1.9 Initialiser les limites hautes sur le travail en cours . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.1.10 Initialiser les limites hautes aux interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.1.11 Allouer de la capacité par type d’éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.2 Limiter les files d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

8.2.1 Insérer une file d’attente entre deux activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

8.2.2 Mettre une limite sur une file d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8.2.3 Définir la limite d’une file d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapitre 9 – Définir les cadences du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9.1 Définir les cadences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9.1.1 La cadence en cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9.1.2 La cadence en méthode agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9.1.3 Les cadences en Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9.1.4 L’exception aux cadences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9.2 Les cadences spécifiques du Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.2.1 La cadence d’injection des éléments dans le système . . . . . . . . . . . . . . . . . . . . . . . . 78

9.2.2 La cadence de triage des files d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

9.2.3 La cadence de livraison des éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

9.3 Le juste à temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Chapitre 10 – Mettre en œuvre le système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

10.1 La réunion quotidienne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

10.1.1 Objectif de la réunion quotidienne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

10.1.2 Le format de la réunion quotidienne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

10.2 Gérer le mouvement des éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

10.2.1 La sélection d’un élément . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

10.2.2 Guide de sélection d’un élément . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

10.3 Gérer l’affectation des éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.3.1 L’affectation des éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.3.2 L’affectation dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.3.3 Affectation dynamique et management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Table des matières XI

10.4 Gérer le blocage des éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

10.4.1 Qu’est-ce qu’un blocage ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

10.4.2 Répondre à un blocage par la gestion des demandes . . . . . . . . . . . . . . . . . . . . . . . . 88

10.4.3 Répondre à un blocage par la gestion de la capacité . . . . . . . . . . . . . . . . . . . . . . . . 89

10.4.4 Répondre à un blocage par l’ajustement des règles . . . . . . . . . . . . . . . . . . . . . . . . . 90

10.4.5 Anticiper un blocage en amont du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

10.4.6 Synthèse des tactiques pour gérer les blocages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

10.5 Gérer des anomalies internes au système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Chapitre 11 – Suivre au quotidien le système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . 99

11.1 Mettre à jour les indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

11.2 Suivi des temps sur des cartes de contrôle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

11.2.1 Temps de traversée et temps de cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

11.2.2 Les cartes de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

11.3 Suivi du débit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

11.4 Suivi du nombre d’éléments dans le système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Chapitre 12 – Étudier un système kanban globalement saturé . . . . . . . . . . . . . . . . . . 107

12.1 Étudier le système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

12.2 Un système kanban globalement saturé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

12.3 La théorie des files d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

12.4 La loi de Little . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

12.4.1 Définition de la loi de Little . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

12.4.2 La loi de Little illustrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

12.4.3 Un système disponible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

12.4.4 La loi de Little n’est qu’un modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Chapitre 13 – Étudier un système kanban localement saturé . . . . . . . . . . . . . . . . . . . . 115

13.1 La théorie des contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

13.1.1 Définir la théorie des contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

13.1.2 Les types de contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

13.2 Améliorer un système à contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

13.2.1 Les cinq étapes de la démarche TOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

13.2.2 Identifier les contraintes du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118D

unod

–To

ute

repr

oduc

tion

non

auto

risé

ees

tun

délit

.

XII Kanban pour l’IT

13.2.3 Décider comment exploiter la contrainte du système . . . . . . . . . . . . . . . . . . . . . . . 118

13.2.4 Subordonner le reste du système à la contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

13.2.5 Élever la performance de la contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

13.2.6 Recommencer à la première étape si la contrainte a changé . . . . . . . . . . . . . . . . . . 124

13.3 Les limites de l’approche TOC pour la méthode Kanban . . . . . . . . . . . . . . . . . . . 124

Chapitre 14 – Étudier un système kanban variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

14.1 Pourquoi la variabilité ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

14.2 Le système est variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

14.2.1 La maîtrise statistique des procédés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

14.2.2 Utiliser la carte de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

14.2.3 Causes communes et causes spéciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

14.2.4 Des limites pour réagir et investiguer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

14.2.5 Des limites pour être proactif sur les temps de cycle . . . . . . . . . . . . . . . . . . . . . . . . 131

14.2.6 Analyse des cartes de contrôle étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

14.2.7 Suivre les tendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

14.3 Les limites de l’approche statistique pour la méthode Kanban . . . . . . . . . . . . . . 134

Chapitre 15 – Des limites trop hautes pour la capacité . . . . . . . . . . . . . . . . . . . . . . . . . 135

15.1 La cartographie de chaîne de valeur ajoutée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

15.2 Le Muda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

15.2.1 Les 3 Mus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

15.2.2 Le Muda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

15.2.3 Diminuer les limites des files d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

15.2.4 Jusqu’où diminuer ces limites ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Synthèse des modèles des chapitres 12 à 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapitre 16 – Mesurer les impacts globaux des changements locaux . . . . . . . . . . . . . 145

16.1 Analyse du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

16.1.1 Analyse de son équilibre global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

16.1.2 Analyse des temps moyens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

16.1.3 Exemples de diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Table des matières XIII

16.2 Analyse des impacts des changements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

16.2.1 Analyse des motifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

16.2.2 Impact d’un changement sur le diagramme de flux cumulé . . . . . . . . . . . . . . . . . . 150

Chapitre 17 – Identifier les comportements émergents . . . . . . . . . . . . . . . . . . . . . . . . . 155

17.1 Les modèles de conception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

17.1.1 Les files d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

17.1.2 Les classes de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

17.1.3 Le coût du délai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

17.1.4 Description des classes de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

17.1.5 Allouer de la capacité par classe de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

17.1.6 Un tableau kanban à deux niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

17.1.7 Les couloirs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

17.2 Les modèles de collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

17.2.1 L’équipe propriétaire du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

17.2.2 L’équipe auto-organisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

17.2.3 Le fourmillement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

17.2.4 L’équipe fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

17.2.5 Fusion des petites équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Chapitre 18 – Acter les résultats du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

18.1 Définir la référence du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

18.2 La référence pour l’engagement de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

18.2.1 Définir le niveau de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

18.2.2 Niveau de service et classe de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

18.2.3 Package d’engagements de service par classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

18.3 La référence pour l’amélioration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

18.4 Standardiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Chapitre 19 – Ajuster les règles du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

19.1 Ajuster le processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

19.2 Ajuster les limites kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

19.2.1 Pourquoi les ajuster ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

19.2.2 Comment gérer la diminution des limites ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182D

unod

–To

ute

repr

oduc

tion

non

auto

risé

ees

tun

délit

.

XIV Kanban pour l’IT

19.3 Ajuster les règles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

19.3.1 L’approche TOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

19.3.2 Le filtre de décision des ajustements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

19.4 Ajuster le management visuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

19.5 Quand faire ces ajustements ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

19.6 Méthode Kanban et gouvernance IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Chapitre 20 – Bilan de la démarche Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

20.1 Les points clés de la démarche Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

20.1.1 La phase de conception du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

20.1.2 La phase de mise en œuvre du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

20.1.3 La phase d’étude du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

20.1.4 La phase d’amélioration du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

20.1.5 Bilan de la démarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

20.2 Enchaîner les cycles PDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

20.3 Affiner la démarche avec le modèle Cynefin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

20.3.1 La définition du modèle Cynefin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

20.3.2 La méthode Kanban dans le domaine simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

20.3.3 La méthode Kanban dans le domaine compliqué . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

20.3.4 La méthode Kanban dans le domaine complexe . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

20.3.5 La méthode Kanban dans le domaine chaotique . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Troisième partie – Étendre le noyau Kanban

Chapitre 21 – Étendre le Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

21.1 Étendre le management visuel du Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

21.1.1 Objectifs du management visuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

21.1.2 L’obeya Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

21.1.3 Concevoir l’obeya Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

21.1.4 Le flux d’apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

21.1.5 Construire le management visuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

21.2 Étendre le rôle de coach kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

21.3 Étendre la portée du système kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

21.3.1 Du temps de cycle au temps de traversée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Table des matières XV

21.3.2 Un réseau de systèmes kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Chapitre 22 – Pour une meilleure organisation du travail . . . . . . . . . . . . . . . . . . . . . . 207

22.1 Définition et caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

22.1.1 Définition d’un système complexe adaptatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

22.1.2 Caractéristiques d’un CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

22.2 CAS et Kanban. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

22.3 Kanban et leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

22.3.1 Le système kanban a-t-il un impact sur les styles de management ? . . . . . . . . . . . 209

22.3.2 Certaines habitudes managériales ont-elles un impact sur une démarche Kanban ? 211

22.3.3 Quel leadership pour prolonger l’expérience Kanban ? . . . . . . . . . . . . . . . . . . . . . . 213

Thésaurus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Références bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Webographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Avant­propos

Je travaille dans l’IT depuis plus de quinze ans. Mon activité de coach agile m’a permisde travailler en 2008 sur des projets dont les contextes ne se prêtaient guère à l’agilité.Les obstacles rencontrés alors m’ont amené à chercher une autre manière de répondreau besoin d’agilité dans le développement logiciel.

À cette époque, des blogs et des essais traitaient de développement en flux etproposaient une approche pour visualiser le travail et les tâches à réaliser tout enlimitant le travail en cours.

Passé le stade de l’expérimentation de cette approche, j’ai eu l’opportunitéd’intervenir sur des projets majeurs et de mettre en place cette méthode qui seformalisait en empruntant le nom de Kanban, mot japonais utilisé pour décrire unsystème de production industriel. Si le concept était nouveau dans l’IT, il était utilisédepuis des décennies dans l’industrie.

Kanban pour l’IT est une méthode permettant aux équipes d’améliorer leurprocessus de réalisation. Elle conduit à plus d’agilité et permet un travail plusprédictible.

Les retours d’expérience de la communauté Kanban ont montré que la méthodepeut être utilisée avec tous les cycles de développement logiciel, du cycle en V àScrum. Elle complète ces approches plutôt qu’elle ne les remplace.

Avec ce livre, je souhaite vous faire partager ma compréhension, mon expérienceet mes leçons apprises sur le Kanban.

Il décrit les concepts de la méthode, la démarche pour l’implémenter et détailledes pratiques du Kanban. Il ne remplace pas une application concrète dans votreenvironnement avec vos contraintes.

Les objectifs de ce livre

Ce livre est un guide pour tout agent du changement qui entame et mène unedémarche Kanban dans le contexte de l’IT. Cet ouvrage va lui permettre :

• de comprendre ce qu’est le Kanban et de s’assurer ainsi que cette méthodeconvienne à son contexte et à son organisation ;

Dun

od–

Tout

ere

prod

ucti

onno

nau

tori

sée

est

undé

lit.

XVIII Kanban pour l’IT

• de pouvoir démarrer concrètement une telle démarche ;• de savoir comment la mettre en place dans le temps ;• d’identifier la cible de l’amélioration continue dans son cas particulier.

À qui s’adresse ce livre ?

Ce livre s’adresse à tous ceux qui s’intéressent au Kanban, qu’ils soient chef ou directeurde projet, ScrumMaster, coach agile, manager, responsable méthode, DSI, développeuréclairé... Bref à tous ceux qui sont avant tout des agents du changement.

Les novices y découvriront les concepts, des applications concrètes et unedémarche en quatre étapes.

Ceux qui ont une expérience Kanban y trouveront des pratiques avancées et desconseils utiles pour aller plus loin dans leur application quotidienne.

Comment est structuré ce livre ?

Figure 1 — Structure du livre.

Le livre comporte trois parties. La première partie propose un tour d’horizon duKanban, du contexte aux définitions, sa position par rapport aux autres méthodes dedéveloppement logiciel, ainsi que la démarche de mise en œuvre.

La deuxième partie décrit le noyau de la méthode Kanban. Son plan va suivre ladémarche d’implémentation, qui va de la conception d’un système à son évolution.Sa lecture est de préférence linéaire pour suivre la logique d’écriture.

Avant­propos XIX

La conception d’un système kanban, la définition des limites kanban sur le travailen cours et la représentation visuelle des tableaux sont détaillées dans les chapitres 4à 9. Ces chapitres doivent être lus avant d’entamer une démarche Kanban.

Les chapitres 10 et 11 ont pour objectif de permettre la mise en œuvre d’unsystème kanban et proposent des réponses aux obstacles ou difficultés que l’équipeva rencontrer au quotidien. Ces chapitres peuvent être lus au démarrage du premiersystème kanban.

Les chapitres 12 à 16 donnent des pistes pour étudier un système kanban et mieuxle comprendre. Pistes qui permettent d’aborder la dernière partie d’amélioration etd’évolution du système kanban, des chapitres 17 à 19. Ces chapitres peuvent êtrelus après quelques semaines d’expérimentation et nécessitent un bagage culturelméthodologique. La synthèse qui constitue le chapitre 20 clôture cette deuxièmepartie.

La troisième partie propose d’étendre le noyau de la méthode Kanban. Le cha-pitre 21 permet d’identifier des pistes pour étendre la portée du Kanban, d’abord sonmanagement visuel, puis le rôle de coach et enfin les réseaux de systèmes kanban.

Les systèmes complexes adaptatifs abordés au chapitre 22 posent le cadre évolutif àl’approche Kanban et abordent le style de management et le leadership qui le soutient.

Cette dernière partie plus avancée est à destination de tous ceux qui veulent allerplus loin dans les pratiques.

Le livre est écrit pour accompagner :

• la progression des concepteurs du système ;• la pratique des membres de l’équipe qui l’utilisent ;• l’étude du système à destination de ce public ;• la réflexion des coachs et des managers qui accompagnent la démarche.

La difficulté de parler du Kanban tient au fait qu’il s’agit d’une approche d’amé-lioration continue des processus qui peut être utilisée dans des contextes très variésd’entreprises IT. Le discours est de fait généraliste. Le parti pris de ce livre est d’illustrerles propos principalement au travers la transition de Scrum vers Kanban.

Roman d’entreprise

Pour agrémenter la lecture du livre, imager les propos théoriques et les concepts, jevous propose de suivre une organisation fictive, travaillant sur des projets et avecdes personnages imaginaires. Ce roman ne fait référence à aucun retour d’expérienceprécis. Vous suivrez la mise en place de l’approche Kanban dans cette organisation.

Les dysfonctionnements des équipes, qui y sont décrits, ne sont pas là pour montrerles limites de telle ou telle méthode de gestion de projet mais pour illustrer le proposdu livre. Les problématiques et les solutions en sont simplifiées.

Les encadrés « Débriefing » expliquent les points importants et les choix deséquipes de cette organisation.

Dun

od–

Tout

ere

prod

ucti

onno

nau

tori

sée

est

undé

lit.

XX Kanban pour l’IT

Mon expérience

Au même titre que le roman, mes retours d’expérience sont proposés sous les encadrés« Mon expérience ». Ils rendent compte des difficultés ou des solutions issues du terrainopérationnel que j’ai pu rencontrer.

Compléments en ligneSur le site web associé à ce livre, vous trouverez les dernières informations relativesau livre, des articles complémentaires, des précisions, des mises à jour, ainsi que lesformations et conférences de l’auteur à l’adresse www.morisseauconsulting.com.

Remerciements

Un grand merci à tous mes relecteurs qui m’ont apporté un regard pertinent etconstructif sur le contenu de ce livre. Ils m’ont permis de l’améliorer grâce à leursquestions et à leur exigence de qualité.

Je remercie tout particulièrement Pierre FAUVEL, Claude AUBRY, Thierry MON-TULE, Philippe ENSARGUET, Guillaume LOURS, Dominique DE PREMOREL,François-Xavier MAQUAIRE, Dimitri BAELI, Pierre NEIS, Guillaume COLLIC,Joseph SOARES et Jean-Michel LEGRAND pour leur engagement dans ce projet etleurs encouragements.

Je remercie également Nicolas DE LOOF, Jacques COUVREUR, Thierry CROSet Christophe HERAL pour leur contribution.

Un grand merci à Alexis NICOLAS1 : il est l’auteur du paragraphe sur le Kanbanet le leadership du chapitre 22. Je le remercie pour sa contribution à ce livre, ainsi quepour le passage du PDCA au PDSA.

Je remercie chaleureusement David ANDERSON pour la préface de ce livre etson soutien. Merci à Yann PICARD DE MULLER pour la traduction de cette préfaceainsi que sa contribution en tant que relecteur.

Je remercie mon éditeur Jean-Luc BLANC de m’avoir fait confiance pour cepremier livre.

Un grand merci à Sylvie pour son soutien et sa patience pendant l’écriture de celivre.

1. Alexis Nicolas exerce une activité de conseil en organisation et management chez BNP Paribas.

PREMIÈRE PARTIE

Les concepts de laméthode Kanban