Le livre de David Anderson, “Kanban,”, captive dès la première page. Avec des illustrations, des graphiques et des conclusions, la biographie concise d’Anderson dévoile la méthodologie Kanban pour les amateurs de gestion de projet saine. La gestion de projet devient fascinante lorsqu’elle est racontée par le développeur de la méthode dans une perspective de première personne.
À propos de l’auteur
D’après le blog officiel de son entreprise, David J Anderson est mentionné comme le président de Lean Kanban Inc. Il est formateur et consultant en management depuis les années 2000 et conférencier et animateur depuis 2005. Anderson a occupé un poste de direction pour la première fois en 1991, lui conférant une vaste expérience pour comparer honnêtement Kanban avec Waterfall, Agile, Scrum et d’autres méthodologies de gestion de projet.
Il a créé Kanban pour élever le niveau de travail intellectuel et créatif. Les objectifs d’Anderson comprenaient la livraison à temps, l’alignement du travail sur des objectifs fixés, et la gestion efficace des entreprises modernes dans leur ensemble. En utilisant des exemples concrets de Microsoft, Motorola et Corbis, il a expliqué et démontré les principes, méthodes et instructions pour mettre en œuvre Kanban dans les entreprises.
Contenu et essence du livre
“Kanban : Le chemin alternatif vers Agile” est écrit par la personne qui a inventé Kanban. Le livre est à la fois intéressant et informatif, révélant la fine ligne entre la philosophie Kaizen (amélioration continue), la méthodologie Lean (production allégée) et Kanban (une méthode pour conserver les ressources humaines et matérielles).
Kaizen : Une philosophie et une éthique des relations entre les travailleurs d’usine et l’administration.
Production Lean : Un système de gestion de projet créé chez Toyota pour éliminer tous les gaspillages de temps et de ressources dans les processus de l’entreprise.
Kanban : Une méthode de gestion de projet qui limite le nombre de tâches simultanées. S’il y a un nombre limité de personnes, d’outils ou de temps, Kanban aide à répartir les tâches et les projets.
Énormément influencé par la Théorie des Contraintes, le livre d’Anderson couvre en profondeur les limites de WIP, les goulets d’étranglement et la capacité à déterminer honnêtement la charge de travail maximale par unité de temps tout en maintenant une qualité optimale.
La Théorie des Contraintes, développée par le Dr Eliyahu Goldratt, est une méthodologie de gestion pour les entreprises de fabrication. L’approche systémique de Goldratt pour identifier les contraintes dans les entreprises aide à rationaliser tout. Selon l’expérience de Goldratt, la politique de l’entreprise devient souvent la contrainte principale.
Limite de WIP (Travail en Cours) : Le nombre de tâches qui peuvent être ouvertes simultanément.
Goulet d’étranglement : Un point dans le flux de travail où il y a une contrainte sérieuse sur les ressources ou les capacités. Sur les diagrammes, cela ressemble au cou étroit d’une bouteille, avec des lignes s’élargissant avant et après une telle situation.
Stereotypes sur Kanban
Lorsque nous entendons parler de Kanban, nous imaginons souvent un tableau avec des notes autocollantes, un stéréotype perpétué par les médias. Symboliquement, il y a une liste de tâches ouvertes, en cours et terminées sur le mur. Des murs virtuels et des logiciels de gestion de projet peuvent être utilisés, où des listes de tâches, des priorités et d’autres nuances sont saisies.
Dans cette méthodologie, Kanban n’est pas seulement un tableau ou des notes autocollantes mais un processus de contrôle et de transfert des tâches sur le mur. Anderson explique qui déplace les autocollants, pourquoi et combien peuvent être conservés dans la colonne “en cours” et pourquoi limiter ce nombre est important.
Kanban n’est pas un tableau avec des notes autocollantes ; les notes autocollantes né sont que des indicateurs de charge de travail.
Anderson a développé Kanban pour éviter de commencer de nouveaux projets avant d’avoir terminé les précédents. Par exemple, si un développeur peut gérer 3 à 5 tâches à la fois, il né peut prendre une nouvelle tâche qu’après avoir terminé une.
Agile, Scrum et Kanban
Anderson pense que les méthodologies Agile et Scrum sont rigides et standardisées. À son avis, la gestion de projet devrait être individualisée pour chaque entreprise. Par conséquent, Agile et Scrum, avec leurs algorithmes d’action standardisés, sont obsolètes, tout comme la méthodologie classique en cascade. Kanban, en revanche, s’adapte aux caractéristiques uniques d’une entreprise, ce qui peut être intimidant pour les partisans de la méthodologie Agile.
Agile : Une méthodologie flexible qui a historiquement commencé le développement de logiciels au format de déploiement de mises à jour tous les quelques mois. Les itérations de quelques semaines pour chaque fonctionnalité accélèrent le développement et réduisent les risques.
Scrum : Une autre méthodologie flexible avec de courtes itérations et un contrôle significatif sur le processus de programmation. Il y a des sprints — des segments de temps avec des tâches spécifiques à accomplir. Ils sont strictement limités. Il y a des backlogs — des listes de tâches distribuées par le propriétaire du produit. Le propriétaire du produit né fait pas partie de l’équipe de développement mais définit les priorités des tâches.
Waterfall : Un modèle classique de gestion de projet avec une séquence stricte d’actions. Il est souvent expliqué par l’analogie de la construction d’un bâtiment de la fondation au toit.
Qualité littéraire
Les critiques de l’original anglais de “Kanban” de David Anderson sont similaires : tout le monde mentionne que l’auteur explique :
- Comment la méthode a été créée, pourquoi et avec qui elle a été développée.
- Qui en bénéficie et qui en a absolument besoin.
- Comment l’appliquer pour obtenir des résultats.
“Kanban” est écrit dans le style d’une bonne littérature d’affaires. Il inclut des conclusions à la fin de chaque chapitre, et tous les chapitres traitent individuellement chaque question possible qu’un lecteur pourrait avoir dans un ordre logique.
Le chapitre 20, “Gestion des problèmes et règles d’escalade,” m’a particulièrement frappé. Differentiating a bottleneck from a blocked task is obvious, but how often do we mistake one for the other and try to push through a dead end? If a task can’t be solved now, address its root cause. Here’s a quote from the book:
“Une tâche bloquée forme en effet un goulet d’étranglement qui restreint le flux. Cependant, ce n’est pas la même chose que le goulet d’étranglement décrit au chapitre 17, car ce n’est pas une contrainte de ressources et pas une ressource attendant un accès. De même, un bouchon n’est pas un goulet d’étranglement. Pour rétablir le flux de liquide de la bouteille, il suffit de retirer le bouchon.”
Verdict
À lire absolument ; cela sera bénéfique pour :
- Les entrepreneurs aux prises avec la gestion de l’augmentation des taux de production.
- Les directeurs d’entreprises informatiques insatisfaits de Scrum.
- Les cadres supérieurs et les chefs d’équipe.
- Les marketeurs obsédés par les KPI mais incertains de leur efficacité.
- Les équipes de startup ayant besoin de tout bien faire dès le départ sans “réinventer la roué”, que ce soit en code, en vie, ou dans les projets.