J’ai évoqué l’article sur Kanban contre le flux continu de Jim Coplien dans le dernier Agile Digest, un peu rapidement. Je souhaite réagir à cet article dans ce post.

Dans cet article, les phrases ayant ce même format (décalage à gauche avec une marge bleue), sont des citations de l’article.

Le flux continu, une alternative à Kanban

Aux origines de Scrum et Kanban

Au début de l’article sur le flux continu, Jim Coplien, l’auteur, parle des origines de Scrum et de Kanban, en évoquant surtout le Lean Manufacturing en fait. Il rappelle que la cible du Kanban (non IT) n’est pas de mettre en place du flux tiré (i.e. avec des limites kanban pour gérer du stock intermédiaire) mais de mettre en place un flux idéal : le flux continu pièce à pièce (le One Piece flow).

Il est intéressant de rappeler que le Kanban est initialement un outil du Lean Manufacturing. Mais ici, on parle de Kanban pour l’IT : Une méthode utilisée dans le développement logiciel, pour savoir piloter et optimiser un flux de travail. Le Kanban pour l’IT s’inspire seulement des concepts du Lean. En tant que méthode à part entière, ce n’est ni un outil ni une sous partie du Lean. Son contexte d’application est complètement différent du manufacturier. C’est une des raisons qui explique que le Kanban est mis si longtemps à arriver dans notre profession.

Le kanban dans le Lean

Le kanban constitue un moyen de lutter contre le gaspillage lors d’un travail de fabrication répétitif

Le développement logiciel est tout sauf répétable. Le processus l’est certes, mais le travail qui parcourt le processus lui ne l’est pas, et cela fait une énorme différence. C’est un travail très hétérogène, proche de l’artisanat (#software craftmanship). Deux bonnes raisons d’oublier l’origine du Kanban Manufacturier pour se concentrer sur nos contraintes de développement. S’il en fallait une autre, le Kanban est un outil pour le processus de FABRICATION pas le processus de CONCEPTION. Je suis bien placé pour le savoir, intervenant dans des PMI où du Lean est mis en place mais où le bureau d’études reste loin de ces pratiques.

le kanban est un système organisé de stocks tampons et, selon Ohno, le stock est un gaspillage, que ce soit dans un système à flux poussé ou à flux tiré. Le kanban est donc quelque chose dont vous cherchez à vous débarrasser, dont vous n’êtes pas fier.

Tout à fait raison sur ce point. Il faut avoir ce modèle de gaspillage en tête et le partager avec l’équipe. Car, dans notre profession, il y aura beaucoup de stock. Des spécifications non codées sont du stock, du code non testé également, une fonction testée mais non déployée … Nous sommes confrontés à de l’incertitude, de la complexité, de l’hétérogénéité. Le stock est là pour nous prémunir de toutes les perturbations, tous les grains de sable dans le rouage. Et dans le développement logiciel, et bien, il y en a malheureusement souvent. Cela ne va pas dire que c’est une fatalité et qu’il faut baisser les bras. Mais compte tenu de cette réalité, avoir le flux pièce à pièce comme cible n’est pas réaliste.

Et là, ça dérape …

Autant le début de l’article est intéressant car il rappelle les origines, la cible idéale qui guide notre démarche d’amélioration, cela fait toujours du bien. Autant la seconde partie de l’article est un florilège.

Le monde du logiciel a détourné l’usage de kanban

Et oui !! Bien sûr ! Heureusement… S’est inspiré serait plus juste que détourné, mais passons.

Nous voyons des équipes adopter cette forme de kanban en tant qu’outil ou méthode à part entière plutôt que comme une vision du monde

Ah oui, désolé, personnellement je n’ai pas élevé le Kanban au rang d’une religion, d’un art de vivre ou d’une vision du monde.

Kanban, engagement et travail collaboratif

Mais revenons à nos moutons :

Le kanban (la méthode) décourage le travail d’équipe et augmente le risque de ne pas terminer la quantité de travail convenue à l’avance au sein d’une boîte de temps semblable au Sprint

Pour la collaboration au sien de l’équipe, mon expérience va dans le sens contraire. Kanban encourage au contraire le travail collaboratif au sein d’une équipe et surtout entre équipes. Au sein d’une équipe, ce sont le daily meeting et le management visuel qui y contribuent entre autre; au même titre que les méthodes qui utilisent ces outils et pratiques comme Scrum ou le Lean. Cela peut dépendre de la culture de l’entreprise. Dans pas mal d’entreprises, je constate  que les gens travaillent individuellement, même lorsqu’ils font partie d’une même équipe, quelques soient les méthodes. Par exemple, dans une équipe Scrum, les équipiers travaillent souvent chacun sur leur propre user story. Ce qui est clairement un anti pattern.

Comment Kanban favorise le travail collaboratif au sein d’une équipe ?

Simplement en limitant le travail en cours. Si une équipe de 5 développeurs limitent le nombre de stories en cours à 3, ils seront amenés à travailler ensemble. Maintenant s’ils fixent la limite à 5, chacun va travailler dans son coin. Tout est là pour collaborer mais ce n’est qu’un outil. La question est comment utilisez-vous cet outil ?

L’engagement avec Kanban

Pour ce qui est de l’engagement, il est vrai que Kanban ne favorise pas d’engagement fonctionnel sur un Sprint. Tout simplement parce que la nature d’un travail au fil de l’eau ne permet pas ce type d’engagement. Attention, cela ne veut pas dire qu’il n’y a pas d’engagement en Kanban. C’est un engagement de type niveau de service qui est recherché, généralement basé sur le délai et le débit. On ne s’engage donc pas sur la liste des user stories à livrer au prochain Sprint, mais sur le fait qu’une story soit finie en 3 semaines, et qu’il en sort 5 par semaine par exemple. Un product Owner ayant cette information peut faire du pilotage fonctionnel.

Avec Kanban on peut faire n’importe quoi

cela permet au Product Owner de venir voir l’équipe en plein milieu d’un Sprint et d’arrêter ce qu’elle est train de faire tout en introduisant un nouvel élément dans le Backlog du Produit

Le flux pièce à pièce

Kanban, le mauvaise élève

Cette mauvaise compréhension des fondamentaux de Toyota est profonde

Le point n’est pas là ! La méthode Toyota n’est pas transposable à l’identique partout. Kanban IT n’est pas une implémentation du Lean. Par contre, son interprétation de Kanban pour l’IT est profonde.

Le kanban est un bouche-trou en l’absence de flux pièce à pièce

Pour information, j’ai subi du flux tendu avec une équipe de plus de vingt personnes pendant deux semaines sur un projet informatique. Et bien cela mais une pression beaucoup trop forte sur tout le monde. Ce n’est pas tenable. Je ne pense sincèrement pas que le flux pièce à pièce soit une cible réaliste dans notre contexte. Par contre, elle peut être une cible idéale pour nous rappeler que c’est une démarche d’amélioration continue et qu’il faut chercher à diminuer les limites Kanban.

Scrum, premier de la classe

Les fondamentaux de Scrum favorisent le flux continu pièce à pièce.

Alors là, je rigole doucement. Et qu’est-ce qu’une story prête en attente de rentrer dans un sprint ? Un stock, oui merci. Et le Sprint Backlog ? Toujours du stock. Une story finie de développer en attente de la démo ? Un incrément du produit en attente de la prochaine release ? Du stock, du stock toujours, merci élève ducobu. Dire qu’avec du devops, on peut faire du déploiement continu et que là on se rapproche plus du one piece flow, ok. Mais raconter que Scrum s’en rapproche plus que Kanban, il faut oser. C’est une vision soit très locale du processus soit très théorique soit très spécifique qui, j’imagine, permet à l’auteur de dire cela. Mais en dé zoomant de la demande utilisateur à la mise en production de la solution, je propose que l’on en reparle de flux continu avec Scrum, mais sérieusement cette fois. Bien sûr, on trouve d’excellentes implémentations de Scrum très proches et des implémentations de Kanban très médiocres, loin de tous ces principes. L’inverse est vrai aussi.

Une question de granularité

Si on cherche à mettre en place du flux pièce à pièce, cela pose la question compliquée de la granularité de la pièce. L’auteur cite Scrum comme une bonne implémentation en évoquant le flux des stories. A cette granularité, il peut être difficile d’avoir un bon flux tout au long de la chaîne. Les stories peuvent s’arrêter en attendant d’autres stories complémentaires pour faire des tests métiers par exemple, ou des tests d’intégration. On pourrait envisager du one piece flow plus facilement à la granularité de la feature. Cela fait plus de sens pour l’utilisateur et on n’est pas arrêté à certaines étapes du processus comme on peut l’être avec les stories. Le problème de se focaliser à la granularité de la feature est de perdre l’avantage de l’agilité. L’agilité va aller se chercher plus au niveau des stories. Il est pertinent de ne pas implémenter toutes les stories d’une même feature tout de suite, en attendant un feed back des démos par exemple.

nous soulignons que toute l’équipe doit travailler sur un seul élément du Backlog Produit à la fois

Oui bien sûr, et essayez cela avec une équipe de plus de 3 personnes… systématiquement ! Il faut être réaliste aussi. A moins de travailler sur une feature, on revient à la question de la granularité. Essayons maintenant avec le message suivant :

nous soulignons que toute l’équipe doit travailler sur un minimum d’éléments du Backlog Produit à la fois, et qu’elle cherchera à diminuer ce minimum.

C’est plus dans l’esprit kanban déjà. Mettre en place le One piece flow, que ce soit via Scrum ou Kanban, peut, à mon sens, mettre les équipes sous pression négative dans un contexte avec perturbations et incertitudes. Personnellement, je ne croise que ce type de contextes. Le stock, avec les limites Kanban, permet d’amortir ces perturbations.

Le kanban, c’est pour les équipes de pompiers

Le kanban : adapté pour les équipes qui voient leur travail comme le fait d’éteindre les incendies

Non, même pas. Ceux là travaillent toujours dans l’urgence et n’aiment pas réguler leur travail, ils ne suivent pas les limites. Par contre, cela va être adapté à des équipes qui doivent gérer de vrais incendies, de prod par exemple. Mais Kanban marche bien dans bien d’autres contextes également. Et par miracle, les équipes qui font du Scrum n’ont jamais d’incendies à éteindre… Pensez aux équipes ayant un logiciel en production par exemple. La vraie vie va vite compliquer leur flux parfait. Bien que ce ne soit pas l’exemple décrit dans l’article, imaginez une équipe Scrum ayant fait une bonne première version qui va en production. Tout le monde est content au point de souhaiter garder les bénéfices de Scrum (tiens ça ressemble au début de l’histoire que j’ai raconté dans mon livre).

Il est dit qu’il ne faut pas perturber une équipe Scrum au sein d’un sprint. Alors on met en place une équipe « Kanban » en face de la production, pour le support, le petit correctif; et une équipe Scrum protégée pour l’évolutif. Dans ce contexte, facile de dire que Scrum permet le one piece flow et que le kanban est fait pour les équipes gérant les incendies, si on ne l’utilise que pour cela. Ça marche, c’est sûr. Mais est-ce l’organisation optimale ? L’équipe Scrum n’est alors pas au contact direct des utilisateurs. Elle entend moins bien la voix du client que l’équipe Kanban. C’est malheureux, car c’est cette équipe qui construit la solution de demain. Elle est en train d’alimenter les incendies que l’équipe Kanban devra éteindre plus tard. La solution n’est pas dans aucun dogmatisme méthodologique. Elle passe par un mixte des deux approches Scrum et Kanban. Il est possible de faire cohabiter les deux approches et avoir une seule équipe sachant gérer à la fois le correctif, le support et l’évolutif.

Scrum, la seule et unique méthode universelle

Une bonne équipe Scrum bénéficie automatiquement des apports de kanban lors de la pratique d’un flux continu pièce à pièce.

C’est vrai ! Mais pour celles où il est difficile de mettre en place Scrum by the book ? Et pour les autres contextes qui ne peuvent pas du tout mettre Scrum en place ? Elles n’ont pas droit à autres choses pour s’améliorer ? Scrum n’est pas une réponse universelle. Je pense aux organisations où l’on ne peut pas avoir d’équipes pluridisciplinaires, où l’on ne peut pas avoir d’équipe dédiée au projet, où la notion de projet n’existe pas au profit d’un flux de petites demandes.

notre propre expérience suggère qu’il est probable d’échouer sans un cadre comme Scrum

C’est vrai que rien ne fonctionnait avant l’arrivée de Scrum. Un peu de recul, voyons. Dans ma trousse à outils d’agiliste, j’ai de l’XP, du Scrum, du Kanban, du Lean, du Lean startup, parce qu’il n’y a pas une réponse universelle.  Il faut choisir le bon outil par rapport au contexte, sans chercher à imposer un outil pour tous les contextes. Cherchons plutôt à étoffer notre trousse à outils. Dogmatisme encore et toujours, surtout provenant de ceux qui n’ont qu’un seul outil à leur disposition. Fuyez les, ces gens là.

Kanban contre le flux continu

D’un côté la mauvaise interprétation du Kanban IT par le prisme d’une vision très Lean des choses est un argument que je rencontre. Dans mon livre, j’ai d’ailleurs enlevé la plus part des références Lean intentionnellement pour ne pas brouiller le message. Le choix du terme Kanban y est pour beaucoup dans cette confusion, je le regrette. D’un autre côté, une mauvaise interprétation du Kanban par le prisme d’une vision dogmatique de Scrum est aussi quelque chose que j’ai rencontré fréquemment, moins maintenant heureusement. Ce qui est étonnant dans cet article, c’est d’entendre les deux en même temps de la part de la même personne. Mon point de vue, est que le kanban dans l’IT est le chaînon entre l’agilité et le Lean, sans dire que le Lean est la cible finale. Et que c’est le contexte ET la maturité des organisations qui font que l’on va se positionner sur l’une ou l’autre des approches.

Scrum c’est mieux, c’est pourquoi il faut venir se faire certifier chez nous

Un flux continu pièce à pièce fait partie intégrante des techniques que nous enseignons aux participants de la formation certifiante ScrumMaster

Ah nous y voilà ! Je comprends mieux d’où vient le problème … Kanban est une menace pour le bon business de la certification Scrum. Taper sur Kanban IT avec le sabre laser du Lean Manufacturing pour mieux vendre des certifications Scrum, certains sont prêts à tout pour remplir leur salle de cours !

Merci pour ce moment

Certains passages de cet article sont très critiquables et dénotent une mauvaise interprétation de la méthode Kanban (en tout cas, ce n’est pas la mienne) ou une mauvaise mise en place (i.e. avec de mauvaises intentions managériales) de Kanban. Et malheureusement cela est possible, tout comme ça l’est avec Scrum ou avec toute autre méthode. Et je ne parle même pas d’une mauvaise utilisation du Lean… Personnellement, je trouve navrant de trouver ce genre d’article à charge envers l’une ou l’autre des méthodes. Ce n’est pas constructif. Réagir à toutes les phrases de cet article serait trop long mais le cœur y est sincèrement.