David J. Anderson, pionnier de l'application de Kanban au développement logiciel est récemment venu au Brésil. Un groupe d'éditeurs d'InfoQ Brésil a pu interviewer David au sujet de Lean, Agile et Kanban. Voici les point principaux de cette interviews.
InfoQ Brésil : Quels sont les liens entre les philosophies Lean et Agile ?
David : Il y a évidemment beaucoup de similarités. Une des différences vient du fait que la philosophie du Lean repose sur la recherche de la perfection alors qu'une des idées sous-jacentes de l'Agilité est de s'améliorer en s'appuyant sur de l'information imparfaite quitte à corriger plus tard lorsqu'on en sait plus. De nombreux penseurs Lean auraient du mal avec ça ; ils auraient du mal avec l'idée d'aller de l'avant malgré une information incomplète. Ils verraient le rework comme du gâchis. L'Agilité, ça n'est pas la recherche de la perfection. Voilà une différence importante.
Je pense qu'une autre différence c'est la façon de considérer les gens dans les deux philosophies. Dans Lean, on est sur un mode de pensée systémique. L'idée est que la performance des gens est largement influencée par le système dont ils font partie et qu'en les respectant on conçoit un système qui leur permet de travailler efficacement. L'Agilité a une approche plus humaniste et considère les gens comme des individus. C'est une vision anarcho-libertaire selon laquelle on doit laisser les gens seuls décider de la bonne chose à faire, les meilleurs résultats émergeant de l'auto-organisation. Dans leur rapport aux personnes, Lean et Agile sont très différents.
Et au sein de la communauté Agile et particulièrement aux États-Unis, il y a de nombreuses influences politiques ; certains sont très humanistes, ou très libertaires, ou carrément anarchistes. L'idée selon laquelle chacun doit avoir le droit de faire ce qui lui plaît car l'homme est intrinsèquement bon (et qu'il suffit de lui faire confiance) est une idée forte dans la communauté Agile. Personnellement je pense que c'est un voeux pieux.
Historiquement, la communauté Agile a subi une pure influence communiste. Le manifeste lui-même en est imprégné avec des idées comme, "tous les managers sont mauvais", "toute tentative de contrôler les gens est mauvaise", "toute tentative d'affirmer son autorité sur les gens est mauvaise". Je ne suis pas convaincu que ça soit vrai, et je pense que les gens qui pensent Lean ont une approche différente. Ils croient à la Construction de Systèmes ; ils croient qu'il y a une classe de gens qui savent le faire et qui font marcher le système. La Culture Kaizen n'est pas l'auto-organisation. Agile et Lean ont donc des approches extrêmement différentes des gens et de l'organisation.
Pour moi, il est parfaitement acceptable que quelqu'un vienne au travail, fasse son boulot, récupère son chèque, rentre chez soi, vive sa vie et s'intéresse à sa famille. Rien à redire si ses passions sont en dehors de son travail. Je crois que de nombreux Agilistes pensent que tout le monde dans l'équipe devrait être profondément passionné par sa profession. Je pense que ça n'est ni faisable, ni réaliste, ni pragmatique dans le cas de grands projets ou de grandes entreprises. L'idée que chacun doive être passionné par son boulot, c'est quelque chose qui fonctionne pour une startup de six personnes, pas dans un département de 300 personnes au sein d'une grosse boîte.
InfoQ Brésil : Quand on parle de donner plus de pouvoir à l'équipe, est ce que ça n'est pas contradictoire ?
David : Donner du pouvoir, ça n'est pas laisser les gens faire ce qu'ils veulent, ou imaginer qu'ils vont, comme par magie, s'auto-organiser pour produire ce qu'on attend d'eux. Donner du pouvoir, c'est d'abord poser des limites, et c'est ce que nous faisons avec les enfants quand nous les élevons ; nous leur disons quand il est temps d'aller se coucher, où ils peuvent aller jouer, s'ils peuvent sortir de la cour de la maison, qu'ils ont le droit de nager dans le petit bain mais pas de sauter du plongeoir... Donner du pouvoir, c'est fixer clairement les limites, et laisser toute initiative aux personnes à l'intérieur de ces limites.
InfoQ Brésil : Tu as, récemment ajouté une nouvelle pratique de base à Kanban : mettre en place un Feedback Organisationnel. Pourquoi est-ce un besoin ?
David : Je n'ai pas vraiment ajouté cette pratique, je l'ai juste explicitée. Dans mon livre Kanban, Enclenchez le Moteur d'Amélioration Continue de Votre IT, il y a un chapitre entier sur le sujet ; mais je ne l'ai pas présenté comme une pratique de base. Je me suis rendu compte de mon erreur quand j'ai vu le peu d'adoption de boucles de feedback au niveau organisationnel. Quand les choses ne se produisent pas comme attendues, il faut parfois les rendre plus évidentes, et c'est pour ça que je l'ai ajouté à la liste des pratiques de base. Ça n'est donc pas quelque chose de nouveau, c'est juste une mise en avant.
InfoQ Brésil : Tu dis que Kanban est une manière de niveler la demande par la capacité. Peux-tu nous en donner les avantages et comment convaincre les gens du métier que c'est quelque chose d'important ?
David : Il faut équilibrer la demande, la capacité et les ressources, et il est clairement important de ne pas surcharger les ressources. Si on est en surcharge, on produit en fait moins, on diminue la qualité et la plupart du temps, cela prend plus de temps. En créant cet équilibre, on améliore effectivement la capacité et les choses vont plus vite. On produit plus. La qualité s'améliore.
Les gens du métier doivent pouvoir comprendre ce que signifie limiter la demande en fonction des ressources. Cela signifie qu'il doivent rationner leur demande par rapport à la capacité à produire, car il y aura toujours plus de demande que ce qu'on peut produire. Il n'y a pas de limite à l'ingéniosité humaine. Ce qui est vraiment important, c'est d'être en mesure d'évaluer avec précision les risques, les récompenses et les avantages de ces idées sur le nouveau logiciel que ces gens vont obtenir.
Il y a donc beaucoup de valeur à aider les gens du métier à analyser les risques et les bénéfices de leurs idées, et à les aider à se concentrer sur les meilleures et à en fournir une liste équilibrée en fonction de nos ressources. Donc, en même temps que nous essayons d'améliorer notre capacité à fournir, ils doivent aussi apprendre à choisir les meilleures options parmi les idées possibles.
Si nous réussissons à faire les deux (augmenter notre capacité et limiter/améliorer la gestion du risque liée à la demande), alors nous pouvons vivre en harmonie. Une des raisons pour laquelle nous sommes submergés de demande, c'est l'incertitude envers le futur ; pour se couvrir, les gens du métier nous demandent "faites tout". Ça n'est clairement pas faisable, donc nous devons les aider à évaluer les risques et à comprendre l'incertitude à laquelle ils font face. C'est grâce à ça, qu'ils pourront faire leurs choix en confiance.
InfoQ Brésil : Y a-t-il des mythes ou des idées fausses concernant Kanban ? Lesquelles, selon toi, sont les plus fréquentes ou les plus importantes
David : Alan Shalloway a publié un article sur les mythes liés à Kanban, c'est une bonne référence. Je pense qu'il y a de nombreux mythes, l'un d'entre eux est relatif au tableau. En fait, l'Alliance Agile a publié une page web décrivant le tableau kanban comme une pratique agile. La méthode Kanban ne s'appelle pas "Kanban" à cause du tableau ; elle s'appelle Kanban car elle met en oeuvre un système kanban virtuel, un système à flux tiré pour limiter le travail en cours et retarder la prise de décision jusqu'au moment que les gens du Lean appellerait le "Dernier Moment Raisonnable" ; le tableau n'est qu'un moyen de visualiser ce qui se passe.
Le tableau a été ajouté plus tard ; le système kanban existait avant. On appelait les tableaux "tableaux de bord" ou "tableaux à fiches", et ils étaient commun au sein de la communauté Agile. Le tableau n'avait rien de nouveau, il ne représentait pas d'innovation majeure. L'innovation c'est l'utilisation du système de Kanban virtuel.
Il y a plein d'autres mythes récurrents. L'un d'entre eux est que Kanban serait réservé à la maintenance et à l'exploitation informatique et qu'on ne devrait pas l'utiliser sur de grands projets. C'est clairement de la désinformation ; en 2007 par exemple, nous avons réalisé un projet de onze millions de dollars avec plus de 50 personnes, en utilisant Kanban.
Nous l'avons donc utilisé sur de grands projets dès le début, et les raisons pour choisir Kanban c'est qu'il aide à améliorer la prévisibilité et la gestion du risque. Avoir des certitudes sur les dates de livraisons est évidemment une chose importante quand on parle de gestion de projet ou de gouvernance.
Malheureusement, ce mythe selon lequel Kanban ne serait que pour la maintenance et l'exploitation est commun et récurrent dans la communauté agile.
InfoQ Brésil : Que dire du mythe selon lequel Kanban serait un retour au cycle en cascade ? Est-ce qu'il est toujours vivace ?
David : Le mythe du cycle en cascade a été très présent entre 2007 et 2009, mais on ne le voit plus trop souvent. Cela venait principalement du fait que de nombreux exemples étaient construits par des équipes qui utilisaient des processus de développement ou des méthodes qui n'étaient pas reconnues comme Agiles (comme par exemple le Personal Software Process et le Team Software Process). Les premiers exemple de Kanban n'étaient donc pas des exemples Agiles.
Comme j'ai présenté Kanban comme une méthode pour améliorer des équipes qui rejetaient les méthodes agiles, il était assez naturel que les premiers exemples soient des exemples non agiles. De fait, aujourd'hui, l'Agilité est très courante : probablement plus de la moitié des gens ajoutent Kanban par dessus Scrum, donc je pense que ce mythe n'est plus d'actualité.
InfoQ Brésil : Tu as récemment proposé d'ajouter la pratique d'"autoriser les idées et d'encourager l'innovation dans le processus". Peux-tu nous dire pourquoi ? Ressens-tu le besoin d'un "Kanban Master" ?
David : En fait, j'ai ajouté l'idée qu'il fallait encourager le leadership et qu'il fallait bien que les gens distinguent leadership et management dans les principes de la méthode Kanban. Les managers sont responsables du système qu'ils pilotent, de sa conception, de toute les règles d'organisation et de toutes les décisions qui impactent ou modifient ces règles. Tout ça c'est très bien, mais nous avons besoin que chacun, qu'il soit simple contributeur ou manager, fasse preuve de leadership.
Faire preuve de leadership c'est se dire que quoiqu'il arrive, ça n'est pas assez bien, et qu'il faut suggérer ou montrer comment on peut l'améliorer. Si on n'a pas ça, alors on ne catalyse pas l'amélioration continue. Tout le monde peut baisser les épaules et se dire "Bon, c'est comme ça. Je retourne bosser !" et rien n'ira jamais mieux. Le leadership, c'est l'ingrédient magique. C'est le catalyseur.
Il y a un autre exemple récent : Håkan Forss, un consultant Kanban, après avoir lu le livre de Mike Rother sur les Kata Toyota a suggéré qu'il y avait trois Kata dans Kanban, trois "Kanban Kata".
Le premier c'est la réunion quotidienne du matin qui provoque des événements kaizen locaux. Le second, c'est la revue d'opérations qui provoque les améliorations inter processus et inter systèmes Kanban. Et le troisième, c'est la relation entre le supérieur et son subordonné, le manager N et son N-1 où le plus senior coache le moins expérimenté sur "Est-ce que notre système fonctionne bien ?", "Avons nous les bonnes règles d'organisation ?", "Est ce que nous mesurons les bons indicateurs ?", "Est-ce que nous observons les bonnes choses ?". Tout cela pour observer le monde dans lequel nous vivons et le modifier pour l'améliorer.
InfoQ Brésil : Est-ce que la communauté s'approprie le terme Kanban Master ?
David : Non ! Nous décourageons vraiment l'idée d'un "Kanban Master" (à mettre en parallèle du rôle de Scrum Master). Je suis persuadé de l'intérêt d'utiliser un coach. C'est un rôle différent, typiquement à rapprocher de celui de coach Agile. Quand j'observe les coaches Agiles, ils font souvent partie des équipes, et ils sont présents tous les jours de la semaine.
On peut voir que les coaches Kanban sont, eux, présents deux ou trois jours par mois pour discuter avec les gens des règles d'organisation, de visualisation ou des métriques. Ils les aident à comprendre les notions de capacités ou à trouver des améliorations. Pour faire ça, ils n 'ont pas besoin d'être présents tous les jours.
InfoQ Brésil : InfoQ a récemment publié un article présentant Kanban comme l'étape suivante après Scrum. Qu'en penses-tu ?
David : Si l'on parle de développement d'un marché, et qu'on voie Kanban comme le prochain élément significatif d'un marché du processus logiciel, je pense que c'est correct. Il y a de nombreuses preuves que nous faisons face à un véritable mouvement vers plus de formations Kanban, de coaching Kanban, de consulting Kanban, de logiciels Kanban, de simulations, de jeux, etc... Donc, d'un point de vue "marché", Kanban est bien la prochaine étape. Si vous pensez qu'il y a eu CMMI, RUP, XP et Scrum, Scrum est bien le prochain sur la liste.
Mais si l'on veut dire par là qu'il faudrait commencer par appliquer Scrum avant de passer à Kanban, là, je pense que c'est complètement faux. Scrum est difficile à adopter pour de nombreuses organisations. Culturellement, il y a de nombreuses entreprises auxquelles il n'est pas adapté et où les gens résistent à son adoption.
D'un autre côté, Kanban est conçu pour être adopté facilement. Il est fait pour démarrer avec ce qu'on fait déjà maintenant. C'est une alternative à Scrum. Si on attendait de vaincre la résistance au passage à Scrum, on perdrait de nombreuses opportunités d'améliorations rapides qu'on aurait obtenues en passant rapidement à Kanban. Quand les gens utilisent déjà Scrum, et qu'ils ressentent un besoin d'aller plus loin dans l'amélioration, alors ajouter Kanban est une bonne idée. Mais s'ils ne pratiquent pas déjà Scrum, ils devraient voir Kanban comme une approche qu'ils peuvent appliquer tout de suite.
InfoQ Brésil : Dans son livre Management 3.0, Jurgen Appelo explique qu'une des raison du succès de l'adoption de Scrum, c'est que Scrum remplace entièrement le "méméplexe" actuel par un nouveau. Qu'en penses-tu ?
David : Je ne vais pas argumenter. Le challenge est : est-il possible d'arriver à effectivement supprimer et remplacer le méméplexe ? Même si on peut dire qu'il y a des succès, on doit aussi constater qu'il y a de nombreux cas de résistance. Il y a de nombreux cas où l'adoption de Scrum a été remise en cause, voire a échoué. J'ai vu une étude relativement récente qui révèle que Scrum a été adopté par environ 15% du marché. C'est mieux que ce que RUP a jamais atteint : au plus haut, RUP était à 11%. Donc 15% c'est bien, mais il faut se poser la question : dans ces 15% combien de ces implémentations sont remises en cause ?
Soyons généreux et disons que tous ces 15% fonctionnent à merveille. Il reste quand même 85% du marché. Je ne doute pas que la plupart des choses que Jurgen a dites à propos de Scrum sont justes et précises. Malgré tout, il reste plein de problèmes à résoudre dans l'univers et dans le monde du management et du processus logiciel et c'est à cet espace que je m'intéresse le plus. Je suis sur qu'il y a beaucoup de gens dans la communauté Scrum qui s'intéressent à l'amélioration de Scrum.
A propos de l'Interviewé
David J. Anderson a trente ans d'expérience dans la high tech, et a mené des équipes de développement logiciel vers une amélioration drastique de la productivité et de la qualité en utilisant des méthodes innovantes et agiles pour 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 – Successful Evolutionary Change for your Technology Business (traduit en français : Kanban, Enclenchez le Moteur d'Amélioration Continue de Votre IT) et Lessons in Agile Management: On the Road to Kanban.