Pour mémoire, il convient de rappeler que l’approche agile est basée sur des pratiques itératives et collaboratives, dont les quatre valeurs fondamentales sont :
les individus et leurs interactions plus que les processus et les outils
les logiciels opérationnels plus qu’une documentation exhaustive
la collaboration avec les clients plus que la négociation contractuelle
l’adaptation au changement plus que le suivi d’un plan.
Pour autant, méthodes agiles ou pas, aucune entreprise ne peut renoncer au triptyque périmètre, délai, budget.
De sorte que, en présence d’une méthode agile, tout projet d’importance sera le théâtre d’une âpre lutte contractuelle entre la SSII et son client. Il n’y a ni vainqueur ni vaincu à ce stade.
Un contrat finit toujours par être signé ... d’autant plus que le prêt à porter contractuel est aujourd’hui abondant.
Traditionnellement, les méthodes agiles découpent le projet en itérations, ou « sprints », tandis que le « backlog » comptabilise ce qu’il reste à faire pour respecter le périmètre fonctionnel initialement convenu.
Et c’est là le premier germe de la discorde : la valeur d’une itération repose-t-elle sur la quantité de travail fournie par la SSII ou s’apprécie-t-elle au regard de la progression vers l’atteinte du périmètre fonctionnel visé par le client ?
Bien entendu, la SSII demandera à être payée pour le travail accompli, c’est à dire en régie, plus ou moins bien dissimulée derrière « points de complexité », « vélocité » ou autres termes pompeux ...
Face à cette demande, le client aura bien du mal à mesurer le bénéfice qu’il tire de l’itération et à la caractériser en termes de résultats, d’autant que - conformément au dogme de l’agilité - il a accordé peu de temps aux spécifications, surtout s’agissant des livrables des itérations.
Le second germe de la discorde apparaît généralement au même stade : la collaboration et l’interaction entre les équipes étant au cœur des méthodes agiles, la SSII comme le client pourront s’incriminer mutuellement en cas de retards, de difficultés de recettes, de manquements aux obligations de compétence, d’alerte ...
Le client aura bien du mal à se prévaloir des obligations de résultats mises à la charge de la SSII. Chacun sait que l’immixtion du maître d’ouvrage permet à la SSII de s’exonérer de sa responsabilité.
Moteur même de la démarche agile, l’interaction SSII-client sape ainsi directement les bases de la responsabilité du prestataire en matière d’obligations de résultats. Pire, le client peut se voir demander réparation du préjudice que la SSII pourrait prétendre supporter : équipes mobilisées pour ne faire qu’attendre ou se substituant aux carences du client, ...
Ultérieurement, en présence d’un litige, plusieurs questions additionnelles se poseront : résiliation ou résolution du contrat, jouissance des droits de propriété intellectuelle afférents aux programmes et/ou aux spécifications, réutilisabilité opérationnelle des livrables ...
En définitive, il semble raisonnable de retenir que, en présence de méthodes agiles, le cadre contractuel SSII- client est particulièrement délicat. Il s’avère bien souvent un leurre, sauf à se satisfaire de l’achat en régie de prestations qu’il conviendra de piloter de très près - tout en sachant parfaitement où l’on souhaite arriver.
Ainsi, Sénèque a encore et toujours raison : « il n’est point de vent favorable pour qui ne sait pas où se trouve son port ». Les méthodes agiles nous le rappellent parfois cruellement.
Discussions en cours :
Le parfait article scandale, basé manifestement sur un seul cas non représentatif.
Ecrire « Pour autant, méthodes agiles ou pas, aucune entreprise ne peut renoncer au triptyque périmètre, délai, budget.
De sorte que, en présence d’une méthode agile, tout projet d’importance sera le théâtre d’une âpre lutte contractuelle entre la SSII et son client. »
c’est d’une part ne pas s’être documenté sur les méthodes agiles convenablement, pourtant la littérature de qualité ne manque pas
d’autre part insinuer que le forfait n’est pas le théâtre d’une âpre lutte contractuelle, ce qui doit faire marrer tous ceux, clients et prestataires, qui le pratiquent.
Je peux vous présenter des entreprises qui ont renoncé à ce fameux triptyque avec plaisir pour travailler dans un objectif de "qualité", un mot pas une seule fois cité dans votre article, et qui est pourtant à la base des méthodes agiles.
Il est évident que dans les milieux SS2I le terme "agile" est déjà galvaudé. L’affaire qui vous a menée à écrire cet article est probablement un mauvais exemple de cette pratique, le mot "agile" aura servi d’argument marketing pour mieux déplumer le client.
En revanche, je peux vous assurer que des centaines d’entreprises, dont la mienne, pratique l’agilité avec conviction et je ne vois vraiment pas comment un client pourrait s’en plaindre, n’en tirant que des avantages immédiats et de valeurs.
Le problème de votre article est qu’il stigmatise la pratique plutôt que les gens qui usurpent son nom. En ce sens, il est mauvais. Il aurait été plus intéressant de savoir comment protéger son contrat agile par exemple. Mais c’est sur que cette pratique limite les litiges, donc l’intervention des avocats...
Bonjour,
Je vous remercie pour votre commentaire.
Bien que “mauvais”, il nous permet d’apprendre que votre entreprise pratique l’agilité avec “conviction”.
Nous nous en réjouissons.
Cordialement.
Michel PASOTTI
(...)
Notons toutefois, pour les gens qui ignorent ce qu’est l’agilité (...), que le client est livré de l’avancement de son produit à intervalles réguliers (entre 1 et 4 semaines généralement) et qu’il peut arrêter la prestation à tout moment.
Un client mécontent peut donc arrêter très vite la collaboration au moindre doute sur des faits concrets sans faire appel à un avocat. Et oui la confiance est à double sens.
Il a également le devoir d’être impliqué dans son projet et de tester ces fameuses livraisons, de manière à ne pas pouvoir dire 6 mois après qu’il s’est fait arnaquer.
Bonjour,
Merci pour votre intérêt.
Il me semble que votre réponse met en exergue l’une des difficultés propres aux méthodes agiles.
Exemple : un projet de 990 jours et 11 itérations (ou sprints ...).
Un client peut s’avérer très satisfait suite aux recettes des itérations 1 à 4. (So far, so good ... dixit Arlequin tandis qu’il chutait avant de percuter le sol).
Le client paie donc régulièrement son fournisseur.
Arrivé à l’itération 8, le client considère (à tort ou à raison - la confiance est rompue) qu’il n’obtiendra pas le résultats final qu’il escomptait à la fin de l’itération 11, donc du projet.
Les difficultés commencent ...
Je présume que vous n’aurez pas de difficulté à les concevoir.
Cordialement.
Michel PASOTTI
PS : l’exemple fait référence à un projet de 990 jours ... taille assez moyenne ... il est bien évident que les risques augmentent plus que proportionnellement avec la taille du projet ... ce qui soulève la question du domaine d’éligibilité des méthodes agiles ... VRAI sujet par ailleurs ...
Bonjour
Effectivement la durée du projet impacte la visibilité finale.Cependant, 990 jours (/homme je suppose) c’est plutôt un gros projet !!! Quand bien même, les plus grandes entreprises passent à l’agile (AIR FRANCE, EADS, CNRS source EKITO). D’ailleurs l’agilité les aide à passer au lean ou autres méthodes de développements produits rapides. (au passage : http://www.journaldunet.com/management/expert/50957/quand-l-agilite-fait-son-retour-dans-le-discours-des-entreprises-francaises.shtml).
Il s’agit d’optimiser son organisation, l’intelligence collective et la façon d’arriver à un résultat sans avoir tous les besoins au démarrage, et justement pas de respecter un délai ou un prix. La durée du projet est certainement un facteur prédominant car sur la durée les besoins évolueront et le forfait empêchera toute évolution avec son effet tunnel, ou nécessitera une paperasse abondante et contre-productive.
Et justement, en agile on ne s’engage pas sur un délai ou un prix, preuve que dans votre dossier le prestataire n’a d’agile que l’étiquette commerciale, ou que le client n’a pas compris ce que proposait son prestataire.
Si le client pense ne pas atteindre l’objectif qu’il s’est donné au départ, il a néanmoins pu tester régulièrement son produit et modifier son besoin tant qu’il a voulu pour arriver plus vite à la qualité souhaitée qu’il aurait été incapable de spécifier en avant-projet.
Si vous donnez au client toute liberté pour changer les fonctionnalités à tout moment, il doit aussi admettre que tout changement impactera le délai et le prix par rapport à l’estimation initiale.
Il ne peut pas donc à la fois jouir d’un contrôle permanent sur son développement et maintenir un cap délai / prix immuable, ou malgré tous les changements et ajouts qu’il aura demandé, avoir au même prix toutes les fonctionnalités prévues initialement. Effectivement, pour le client qui émet des besoins fonctionnels sans en connaître de suite les impacts en terme de développement, il a parfois du mal à accepter qu’une chose toute simple soit en fait complexe à coder, et la confiance peut se perdre. Mais le prestataire doit être en mesure de prouver et expliquer sur quoi il a passé du temps, les imprévus, etc...
Je ne dirais pas que c’est une difficulté propres aux méthodes agiles. Il s’agit plutôt que le client comprenne bien ces méthodes littéralement différentes du forfait et que le prestataire soit vraiment agile.
faire un point pour comprendre ce qui n’allait pas, tenter de renouer la confiance par l’échange humain et non contractuel
s’arrêter de suite pour continuer avec un autre, pas facile certes, mais plus logique que d’aller jusqu’au bout.
Alors, dans une relation de confiance mutuelle qui est à la base de la collaboration, les résultats seront décuplés par rapport au forfait, y compris sur les délais et les coûts. Et pour le coup c’est justement bien plus facile !
Quel client peut affirmer qu’il a eu, au budget initial, dans les délais prévus, un développement conforme aux specs et fonctionnel ? Sincèrement ? Est-ce facile de terminer les projets quand tout est bloqué partout ?
Si votre client a subitement perdu la confiance alors que tout allait bien, il pouvait :
Ce qui reste gênant dans votre article c’est le dédain pour les termes agiles (exemple "(...)plus ou moins bien dissimulée derrière « points de complexité », « vélocité » ou autres termes pompeux ...").
Ces métriques et unités ont été inventée par des personnes réellement soucieuses d’apporter une façon de faire plus saine, transparente et juste. C’est leur manquer de respect et remettre en cause toute une pratique pourtant de plus en plus utilisée avec résultats probants que de faire d’un cas de discorde spécifique le procès de l’agilité. Finalement vous criez au loup mais ne conseillez personne concrètement.
A nouveau, puisque vous semblez bien connaître le monde de l’IT (échange de visite VIADEO), il serait génial pour tout cet écosystème d’avoir des conseils constructifs pour sceller un projet agile de la part d’un avocat !
Plusieurs démarches existent déjà : http://www.contrat-agile.org/ - https://github.com/tibastral/contrats-francais
Qu’en pensez-vous ?
Bonjour,
Merci pour votre réponse.
J’avais bien connaissance des travaux impulsés par XEBIA et CELLENZA.
Un modèle de contrat est rarement neutre ...
Souvent s’applique l’adage : "dis moi qui a financé le contrat, je te dirai qui il sert ..."
Quant à la seconde source, il me semble qu’elle ne peut se décliner sur des projets importants, qui précisément justifient des contrats à l’épreuve des difficultés au fil des trimestres.
Cordialement.
Les personnes qui ont écrit ce manifeste et celles qui y adhèrent sont déterminées à réussir leurs projets et pour cela partagent des valeurs et des principes empiriques (et non pas dogmatique comme vous l’avez écrit).
C’est d’ailleur ainsi qu’est introduit le manifeste :
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value : [...]"
Est-ce utile de préciser qu’ils ne sont pas avocats et qu’ils ne jouent pas avec les mots pour servir leurs ambitions personnelles ?
Enfin,
"la collaboration avec les clients plus que la négociation contractuelle"
Effectivement, lorsqu’on collabore sans contrat (ou avec un contrat léger), il n’y a pas de travail pour un avocat, d’où cet article scandaleusement à charge contre des méthodes et non pas contre ceux qui font n’importe quoi en leurs noms.
Auriez vous peur de perdre votre travail ?
Bonjour,
Merci pour votre commentaire.
Mais il me semble que vous tenez à faire prioritairement le procès ... des avocats.
Cordialement.
Michel PASOTTI
Il me semble qu’aujourd’hui votre réflexion est un peu décalée de la réalité economique ( celle des PME ou des gens ne sont pas des bureaucrates ).
Bonjour,
Merci pour votre commentaire.
Toutefois, je ne vois pas en quoi ma “réflexion” est décalée de la réalité économique.
Au contraire, elle me semble au coeur d’un débat intéressant : quels sont risques inhérents aux méthodes agiles ?
Ainsi, il ne s’agit pas d’exclure ces méthodes mais de les utiliser de manière sélective et dans un cadre adapté, voire limité.
Cordialement.
Michel PASOTTI
Je serais curieux de connaitre les sources et les faits qui vous conduisent a dresser le bilan d’un sujet que vous ne connaissez manifestement pas.
Cher Monsieur,
Comme votre grande perspicacité vous l’a fait pressentir, cet article est fondé sur des faits imaginaires.
Meilleures salutations.
Michel PASOTTI