L’agile au forfait : est-ce vraiment compatible ?

Leikir web propose 2 mode de fonctionnement (cycle en V ou Agile) et donc la facturation qui va avec à ses clients : le forfait et le réel.
Dans le monde du développement il existe globalement 2 grands types de méthodes pour réaliser un projet : cycle en V ou Agile. La facturation en fonction de ces deux méthodes est opposée. De plus en plus les méthodes Agiles sont décriées car combinées à une facturation au forfait, elle est mal appliquée et génère plus de contraintes que de satisfaction. Mais pourquoi ça ne fonctionne pas au juste ?

Un bref rappel…

Le cycle en V c’est la méthode de gestion de projet classique : un cahier des charges, des coûts prévus et des délais fixes.
Le prestataire s’engage à livrer toutes les fonctionnalités spécifiées dans le temps imparti. Le cycle en V est donc un modèle inflexible.

En méthode Agile, on parle “incrémentale” c’est-à-dire que l’implémentation se fait en cycles itératifs courts. Méthode “User centric”, des modifications sont possibles en cours de développement en fonction des retours utilisateurs que l’on récolte. On construit donc le produit au fur et à mesure en fonction du feedback.

Quel rapport avec la facturation ?

Au forfait, le client établit son cahier des charges, le prestataire s’en sert pour faire son estimation. Ainsi, il établit le plan de release et la somme totale que le client doit engager pour l’ensemble du projet. Le client a peu de risques, ils portent sur le prestataire. Il a donc la « garantie » que le projet sera livré en temps et au prix initial.

Un fonctionnement au forfait nécessite d’établir une estimation précise et ce faisant un périmètre fonctionnel précis. Or bien souvent, il n’est pas aisé d’avoir des spécifications complètes notamment dans un cadre d’innovation ou parce que le produit n’a pas encore été confronté au marché. Par conséquent, ce mode de fonctionnement peut générer de la frustration car en cas de modification du périmètre fonctionnel cela donnera lieu à un nouvel engagement contractuel.

A la régie, le prestataire ne gère pas la partie financière, il peut se concentrer pleinement sur la performance et la qualité du code. Le client doit de son côté être plus investi sur la production de valeur ajoutée en fonction de son budget à allouer par fonctionnalités. Cette méthode lui demande certes, plus d’investissement, mais il offre surtout plus de souplesse en cours d’implémentation pour corriger le tir si des choses ne lui conviennent plus.
On notera que la relation de confiance entre les équipes de développeurs et le client doit être forte, puisqu’on paie aux heures réalisées.

On comprend donc que par essence c’est compliqué de faire de la gestion de projet Agile au Forfait, puisque les deux modèles sont complètement opposés.

Dans cette situation tout le monde ressent de la frustration et se retrouve dans des positions délicates. L’équipe de développement a le sentiment de travailler en étant pressé par les délais et les finances pour assurer son bénéfice. Le client se disant en Agile veut quand même pouvoir modifier comme il le souhaite son produit, mais comme on a déjà fait une estimation en principe ce n’est pas possible. Bref, vous voyez les contradictions ce n’est pas le cadre de travail idéal.

Pourtant nombreux sont les clients aujourd’hui qui cherchent à travailler en Agile tout en payant au forfait.
Mais alors, comment faire pour concilier la possibilité de modifier son produit à sa guise tout en ayant au départ prévu un budget fixe sur des spécifications qui… seront amenées à changer tout au long de l’implémentation ? Oui. C’est contradictoire.

Comment rassurer un client réticent au temps passé mais qui veut quand même travailler en Agile ?

Soit on lui explique qu’on ne fera pas d’Agile, mais notre bon vieux cycle en V. D’ailleurs si le projet voulu est de petite envergure et bien spécifié ça marchera bien. On établira un cahier de charges précis et on n’en sortira pas, des modifications sont possibles mais elles devront être minimes.
Il faut savoir qu’au forfait, toutes les agences sont amenées à estimer plutôt à la hausse parce qu’on sait que le projet va évoluer un minimum en cours de route et pour être sûr de ne pas travailler à perte si des embûches ont été mal anticipée. Jusqu’à présent personne ne peut estimer parfaitement les éventuelles embûches, sinon je veux bien connaître votre recette secrète.

Si malgré ça le client insiste pour faire de l’Agile au forfait alors on peut tenter le compromis. Il existe des alternatives au temps réel sans pour autant faire de forfait.

Comment ?

On part sur une enveloppe fixe et on priorise à fond. En gros, on fait un MVP (Minimum Viable Product) et on va chercher de la valeur. On ne garde que les fonctionnalités essentielles pour le fonctionnement du produit, jusqu’à implémenter les moins importantes en fin de course s’il reste du budget.

En Scrum, sur les premiers sprints on cherche la forte valeur ajoutée des fonctionnalités.
Si on ajoute au backlog une user story on en retire une d’une complexité identique et ainsi de suite. Chaque sprint doit aboutir à une version plus avancée et fonctionnelle. Le travail de priorisation par le client est la clé de la réussite.

Pour la facturation, le client paie au sprint, ou à la release en fonction de ce qui est défini dans votre contrat et de votre maturité vis-à-vis de celui-ci.
Il peut stopper à tout moment en fin de sprint si les ressources engagées par le prestataire sont insuffisantes et ne respectent pas les modalités du contrat (pas assez de valeur, non respect des objectifs de sprint etc.).
Si le projet se termine avant alors le client ne paie qu’une partie du montant restant du contrat initial, ainsi les deux parties sont gagnantes.

Que l’on choisisse une facturation au temps passé ou un contrat hybride, en agile il est essentiel de définir une équipe de développement fixe ainsi que des indicateurs précis pour le suivi (backlog, vélocité etc.). L’équipe produit et le client doivent tous les deux être fortement engagés, travailler en étroite collaboration, être réactifs et communiquer. C’est une relation de confiance et de transparence qui doit s’établir pour assurer le bon déroulement du projet.

Quoi qu’il en soit, si le prestataire et le client sont conciliants, qu’ils comprennent les enjeux des deux parties, en collaborant en bonne intelligence il est tout à fait possible de produire de la valeur dans un cadre de travail agréable pour tous. Quelles solutions avez-vous mise de place de votre côté ?

—

User centric : Logique produit axée sur besoin utilisateur en opposition à la logique projet axée sur le projet
Scrum : Méthode agile itérative qui repose sur une organisation en sprints pour livrer régulièrement et de manière prédictible des incréments de produits.
Release : Une version composée de plusieurs fonctionnalités souvent implémentées sur plusieurs sprints.
MVP : Méthodologie de priorisation basée sur la valeur qu’une fonctionnalité peut produire à l’utilisateur du produit.
Sprint : dans Scrum, un sprint est une période d’une durée de 1 à 4 semaines pendant laquelle l’équipe de réalisation (product owner, scrum master, développeurs, UX/UI) réalise toutes les tâches nécessaires pour fournir l’incrément de produit sur lequel elle s’était engagée. Les sprints se succèdent pendant tout le cycle de vie du produit.
User story : Élément de travail décrivant avec suffisamment de précision le contenu d’une fonctionnalité à implémenter. Elle est rédigée selon les 3W : En tant que (who ? utilisateur), je veux (what ? objectif), afin de (why ? raison);