Au risque de me faire encore conspuer par nos camarades agilistes militants, je vais vous raconter comment j’ai contribué à la sortie d’un des projets auxquels je participe du mode Agile/Lean. Car oui, je l’avoue, j’ai fait du lobbying pour le retour du cycle en V…

Tout commence par un projet de migration Cognos vers SQL Server, avec une petite équipe de développeurs experts et un client qui fait confiance. Aucun frein à la productivité, les résultats sont immédiats et visibles à travers les premiers états livrés après seulement quelques semaines de travail. Point de vue gestion de projet, l’équipe fonctionne alors en mode cowboy, juste quelques todo lists priorisées, une réunion de suivi hebdomadaire, et tout le monde est bien content.

Les choses s’accélèrent, la migration avance à bon rythme, et le succès rencontré par la production des premiers rapports déclenche la demande de nouveaux rapports. Le client trouve sa place en tant qu’évangéliste de la solution, il identifie des utilisateurs potentiels, vend sa solution en interne et génère encore plus de besoins.

On avance de 6 mois, et… la migration n’est toujours pas terminée. En effet la recette des rapports est décalée en permanence car chaque revue déclenche une flopée d’évolutions. Les nouvelles demandes s’entassent et parfois même disparaissent puisqu’elles ne sont pas suivie d’une manière centralisée (pas de réel backlog) et que la priorité est attribuée aux derniers utilisateurs venus se plaindre dans l’open-space. Il n’y a ni planning, ni suivi du consommé, ni documentation, et même l’architecture technique commence à en souffrir (effet de bord d’une autre décision qui n’est pas le sujet du jour).

Le problème est identifié et c’est à ce moment-là que je rentre en scène. Ma mission est évidemment de remettre de l’ordre dans tout ça. Je reprends donc la longue liste des demandes, je clarifie les items, génère un backlog unique et accroche au mur un beau Kanban tout neuf.

 

Pourquoi un Kanban ?

• L’équipe fonctionne en livraison continue, sans itération, point positif à conserver
• On lui reproche un manque de visibilité sur son activité en cours, il faut y remédier
• Les priorités changent tous les 2 jours, il faut pouvoir s’adapter
• L’équipe travaille sur trop de sujets à la fois, il faut rationnaliser

On est donc dans le cadre d’application idéal pour cette technique.

Et hasard des réorganisations, c’est justement le moment où un des utilisateurs principaux de la solution, directement en provenance du métier, passe officiellement business owner à temps plein.

S’en suivent 2 mois plutôt positifs, où une fois les process mis en place, le business owner et les utilisateurs constatent une amélioration du delivery en terme de rythme, de réactivité et de visibilité sur l’activité (par ce que oui, un développeur qui ne fait pas de réunion et qui n’envoie pas de mail c’est bien un développeur qui travaille, et pas le contraire). Le reproche éternel de la capacité à s’engager sur des dates est évidemment toujours dans l’air, mais on atteint une visibilité à 3/4 semaines qui à mon sens est la seule période vraiment réaliste.

Et là, c’est le drame…

Devant le regain de productivité de l’équipe, les demandes explosent à nouveau. Les développeurs reçoivent plus de 5 mails par jour des utilisateurs, avec ou sans le business owner en copie. Les règles de gestion évoluent sans cesse, les couleurs dans les rapports aussi, les sources de données changent considérablement, et la mauvaise habitude de donner la priorité au dernier qui a parlé réapparaît. A nouveau l’équipe s’enlise et la satisfaction des utilisateurs sombre.

Pour moi le problème est clair : l’équipe est en sous-capacité. Si nous étions capables de dépiler plus vite les tickets, nous arriverions à retrouver un flux optimal. Mais dans notre cas, même avec l’ajout d’un développeur, la situation persiste. Le delta entre besoin et capacité de production est vraiment trop important. Pas possible d’ajouter plus de ressources, d’un point de vue budget et praticité, nous sommes au maximum.

 

Alors j’ai pratiqué ce que je prêche, et j’ai demandé au business owner, qu’on considérera désormais comme un chef de projet MOA, de commencer à écrire des spécifications fonctionnelles. Chaque demande d’évolution doit mettre à jour la spécification correspondante, chaque nouveau besoin doit être pensé et écrit dans le dur.

Mon objectif est clairement d’introduire une contrainte au niveau métier, pour stabiliser la génération des besoins (le rythme est sincèrement démesuré) et ainsi faire basculer au niveau MOA le goulet d’étranglement du flux.

Car à être trop disponible et réactive, l’équipe de développement était devenue une extension du cerveau du business owner, et de certains utilisateurs trop exigeants. Chacune de leurs pensées à demi digérée était rapidement écrite dans un mail et transmise en priorité 1, trop souvent en totale contradiction avec l’info précédante. J’espère que le fait d’avoir à se poser pour penser et écrire concentrera leurs idées et diminuera les changements d’avis. Le travail de réconciliation et d’harmonisation fonctionnelle doit définitivement être réalisé par le business owner, pardon, le chef de projet MOA.

Evidemment c’est une étape temporaire, une astuce qui donnera également à l’équipe le temps de souffler un peu et traiter les vraies priorités. Je compte bien retourner à nouveau dans un mode plus lean une fois l’orage passé. Et je provoque en parlant du retour du cycle en V, puisqu’on conserve bien la livraison continue et le fonctionnement en mode pull. J’impose juste une contrainte de documentation plus lourde côté utilisateur avant d’accepter les activités dans le backlog.

On en reparle dans quelques mois, pour voir si l’expérience porte ses fruits !

PS : Evidemment toute cette histoire se vit dans un contexte d’entreprise plus global, sur fond de guerre politique entre services, de rachat de sociétés et d’avancement de carrière des internes, qui expliquent beaucoup plus mais que je ne peux évidemment pas raconter ici 😉