Agilité et pragmatisme

L’agilité est désormais quasi-incontournable dans le développement digital. Dans les premiers échanges avec un prospect sur son projet, on en arrive inévitablement au moment où il glisse, l’air de rien, « et sinon, vous travaillez en méthode agile ? ».

Tout en sachant que cette question est éliminatoire (quelle agence digne de ce nom oserait répondre par la négative ???), on tempère toujours notre réponse. Oui, bien sûr, chez TPZ on sait travailler en agilité, mais on rappelle aussi ses principes de base et les contraintes inhérentes. Cela peut occasionner quelques surprises :)

Quand j’étais petit - il y a un certain temps déjà - l’agilité consistait principalement à grimper dans les arbres. Idéalement très haut et si possible sans tomber. C’était un concept simple que l’on pouvait appliquer à peu près à n’importe quel arbre. Et sans vouloir me vanter j’étais plutôt bon à l'époque !

Au changement de millénaire, l’agilité est devenue un concept théorisé formalisé par le manifeste de l’agilité. Celui-ci repose sur 4 valeurs fondamentales et 12 principes directeurs. L’idée de base vient en opposition aux méthodes classiques de cycle en V ou en cascade : expression du besoin, analyse, rédaction des spécifications, conception, développement, recette et livraison. Donner un cadre évolutif et inclure toute la chaîne de décision dans le projet est le moteur de l'agilité.

Contrairement à la version sylvestre et primitive de mon enfance, l’agilité moderne peut paraître complexe. Elle nécessite une certaine acculturation pour bien comprendre la philosophie sous-jacente. Il est donc indispensable de s’en imprégner pour mettre en place le cadre méthodologique (scrum par exemple) à bon escient et éviter des effets pervers.

On découpe le projet en US (user story) qui constituent un backlog (la liste des fonctionnalités souhaitées). Un certain nombre de ces éléments sont sélectionnés sur des critères à la fois techniques (estimation de l'effort de développement) et marketing (valeur intrinsèque pour l’utilisateur final / le client final). L'équipe les inclus dans un cycle de développement (un sprint) dont la durée est fixe (idéalement 2 ou 3 semaines, dépendant du projet bien entendu). On va travailler ces sprints de manière itérative et incrémentale, en se donnant la possibilité d’adapter chaque sprint aux complexités rencontrées et à l’évolution des priorités métier.

Ce fonctionnement est accompagné par la mise en place d’un environnement physique et humain dédié au projet :

Dans la réalité, et bien que la théorie soit alléchante, il est rare que toutes les planètes soient alignées pour permettre une méthodologie agile « pure ». Avoir des développeurs ou représentants métiers dédiés et mono-projet se heurte souvent aux impératifs business et à la gestion d’urgences. Un responsable produit va généralement devoir gérer les aléas en production et ainsi se déconnecter temporairement du projet. Un bug sur un site ou une appli en production nécessite une intervention en urgence qui déconnecte là aussi une partie de l’équipe technique et fonctionnelle du projet. Le décloisonnement MOA / MOE est parfois difficile car les vieilles habitudes ont la dent dure. La transparence exacerbée peut également avoir un impact sur le fonctionnement humain de l'organisation.

On assiste aussi à un phénomène de mode de l’agilité qui entraîne des effets pervers. Vouloir mettre en place l’agilité sans en comprendre les valeurs entraîne des résultats contraires à l’objectif : explosion des budgets, incapacité à livrer, désorganisation et ambiance dégradée. Un certain nombre de coaches agiles qui ont flairé la bon plan profitent de l'apparente (et réelle) complexité des méthodes et parfois de la crédulité des managers pour vendre à prix fort un accompagnement stérile.

L’agilité engendre autant de retours positifs que de retours négatifs, certains assez violents. La mise en place biaisée de l’agilité provoquerait l’exploitation des développeurs réduits à traiter des tickets JIRA à la chaîne comme les ouvriers d’une nouvelle forme d’usine. La pression du livrable, l’inconstance du périmètre d’un sprint (censé rester stable pour garantir l’avancée du projet) et la mise en place d’une forme d’urgence permanente (war room) sont autant de dérives qui remontent dans les réseaux sous forme de partage d’expérience (voir en bas de page).

Même si on aime toujours autant grimper aux arbres, on a aussi pris l'habitude de travailler notre agilité dans le quotidien professionnel !

D’un point de vue projet, l’agilité pure implique la maîtrise des moyens mais pas des résultats dans une temporalité certaine. Le contexte d’adaptation permanente ne permet pas de dire avec précision ce qui sera livré et quand. Le cadrage budgétaire devient alors plus complexe, or la plupart du temps on nous demande de chiffrer précisément et de s’engager sur une date de livraison. On en revient alors à une forme de cycle en V antinomique avec l'agilité souhaitée. Pour éviter cela nous proposons généralement deux modes de fonctionnement.

Si la structure de l’entité porteuse le permet, nous intégrons une ou plusieurs ressources (techniques / MOE, gestion de projet / AMOA) dans l’équipe projet. Une consommation mensuelle prédéfinie est mise en place, basée sur une estimation « grosse maille » du projet. Les itérations successives permettront de suivre cette consommation pour maîtriser le budget et adapter celui-ci en fonction des choix du product owner.

Dans le cas contraire, nous adoptons une forme de semi-agilité basée sur un découpage du projet par lot. Ces sortes de sprint prédéfinis permettent un chiffrage et un planning initial du MVP (minimum viable product). Le client final est inclus au plus tôt dans le test de chaque lot afin de pouvoir échanger sur des évolutions potentielles ou remonter des niveaux de complexité inattendus. Lorsque l’on veut revoir le périmètre d’un lot, on peut agir sous forme d'échange (on supprime une fonctionnalité pour en ajouter une nouvelle de charge similaire) ou on passe par une facturation et un délai complémentaire.

Cela provoquera peut-être des réactions épidermiques aux fondamentalistes de l’agilité, mais je suis convaincu que l’important reste l’application des principes du manifeste plutôt que la mise en place de méthodes dans un contexte inadapté. Les mots-clés restent le pragmatisme et l’adaptation à l’environnement.