Contrats agiles

Dans cet article, vous découvrirez ce qu’il faut prendre en compte lors de la rédaction d’un contrat Agile. J’espère que cela augmentera vos chances de succès en mettant l’accent sur la collaboration et des fréquences de livraison courtes.

J’ai besoin d’un logiciel et je suis sur le point d’engager une entreprise pour le développer pour moi. Comment rédiger un contrat qui protège les intérêts des deux parties ?

Le Scrum a fêté ses 21 ans l’année dernière, le Manifeste Agile en a 16, et pourtant, la plupart des contrats que nous signons aujourd’hui sont négociés de manière stricte avec un périmètre, un prix et une date de fin bien définis. Si vous faites partie des chanceux, votre direction a été d’une manière ou d’une autre éclairée et a le courage d’être vague sur le périmètre. D’une certaine manière, cela oblige les parties prenantes et l’équipe à collaborer étroitement pour obtenir des résultats. Bien que ce ne soit pas parfait, c’est une bonne tentative pour modifier les contrats conventionnels à périmètre, budget et timing fixes. Si le client doit effectuer un virage à 180 degrés, il reste nécessaire d’avoir une gestion du changement pour négocier le prix de toute modification—ce qui n’est pas idéal.

Ce qui éveille vraiment ma curiosité dans cette question, ce sont les non-dits et toutes les hypothèses que nous faisons.

Pourquoi rédigeons-nous des contrats en premier lieu ?

Parce que nous voulons nous assurer d’obtenir ce que nous voulons et pouvoir poursuivre l’autre partie en justice si ce n’est pas le cas. Nous voulons nous assurer d’être correctement rémunérés ou pouvoir poursuivre l’autre partie. Nous nous protégeons légalement, dans les deux sens—très bien.

Pour nous aider à rédiger ces contrats, nous avons identifié les éléments à risque qui sont mesurables et nous souhaitons les clarifier dès que possible, avant de commencer à y travailler. Avec cette mentalité, un démarrage anticipé peut se traduire par une perte de temps. Par conséquent, nous plongeons directement dans les détails du périmètre, du budget, du calendrier. De nos jours, certaines personnes penseront même à la qualité du produit, ironiquement, un critère difficile à mesurer. (Pensez à une expérience utilisateur maladroite, par exemple, ou à un logiciel bogué).

Néanmoins, je pense que nous protégeons les mauvaises contraintes. Des années d’expérience nous ont appris que le périmètre peut être modifié, que la technologie peut être imprévisible et que les personnes peuvent aussi avoir un impact !

Au lieu de cela, pourquoi ne pas protéger « comment » nous travaillons ensemble, les deux parties, afin d’atteindre le meilleur résultat ?

C’est exactement ce que le Manifeste Agile exprime.

Les individus et les interactions plutôt que les processus et les outils
Le logiciel fonctionnel plutôt que la documentation exhaustive
La collaboration avec le client plutôt que la négociation du contrat
Répondre au changement plutôt que suivre un plan

C’est-à-dire que, bien qu’il y ait de la valeur dans les éléments de droite, nous accordons plus de valeur à ceux de gauche.

Heureusement pour moi, je ne suis pas avocat ! C’est pourquoi ce n’est pas un livre blanc sur la façon de rendre vos contrats plus compatibles avec le Manifeste Agile ! Je peux seulement imaginer à quel point la « collaboration » sera difficile à mesurer et à quel point il sera difficile de le prouver en cas de conflit.

D’autres étaient également curieux et ont eu la gentillesse de partager leurs idées. Voici quelques bons liens à considérer :