Au cours de nos conversations avec David J. Anderson, pionnier de la méthodologie Kanban, lors du Lean Kanban Conference de Chicago, nous lui avons demandé s'il existait un guide de démarrage rapide Kanban qui pourrait démystifier ce sujet. David nous a recommandé de parler au Dr Arne Roock d'IT-Agile, auteur du livret "Stop starting, Start Finishing". Dr. Roock est conférencier, président de la série "Scaling Kanban" de la conférence, et travaille également comme coach Agile en Allemagne.
InfoQ: Basé sur la littérature existante, le Kanban semble être quelque chose plutôt philosophique. Comment une équipe peut-elle commencer à évaluer si c'est le bon outil, et les prérequis pour commencer ?
Dr. Roock: Le plus important est d'être d'accord sur le fait de vouloir changer. Si nous ne voulons pas changer, alors Kanban n'est pas adapté, principalement parce que Kanban est avant tout une méthode de changement. Souvent les gens considèrent Kanban comme une méthode de gestion de projet ou de développement, mais ce n'est pas le cas; c'est une méthode de changement. Il n'y a qu'un prérequis pour le changement, c'est ce que l'expert du leadership John Kotter appelle dans son livre du même titre "A sense of urgency" (un sentiment d'urgence).
InfoQ: Disons que nous sommes d'accord sur le fait d'être prêts à changer. Nous voulons faire les choses correctement, s'il faut une révolution, nous sommes prêts à le faire, mais si nous pouvions obtenir des améliorations significatives avec un changement évolutif, ce serait préférable. Nous voulons voir des améliorations en termes de livraison, de prévisibilité et de transparence.
Dr. Roock: D'après mon expérience, avant de mettre en place Kanban, nous devons être d'accord sur les objectifs majeurs que nous voulons atteindre. Cela signifie que nous avons besoin du soutien du management.
Vous pourriez essayer une approche "discrète" localement, en le cachant au management, seulement pour une seule équipe. Il peut y avoir un certain succès avec cette approche mais vous atteindrez vos limites très rapidement. Si vous voulez vraiment que ce soit une réussite au niveau de l'entreprise, vous aurez besoin du soutien de la direction. Il est important de parler au management et de comprendre ce qu'ils essaient d'accomplir, quels sont leurs points de douleur, et quels sont les objectifs qu'ils veulent atteindre.
Dans votre exemple, ce serait "nous voulons plus de prévisibilité et une amélioration du processus livraison." Donc la première chose que je ferai serait d'exposer le flux de bout en bout. Un énorme problème dans le travail intellectuel, c'est que nous ne pouvons pas voir ou toucher ce qui est produit. Si vous alliez dans une usine, vous verriez des matières premières et des produits non finis sur le sol de l'atelier. Mais si vous regardez dans n'importe quel bureau, ils se ressemblent tous; vous avez le bureau, vous avez le clavier, le téléphone, l'ordinateur et beaucoup de papier, et c'est tout. Nous ne pouvons pas voir notre travail, et ça signifie qu'il est très difficile d'améliorer les choses.
Donc la première chose que nous faisons lorsque nous commençons à mettre en place Kanban est une visualisation de notre travail. Combien de tâches que avons-nous commencé et à quel stade sont-elles
Quelle quantité de travail avons-nous en développement, combien en avons-nous en cours d'analyse, combien sont en cours de tests et ainsi de suite.
Cela devrait être très informatif. Dans de nombreux cas, les gens ne sont pas conscient de la quantité de travail qu'ils ont en cours, (par là on entend la quantité de travail qui a été commencée mais pas terminée.)
Ensuite il faut créer une boucle de feedback. Observer notre flux et notre travail régulièrement, se mettre d'accord sur ce que nous voulons faire pour améliorer notre processus.
Maintenant que nous avons cette transparence, nous voyons que dans la colonne dédiée aux tests, les tâches s'accumulent. Donc, nous sommes plus rapides pour les développements que pour les tests et les déploiements. Réunissons-nous donc, faisons un atelier de perfectionnement pour voir ce que nous pouvons faire pour lisser notre flux.
Que pouvons-nous faire pour travailler sur ce goulot d'étranglement ? La première chose qui vient à l'esprit pourrait être d'embaucher des testeurs supplémentaires. Mais très souvent, ce n'est pas la bonne solution. Peut-être améliorer la qualité de ce qui va être testé, ou automatiser certains processus, ou encore assigner les développeurs aux tâches de test parce que très souvent, les développeurs peuvent le faire.
Donc, la transparence est la première étape. Les boucles de feedback sont très importantes. La plupart des équipes Kanban font des réunions quotidiennes (standup) devant leur tableau Kanban, là où ils peuvent voir leur travail. De plus, ils font des ateliers d'amélioration, ou comme ils sont souvent appelés "Rétrospectives" ou "réunions Kaizen".
Il faudrait ensuite avoir des métriques pour pouvoir décider si nous allons dans la bonne direction.
Si l'objectif est d'améliorer la prévisibilité et de livrer souvent et rapidement, cela pourrait être une bonne idée de mesurer le temps de cycle, c'est-à-dire le temps passé à partir du moment où vous avez commencé une tâche jusqu'à ce qu'elle soit terminée. Ensuite voyons ce qui se passe si nous passons un développeur dans l'équipe de test. Ou voyons ce qui se passe si nous découpons notre travail différemment. Ou encore si nous nous mettons d'accord sur une règle disant que nous ne voulons pas avoir plus de deux tâches en développement et trois tâches dans les tests.
Il y a une paire d'autres choses que nous pourrions essayer. Maintenant que nous avons les boucles de feedback et les métriques, nous pouvons voir si cela fonctionne bien et devrait être amplifié, ou si ça ne fonctionne pas, ce que nous voudrions réduire.
InfoQ. Vous avez parlé du tableau, ce qui semble être le point central. J'aimerai connaître le niveau de granularité qu'il devrait posséder. Dois-je aller du début à la fin, ou dois-je inclure uniquement mes étapes de développement ?
Dr. Roock: Commencez par la portion de la chaîne de valeur que vous pouvez contrôler. Si votre sponsor est le responsable du développement alors le point de départ devrait être le développement. Le tableau devrait commencer par une sorte d'explosion de l'analyse des tâches, puis le développement, suivi des tests, et enfin des interfaces avec les processus en amont, telles que la gestion des produits et en aval telles que le déploiement.
Bien entendu dans le long terme nous voulons étendre les frontières de l'équipe. Nous ne recherchons pas des optimisations locales mais bel et bien une collaboration à travers les frontières de l'équipe. Mais si nous n'avons aucun contrôle dessus cela n'a pas de sens d'avoir tout ça sur votre tableau si vos partenaires en amont et en aval ne souhaitent pas collaborer avec vous. C'est très important.
Commencez avec ce que vous pouvez contrôler. N'essayez d'évangéliser, ça ne marchera pas. Ce qui fonctionnera est d'obtenir de meilleurs résultats et de les rendre transparents, ainsi les gens deviendront curieux, et la curiosité est un outil très puissant. Les gens vont continuer à se rapprocher et vous poseront des questions, "comment livrez-vous si souvent ?" ou "pourquoi avez-vous moins de bugs ?" Ce que nous observons alors très souvent est la propagation de Kanban à toutes les équipes.
Nous avons assisté à une présentation donnée par Jimdo, une société allemande qui utilise Kanban pour leur équipe de marketing en ligne, de presse, de vidéo, et pour les équipes partenaires, et bien sûr les tableaux Kanban sont différents pour chaque équipe, mais ils appliquent les mêmes principes. Cela montre l'amélioration continue en petites étapes.
InfoQ: Comment redimensionnez-vous le tableau pour des équipes délocalisées ?
Dr. Roock: C'est une question difficile mais très pertinente car beaucoup d'équipes sont aujourd'hui délocalisées. Il y a beaucoup de bons outils Kanban sur le marché, mais il y a des aspects positifs et négatifs aux outils électroniques. Pour ma part j'essaierai de garder la composante physique aussi longtemps que possible. Même si vous avez deux endroits différents, cela peut fonctionner avec des tableaux Kanban physiques. Vous devrez synchroniser les équipes bien sûr. Vous pouvez utiliser des webcams, la messagerie instantanée, ou un système de jumelage où chaque équipe a un représentant dans l'autre équipe.
InfoQ: Qu'entendez-vous par un représentant ?
Dr. Roock: Le système de jumelage est un système où chaque équipe a un représentant en permanence dans l'autre équipe. Chaque fois que le tableau Kanban évolue, par exemple le déplacement d'une tâche de développement vers les tests, vous aviserez le représentant de mettre à jour le tableau de l'autre côté. Vous pouvez utiliser le téléphone, la visioconférence ou la messagerie instantanée. Cela peut sembler être beaucoup de travail, et ça l'est. Cependant vous devez avoir ces moyens de communication. Vous remarquerez que les représentants vont commencer à communiquer, pas seulement au sujet des tâches qui évoluent, mais également sur des choses comme "Je suis en vacances la semaine prochaine, donc s'il vous plaît veuillez rappeler aux autres membres de l'équipe de faire ceci et cela." ou "Je vois que vous êtes en train de travailler sur cette partie du code. Je sais qu'il y a des parties difficiles, alors permettez-moi de vous donner quelques conseils." Maintenant les gens communiquent au travers des frontières de l'équipe et c'est vraiment précieux.
InfoQ: Que faire s'il y a plus de deux équipes, et de grandes décalages horaires comme New York et Singapour, qui peuvent être de 12 heures ?
Dr. Roock: Pour deux régions ça peut fonctionner, mais pas trois, je ne l'ai jamais vu. L'autre problème est le décalage horaire, qui complique beaucoup les choses.
Ce que je tiens à souligner est que Kanban peut être comme une méchante belle-mère; elle vous dit ce que vous faites mal tout le temps, mais elle ne vous aide pas à vous améliorer. Dans ce cas, si vous appliquez Kanban, vous verrez que vous avez beaucoup de difficultés avec vos équipes délocalisées, qu'il faut beaucoup d'efforts pour synchroniser ces équipes. Mais c'est la réalité, indépendamment d'appliquer Kanban ou pas. Kanban rendra ces problèmes visibles. Pour plus de deux équipes, vous aurez sûrement besoin d'un outil électronique. Mais ce dont vous aurez besoin c'est de beaucoup de communication. J'ai vu cela maintes et maintes fois. Quand les personnes ne communiquent que via l'outil, vous êtes foutu ! Les gens doivent continuer à communiquer. Le face à face est bien sûr mieux que la vidéoconférence, qui est mieux que le téléphone, qui est mieux que le courrier électronique. Donc, assurez-vous que les personnes communiquent aussi souvent que possible. Cela signifie que vous devez envoyer les gens de temps en temps à l'autre endroit, même si c'est Singapour. Et vous devez avoir un très bon équipement de vidéoconférence, ainsi qu'un très bon outil de Kanban. Ce qui est important pour changer l'organisation, (et c'est ce que Kanban est conçu pour faire), c'est d'instaurer la confiance. Il est plus facile d'établir la confiance quand les personnes se connaissent. Quand les gens se voient les uns les autres, se parlent face à face, prennent une bière ensemble, en savent un peu plus sur leur vie privée, s'ils ont des enfants, ou le type de films qu'ils aiment. Ça renforce la confiance, et c'est vraiment, vraiment important.
Les standups sont un moyen de créer ce forum afin que les membres puissent se réunir et se parler régulièrement. Bien sûr s'il y a un décalage horaire c'est problématique, mais vous devrez le résoudre dans tous les cas, ça n'a rien à voir avec Kanban.
InfoQ: Y a-t-il une solution standard pour avoir des standups entre équipes délocalisées ?
Dr. Roock. Même si il y a un décalage horaire, vous avez souvent une ou deux heures en commun.
InfoQ: Eh bien, pour Singapour il est de 12 heures, et même s'ils travaillent tard, il serait difficile de le faire de façon quotidienne.
Dr. Roock: Oui, même si vous pouviez le faire vous seriez à des stades différents de votre journée, de sorte que le niveau d'énergie est différent. C'est une question difficile. Il doit y avoir une communication régulière, même si certaines personnes ont à travailler la nuit. Vous pouvez avoir une seule personne qui communique avec l'autre équipe en utilisant un mécanisme de jeton.
Nous devons abattre les frontières. Très souvent nous rencontrons le cas où vous avez une équipe aux Etats-Unis et une équipe à Singapour, l'équipe des États-Unis dit "oh ces gars de Singapour, ils ont cassé notre build", ou vice versa. Souvent, cela commence comme une blague, mais il y a une raison de fond. Envoyer des représentants à l'autre endroit pendant quelques mois, puis recevoir leurs représentants peut être une façon de faire très efficace.
InfoQ: Alors maintenant disons que nous avons l'accord du management, n'est-ce pas mieux de commencer petit pour réduire le risque ?
Dr. Roock: Oui, c'est l'idée de base avec Kanban. Vous commencez avec ce que vous avez, puis vous faites évoluer. Si vous visualisez votre travail, visualisez ce que vous avez maintenant; n'essayez pas de visualiser votre état cible.
Nous avons eu une présentation de Daniel Vacanti qui était responsable de la mise en œuvre de Kanban chez Siemens Health Care. Ils ont fait les choses différemment, ils ont eu une énorme implémentation de Kanban à travers toute l'entreprise.
Mais généralement, on commence petit, et il se répand de manière virale, ou d'équipe en équipe.
Il y a un principe très important dans Kanban qui dit de respecter les rôles, les processus et les responsabilités existants. C'est très important et c'est lié à l'approche évolutionniste dont je parlais.
Si vous avez une organisation où les services ne collaborent pas, ou si vous avez certaines structures de management ou de rôles, vous devez les conserver. Respectez le statu quo actuel. Si vous avez des gestionnaires de test, des architectes, des chefs d'entreprise, vous devez les garder. L'expérience montre que les gens n'aiment pas voir changer leurs responsabilités, leurs titres et leurs rôles. Ils acquièrent beaucoup d'estime de soi via leurs rôles professionnels. Si j'avais travaillé comme analyste d'affaires au cours des vingt dernières années, et que maintenant nous avions un nouveau processus où il n'y a pas de place pour un analyste d'affaires, je devrais imprimer de nouvelles cartes de visite avec un nouveau titre, et j'en serai offensé . C'est la raison pour laquelle nous ne faisons pas cela dans Kanban dès le départ. Mais à mesure que nous avançons, nous commençons par développer la confiance, et nous pouvons commencer à introduire ce genre de changements.
InfoQ: En ce qui concerne les colonnes du tableau Kanban, quelles devraient être leur niveau de granularité ?
Dr. Roock: Les colonnes sur le tableau doit refléter la façon dont vous travaillez en ce moment. Cette organisation est généralement facile à détecter en écoutant les gens parler. Ils diront "Les développement sont terminés; avez-vous commencé à tester ?" Cela indique qu'il devrait y avoir une colonne pour le développement et l'autre pour les tests, ce qui reflète la façon dont les gens travaillent de toute façon. Nous voulons avoir une image réaliste de notre flux de travail.
D'autre part, si nous avons trop de granularité, trop de colonnes, trop de "swim lanes" le tableau n'est plus transparent. Il y a une règle appelée "trois par trois", si vous êtes debout à trois mètres du tableau Kanban, alors en trois secondes vous voulez savoir ce qui se passe. Vous ne pouvez pas lire toutes les cartes, mais vous pouvez voir où les choses s'accumulent, et où les gens n'ont rien à faire. Mais si vous avez trop de colonnes ou de trop nombreuses swim lanes, alors vous commencez à vous perdre. (Notes: "colonnes" se réfèrent aux colonnes verticales sur le tableau Kanban. "Swim lanes" renvoient aux lignes horizontales.)
InfoQ. En ce qui concerne le travail en cours (WIP); dans un processus Scrum, nous avons un certain nombre de stories, sur lesquelles nous travaillons. Si nous ne les terminons pas, nous les embarquons dans le prochain sprint, mais nous gardons un œil sur le temps restant, afin de pouvoir utiliser notre vélocité et déterminer combien de nouvelles user stories ajouter. Donc, dans la pratique, WIP est déjà un concept Scrum !
Dr. Roock. Oui, c'est vrai. Scrum limite le travail à faire via le concept des sprints. C'est différent de ce que nous faisons dans Kanban, même si le principe est le même. En Kanban nous avons des limites de WIP par colonne, par swim lane ou par personne. L'astuce consiste à équilibrer la demande contre capacité. Nous ne voulons pas accepter plus de travail que nous ne sommes capables de finir.
InfoQ: Alors disons que nous avons dix développeurs travaillant sur un projet. Ma capacité est un, tout comme les autres. Par conséquent, notre limite de WIP est de dix. Quelqu'un bloque sur quelque chose, ils peuvent prendre un développeur de plus. S'il y a un problème de production, je suis obligé d'en prendre un de plus.
Dr. Roock: Vous posez deux questions différentes. Je m'explique: Un problème de production est appelé un "expedite" dans le monde Kanban. Si nous ne les traitons pas immédiatement nous avons un coût élevé. Dans un tel cas, l'expedite aurait besoin de briser la limite de WIP, et certaines règles devraient s'appliquer. Par exemple, nous allons sauter sur les problèmes et les traiter immédiatement comme une équipe. Après cela, nous devons réfléchir en équipe pourquoi nous avons autant d'expedite. Que pouvons-nous faire pour réduire leur nombre ? Ce serait l'approche Kanban.
L'autre chose dont vous avez parlé est un élément qui est bloqué, mais qui n'est pas un expedite. J'attends une autre équipe parce que j'ai besoin de renseignements ou quelque chose d'eux. Je peux commencer une autre tâche et briser la limite de WIP, ou je peux utiliser cette "souplesse" que j'ai acquise pour améliorer notre système. C'est l'idée derrière Kanban. La limite de WIP est un moyen très puissant de création de souplesse. La "souplesse" vous permet de prendre une profonde respiration, jeter un œil, voir ce qui se passe, d'évaluer ce que je peux faire pour éliminer le problème, et de supprimer la cause racine.
Par exemple, si nous rencontrons le même problème bloquant à plusieurs reprises, peut-être que nous devrions avoir une personne là-bas, ou faire travailler une personne de chez eux ici pendant un certain temps afin que nous puissions transférer les connaissances. Kanban ne dicte pas comment faire face à ces problèmes, elle dit simplement "utilisez les limites de WIP pour créer de la souplesse, n'utilisez pas votre équipe à 100%." C'est ce que nous faisons dans la gestion de projet classique. Nous essayons toujours d'utiliser pleinement les personnes qui de ce fait perdent la souplesse qui pourrait être utilisée pour l'amélioration des processus.
InfoQ: Si je suis chef de projet dans mon organisation, j'ai une faible exposition à Kanban et je décide que je veux faire un essai. Mon entreprise ne va pas investir des milliers de dollars pour me former. Quel est le minimum que je dois savoir pour commencer?
Dr. Roock: J'ai vu des entreprises qui ont tout à fait réussie avec Kanban, et ce sans coaching ou formation extérieure. Ils ont juste lu un livre ou un article de blog, et se sont inscrit à une liste de diffusion. C'étaient de petites entreprises, et je dirais que les chances de succès augmentent si vous aviez au moins une personne vraiment expérimentée. Le mieux est que ces personnes soient internes à l'entreprise, mais si vous n'en avez pas, alors vous devez faire appel à des consultants.
Habituellement, nous commençons avec un atelier sur la gestion, et nous évaluons des questions telles que pourquoi implémentons-nous Kanban ? Acceptons-nous d'avoir un changement incrémental ? Quels sont nos objectifs ? Ensuite, nous formons l'équipe afin que tout le monde parle le même langage. Quelles sont les colonnes et les swim lanes, comment gérons-nous les expedites, et ainsi de suite. Après cela, j'aiderai l'équipe de façon régulière afin de réfléchir sur le système et de l'améliorer. Maintenant, ce n'est pas un emploi à temps plein cinq jours par semaine. On commence par deux ou trois jours au début, mais ensuite on diminuera la fréquence parce que nous essayons de construire une expérience de coaching en interne. Ainsi, le montant du coaching n'est pas énorme, mais on augmente les chances de succès.
InfoQ: Combien de temps le coach doit passer dans l'organisation ?
Dr. Roock: C'est difficile de répondre en général, cela dépend du nombre d'équipes avec lesquelles le coach travaille. Si le coach travaille avec trois ou quatre équipes en même temps, alors ce sera un emploi à plein temps. Mais si vous avez une seule équipe, la meilleure stratégie serait d'avoir de petites périodes de coaching plus fréquentes. Ainsi, par exemple un jour par semaine serait mieux qu'un passage de cinq jours tous les six mois.
InfoQ: Avez-vous un dernier conseil ?
Dr. Roock: Une chose vraiment importante. Ce que nous essayons de réaliser avec Kanban est de comprendre la façon dont nous travaillons, et de comprendre notre travail. C'est une valeur fondamentale derrière Kanban. Si un consultant entre dans mon entreprise et dit que vous devez faire ceci et cela, il a probablement tort. Un bon gestionnaire du changement facilite la compréhension qu'a tout le monde dans l'entreprise, et en particulier des dirigeants, de la façon dont ils travaillent, parce que sinon il est vraiment difficile de s'améliorer. Donc, n'appliquez pas Kanban de façon littérale, essayez de comprendre pourquoi vous voulez avoir des limites de WIP, pourquoi vous voulez avoir de la transparence, etc. Si vous le faites, il y aura de bonnes chances de succès.
A propos de la personne interrogée
Dr. Arne Roock travaille comme formateur et coach pour Lean et Kanban pour IT-agile en Allemagne. Son objectif est d'aider les entreprises en établissant une culture Kaizen avec Kanban. Il a écrit plusieurs articles sur Lean / Kanban et traduit le livre "Kanban - Successful Evolutionary Change for Your Technology Business» en allemand. Arne est le fondateur de la première Limited WIP Society en Allemagne ainsi que membre du conseil et organisateur de la conférence «Lean Kanban Central Europe". Il a été récompensé par le Brickell Key Award 2012 par la Lean Systems Society. Vous pouvez joindre le Dr Roock via Twitter, son blog ou son e-mail.