Aujourd'hui, presque 20 ans après l’écriture du manifeste agile, 90% des sociétés disent avoir lancé des projets informatiques utilisant les techniques agiles. Les projets agiles sont bâtis sur un paradigme : gérer un périmètre non spécifié au début du projet dans un détail défini et permettre changement et priorisation en cours de projet. Si cette ouverture ravit le métier qui ne sait en général pas tout ce dont il aura finalement besoin, cela semble contraire à l'esprit d'une contractualisation maîtrisée où tout aura été prévu : périmètre précis, délai et charges financières. Comment "faire Agile" si les contrats restent les garde-fous d'une obligation de résultat? Allez c'est parti pour un petit briefe sur les choses qui fâchent, façon "les temps changent"...
Depuis une grosse quinzaine d’années, l’obligation de moyens (sous forme d’assistance technique) a graduellement laissé place à un mode de contractualisation où les acheteurs sont en droit d'attendre de leurs fournisseurs un engagement sur les résultats. Cet engagement est matérialisé par des livrables précis et des SLA. Or, la contractualisation avec "obligation de résultats" est aujourd'hui inadéquate, ou en tout cas incompatible avec une gestion de projet agile dont la méthode, la plus utilisée étant Scrum, permet au produit d'évoluer pendant tout le cycle de construction et où les livrables potentiels ne sont définis qu'à chaque début de "Sprint".
le "Chaos Report"
Posons le problème simplement.
Dans une méthode de gestion traditionnelle, en début de projet, tout est fixé : périmètre, coût et délai. Cette phase initiale est souvent chronophage (et couteuse) pour l’organisation du client. Elle mène à la rédaction d’un cahier des charges le plus complet possible.
Si après tout se passe comme prévu, le fruit des développements est un produit conforme aux exigences et de qualité.
Une spécification technique ou fonctionnelle qui se révèlerait plus difficile à développer que prévu aurait une incidence sur la charge de travail et donc le coût. Comme le client est contractuellement en position de refuser ce "dérapage" (obligation de résultat), la seule variable d'ajustement pour le prestataire de réalisation consiste à rattraper et "aller plus vite" sur le reste à faire. Donc prendre un risque fort sur la qualité.
C'est ainsi que tout d'abord la majeure partie des sociétés rodées aux projets 'au forfait' appliquent dans leurs cotations des coefficients de risques qui gonflent l'évaluation initiale de la charge projet. Il est également fréquent qu'elles 'négocient' avec leur client en cours de route, face aux imprévus techniques ou aux demandes de modification du périmètre projet.
Concrètement, le "Chaos Report 2015" du Standish Group montre que 84% des projets dépassent leurs délais et/ou leur budget. Plus précisément, 53% des projets coûtent finalement 2 fois plus (189% en moyenne) que l'estimation initiale.
Le même document rapporte que 72% des projets intègrent des changements conséquents d'exigences clients au cours du développement, ces derniers font alors l’objet d’avenants contractuels. En bref, l’incertitude et le changement d’avis client gonflent le budget global du projet.
Rien d’étonnant, l’esprit humain est tout simplement incapable de concevoir des estimations anticipées fiables à cause de certains de ses biais cognitifs. Le plus connu est le "planning fallacy" (Daniel Kahneman - 1977) : notre penchant pour la sous-estimation systématique, par optimisme chronique et naïveté quant à prévoir les aléas possibles. Si on mixe ce trait de caractère de l’humanité avec notre tendance à s’inspirer de ce que l’on voit, il est plus que probable que 3 ou 6 mois plus tard, au moment de la livraison, nous aurons (un peu au moins) changé d’avis sur ce que l’on aimerait avoir eu et que de surcroit, notre estimation initiale était fausse dès le départ. Un petit principe de base de physique par dessus tout cela (tout mouvement consomme de l’énergie) et on comprend aisément qu’il est logique que 84% des projets dépassent leur budget initial.
La méthode de projet agile, en revanche, permet le changement d'exigences clients pendant le projet et le périmètre est réactualisé à chaque itération. Les nouvelles exigences sont intégrées dans le "Backlog Produit" qui est re-priorisé à chaque itération. Et ces nouvelles "Features" remplacent celles qui ont une valeur métier moindre. La variable d'ajustement devient donc le périmètre ; les données coût, délai et qualité restant fixes.
Le budget du projet reste complètement sous le contrôle du "Product Owner" et des "Stakeholders" (les parties prenantes: clients et utilisateurs finaux) pour les changements mais également sous celui de la "Dev-Team" pour les estimations et la réalisation.
Que contient le contrat agile ?
Comme tout contrat, le contrat agile est fait d'un corpus juridique et d'annexes qui le complètent et le précisent.
En voici la structure générale :
Le contrat : pose l'esprit de la collaboration agile. Il détaille également les définitions des termes utilisés, liste les documents contractuels utilisés, les acteurs nécessaires au bon fonctionnement du projet, les garanties, obligations, conditions financières, la propriété intellectuelle etc.
Annexe 1 : Méthodologie Scrum (par exemple) : rappel des principes des méthodes agiles et des droits et devoirs de chaque partie ;
Annexe 2 : La vision du client : description de la cible à atteindre et des contraintes particulières du client ;
Annexe 3 : Product backlog V0 : Version de départ qui sert de référence en Story Points. Le product backlog va évidemment varier pendant la durée du contrat, mais le total des Story Points, ne doit pas varier significativement sous peine d'avenant.
Annexe 4 : Estimations initiales, délais et charges du prestataire : Sur la base de la vision du produit (l'Annexe 2 ou le cahier des charges), proposition d'un backlog V0 valorisé en Story Points, de l'équipe proposée et du nombre de sprints pressentis (product release plan). Cette estimation de charge pourra être revue à l'issue d’un Sprint 0 (1) (en obligation de moyens) mais dans une limite définie contractuellement (conditions particulières, annexe 5).
Annexe 5 : Annexe financière : base pour le calcul du Sprint 0 (1) (ex: phase commune de cadrage projet) et le montant forfaitaire fixe pour chaque autre sprint (en SCRUM, la durée d'un sprint est fixe et l'équipe reste stable)
Annexe 6 : Conditions particulières : limites d'ajustement des charges, structure et délais ; site d'exécution ; identification des interlocuteurs clefs du projet (chez le client & le prestataire)...
Annexe 7 : Plan de qualité de service V0 (PQS) - si requis
(1) le concept de sprint 0 ne fait pas partie du framework SCRUM. Il permet de réaliser certaines taches amont et essentielles (définition et affinage du backlog V0, cadrage technique, définition d'un MVP et d'un MMP, etc.) sous un mode contractuel généralement différent de la prestation de réalisation.
Obligation de résultat et projet agile
Dans un contrat établi pour un projet traditionnel, l'obligation de résultat se traduit par la présence de livrables et de services encadrés de SLA (Service Level Agreement). Or en agile on ne connaît pas au moment de contractualiser les livrables produits à chaque itération. Cependant l'équipe (le fournisseur) s'engage bien à chaque début d'itération à livrer un "Potentially Shippable Product" (produit fini) défini avec le "Product Owner". C'est la première obligation de résultat : livrer à chaque itération la majeure partie des produits commandés. Attention, une fonction partiellement réalisée à 99% n'est pas livrée (notion agile du "Done") parce qu'elle n'est pas "Potentially Shippable".
Comme pour les projets en mode traditionnel, le prestataire agile s'engage à réaliser les prestations dans le respect des niveaux de service définis dans le plan qualité de service. Ces niveaux de service sont mesurés grâce aux indicateurs agiles (1) et peuvent donner lieu à l'application de pénalités lorsque la non atteinte du niveau de service est imputable à un manquement évident du prestataire à ses obligations contractuelles.
Considérant son rôle clef, le client a lui aussi des obligations au terme du contrat agile.
La première concerne une participation active à la co-animation du projet avec son partenaire fournisseur.
La seconde consiste à être présent auprès des fournisseurs pour que ces derniers ne perdent pas de temps et à traiter dans un délai imparti toutes les demandes de suppression d'obstacles qui lui seront soumises par le Scrum Master.
La suivante consiste à correctement prioriser le backlog produit à chaque itération.
Enfin la dernière consiste à appliquer le principe de pénalités progressives pour favoriser l'apprentissage et sinon à faciliter l'arrêt de la prestation en cas de rupture de la confiance, situation préférable à l'application de lourdes pénalités systématiquement.
(1) Les indicateurs de performance agile, base des SLA sont généralement : Prédictibilité, Productivité du sprint, Qualité Fonctionnelle & Technique, Motivation d'équipe et Satisfaction client
La contractualisation agile doit créer une situation Win-Win
Une étude du Standish Group sur la fréquence d'utilisation des fonctions des logiciels met en évidence que seulement 21% des fonctionnalités développées sont vraiment utilisées. Ca vous parait aberrant? Et bien, posez-vous la question de combien de fonctionnalités vous utilisez usuellement dans Excel - Sachant que ce tableur a une profusion de possibilités et d'automatisations possibles...
Partant de ce constat, on intègre généralement dans le contrat agile une incitation à finir plus tôt.
C'est la notion du "Money for Nothing" qui conduit à l'arrêt des développements dès que le ROI (return on investment - logique de coût/bénéfice) n'est plus suffisant.
En bref, en application du principe MoSCoW (Must-Have/Should-Have/Could-Have/Would-Have), dès que les fonctionnalités Must & Shoud Have sont développées, Product-Owner et Stakeholders doivent se demander pragmatiquement ce qui mérite encore que l'on dépense de l'argent dessus.
Pour que ce soit incitatif, 20% (classiquement) du budget économisé revient alors au fournisseur en tant que prime de performance.
En conclusion
Vous le voyez, contractualiser l'agile est possible. Le meilleur conseil que l'on puisse vous donner, c'est de ne surtout pas partir sur un contrat "au forfait" et de faire de l'agile en interne. Faire cela, c'est comme jouer à la roulette russe - C'est cool, mais plutôt dangereux.
Alors oui, l'agile, c'est un mind-set différent, mais en y pensant bien, ce qui a poussé à la généralisation des contrats à engagement de résultat, c'est surtout la volonté légitime des clients de contraindre et maitriser des budgets de développement qui dérivaient systématiquement. Or sur ce dernier point, l'Agile a comme principe fondateur que ce n'est pas le coût, le délai ou la qualité qui doivent varier en cas d'imprévu (et des imprévus, il y en a toujours!). Il n'y a donc aucune incompatibilité d'objectif entre un département achats et une équipe rompue à l'agile!
Qu'on se le dise, le contrat c'est la première étape et ça se travaille sur les mêmes bases que la suite du projet agile : Ensemble (client et prestataire de réalisation)!
Dites-vous bien que (que vous soyez coté client ou coté développement) pour plus de productivité, le mur de séparation doit tomber et lever l'omerta. Le premier des 3 pilier de SCRUM, c'est la transparence; et le but est de créer de la valeur et de la confiance, en autorisant le droit à l'erreur tant coté client que coté fournisseur.
Donc oubliez le costing, le pricing, le cost-drill-down, les provisions pour risque de vos abaques, travaillez de concert et en général si tout le monde est de bonne foi, ça se passe même mieux que prévu... Comme le dit Ron JEFFRIES (fondateur de XP ) : "l'agilité, c'est revenir à un processus qui donne du sens à ce que l'on fait et qui permet de réconcilier plaisir de travailler et productivité".