Réflexions sur les stratégies d'amélioration des processus et méthodes agiles

Lors de mon retour d'expérience de Scrum au Kanban, je faisais part de mon constat opérationnel que le Kanban minimise l'impact du changement et réduit la résistance à l'adoption de l'agilité.

Est-ce une bonne chose?
Un changement de paradigme comme l'apporte Scrum permet de bousculer les choses, des prises de conscience plus radicales, plus rapides mais plus perturbantes peut être dans certains contextes. Ce sont tous les freins à l'adoption de l'agilité que l'on rencontre régulièrement. L'accompagnement au changement devrait être plus présent dans ce cas. Dans la réalité, elle se résume à une formation, et plus rarement à du coaching. Bien que je constate avec satisfaction que ces missions de coaching se développent bien.

Avec Scrum et le Kanban, on a deux stratégies d'amélioration différentes:

• L'amélioration par rupture avec Scrum : vs les approches traditionnelles
• L'amélioration continue avec le Kanban : commencer là ou on est par petits incréments d'amélioration, c'est un principe fondamental du Kanban

Ce qui peut être perturbant avec Scrum, c'est que cette amélioration par rupture lors de son adoption est en décalage avec le cadre d'amélioration qu'elle propose : une amélioration au quotidien par tous les mécanismes de feed-back qu'elle met en oeuvre et par son modèle d'Inspection et d'Adaptation, proche du PDCA.

Pour moi, il n'y a pas de jugement autour de l'une ou l'autre de ces stratégies d'amélioration, puisque les deux sont nécessaires pour innover. Mais là encore, une contextualisation importante est à faire.

Le Kanban permet une approche Kaizen facilitant l'adoption de l'agilité et pour imager cela, je prends l'exemple d'un projet que j'accompagne depuis quelques mois avec une équipe d'une vingtaine de personnes. Récemment, j'ai eu plusieurs retours par quelques acteurs du projet que l'on ne faisait pas d'agilité sur le projet. Bonne nouvelle! Car d'abord ce n'est pas une fin en soi, donc j'évite de mettre le mot Agile à toutes les sauces. Mais surtout c'est le signal faible que la stratégie petit pas du Kanban a été payante, car en réalité le degré d'agilité sur le projet est important.

Je vais faire un focus sur les limites du travail en cours, car déjà Guillaume m'en faisait la remarque sur le trajet des XP Days Benelux récemment et d'autre part c'est un élément différenciant du Kanban qui met une limite sur le travail en cours sur les états, là ou Scrum met une limite indirecte via la vélocité.
Je n'ai pas de limite explicite sur le travail en cours sur ce projet, en théorie je ne suis pas dans les standards du Kanban. Mais la limite est implicite et surtout elle a largement évolué pendant le projet: J'ai commencé d'abord par deux tag names par personne. Puis à l'occasion d'un refactoring du tableau de taches, j'en ai profité pour ne laisser physiquement que de la place pour une tache en cours par personne sans autre contrainte. Résultat, les taches dépassaient régulièrement la colonne En cours. Mais au fur et à mesure, cette contrainte a forcé naturellement les personnes à finir les taches ou à binômer.

Dernièrement, à l'occasion du dernier refactoring du tableau pour passer à trois équipes en parallèle, je suis passé à un tag par personne, ce qui n'a pas posé de problème à l'équipe.

Donc en quelques mois sans tambour ni trompette, et surtout sans pression sur l'équipe, nous sommes maintenant et durablement sur une limite implicite de travail en cours à une tache par personne, à une limite physique par équipe et à une limite physique sur le projet; Et une équipe qui se focalise d'elle-même sur les taches à finir avant d'en commencer d'autres.

C'est un exemple simple mais significatif. L'amélioration sur le processus a lui aussi été appréhendé par petits pas et n'est pas encore fini.

Ce qu'il est possible de faire au niveau projet (une rupture avec Scrum) est plus difficile à faire au niveau organisation (amélioration Kaizen du Lean). il y a bien derrière ces deux stratégies, portées par des approches différentes, un enjeu d'adoption de l'agilité aux différents niveaux d'une organisation. C'est l'un des messages que l'on entend bien sur dans la communauté Lean & kanban. La relation entre un projet agile réussi et une adoption agile réussie n'est pas bijective.