Upload
others
View
14
Download
0
Embed Size (px)
Citation preview
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
Avantpropos
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.
Avantpropos 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.