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

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

  Pour finir et assurer la bonne fin de projet sur les derniers mois, des pratiques Lean ont été utilisées pour résoudre des problèmes de qualité. Ils se traduisent par un nombre grandissant d’anomalies. Les problèmes sont principalement dus à la dette technique du code source que l’on migre. Le remaniement de code de l’équipe ne suffit pas à effacer complètement la dette existante. Alors naturellement, elle s’accumule dans le code migré. On change d’indicateurs sur notre management visuel pour traduire ce nouveau focus. L’équipe est réellement autonome et trouve l’essentiel de ses solutions face aux problèmes qui émergent.

Épilogue

Le projet a été réalisé dans les temps et le budget en respectant tous les engagements contractuels, ainsi que (presque) tous les jalons intermédiaires. Il a été mis en production début 2012 sans réserve. « Arriver à ce niveau d’excellence pour des projets de cette taille et de cette complexité est suffisamment rare pour le noter » communiquera la direction de projet à la fin du projet. Au-delà de cet aspect projet, c’est un succès pour toutes les parties prenantes. Le client le confirme et félicite toute l’équipe. Ce projet a reçu les honneurs en étant élu meilleur projet « Delivery ouest 2011 » côté intégrateur.   Nous avons toujours fait passer la réussite du projet et de l’équipe avant toute considération méthodologique. Pour l’intégrateur, le projet serait une vitrine Kanban? Surtout pas. D’ailleurs, c’est quoi le Kanban ? L’approche est pragmatique et réellement empirique. Le management de projet challengeait certains choix. Normal et plutôt sain. Pour l’équipe, pas de formation, pas de blabla. Des Scrum masters? Non. Plutôt des chefs d’équipe. Il n’y a pas eu de communication officielle ni de formation pour aligner tout le monde sur la méthode. C’est peut-être une erreur mais nous n’en avons pas ressenti réellement le besoin. Une formation aurait-elle pu accélérer l’évolution ? Sûrement. Mais à l’époque, la question ne se posait pas. Il n’y avait pas de formation encore sur Kanban ou de manière très anecdotique. Elle aurait permis de montrer la cohérence de l’ensemble de l’approche, diminuer les interrogations. Mais elle aurait pu également mettre le focus sur le suivi d’un plan plutôt que se focaliser sur une approche terrain qui a fait le succès du projet. La formation a du sens pour l’agent du changement, le concepteur du système, celui qui porte cette vision méthodologique et processus. C’était un de mes rôles dans le projet.   Un bon contexte pour Scrum ? Sûrement pas, mais un contexte pour l’agilité évidente, celle d’une équipe qui s’adapte, qui s’améliore, se challenge et avance en apprenant ; une équipe qui ajuste son processus et fait évoluer sa cible et son code. L’agilité, c’est aussi développer cet état d’esprit d’approche itérative, de voir et de monter les marches les unes après les autres plutôt que d’échouer au pied de la montagne. Scrum ne suffit pas toujours pour les projets. Et pour une transformation plus profonde, un changement de culture et de mentalité sont nécessaires.Il n’y a pas eu de formation aux méthodes agiles pour l’équipe, mais une formation au Test Driven Development. Du TDD pour une migration ? Pas vraiment adapté ! L’objectif était plus de donner une culture des tests unitaires à l’équipe. Pour cela, la formation a été réalisée au format Coding Dojo pendant deux jours. L’idée : construire l’équipe autour du code. Important, capital vu la difficulté de l’exercice. Mon objectif secret était que le Coding Dojo devienne une pratique récurrente de l’équipe et le binômage un réflexe. Si la formation a été appréciée, la pratique ne prendra réellement que quelques mois plus tard. D’abord au sein de l’équipe une fois par semaine, puis ouverte aux développeurs en interne. C’est un succès qui a été dépassé, car le Coding Dojo a, par la suite, été ouvert aux développeurs ne faisant pas partie de la société. C’est également cela qui créé une culture agile d’ouverture et de partage. Plus qu’une transition agile, nous avons mis en place une dynamique d’évolution qui a finalement conduit à chaque fois plus d’agilité. Une évolution pas à pas. Et cela ne se traduit pas seulement par des pratiques mais aussi par des changements d’état d’esprit : des blocages qui se lèvent, des échanges plus fluides et une réflexion plus globale, plus systémique par l’ensemble des acteurs.   Au cours de la phase industrielle, certains équipiers m’ont fait le retour que l’on ne faisait pas d’agilité sur le projet et m’ont challengé sur mon rôle de coach agile… Bonne nouvelle pour moi ! Excellente même (même si c’est plus facile à écrire aujourd’hui qu’à entendre sur le moment…). Car d’abord ni l’agilité ni le Kanban n’étaient une fin en soi ou un objectif projet. Mais surtout, c’était le signal que la stratégie « petit pas », l’approche kaizen, était payante. En réalité, le degré d’agilité sur le projet était important compte tenu de la complexité du projet. A titre d’exemple, je vais évoquer les limites du travail en cours, car c’est un élément différenciant du Kanban : Kanban met une limite explicite sur le travail en cours pour chaque activité. Scrum met une limite indirecte via la vélocité sur l’activité de réalisation. Sur ce projet, il n’y avait pas de limite explicite. En théorie, nous n’étions pas dans les standards du Kanban puisque la seconde pratique de la méthode (Limiter le travail en cours) ni la quatrième (Rendre explicites les règles de gestion du processus) n’étaient pas complètement suivies. Mais les limites étaient bien présentes et ont largement évolué au cours du projet. Nous avons commencé d’abord par deux étiquettes de nom par personne, sans parler de limite, simplement pour savoir qui travaillait sur quoi. Puis à l’occasion d’un premier remaniement du tableau kanban, j’en ai profité pour ne laisser physiquement de la place que pour une tâche en cours par personne sans autre contrainte et sans l’expliquer. Résultat, les tâches dépassaient régulièrement de la colonne « En cours ». Au fur et à mesure, cette contrainte a amené naturellement les personnes à finir les tâches ou à binômer. A l’occasion du second remaniement du tableau pour passer à trois couloirs, je suis passé à une étiquette de nom 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 passés de manière durable (j’ai pu le constater jusqu’à la fin du projet) sur une limite d’une tâche par personne et à une limite physique par couloir ; et surtout, une équipe qui se focalise d’elle-même sur les tâches à finir avant d’en commencer d’autres. En fait, nous avons suivi les pratiques du kanban, sauf que les règles étaient explicitées d’une manière physique et visuelle. C’est un exemple simple mais significatif d’une transition silencieuse. Les comportements qui émergent de l’équipe, sans frein individuel, sans opposant au changement malgré une équipe importante, sont autant de signaux forts de cette rupture douce :

Une évolution, pas une révolution

C’est un mantra de la communauté Kanban. Nous avons constaté effectivement cette évolution tout au long du projet. Elle se matérialisait par la refonte régulière du management visuel. Quatre remaniements majeurs en douze mois pour prendre en compte les changements de l’équipe, sa manière de travailler et ses ajustements au quotidien. Chaque refonte du tableau a été l’occasion de relancer la dynamique d’amélioration de l’équipe. Le support de cette transformation : le management visuel. Au-delà du tableau de tâches et de l’outil indispensable d’auto organisation de l’équipe, c’est la concrétisation de cette évolution.

---

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