En matière de gestion de projets, tout le monde n’a qu’un mot à la bouche : Agilité. Les clients veulent tous travailler « en mode Agile » mais peu savent vraiment ce qu’il en est. L'agence Gaya nous explique comment gérer ces clients qui veulent de l'agilité sans les risques ni les contraintes.
La réunion de lancement se déroulait comme d’habitude : on faisait connaissance avec le client, on passait en revue la réponse de votre agence, on discutait un peu planning, bref, du classique. Votre cerveau de chef de projet était en pilote automatique. Et voilà que le sujet Agile est posé sur la table. Un fol espoir vous saisit : un client qui veut travailler en mode Agile, sérieusement ? Vous avez d’un coup pour lui les yeux de Chimène.
Mais c’est alors que cet audacieux demande à revoir les lignes budgétaires et à se faire confirmer que la date-de-dans-6-mois est toujours tenable pour la livraison de son site. Aouch. Votre DG, vous connaissant bien, effectue une discrète pantomime pour vous déconseiller silencieusement d’exprimer le fond de votre pensée. Et il a raison. Parce que le client :
- Doit être rassuré sur votre compétence
- N’a pas envie d’entendre que son approche ne peut pas fonctionner
- N’a sans doute aucune idée de ce qu’implique la méthode Agile
L’erreur de ce client, qui n’est pas un cas isolé, est dangereuse pour le projet. Comme 100% des clients acquis via un appel d'offres, il a émis un cahier des charges auquel vous avez répondu. Y était noté l'ensemble des fonctionnalités que le site devait intégrer ainsi qu'une date de livraison. Vous y avez répondu avec un budget et un planning. Typiquement, c’est un projet qui va se baser sur un périmètre fonctionnel, un cadre budgétaire fixe et une date butoir.
Plus loin de l’Agilité, tu meurs.
Soit on est Agile, soit on ne l'est pas
En gros, on liste les besoins, on les priorise et on les traite par des cycles de développements (des sprints). L'objectif étant que chaque sprint fournisse un livrable fonctionnel. Tant qu'on a du budget pour couvrir le travail, on avance. On peut mal estimer un sprint, on peut avoir du retard ou de l'avance : le but est de s'en rendre compte assez vite pour ajuster.
D’où, l’Agilité.
Évidemment, si vous annoncez à un client que son budget va servir à acheter des ressources sans garantie quant au périmètre fonctionnel final ou aux délais, celui-ci va avoir un peu de mal à déglutir (et à justifier cela auprès du Service des Achats ou de sa tutelle budgétaire).
Alors pourquoi veut-il de l’Agilité ? Parce qu’il a sans doute dû en entendre parler, succinctement, et n’a dû en retenir qu’un aspect : la capacité à s’adapter en cas d'obstacles. Et pour lui, c'est du pain béni. Quand votre client veut de l’Agilité, comprenez malheureusement parfois qu'il se réserve le droit de changer d'avis, quand ça lui chante… parce qu’on est agile ou bien ?
Fuyez.
Agile ou pas, la communication est la clé du succès
L’Agilité n'est-elle donc pas possible dans un projet Web ? Si, bien sûr, mais il faut s’entendre sur ce qu’est l’Agilité. Ce n’est pas un open bar sur le budget. Pour qu'un projet Agile fonctionne, il faut communiquer. Il faut intégrer le client dans vos équipes, qu'il soit tenu informé de votre travail, des pistes que vous explorez, de vos contraintes. Il faut qu'il comprenne ce que vous faites. C'est grâce à cette participation qu'il pourra soutenir vos choix, que le projet avancera sereinement et que les livrables seront utiles aux utilisateurs.
Il est certes toujours possible de mettre en place des outils dérivés de l’Agilité, pour fluidifier la production. En soi, faire des sprints, impliquer le client, etc., tout cela est grandement recommandé. Et vous aidera à livrer votre projet à temps et dans des coûts maîtrisés. Mais soyons clairs, tant que budget, périmètre et planning seront définis avant de commencer à travailler, vous ne pourrez pas faire d'Agile. Pire : maintenir le client dans cette illusion se retournera contre vous. Expliquez-lui, soyez pédagogue : la bonne marche du projet et votre relation commerciale avec lui en dépendent.
Et puis ce n’est pas si grave, vous ferez de l'Agilité avec le prochain.
Article intéressant dans l'ensemble, qui permet de sensibiliser aux dangers de l'effet buzzword autour de l'Agilité.
Je note néanmoins deux points pouvant être améliorés.
L'Agilité ne se résume pas à Scrum, ce que l'article suggère pourtant dans sa seconde partie.
Enfin, une équipe peut être agile, mais pas "faire de l'Agile", ni "faire de l'Agilité".
Ces expressions font typiquement partie du registre employé par ceux qui ignorent ce qu'est l'Agilité - ce qui ne me semble pas être votre cas.