S'il venait à se tailler un nouvel Everest dans les montagnes encerclant la Silicon Valley, alors, aux côtés de Dijkstra, Kernighan, des Three Amigos et du Gang of Four, il faudrait faire une place pour David J. Anderson, père de Kanban dans l'industrie du développement logiciel. La Lean Kanban North America Conference s'est tenue à Chicago la semaine dernière, InfoQ y a interviewé Anderson, dont la société David J. Anderson and Associates préside l'évènement.
InfoQ : J'ai rencontré récemment un collègue qui a dirigé dans le passé un projet de développement en Scrum. Il m'a surpris en me disant qu'il utilisait à présent Kanban. Je lui ai demandé quels changements dans le processus il avait été amené à mettre en œuvre et il m'a répondu qu'il ne voyait en fait que très peu de différences entre Scrum et Kanban ! C'est évident qu'il était passé à côté. Cet épisode a été une réminiscence des premiers jours des méthodes Agiles, quand tout le monde se disait Agile jusqu'à ce que vous y regardiez d'un peu plus près. Je trouve cela symptomatique. Il semble qu'il y ait un manque de documentation lié à Kanban. Votre ouvrage est la bible en la matière et doit faire dans les 300 pages. Si je devais décrire Scrum en quelques phrases, je dirais que Scrum, ce sont des itérations limitées dans le temps, chacune commençant par des réunions de planification, finissant par une rétrospective, une mesure de la vélocité et des "mêlées" quotidiennes pour faire le point sur l'avancement et les obstacles. Je me demandais si vous pourriez nous enseigner Kanban, un peu de la même façon, "sur le pouce" pour ainsi dire ?
David : Nous avons conscience de ce manque. Nous avons essayé par le passé de produire un guide de démarrage rapide de huit pages, qui a fonctionné à l'époque, mais qui mérite d'être revu. Il y a quelques publications par ci par là mais qui commencent à dater, de 2008 à peu près, et notre compréhension n'était pas aussi bonne à cette époque, ni notre capacité à l'exprimer. Il y a donc une réelle nécessité de produire quelque chose que les gens pourraient lire en une heure.
La Lean Kanban University prévoit de publier ce qui sera "Le guide officiel de Kanban".
InfoQ : Quand pensez-vous que ce "guide officiel" sera prêt ?
David : Eh bien cela aurait déjà dû sortir. L'objectif reste courant de l'année. J'ai aussi commencé à travailler sur une deuxième édition du Kanban book, qui, nous l'espérons, devrait être prête d'ici à la fin de l'automne. Nous avons beaucoup appris depuis la première publication. Nous avons beaucoup appris en l'enseignant, nous avons beaucoup appris en faisant du conseil et en écoutant les autres consultants du marché. Une fois que cette seconde édition sera prête, nous en extrairons le "guide officiel".
InfoQ : Si je veux lancer un projet Kanban aujourd'hui, pouvez-vous me dire comment faire ; comment je commence, comment j'analyse ce que je fais, comment je le vends au management ?
David : Des lignes directrices sont disponibles à ce sujet, par exemple, ma présentation à la Lean Conference de l'an dernier à Boston.
Nous commençons par apprendre aux gens à se demander "quelles sont les insatisfactions des clients et autres parties prenantes extérieures à l'équipe et quelles sont les insatisfactions de l'équipe. En d'autres termes, quels problèmes essayez-vous de résoudre, pour quelles raisons les gens ne sont-ils pas heureux ?" En faisant cela, nous récoltons une meilleure compréhension de ce qui pourrait en être la cause. Alors, nous leur demandons d'identifier qui est à la source de leur travail. Dans un monde agile, nous allons souvent entendre des choses comme "la source est le Product Owner". La source n'est pas le Product Owner ! Le Product Owner est un intermédiaire. Il est donc vraiment important de les amener à faire l'effort de découvrir d'où vient la source de la demande. Cela peut être du département de vente ou marketing, d'une autorité de planification ou de régulation, ou éventuellement d'un client ou d'un segment marché particulier. Nous les aidons donc à comprendre les origines de la demande.
Nous leur demandons également de découvrir leurs cibles. Par exemple, une société développant des applications mobiles peut avoir une version iPhone, une version Android, une ancienne version Symbian. J'imagine que la version Symbian ne fait l'objet que des changements de mise en conformité minimums, à moins de faire l'impasse sur un ensemble de clients historiques dans le milieu de la banque équipés de téléphones Symbian. En revanche, la version iPhone bénéficie de toutes les dernières fonctionnalités. Nous venons alors pour les aider à identifier les risques et faire comprendre ce que représente un niveau de service satisfaisant. C'est un exercice d'analyse de la demande. Donc à nouveau, nous commençons par la voix du client, celle de l'employé et nous passons à l'analyse de la demande.
L'étape suivante, c'est l'analyse des moyens, qui consiste à examiner les systèmes de suivi en place et à extraire les données historiques sur le délai et le taux de livraison dans le but de comprendre ce dont on est actuellement capable. Cela dit, il y a des cas où les gens n'ont aucune donnée historique, mais cela devient de plus en plus rare. Ils ont généralement au moins un système de suivi comme JIRA. Ceci peut nous aider à connaitre la capacité actuelle pour ensuite essayer de mettre en regard la demande du client (à partir de l'analyse de la demande) et les moyens existants pour voir où sont les écarts. Et c'est à partir de ces informations que nous pouvons commencer à concevoir le Kanban.
InfoQ : Est-il réaliste pour un chef de projet profane de se lancer dans une telle implémentation ?
David : C'est possible mais en général, nous recommandons que les gens soient formés à le faire correctement. Ceux qui épinglent simplement un tableau sur le mur et y collent quelques post-it peuvent arriver à visualiser le travail à faire et le flux, mais ils ne sont pas forcément en train de concevoir un système ayant pour but d'améliorer le service au client. Kanban est un système orienté service, c'est un mécanisme pour améliorer la capacité de livraison. Et donc, il est nécessaire de comprendre quel service vous fournissez, quelle est la demande pour ce service et quelle est votre capacité actuelle pour répondre à cette demande.
InfoQ : Est-ce que cela n'est pas une barrière à l'entrée ? Les gens veulent comprendre ce qu'ils font avant de s'investir de façon plus importante.
David : Soyons clairs, il n'y a pas de solution miracle. Pour réaliser des résultats tels que ceux qui ont été vus dans des organisations comme la BBC, où des départements ont de façon individuelle amélioré leur productivité de 700% et 800%, en particulier un en charge de produire les pages web pour le site commercial de BBC Worldwide, où ces départements ont amélioré leurs revenus sur les encarts publicitaires d'1 million de dollars par an, ils se sont attachés à améliorer leur taux de livraison, ce qui a eu pour effet de réduire le délai de livraison et permis de livrer plus tôt pour finalement générer le million supplémentaire. Voici le genre de bénéfices que vous pouvez obtenir en mettant en œuvre Kanban correctement.
InfoQ : Mais du point de vue d'un responsable de projets, cela résonne comme de beaux discours marketing. Comment puis-je savoir si je peux espérer de tels résultats dans mon contexte ?
David : Je ne vois pas cela comme de beaux discours. Les gens nous font part d'études sur Kanban qui rapportent des améliorations de 400% de productivité et lorsque je me penche dessus, je me dis : "tout me parait complètement normal". Vous pouvez faire le tour de cette conférence et trouver 100 personnes qui vous raconteront des histoires comme celle-là.
InfoQ : C'est très convaincant mais le problème, c'est que nous n'entendons rien au sujet des projets qui auraient pu échouer et qui auraient pu envoyer tout cela au rebut.
David : Nous avons vu des sociétés qui ont lu le livre, qui n'ont eu recours à aucune assistance et qui ont tout de même connu ce genre de résultats. Maintenant, cela peut paraitre peu rassurant du point de vue commercial. Les gens ne vont pas payer pour des formations s'ils peuvent obtenir ces résultats, juste en lisant le livre. Cependant, ici, en Amérique du Nord, il y a une énorme part des implémentations de Kanban qui sont faites de façon trop superficielle et beaucoup pourraient grandement bénéficier d'une mise à niveau vers une implémentation plus "en profondeur".
Le marché du Kanban fait preuve d'un grand dynamisme, on en entend beaucoup parler, les gens vous diront qu'ils ont des tableaux aux murs, qu'ils supervisent le flux, etc. Mais cela reste superficiel, cela reste ce qu'ils ont pu glaner sur Internet. Mais la compréhension de Kanban par la communauté Agile, particulièrement en Amérique du Nord est pauvre, de façon abyssale. Les gens n'ont pas accordé d'attention à l'aspect plus profond, l'approche systémique, l'approche orientée service. Ils n'ont peut-être même pas réalisé qu'un système imposant que l'on "tire" le travail vers soi, un "pull system", et sur lequel on applique des limites à la quantité de travail en cours est essentiel. Ils ne regardent pas les dynamiques au cœur de la conception du système Kanban.
InfoQ : Mais n'est-il pas important pour outrepasser les barrières à l'entrée, d'établir un premier contact et dans un second temps, de prendre de l'ampleur ? Une grande compagnie financière, par exemple, peut avoir tout un ensemble de couches hiérarchiques de management et une équipe de développement pourrait avoir l'envie soudaine de faire du Kanban. Ils auront à convaincre leurs managers, qui auront à convaincre leurs propres managers, qui répondra "vous savez que vous m'avez vendu Scrum l'année dernière et maintenant, vous essayez de me vendre Kanban, où sont passés les bénéfices que nous étions censés réaliser grâce à Scrum ?".
David : Il y a un point important qui, je pense, est largement incompris et qui est, à nouveau, un problème de la communauté Agile en Amérique du Nord. Un certain nombre de praticiens Agiles bien connus ont décrit Kanban comme étant un processus à mettre en place au niveau d'une équipe. Cela n'a jamais été juste un processus d'équipe. Le premier Kanban a été un processus multi-département ainsi que le second et les suivants, tous mis en place en 2006 et 2007. Cela n'a pas été un processus d'équipe mais une chaine de processus transverses au niveau de l'organisation. La méthode Kanban est un outil de changement conçu pour être amené depuis le milieu de l'organisation, de façon transverse à l'entreprise. C'est ce qui le différencie sur le marché. Beaucoup de consultants Lean, et ce n'est pas pour s'en prendre à Lean en particulier mais c'est un cas typique, vous diront que vous pourrez toujours réussir à partir du moment où le directeur exécutif est convaincu. Ça, c'est du changement "top down". Par ailleurs, les changements apportés par les méthodes Agiles, étant orientés équipe ou orientés développeurs, ont tendance à être des changements locaux, conduits depuis le bas. La méthode Kanban est conçue pour être conduite du milieu, elle est prévue pour être orientée processus, orientée service et doit couvrir de multiples départements et de multiples étapes dans le cycle de vie des différents éléments de travail. Il implique la collaboration de multiples équipes. Afin de faire tout cela, vous devez être un "middle manager" car vous aurez la légitimité pour assembler les différentes parties. Si vous êtes développeur, c'est bien au-delà de vos attributions.
Principalement, Kanban est fait pour me débarrasser de tous les indésirables qui me gâchent la vie, de toutes les interruptions qui me gênent, il aide les managers à se concentrer sur les problèmes bloquants pour que l'on puisse s'en défaire rapidement et reprendre le travail. Avant tout, il m'aide à me concentrer uniquement sur un petit nombre de choses à la fois, plutôt que sur les 20 choses que l'on pourrait me demander.
Une autre complainte qui revient systématiquement dans la bouche des employés, c'est qu'ils sont constamment ballotés dans différentes directions à cause des priorités qui ne cessent de changer. Kanban aide réellement les gens à se concentrer sur ce que l'on appelle dans le cercle du Kanban : "la question des Spice Girls". Quand vous remplissez une file du Kanban, vous devez vous demander : "à présent, quelles sont les deux choses que je désire ?". Le consultant en management Stephen Bungay dirait alors : "dites-moi ce que vous voulez, ce que vous voulez vraiment vraiment (tell me what you want, what you really really want)" et une fois que vous avez décidé, vous ne devriez pas à avoir à changer d'avis. A partir de là, quand quelque chose traverse le "Kanban board", il ne devrait pas être rejeté. Les développeurs et les analystes trouvent cela utile. Ils ne travaillent que sur des choses qui sont souhaitées, la quantité de ces choses est maîtrisée et ainsi, ils peuvent se focaliser, livrer et passer à l'étape suivante. Les implémentations "bottom up" ont tendance à apporter des améliorations seulement jusqu'à un certain point à moins d'aller plus loin en cherchant à élargir sa prise sur la chaine de valeur. Et, à moins qu'il n'y ait quelqu'un avec suffisamment de pouvoir politique, le plus souvent, cela n'arrive pas.
On peut parler de propagation virale et on peut même parfois voir des développements spontanés de systèmes Kanban. Mais honnêtement, implémenter Kanban correctement nécessite l'engagement du "middle management", par exemple au niveau des directeurs de projets ou, dans des compagnies de taille restreinte, des managers seniors. Les implémentations partant du bas fournissent des bénéfices psychologiques et sociologiques à tous les employés, elles les laissent effectuer un travail de qualité et soulage d'une grande part de stress, mais ne vont pas se mettre à soutenir le moteur économique de l'entreprise. Dans mon livre, je parle des bienfaits du "relâchement". Mais vous ne pouvez pas vendre Kanban en tant que produit ou service si vous parlez du relâchement car cela n'est pas convaincant pour les exécutifs.
InfoQ : Existe-t-il un arbre de décision que nous pourrions utiliser pour déterminer si Kanban produira le genre d'effets positifs que vous venez de décrire ?
David : Oui, nous l'enseignons dans le cadre de certaines formations avancées. C'est en fait plus aisé de décrire quand vous ne devriez pas l'utiliser. Vous ne devriez pas l'utiliser si votre management senior est constitué d'impatients révolutionnaires postés dans l'urgence d'obtenir des résultats spectaculaires. Mais si vous êtes dans une organisation bureaucratique, dans une culture conservatrice, cela pourrait mieux marcher. Un autre cas non adéquat serait celui d'un désordre extrême ou d'étapes de recherches précoces. Kanban s'applique bien dans le développement, pas dans la recherche. Vous devez être capable de décrire un "value stream" et identifier quel service votre client attend de vous. Si vous ne pouvez pas décrire tout cela, alors vous ne pourrez pas construire un Kanban.
Egalement, concernant les sociétés avec une activité technologique, vous devez disposer d'un système de gestion de configuration, de contrôle de versions et vous devez avoir la capacité de créer une "release" de votre travail tout continuant à réaliser d'autres tâches de développement. Cela requiert des fonctions de gestion de configuration plus évoluées que celles requises classiquement avec les méthodes Agiles. Si vous commencez une itération, travaillez pendant quelques semaines puis déployez, vous vous coupez de la possibilité d'avoir des branches ou des labels à l'intérieur de l'itération. Mais dans un système Kanban, vous devez pouvoir gérer de multiples branches. Toutes les organisations n'ont pas ces capacités.
InfoQ : J'aimerais comprendre un peu mieux l'implémentation. Disons que vous êtes responsable du processus de développement. Vous commencez généralement par une phase de modélisation, puis vous créez les tests, vous implémentez, passez les tests, faites des revues de code, etc. Devriez-vous retrouvez toutes ces colonnes sur votre tableau Kanban ?
David : je répondrais probablement. Mais vous allez vouloir aussi inclure les processus en amont et en aval. Examinez la couverture de ce que vous contrôlez actuellement sur le plan décisionnaire ; une fois que vous avez consolidé votre capital politique, vous pourrez obtenir les processus amont et aval.
InfoQ : Voici à mon avis le genre d'approche dont nous avons besoin. Le chef d'équipe doit prendre la décision, l'implémenter et si cela fonctionne la vendre à la hiérarchie. Si je peux commencer petit et faire la différence, alors la pratique s'étendra.
David : Dans tout processus, il est nécessaire de construire un capital social. Vous pouvez faire cela en utilisant des méthodes issues de la sociologie qui visent à établir un climat de confiance, par exemple en assurant une meilleure transparence. On a confiance en quelque chose à partir du moment où on comprend comment cela fonctionne et que l'on peut demander : "il y a deux semaines, je vous ai demandé quelque chose, puis-je savoir où cela en est ?". La confiance est développée de cette façon, incrément par incrément et pour des raisons neuropsychologiques, les petites promesses tenues fréquemment établissent la confiance plus rapidement que de gros engagements peu souvent tenus. La confiance se construit ainsi, en livrant en accord avec sa cible. C'est comme cela qu'il est possible de générer une dynamique dans une approche "bottom up".
Parfois, après deux jours de formation avancée, quelqu'un vient nous voir en disant : "Nous avons appris sur le processus de changement, sur la psychologie et la sociologie, quand allons-nous commencer à apprendre Kanban ?". Mais en fait, pour beaucoup, Kanban c'est juste ça. Fondamentalement, on peut ne voir qu'un "pull system" limitant l'encours de travail accompagné d'un mécanisme de signalisation. Cela demande un peu plus, par rapport à la compréhension de la demande et de la façon de choisir les limites. Mais comment faire de tout cela quelque chose qui révolutionnerait la performance de ceux qui détiennent le savoir dans l'organisation ? C'est beaucoup de psychologie et de sociologie.
InfoQ : Très bien, merci pour cet aperçu, David ! Kanban est pour sûr en train de gagner énormément en popularité. Je vous souhaite le meilleur pour votre aventure.
Au sujet de l'interviewé
David J. Anderson a 30 années d'expérience dans le domaine de l'industrie high-tech et a aidé des équipes de développement à livrer avec une meilleure productivité et une meilleure qualité en utilisant des méthodes agiles innovantes au sein de grandes sociétés comme Sprint, Motorola et Microsoft. David est l'auteur de trois livres, Agile Management for Software Engineering - Applying the Theory of Constraints for Business Results; Kanban - sucessful Evolutionary Change for your technology Business; et Lessons in Agile Management: On the road to Kanban.