Le retour des spécifications dans un projet décisionnel lean

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.

 Dilbert - Méthodes Agiles

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.

 Dilbert - Product Owner vs Développeur

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 😉

4 commentaires sur « Le retour des spécifications dans un projet décisionnel lean »

  1. Je ne vois rien qui puisse pousser un « agiliste » à conspuer 🙂

    Ce billet m’inspire quelques réflexions :
    – Même s’il existe côté dev, le sous-effectif semble être clairement à chercher du côté du représentant des utilisateurs (appelons le business owner, chef de projet MOA ou n’importe quoi d’autre…) qui est débordé
    – Le changement n’a bien évidemment rien à voir avec un cycle en V.
    Il semblerait qu’une colonne ait tout simplement été rajoutée dans le kanban, colonne qui représente un état « suffisamment réfléchi pour être développé » alors que jusqu’alors les développeurs piochaient directement dans la colonne « demandé par les utilisateurs »

    Ceci étant, et là je reprend la casquette de « l’agiliste de base », même si la démarche n’est pas en V, elle n’est pas non plus agile.
    Pour moi, une démarche plus intéressante aurait été de montrer aux utilisateurs le merdier qu’ils étaient en train de générer – par exemple en venant passer une journée auprès de l’équipe de dev – et de leur demander de trouver eux-mêmes une solution à leurs demandes incessantes et pas forcément réfléchies (je sais que c’est plus facile à écrire assis derrière un clavier qu’à mettre en oeuvre)

  2. Je me pose une question essentielle à la lecture de ce post :

    Que faisait le PO???
    Pourquoi acceptait-il d’introduire des besoins incohérents dans le backlog, et surtout pourquoi priorisait-il ces non-besoin ?

    Et même si le PO ne s’en aperçoit pas immédiatement, que faisait les dev??? l’agilité c’est aussi quand tu es développeur pouvoir dire aux utilisateurs, qu’ils vont dans le mur….

    m’enfin bref…. je sais on ne vit pas dans un monde de bisounours….

  3. Oaz: merci pour le retour sur le sous-effectif côté utilisateurs. J’étais trop la tête dans le guidon et j’ai raté l’évidence! On va bosser là dessus pour améliorer la situation.

    Concernant l’intégration des utilisateurs à l’équipe de dév pour montrer ce qui se passe sur le terrain, ça a été fait, et l’effet pédagogique dure au moins… 1 journée. Ensuite c’est retour en mode pompier permanent.

    Fabrice: Tu as beau dire qu’on va dans le mur, tu as toujours des utilisateurs qui ne veulent pas y croire, ou qui ne réalisent pas qu’ils font partie du problème. Comme dans toutes les situations de transfert de connaissance, c’est plus facile de blâmer ces idiots qui ne comprennent pas, plutôt que de prendre conscience de ses mauvaises explications, ou de son propre manque de compréhension du sujet!

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s