Comment Kanban a changé ma vie

Le métier de chef de projet n’est pas si simple, vous devez satisfaire votre client en lui livrant une application qui correspond à son besoin, respecter votre budget ainsi que les délais. Le chef de projet a aussi un autre challenge à relever : communiquer auprès de son équipe afin de garder une bonne ambiance générale ! Pas toujours si facile !

J’oubliais le plus important : votre application doit avoir un très haut niveau de qualité sinon vous allez passer la majorité de votre temps à corriger des bugs au lieu de développer de nouvelles fonctionnalités.

On distingue 4 notions autour du mot kanban :

• Un système kanban (avec un k minuscule), système inventé par Taiichi Ohno dans les années 50 au sein des ateliers de Toyota ;
• La méthode de développement logiciel Kanban avec un K majuscule, inventée par David Anderson dans les années 2000 ;
• Un kanban board (souvent appelé kanban), avec un k minuscule ;
• Personal kanban, avec un k minuscule, la méthode inventée par Jim Benson dans les années 2000.

Les objectifs d’un système kanban et la méthode de développement logiciel Kanban restent les mêmes : éliminer le gaspillage par le maintien de la taille des stocks intermédiaires à un niveau raisonnable. Avant de détailler ce que m’a apporté Kanban, regardons les 5 grands principes de cette méthode.

Un système Kanban possède 5 pratiques :

• Visualiser les éléments de travail et le processus ;
• Limiter le travail en cours (WIP : Work In Progress). Chaque activité (spécification, développement ou tests) possède une limite de capacité permettant d’obtenir un flux tiré ;
• Manager le flux afin de s’assurer de la fluidité des activités. Cette fluidité va nous permettre d’améliorer notre prédictibilité de notre système ;
• La mise en place de règles explicites de votre processus ;
• S’améliorer collaborativement, c’est-à-dire que tous les membres du projet sont acteurs dans l’amélioration de leur système Kanban.

Regardons l’impact et la mise en œuvre de ces 5 pratiques à travers un retour d’expérience (Figure 1).

Tout a commencé début juin, j’intervenais dans un projet avec 7 développeurs pour sécuriser la livraison du projet le 31 décembre suite à l’arrivée d’une nouvelle loi réglementaire. Le projet avançait globalement bien, mais l’intégration de nouveaux développeurs dans l’équipe s’était mal passé les mois précédents. Le plan initial prévoyait l’intégration de 10 autres développeurs en août pour construire des mini-sites autonomes, mais tous interconnectés entre eux.

Mon premier travail a consisté à identifier le mode de fonctionnement actuel du projet : le métier rédige des spécifications (plus ou moins simples), ces spécifications sont analysées avec les « LeadDeveloppers », elles sont ensuite priorisées dans la liste des fonctionnalités à développer. Les développeurs présentent les écrans et ajustent les spécifications avec le métier, puis les interfaces et règles de gestion sont codées et livrées pour recette au métier.

Mon premier kanban se dessinait avec les étapes suivantes :

• Spécification ;
• Développement des écrans ;
• Développement des règles de gestion et des interfaces ;
• Recette globale de la fonctionnalité ;
• Prêt pour livrer aux utilisateurs ;
• Une dernière étape lorsque la fonctionnalité est livrée au métier.

Voici sa représentation en figure 2.

Bien sûr, vous vous demandez pourquoi le développement s’est fait en 2 fois, la première fois pour les écrans et la deuxième pour le restant de la fonctionnalité. Je m’étais posé la question, mais il est important d’avancer par petits pas et donc de ne pas remettre en cause ce qu’il se passe actuellement.

À partir du moment où nous avions notre Kanban affiché, l’équipe, le métier et moi avons placé les fonctionnalités sur le Kanban et nous avons tous eu nos premières surprises :

• des fonctionnalités que l’équipe pensait terminée et ne l’étaient pas par le métier ;
• des fonctionnalités que le métier pensait en cours de développement étaient en attente de spécification par l’équipe de développement ;
• etc.

J’étais content, car tous les acteurs du projet partageaient le même état du projet même si je me serai bien passé de certaines surprises !

Le plus important : nous avions passé l’étape 1 de la mise en place de notre Kanban : « Visualiser les éléments de travail et le processus et avoir une vision partagée de l’avancement du projet ».

Durant 3 ou 4 semaines, nous n’avons rien changé, nous utilisions ce Kanban uniquement pour savoir où en était le projet, c’est après cette période que nous avons intégré une nouvelle règle : clarifier les conditions permettant à une fonctionnalité de changer de colonne. Il devait y avoir environ 20 fonctionnalités en attente de recette et l’équipe continuait à développer et pousser de nouvelles fonctionnalités dans la colonne « Test ».  Jusqu’au jour où le métier a commencé à tester ! Le métier a remonté énormément de bugs, pas des plantages, mais des coquilles comme des fautes d’orthographes, des erreurs d’arrondi, des erreurs d’intégrations graphiques, etc.

Toutes ces erreurs ne concernaient pas le fonctionnel, mais la qualité du logiciel, au final le métier a remonté plus de 50 ajustements.

Malgré le fait que tous ces retours étaient justifiés, l’équipe de développement avait deux autres problèmes :

• nos estimations des dates d’arrivée devenaient intenables et ces ajustements remettaient en cause la fluidité de notre organisation ;
• les développeurs « switchaient » entre plusieurs tâches entraînant un agacement palpable au sein de cette équipe.

Après cette « mini-tempête », nous avons mis en place une limite de travail (WIP) par colonne, nous avons tâtonné pour trouver les 4 limites sur les 4 grandes colonnes de notre tableau.

La mise en place des limites de travail en cours sur chaque colonne « Spécification », « Dev écran », « Développement » et « Test » s’est déroulée assez naturellement.

Les limites de Kanban interdisent d’ajouter des actions (tâche ou fonctionnalités) dans une colonne si elle est pleine. Il ne sert à rien d’ajouter des choses à faire tant que les suivantes ne sont pas terminées. Les rôles des intervenants peuvent alors être ponctuellement redistribués pour libérer une colonne.

L’équipe peut être amenée à travailler sur les fonctionnalités en cours de test pour débloquer une situation.

Cette limite d’encours vous permet de basculer d’un flux poussé à un flux tiré. Dans un flux poussé, les développeurs « déversent » leurs fonctionnalités dans la colonne à tester quoi qu’il arrive alors que dans un flux tiré, les développeurs ne pourront développer des fonctionnalités uniquement si le niveau de tâche dans la colonne suivante est en dessous du seuil (WIP).

Ce « mini » changement a aussi un autre effet sur l’équipe projet. Avant la mise en place du WIP, chaque personne ne regardait que sa propre colonne :

• Le métier surveillait la colonne « spécification » et la colonne « test » ;
• Les développeurs étaient concentrés sur les colonnes « dev écran » et « développement ».

Après la mise en place du WIP, tous les acteurs du projet analysaient le Kanban dans sa globalité à la recherche du goulot d'étranglement, mais aussi des solutions à apporter.

Comme chaque colonne possédait maintenant un stock faible de fonctionnalités, je me suis concentré sur les fonctionnalités qui remontaient le Kanban, pas les fonctionnalités qui se déplaçaient de la gauche vers la droite, mais celles qui revenaient dans des colonnes en amont. Le fait d’avoir des fonctionnalités qui remontent le Kanban indique des problèmes/manques sur les règles permettant la transition d’une colonne à une autre. Mon objectif était simple : faire prendre conscience aux acteurs du projet que les règles permettant le passage d’une fonctionnalité d’une colonne à une autre n’étaient pas gravées dans le marbre. Les fonctionnalités remontant le flux étaient donc un excellent prétexte pour identifier ces problèmes. Les listes entre chaque colonne ont continué à évoluer tout au long du projet et l’intégration de nouveaux développeurs sur le projet s’était grandement facilitée.

J’avais gagné bien plus que la possibilité de connaître le véritable avancement du projet ; j’avais une équipe qui connaissait seule l’avancement du projet, les difficultés en cours, les prochaines fonctionnalités qui allaient arriver. Je n’étais plus tout seul à porter le projet, mais toute l’équipe avait un avis, une stratégie et des choix à proposer pour tenir le délai. Cette dynamique a émergé dès les premières semaines de la mise en place du Kanban. Elle a aussi eu un effet très positif par les acteurs du métier, ils arrivaient à savoir si l’équipe était assez « alimentée » en spécification.

Comme vous l’avez vu, la mise en place d’un Kanban n’est pas quelque chose de très compliqué. Personnellement, il m’a permis de trouver d’autres activités sur le rôle de chef de projet : je suis passé du « contremaître » responsable de l’avancement à un rôle de facilitateur d’équipe qui cherche à garantir les conditions propres à la bonne réalisation du projet.

Ma fierté à cette époque n’était pas d’avoir mis en place un Kanban, mais d’être content d’aller travailler, d’aller rejoindre une équipe aussi impliquée et heureuse de travailler sur ce projet, d’avoir un client aussi serein malgré toutes les difficultés que nous avons rencontrées.

Au final, nous avons livré la majorité des fonctionnalités critiques du projet courant novembre et nous avons continué à livrer de nouvelles fonctionnalités courant décembre pour déployer l’application en production avant les fêtes de fin d’année.

Je pense que la réussite de ce projet n’est pas liée à la mise en place du Kanban. Un système Kanban n’est qu’un moyen. La réussite de ce projet est due à la forte collaboration de tous les acteurs du projet, du métier jusqu’au développeur et à l’ambiance positive qui régnait sur le plateau.

L’une des plus grandes difficultés dans la mise en place d’un Kanban est de réussir à instaurer un climat de confiance à tous les acteurs du projet, de leur faire oublier leur côté « Command & Control », accepter que l’intelligence collective soit plus forte qu’un chef de projet, même très expérimenté.

Bien sûr, la chance m’a aidé sur ce projet, la chance d’avoir une équipe sur un grand plateau projet, la chance d’avoir un responsable métier qui m’a fait confiance rapidement.

Si vous souhaitez assimiler rapidement les grands principes du Kanban, il existe un jeu de plateau « GetKanban » permettant de simuler le développement d’un logiciel.  Ce jeu est disponible gratuitement en version 2 à l’adresse suivante : http://GetKanban.com. Je co-anime ce jeu depuis plus d’un an et je ne peux que vous conseiller de le découvrir. J’essaie d’animer une session tous les 2 mois dans le cadre de formations ou de soirées découvertes du Kanban (Figure 3).

Vous allez peut-être vouloir utiliser un logiciel pour gérer vos tâches dans votre Kanban. Il existe une multitude d’offres répondant à ce besoin. Attention, certaines applications ne vous offrent pas la possibilité de gérer votre limite de tâches en cours (WIP) cela sera à vous de vous limiter.

Personnellement, j’utilise Trello depuis quelque temps : http://www.trello.com

Trello m’offre plusieurs fonctionnalités intéressantes ; je peux créer autant de Kanban que je le souhaite, ce qui me permet d’avoir un Kanban pour mes différentes activités. Trello vous autorise le partage d’un Kanban avec d’autres utilisateurs, vous pouvez facilement travailler à plusieurs sur le même Kanban pour partager l’avancement d’une activité. Dernier point, Trello a développé des applications sur iPhone et Android.

J’espère vous avoir donné envie d’essayer de mettre en place un système Kanban dans votre projet et j’espère pouvoir échanger avec vous très prochainement sur les difficultés et succès que vous avez rencontrés.