L'agilité distordue

La méthodologie Agile, à travers ses différents frameworks (XP, scrum, kanban …), est porteuse de nombreuses promesses.

Les individus et leurs interactions, de préférence aux processus et aux outils

Des solutions opérationnelles, de préférence à une documentation exhaustive

La collaboration avec les clients, de préférence aux négociations contractuelles

La réponse au changement, de préférence au respect d’un plan

La grande force de l’agilité réside dans la livraison incrémentale de fonctionnalité dont le retour client va permettre l’ajustement au fur et à mesure du développement. En passant ainsi d’un effet tunnel type waterfall à une livraison continue, le client co-construit la solution finale. Excellent moyen, donc, d’assurer une satisfaction d’un produit dont nous sommes partiellement lauréat de son achèvement.

La méthode Waterfall

Avant l’agilité, la méthode Waterfall était la plus répandue dans la gestion de projet. Méthode simple à comprendre, elle consiste à mettre une emphase sur la phase préparatoire afin que la réalisation qui s’ensuit n’ait qu’à suivre un chemin si balisé que l’exécution et le résultat ne dévient que peu du plan.

Un exemple de conduite de projet waterfall pourrait être la construction d’une voiture comme suit: on prend le besoin du conducteur, on designe l’ensemble des plans pour la voiture de rêve du conducteur puis on envoie la voiture en production à l’usine. Une fois la voiture produite, on la teste pour s’assurer de son bon fonctionnement et on la livre au client. Enfin, on se chargera de maintenir la voiture durant toute sa durée de vie chez le client.

La méthode Waterfall présente aussi certaines contraintes:

• la phase de préparation étant conséquente, l’accueil du changement en cours de route s’en voit restreint, sans incidence minime.
• le risque de non-alignement des besoins. Le recueil du besoin n’étant effectué qu’en début de projet, son développement est en tunnel, coutant cher et d’autant plus si le résultat atteint manque le besoin.

Avec notre exemple de voiture, voici ce qui pourrait rater:

• les plans réalisés ne reflètent pas une réalité technique réalisable en usine.
• les cycles de tests montrent des défaillances techniques ou de design qui nécessite le renvoi dans des étapes précédentes.
• le client voulait une citadine et pas un SUV.

L’alternative agile

L’agilité, au contraire, intègre le besoin client tout au long du développement du projet. La phase initiale d’expression du besoin est plus courte. Les livrables arrivent aussi plus rapidement, à peine fonctionels et gagnent en consistance au fur et à mesure des livraisons. L’intérêt réside dans la prise de retour des clients et de leur besoin afin d’ajuster au fur et à mesure. Cela permet ainsi d’optimiser toute la production en ne fournissant à chaque fois exactement que ce qui est attendu.

Le client souhaite une voiture. Le besoin est pris et synthétisé, les équipes commencent à réfléchir au design. Les premières ébauches sont présentées au client qui précise ses attentes. La carcasse est envoyé à l’assemblage et le client valide la structure. Le moteur est ajouté mais à l’inspection, le client souhaite un moteur plus modeste: le moteur est changé. A terme, le client obtient une voiture complétement assemblée et fonctionnelle.

Les limites

Cependant, cette promesse papier est soumise à la réalité du marché et du business. Si les livraisons sont devenues régulières, c’est aussi parce que le financement des projets s’est échelonné, sous réserve de preuve de satisfaction.

De nombreuses entreprises distribuent des budgets périodiques à leurs projets/département. Leur montant se base sur des résultats précédents, à venir ou attendus. Cela permet aussi de rectifier ces budgets et de ne pas avoir à immobiliser de grosses sommes d’argent (parfois) inutilement.

Et dès lors, cette condition de la satisfaction se transforme en quête de l’approbation. Et c’est ici que le glissement peut s’opérer. Nous sortons du rationnel, et de la proposition de mener le projet à terme dans le bon ordre, pour se concentrer sur le “waow”. Si le stakeholder voit des choses qui lui plaisent, il valide. Peu importe si cela ne fait aucun sens dans la production du projet, ou pire, peu importe si cela ralentit/perturbe son bon déroulement. Et comme le stakeholder est souvent impliqué, de près ou de loin, dans le budget du projet, il est vital qu’il propage un avis positif.

Les postes de ceux qui distribuent les budgets sont aussi éjectables l’un que l’autre. La crédibilité et la longévité reposent donc à miser sur les bons chevaux.

Et l’agilité s’en retrouve ainsi tordue. La porte est grande ouverte pour que le chef du projet se rapproche du PO avec une nouvelle idée qui va impressionner les stakeholders. La vision même du projet s’en trouverait compromises ? Peu importe, maintenant que le chef de projet sait que l’agilité accueille “volontier” le changement. Et difficile ensuite pour le PO de revenir à la charge avec des arguments rationnels car il faut rappeler d’une deuxième realité, le chef de projet a, très souvent, l’ascendant hiérarchique dessus.

Qui n’a jamais entendu au daily son PO annoncer une “NOUVELLE REGLE !” ?

Tous les milieux ne fonctionnent pas comme cela et les cas où la gouvernance joue cavalier seul ne sont pas généralité. Mais plus il y a de la place pour la politique en entreprise, plus l’agilité devient une arme dans cette guerre de pouvoir.