Au cours des formations que nous donnons sur les démarches et la culture agile, ainsi qu’au sein des missions de conseil ou de coaching sur lesquelles nous intervenons, et encore plus lors des discussions en avant-vente de nos missions, un sujet revient souvent… mais alors vraiment souvent !
Le contrat dans une démarche agile.
Nombreuses sont les marques qui font appel à de la prestation intellectuelle externe et qui souhaitent opérer en agile. Et forcément quand on parle de prestation (externe ou interne), on parle d’une relation qui passe par de l’achat/vente et qui se concrétise en un contrat. Et quand on parle de contrat, on parle de régie ou de forfait (avec plus ou moins la même compréhension de leurs modes de fonctionnement d’ailleurs).
Et alors ?
Et alors, comment peut-on gérer efficacement un contrat dans une démarche en Agile ?
Réponse: tu ne fais pas de forfait en Agile !
Fin de l’article :)
.
.
.
.
Allez, on se lance pour de vrai car cette réponse n’est pas satisfaisante, vous en conviendrez !
Notre première conviction, c’est que le sujet du contrat n’est qu’une façade derrière laquelle se cachent les vraies questions à se poser, celles qui font peur, celles que nous devons vraiment affronter collectivement.
Nous vous proposons de creuser et d’y réfléchir ensemble.
Le modèle contractuel pose les bases de l’engagement mutuel entre des parties prenantes, un fournisseur (prestataire) et un client (bénéficiaire), ou entre deux filiales qui collaborent et se refacturent en interne.
Remarque: Attention, régie n’est pas égale à “assistance technique (AT) en logique de débordement”. L’AT suit souvent les règles de la régie mais l’inverse n’est pas vrai, on peut avoir un vrai mandat motivé par des objectifs précis dans une formule régie. On a donc des attentes sur des résultats même en régie, mais ça n’est pas encadré par le contrat.
Nous avons demandé aux Octos ce qu’ils pensaient du contrat en contexte de delivery agile. Voici quelques retours éclairants que nous avons sélectionnés pour étayer le propos :
“Si on regarde du côté des valeurs Agile (Customer Collaboration Over Contract Negotiation / Responding to Change Over Following a Plan), on arrive finalement à quelque chose d'assez simple :
- Il n'y a pas de contrat Agile, il y a des contrats tout court
- Il y a de la collaboration et de la confiance au dessus des aspects contractuels
- La probabilité de changer le périmètre (plan) est de 100%
On pourrait en déduire qu'un contrat adapté à l'Agilité est un contrat classique avec quelques ajouts du type :
- Le client s'engage à collaborer à certains moments clés(cadrage, démo, refinement, feedback...) et le cas contraire est un motif de rupture
- Le fournisseur s'engage à mettre en condition d’opérabilité régulièrement et fréquemment un logiciel de qualité (DoD, CI/CD, tests automatisés, indicateurs ...) et le cas contraire est un motif de rupture
- Changer le périmètre en cours de route est normal et ne devra pas être payant
- Pénaliser des choses comme : le non accès aux utilisateurs (client), la non disponibilité quotidienne de nouvelles fonctionnalités (fournisseur), l’absence de mesure objective de la valeur/feedback (client), l’indisponibilité du produit (fournisseur), ...
Au final, si le client trouve que ce n'est pas assez bordé et qu'il ne comprend pas que “avoir un produit qui délivre de la valeur à J1 et l’adpater en continu” est un énorme avantage, c'est peut-être simplement qu'il n'est pas fait pour bosser avec un fournisseur Agile !”
“Je rappelle que, d'après le manifeste, l'équipe doit prendre deux engagements cruciaux (c'est-à-dire contractuels) vis-à-vis du client, sur lesquels tout est basé :
- Accueillir favorablement les changements d'exigence, même tard dans le projet.
- Livrer régulièrement un logiciel fonctionnel, toutes les deux semaines à deux mois.
Ça n'a l'air de rien pour le juriste profane, mais dans la réalité peu d'équipes atteignent ce niveau d'agilité, donc à mon sens c'est la seule chose qui mérite réellement d'être contractualisée.
Cela tire bien sûr beaucoup de questions :
- DoR/DoD (Definition Of Ready / Definition Of Done)
- Caractéristiques des plateformes de dev/integ/qualif/preprod/prod
- Définition et suivi de la qualité
- Critères de mesure de la progression
- Conditions d'un rythme soutenable
- Conditions d'accès aux utilisateurs ou managers ou d'obtention des feedbacks
- Capacité de réorganisation de l'une et l'autre des parties
- etc.
Les réponses méritent elles-mêmes de figurer dans le contrat, qui doit être donnant/donnant.”
“J’ai fonctionné en agile avec 5 équipes en prestation et j’en retiens les bonnes pratiques suivantes:
- Contrat en régie (long terme) quand cela est possible donc pas d’engagement sur livrable ou de facturation sur storypoint :/
- Engagement mutuel en terme de moyens et de processus
- Fort engagement client de disponibilité, partage d’infos, respect des process agiles (paye tes pseudo PO à temps plein, stables par équipe/projet) etc.
- Mise à disposition des mêmes outils
- Inclusion des "fournisseurs" dans les rituels de gestion de programme.
Les pratiques « gardiennes très relatives» de l’agilité peuvent être détaillées dans la partie relevant du PQP (Plan Qualité Projet) en particulier sur l’organisation de la gouvernance.”
“On s'engage sur un dispositif stable (engagement de moyens).
Je ne vois pas comment s'engager sur des story points ou whatever. On a une reconduction tacite tous les deux ou trois sprints. De notre expérience, c’est sain et simple pour le client et c'est raccord avec nos valeurs de confiance.
Ensuite, point quotidien avec le client, démo et tout le tralalala. Le but est de tisser la confiance. Et le truc c'est de dire : tu paies tant que tu es satisfait de notre relation.”
“On vend des itérations et le client nous challenge s'il est pas content (c'est ça la reconduction tacite dont parle Alex). Ça lui permet de limiter son risque si on est pas performant.”
“Ça rassure les achats et le client de savoir qu'il a un engagement sur un "périmètre" surtout dans une culture habituée aux forfaits.
La complexité des stories était estimée par l'équipe de développement, négociée avec le client.
Sur l'exécution, on a parfois pas atteint la cible mais la proximité et la confiance ont permis de s'affranchir des négociations.”
“Voici les takeaways de mon côté:
- agilité et fixed price (forfait pour les anglicistes :p ), on oublie!
- agilité et time&materials time bound, on oublie!
- en tout cas pour les nouveaux clients tant que récurrente n'est pas démontrée
- Idem pour les débuts de projet.
- Pour un 1er PI SAFe par exemple, le scope est défini, on conseille donc de gérer comme un fixed price. Car le client s'attend au résultat.
- agilité et value added contract, why not, mais idem pas pour les nouveaux clients mais pas pour les mêmes raisons
- agilité et time&materials cap capacity, why not: le client s'engage sur une équipe pas sur un scope, mais souvent plus compliqué à mettre en place
- l'engagement sur des story points et également déconseillé, ils ne parlent à personne, ni au client ni à l'équipe surtout pour un nouveau client”
“Le modèle qui marche bien c’est:
- Engagement time&materials pour des durées de 3 mois
Tous les mois on fait un bilan sur l'avancement : nous sommes satisfait (ou pas), cela nous oblige à nous faire des feedbacks, de partager nos difficultés, nos ressentis et mettre en place des prochaines expérimentations.
Si le client n'est pas satisfait du fonctionnement de l'équipe, qu'il l'a remonté et que rien ne se produit, il garde la main pour sortir des personnes de l'équipe actuelle et faire rentrer d’autres personnes (même d’autres sociétés s’il le souhaite).
Cela permet au client de garder la main sur son budget et sur l'équipe.
Pour nous, cela nous permet de rester vigilant ("ne pas s'endormir sur la mission").
Reste à définir ensemble ce que l'on entend par “un bon mode de fonctionnement de l'équipe” : utilisez les 3 premiers mois pour construire le bon modèle est indispensable.
Cela permet de parler sur du concret et de ne pas construire des indicateurs qui seront hackés au détriment du produit ou des utilisateurs.”
On en a plein d’autres mais ça va globalement dans les mêmes directions, à quelques deltas près.
Tout d’abord, notre premier constat est qu’à travers cette discussion autour du mode de contractualisation, on parle en réalité et avant tout du mode de collaboration avec le client et de comment on va le mettre en œuvre.
Deuxième constat, les Octos nous disent indirectement : lâchez-vous sur les contrats en engagement de moyens mais soyez précautionneux sur le mandat et la clarté de ces engagements de part et d’autre. Une mission sans mandat clair, c'est souvent un fiasco.
La composante principale et fondamentale d’une collaboration qui se passe bien c’est la confiance qu’on s’accorde.
Quand la confiance est là, le modèle contractuel va naturellement s’appuyer dessus et devient un outil constructif, un allié, un levier.
Quand la confiance n’est pas là, le contrat cadre les engagements et on prévoit tout ce qui peut mal se passer pour ne jamais être dans l’impasse ou pour en tirer le plus d’avantages, c’est une lutte qui favorise une des parties. Cela ne va en aucun cas permettre de construire cette confiance, car le contrat va poser les bases d’un modèle opératoire où chacun va chercher à en respecter scrupuleusement les termes pour être au rendez-vous et ne pas avoir à sortir du cadre (même quand c’est pertinent). Le contrat peut donc devenir un outil de contrôle et de protection dans certains cas. On pourrait probablement mesurer un contrat qui n'est pas construit sur la confiance par les indemnités qu’il comprend ou par le nombre d’avenants qu’il génère, ou peut générer, pour faire avancer la mission.
Exemple : dès qu’il y aura un changement de scope, on fait un avenant -> le contrat devient alors un outil d’administration et moins un levier de création de confiance. Et évidemment, ce n'est pas ce que nous recherchons.
L’objectif des collaborations successives devrait toujours être de faire grandir cette confiance pour faire évoluer notre efficacité commune et donc se reposer de moins en moins sur le contrat comme un outil de protection.
La confiance s’adosse à un grande variété d’éléments dont le plus notable est notre capacité à obtenir des résultats ensemble. Et plus on collabore, plus on a d’occasions de démontrer des résultats impactants : un produit qui sort, des utilisateurs contents et impliqués, des livraisons sans bug, des déploiements simples et rapides etc… Vos résultats et apprentissages communs doivent être visibles et partagés, c’est crucial ! C’est bien ces éléments qui initieront ou développeront un climat de confiance.
Le contrat ne peut pas être la composante fondamentale de notre réflexion : il est l’appareil du mode de collaboration, il l’accompagne et favorise des conditions de réussite en restant honnête avec les enjeux manipulés et l’expérience des parties prenantes.
L’Agile ça se vit mais quand on parle de contrat ça veut dire que ça se vend et que ça s’achète aussi. Le contrat est le reflet de la relation : il s’appuie donc sur la compréhension mutuelle, et à nouveau sur la confiance qu’on s’accorde et l’expérience des parties prenantes.
Côté Acheteur/Client
Le client porte les enjeux de l’entreprise et à donc la responsabilité d’acheter de la meilleure des façons de la prestation intellectuelle. Ceci implique de comprendre pourquoi l’entreprise a besoin de l’agilité, qu’est ce que cela tracte comme changements et comme besoins, et de mettre le contrat au service de cela. Le client est également responsable de gérer et de favoriser la confiance mutuelle avec ses partenaires. Le type de contrat va donc devoir traduire ces engagements et accompagner la relation avec chaque partenaire.
Côté Vendeur/Fournisseur/Partenaire
Pour les clients et fournisseurs, le challenge sera donc de générer de la confiance et de la nourrir pour favoriser des modes de contractualisation moins contraignants et donc plus agiles.
Et à la question, est-ce qu’il y a un remède magique, une façon de faire plus efficace que les autres pour construire une relation de confiance, poser des bases solides et donc faire du contrat un allié puissant ?
Réponse: oui, on a des pistes à vous montrer, mais ça, c’est dans le deuxième article sur la relation contractuelle en contexte de delivery agile.
Stay tuned