Nous entendons souvent que le projet serait incompatible avec l’agilité. Et que dans l’agilité il n’y aurait que des produits. Em sommes-nous si sûrs ?
Une définition du projet
Le projet est parfois défini (et souvent enseigné) comme ayant un objectif définitif, une date de début et de fin définies, un planning, un cahier des charges qui se veut exhaustif. Il est composé de phases (par exemple de cadrage, de conception…) et peut s’intégrer dans un programme.
Dans cette acceptation, le projet est prédictif (basé sur la projection du futur), volontairement limité dans le temps, avec une temporalité linéaire (les phases qui se succèdent). La documentation prend souvent une place conséquente. On y distingue la conception et la réalisation. Il y a un temps pour la réflexion et un temps pour l’action.
L’agilité s’est construite en opposition à cette approche.
Une approche produit
Une autre approche, appelée produit, est adaptée à un contexte où l’incertitude est forte (comme le développement de logiciel, par exemple). Elle repose sur un fonctionnement itératif et incrémental.
Dans ces approches adaptatives, on réalise peu, voire pas, de projection du futur. Nous agissons en fonction des informations dont nous disposons actuellement, en réajustant en permanence notre action à la lumière de nos apprentissages et découvertes. Les phases ont disparu. La réflexion et l’action sont menées de front. La temporalité devient circulaire.
Il s’agit là d’un fonctionnement agile.
Le terme produit est utile, notamment lorsque des équipes sont centrées sur leurs fonctionnements internes et ont un peu oublié leurs raisons d’être et leurs utilisateurs.
Raisonner en termes de produit ouvre aussi la possibilité de transformations plus importantes, comme, par exemple, former des équipes pluridisciplinaires constituées autour de produits, plutôt que des équipes spécialisées intervenant successivement sur le produit, comme sur une chaîne de production.
Le projet a-t-il une fin ?
La question peut paraître saugrenue tant elle est dans l’ADN du projet tel que défini précédemment.
Or, dans le développement logiciel, cette date butoir est contre‑productive. Dans un environnement complexe et imprévisible, où les apprentissages sont constants, de quelle fin parlons‑nous ?
Nous pouvons penser que le développement du logiciel aura une fin et qu’après celle‑ci il sera possible de congédier, ou à minima d’alléger, l’équipe, car il ne restera plus que de la maintenance.
Ce raisonnement est valable pour la construction de bâtiments : une fois les travaux terminés, la charge de maintenance est minime. Mais comparaison n’est pas raison.
Dans le développement logiciel, si le produit rencontre un certain succès, le nombre d’utilisateurs, de bugs, de demandes d’évolution, la complexité et la criticité vont s’accroître rapidement, voire de manière exponentielle. La charge de maintenance devient alors bien plus élevée que lors de la « création » du logiciel. C’est le signe même de sa vitalité. À ce propos, le burn‑down chart n’est‑il pas la représentation graphique parfaite d’un logiciel qui échoue ?
Cette fin du développement logiciel n’a donc pas de sens. Ou, plus exactement, la fin d’un logiciel, ce n’est pas lorsqu’il est livré aux utilisateurs : c’est lorsqu’après des années de bons et loyaux services, il meurt de sa belle mort et est retiré de la circulation. À ce titre, nous ferions mieux de comparer le logiciel à un organisme vivant plutôt qu’à un objet matériel.
Si nous voulons maintenir une grande adaptabilité, il faut éviter, autant que possible, de fixer un objectif et une date de fin prédéterminés.
Est-il possible de gérer des dates butoirs dans le développement logiciel ?
Certaines dates butoir sont des contraintes externes à l’organisation, comme, par exemple, une obligation législative entrant en vigueur à une date donnée ou un salon professionnel.
Est‑il possible de gérer de telles dates butoirs avec une approche adaptative, sans estimation ni planning ? Oui, en découpant le plus finement possible fonctionnellement, en priorisant, en livrant souvent et en adaptant le périmètre fonctionnel.
Même s’il est possible de gérer ces dates butoirs externes, il est contre‑productif de piloter notre activité avec des dates butoirs arbitraires, c’est‑à‑dire décidées en interne. Pourquoi ? Parce que cela nuit à notre capacité d’adaptation.
En définissant le projet comme ayant un début et une fin déterminés, un objectif défini, une temporalité linéaire (structurée par des phases), le projet devient incompatible avec l’agilité.
Et d’aucun ne peut affirmer que, dans l’agilité, il n’y a pas de projets, uniquement des produits.
Sauf que…
Le Manifeste Agile pour le développement logiciel n’évoque pas une seule fois le terme produit, mais uniquement celui de projet.
Est‑ce à dire que les auteurs du Manifeste Agile n’avaient rien compris à l’agilité ? Ou bien que le terme projet, tel qu’il est utilisé dans le Manifeste Agile, ne correspond pas à la définition évoquée précédemment ?
Prenons un peu de hauteur
Si un entrepreneur indique qu’il a pour projet d’améliorer sa relation client ou de se mettre en conformité avec le RGPD, il s’agit là d’une envie, d’une intention. Il n’y a ni date de début, ni date de fin, ni planning, ni phase.
C’est finalement un synonyme de la « vision » si chère à la communauté agile.
Et cela correspond à la définition du projet selon le Larousse :
1. But que l’on se propose d’atteindre.
2. Idée de quelque chose à faire, que l’on présente dans ses grandes lignes.
Dans cette acceptation, le projet et l’agilité sont parfaitement compatibles.
Si nous donnons une définition un peu plus restrictive au projet, en nous appuyant sur celle donnée par Wikipédia : « ce que l’on a l’intention de faire, les moyens jugés nécessaires à la mise en œuvre de cette idée, ou un travail préparatoire. »
Alors le projet permet de désigner les acteurs, le processus, les outils, les interactions… tandis que le terme produit oriente la pensée vers le résultat. On peut dire : « Sur ce projet, les échanges sont fluides. », ce qui n’est pas possible d’exprimer avec le terme produit. Nous pensons grâce aux mots ; appauvrir notre lexique, c’est appauvrir notre pensée.
Les termes « projet » et « produit » peuvent tout à fait cohabiter, avec des sens différents. Par exemple : « Sur ce projet, la communication entre les acteurs s’est nettement améliorée, mais l’adoption du produit par les utilisateurs reste faible. »
Sur un projet, il est possible d’accroître la fréquence de livraison, de faire communiquer quotidiennement les développeurs et les utilisateurs, de réaliser des démonstrations, de recueillir les retours utilisateurs… Bref, le projet peut être chaque jour un peu plus agile.
Et si la gestion de projet agile avait finalement tout son sens ?
===
Manifeste pour le développement Agile de logiciels
https://agilemanifesto.org/iso/fr/manifesto.html
Définition de projet, dictionnaire Larousse
https://www.larousse.fr/dictionnaires/francais/projet/64232
Définition de projet de Wikipédia