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

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 ! » sans illustration mais avec une version podcast audio (à la fin du post). 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 cette transition en douceur.

---

Je vais vous raconter l’histoire d’une transition agile évolutive pour un projet ambitieux. Avec cette histoire, j’évoque le Kanban, une méthode d’amélioration des processus pour aller vers du flux tiré, et les serious games. Si le premier a permis une approche évolutive pour aller vers plus d’agilité, la seconde a créé un point d’inflexion du management de projet permettant d’aller plus loin dans la démarche. C’est une histoire vécue sur un projet significatif et si je vous la livre aujourd’hui, c’est que je pense qu’elle apporte une pierre à l’édifice des douces ruptures par son côté transition silencieuse.   Il existe des contextes où l’on pense que l’agilité n’a définitivement pas sa place. Des contextes où notre mission de coach agile va être particulièrement mise à rude épreuve. Cela était le cas pour moi en 2010.  

Imaginez plutôt !

Un projet de migration outillée et de re-documentation de 8000 j.h sur dix-huit mois, dont douze en mode industriel, et plus de 500 k lignes de code à migrer. Si l’application, en production depuis plus de dix ans, continue à évoluer avec une autre société, évolutions à intégrer au cours du projet, la migration est, elle, purement technique. Donc pas besoin de Product Owner, ni de user story ou de feedback utilisateur. L’équipe va compter, au plus fort du projet, jusqu’à trente huit personnes réparties en quatre équipes fortement spécialisées : outillage, analystes concepteurs, développeurs, homologation. Une partie de l’équipe de développeurs sera distribuée en Inde. Les parties prenantes de ce projet sont : le client, un intégrateur qui porte le projet et le contrat, un outilleur qui automatise la migration. Bien sûr, c’est un projet en forte visibilité et avec de forts enjeux pour toutes les parties prenantes : la première tentative de refonte avec un autre fournisseur a été arrêtée au bout de trois mois. Un échec et un premier traumatisme à effacer côté client. Alors évidemment, ce projet ne pouvait être contractualisé qu’au forfait, sans droit à l’erreur, et vendu avec une démarche de refonte en cycle en V. La partie outillage n’est vue au départ que comme un bonus pour le projet. Dans le contrat, des cibles de performance, de conception et de qualimétrie sont non négociables et seront suivies par des audits externes ou benchmarks.  

Sexy, n’est-ce pas?

Et pourtant, l’équipe et l’organisation ont été spécialement à la hauteur de ce projet ambitieux. Et vous, vous signez pour cette aventure?   Challenge relevé donc. Il n’y a pas à l’époque de culture agile ni côté client, ni côté fournisseurs. Il y a bien quelques projets pilotes agiles dans ces organisations mais pas avec les acteurs en présence. L’intégrateur et l’outilleur n’ont jamais travaillé ensemble. L’intégrateur me missionne pour accompagner ce projet en tant que coach agile et expert technique expérimenté dans le domaine des migrations outillées.   En fait, il n’en était pas réellement question au démarrage. C’est pourquoi il n’y a pas eu de formation sur la méthode. Dans ce type de projet, il y a beaucoup d’inconnues sur le processus et la cible technique. Beaucoup de choses sont à mettre en place et tout ne se fait pas en un jour. Plutôt que de passer des semaines à préparer l’environnement et à lancer le projet, plus que de l’agilité, une approche itérative a été choisie pour avancer et mieux gérer les risques du projet. Et dans cette optique, des rétrospectives régulières sont au programme. Un second objectif, plus lié à une approche par lotissement, est de minimiser l’impact économique et les perturbations liés au report des évolutions de l’application socle. De mon côté, j’avais pu expérimenter une démarche Kanban, plutôt un développement en flux, lors de mes expériences passées sur des projets similaires. Sans chercher à imposer cette démarche, j’aborde ce projet avec cette cible en tête, qui ne me quittera pas. Pour commencer, oublier Scrum by the book, il faut retrousser ses manches et revenir à l’essentiel : des valeurs, des principes, des pratiques, du pragmatisme et … de la patience. Une rupture douce pour une transition silencieuse avec en face de nous une montagne à gravir. Mais pour l’heure, nous devons d’abord établir le camp de base de cette ascension.   Le projet commence doucement par un prototype avec deux développeurs juniors. Mon premier objectif est de sortir les premiers écrans migrés, coûte que coûte. Dès le premier jour, du code et du concret. Surtout ne pas procrastiner devant l’ampleur de la tâche. Avancer à la fois sur la migration en tant que telle, manuellement, pour identifier les premières règles de transformations, les premiers patterns de conception et alimenter l’équipe outillage. Nous ne cherchons pas les règles idéales de la migration, mais celles dont nous avons besoin maintenant pour démarrer. La première idée fut de s’attaquer à un module simple, pour se faire la main. Changement d’orientation, nous optons pour le cœur de l’application pour faire remonter au plus vite les problèmes structurants que nous allons devoir résoudre. C’est une priorisation par les risques et la valeur pour connaître les vrais problèmes, pas les problèmes de surface. Nous abordons l’ascension par la face Nord. Cette approche a un coût. Le prototype n’est pas jetable. Chaque ligne écrite ira en production. Si les premières lignes ne passent pas tous les critères du contrat, alors nous devrons repasser dessus plus tard. A plusieurs reprises même. Mais nous avançons. L’équipe est rapidement constituée de vingt et une personnes. La montée en charge est raide et le démarrage difficile. Il est impératif que l’équipe monte en autonomie rapidement. Le management visuel associé aux points quotidiens pour l’organisation et le binômage pour la technique sont nos deux leviers principaux. Le premier tableau Kanban est simple, minimaliste et conçu pour que l’équipe se l’approprie au plus vite et devienne son outil principal d’organisation. Pour notre approche itérative, nous devons avoir quelque chose à montrer et à livrer vite. Une démo ? Non, plutôt un premier jalon pour donner de la confiance, créer un lien rapide entre l’équipe et le client. Pour rassurer et se rassurer. Car ce n’est pas vraiment le cas du côté fournisseur. À ce moment là, le moral de la direction de projet est bas et dans le brouillard avec un pilotage à l’aveugle. En arrivant, j’ai bouleversé un peu les plans en mettant de côté la démarche cycle en V et en changeant la refonte de l’application en une migration outillée. Cela secoue le management et c’est compréhensible. Une bonne partie de mon temps est consacré en explications sur la manière dont j’aborde le projet. Il n’y a pas eu de formation donc naturellement beaucoup de questions se posent. Ces discussions ont une vertu, elles challengent ma vision. Les pratiques sont mises en place, non pas parce qu’il faut faire comme c’est écrit dans la méthode, mais parce qu’elles apportent et ont du sens dans le contexte du projet. Le prototype permet, de manière très pragmatique, de vérifier la faisabilité et de stabiliser la première cible technique et architecturale.

---

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