Je vous ai déjà parlé du livre Rupture Douce, que j’ai eu le plaisir de co-écrire avec d’autres coachs Agiles. La saison 2 du livre étant maintenant en préparation  (lire le teaser de la prochaine saison), je vous livre maintenant mon histoire « L’agilité, même pas mal ! » pour une rupture douce, sans illustration mais avec une version podcast audio (à la fin du post).
Rupture douce : L’agilité, même pas mal

Rupture douce : L’agilité, même pas mal

Dans ce livre, je vous propose de découvrir le récit d’une transition silencieuse d’une équipe vers l’agilité. Et de découvrir comment l’approche Kanban a permis ce changement en douceur. Episode #1 : Lancement du prototype opérationnel Episode #2 : Le pilote opérationnel & la phase industrielle du projet Kanban Episode #3 : L’épilogue et le debreif du projet Episode #4 : Le debreif du projet pour l’équipe et le management

L’agilité, même pas mal ~ épisode #5

Et pour le coach ?

En tant que coach, j’avais un backlog de features (les pratiques agile/Kanban) pour ce projet. L’équipe ne pouvait pas les implémenter toutes en même temps. Il fallait donc prioriser, implémenter quelques pratiques, quelques changements et voir leurs effets. Il faut accepter que toutes les pratiques ne soient pas mises en œuvre et constater que certaines n’apportent pas autant de valeur que l’on aurait supposé. Prioriser au fur et à mesure de ce que l’on apprend du projet et de la valeur que les pratiques apportent. Le backlog n’est pas qu’un outil du Product Owner. Il est aussi celui du coach lorsque le système à améliorer est complexe. C’est peut être frustrant pour le coach. Et cela ne remet nullement en cause la valeur des méthodes. Le problème n’est pas de savoir si l’on est « full » telle ou telle méthode, mais de mettre en place les bonnes pratiques dans le contexte avec la bonne profondeur. L’approche empirique, à la base de ces méthodes, prend alors tout son sens. On a tendance à l’oublier lorsque les méthodes deviennent trop formelles. Là aussi, il faut expérimenter, adapter et laisser émerger les choses. Il faut prendre le temps de voir les effets à plus long terme, les cycles longs de remaniements de processus. Cette approche m’a permis de formaliser la démarche Kanban telle que vous pouvez maintenant la lire dans le livre Kanban pour l’IT. La posture du coach peut être celle d’un Sherpa, dans le bon sens du terme, pour continuer la métaphore de l’ascension. C’est un guide de montagne cherchant la bonne route pour l’équipe : une direction claire mais adaptative, un porteur pour aider l’équipe à se hisser et surtout un compagnon de route qui engage un dialogue permanent avec l’équipe, le management et le client. La vision est importante. Savoir dans quelle voie on emmène l’équipe pour générer de la confiance malgré un contexte incertain. Je pense que c’est une part importante du succès de cette approche. Le management doit laisser place au leadership et toucher la motivation profonde des individus, donner une signification au changement par des objectifs ambitieux mais réalistes, s’occuper d’abord des problématiques à résoudre avec méthode avant de s’occuper de la méthodologie. Ce point fondamental fait d’ailleurs partie de la nouvelle définition du kanban, à juste titre pour faciliter l’adoption et la diffusion virale du Kanban dans l’organisation. Car c’est bien l’équipe qui porte la transition. Le coach n’est qu’un guide et un témoin de ce doux changement. Le management donne les moyens d’y parvenir.  

Le rythme du changement

Lors de mes premiers retours d’expérience de Scrum au Kanban en conférence, 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é.  

Et finalement, est-ce une bonne chose?

Un changement de paradigme comme l’apporte Scrum permet de bousculer les choses, de redynamiser une équipe qui s’essouffle, 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 heureusement, je constate avec satisfaction que ces missions de coaching se développent de plus en plus. 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.
  • Le changement évolutif avec Kanban en instillant une culture Kaizen.
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 œuvre et par son modèle d’Inspection et d’Adaptation, proche de la roue de Deming de l’amélioration. Pour parvenir à cela, les trois piliers du Kanban sont :  
  • Commencer par ce que vous faîtes maintenant.
Trop de changements rapides provoquent du stress et de la résistance. Ne pas changer l’existant au démarrage d’une démarche d’amélioration est moins perturbant pour les membres de l’équipe. En contrepartie, la démarche peut être moins porteuse d’innovation immédiate.  
  • Respecter le processus actuel, les rôles et responsabilités.
La méthode ne se suffit pas à elle-même et s’applique à un processus existant. Et surtout elle s’applique dans un contexte existant.  
  • S’engager à changer de manière incrémentale et évolutive.
Dans une démarche évolutive, if faut trouver le rythme du changement et avoir de la patience. Sur ce projet, je souhaitais faire le troisième remaniement à mi-projet, en décembre. Mais l’atelier Kanban n’eu lieu que début février avec les chefs d’équipe, pour une mise en place début mars avec l’équipe. Il nous aura fallu près de trois mois pour passer de l’idée d’une amélioration à sa réalisation. Pourtant, il s’agissait d’une étape majeure dans l’amélioration visant à se rapprocher du flux tiré et permettant de passer de trois équipes spécialisées à une équipe plus intégrée. C’est évidement long, mais c’était le bon rythme à ce moment là du projet. Il y a eu quatre remaniements majeurs du système Kanban. Ces remaniements traduisaient le début d’un nouveau cycle d’amélioration. Chaque cycle durait entre trois et quatre mois.
Il faut avancer au rythme des individus, de l’équipe et de l’organisation qui l’encadre.
Chaque cycle apporte de la valeur en améliorant à la fois le système et l’équipe. Le temps pour parcourir un cycle représente la capacité propre à l’équipe d’assimiler le changement. Le management et le coach doivent accepter cela. 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. Là encore, une mise en contexte est à faire. Le Kanban permet une approche Kaizen facilitant l’adoption de l’agilité et l’innovation disruptive de Scrum permet de relancer l’intérêt, la dynamique de changement rapidement dans une équipe ou une organisation.

Vous pouvez également écouter la version audio de ce podcast L’agilité, même pas mal ci dessous ou sur iTunes