- Speaker #0
La plupart des projets IT externalisés dépassent leur budget initial ou leur délai et on pense souvent que c'est le prix à payer pour travailler avec des prestataires. Pourtant, le vrai problème n'est pas le recours à une aide externe, mais le piège invisible des contrats traditionnels qui transforment mécaniquement toute collaboration en négociation, où pour que l'un gagne, l'autre doit forcément perdre. Le pire, même quand vous gagnez cette négociation, en obtenant plus de périmètres ou des pénalités, vous perdez au final. Chaque mois de retard, ce sont des bénéfices business qui s'envolent définitivement, sans compter le coût du projet qui n'est pas maîtrisé. Pour décrypter ces problèmes et découvrir les alternatives lignes et agiles, nous avons interviewé Alfred Almandra avec Marion pendant l'Agitour Montpellier. Alfred est consultant expert des approches agiles et auteur du livre « C'est urgence et pour hier » . Depuis plus de 20 ans, il a accompagné grandes entreprises et a expérimenté tout type de contrat, du forfait plus rigide aux clauses agiles les plus innovantes. Dans cette interview, vous allez découvrir pourquoi les contrats classiques à engagement de résultat ou à engagement de moyens sont la plupart du temps des pièges, la technique du découpage par la valeur et du carpaccio d'éléphant pour délivrer la meilleure valeur possible dans des délais courts ou contraints,
- Speaker #1
et le rôle des contrats agiles avec des exemples comme le 50-50 ou le stop ou encore. Et comme d'habitude, pour ceux qui n'ont pas le temps de regarder l'interview complète, Nous avons préparé un guide résumé de cet échange. Le lien est en description. Cet échange a été enregistré au cœur de la JTour. Vous en parlerez donc un peu l'ambiance de l'événement en fond. Là, c'est un interview.
- Speaker #0
Alfred, c'est quoi le problème du modèle contractuel classique qui est en mode client-fournisseur ?
- Speaker #1
Alors le truc, c'est qu'en préambule, il faut dire que n'importe quel type de contrat, quand tout se passe bien, c'est le meilleur contrat du monde, quel qu'il soit. Par contre, dans les deux grands contrats traditionnels, que sont d'un côté à l'extrême l'engagement de résultat ou de l'autre côté l'engagement de moyens, dans ces deux modes de contrat-là, au lieu d'être gagnant-gagnant, on est, d'un point de vue perception, au préalable, on a l'impression qu'on va être gagnant au détriment de l'autre. Et en réalité, on peut même devenir perdant tous les deux. Il faut peut-être que j'explique un tout petit peu ce point. En fait... Dans l'engagement de résultat, donc typiquement pour faire très très très simple, périmètre, coût, délai, c'est-à-dire qu'il y a un délai contraint, il y a un budget contraint, et il y a un périmètre contraint, c'est-à-dire qu'on ne peut pas faire quelque chose qui est en dehors du périmètre, et tout le périmètre doit être fait. Quand on est dans ce mode-là, alors encore une fois, si tout va bien, c'est le meilleur contrat du monde, mais quand ça ne va pas, et bien à un moment donné, dans les négociations, pour que l'un gagne, il faut mécaniquement que l'autre perde. Oui, c'est mécanique. C'est-à-dire qu'en gros... Soit il y aura un délai en plus et donc il y en a un qui perd. Ou alors, il n'y aura pas tout le périmètre, il y en a un qui perd, etc. Donc ça, on le comprend bien. Là où c'est plus délicat à comprendre, c'est qu'en réalité, quand ça ne va pas bien, même si on négocie et même si on a l'impression qu'on est dans le bon côté et qu'on va gagner, en réalité, ça peut devenir perdant deux fois. Alors, il y a plusieurs raisons à ça. Je vais citer la principale. C'est qu'à partir du moment où, par exemple, on va dire, je n'ai pas tout ce que je voulais et j'ai besoin d'avoir tout. Donc je suis prêt à accepter du délai supplémentaire. Ce délai supplémentaire, certains vont dire « Oui, il y a eu un coût supplémentaire associé, et donc qui va le payer ? » Ok, je peux l'entendre. Mais en réalité, le coût principal, qui n'est pas exactement un coût de dépense, le coût principal, il vient surtout du manque à gagner. Le manque à gagner, c'est quoi ? C'est tous les bénéfices que j'aurais pu faire, qu'ils soient financiers ou autres, que j'aurais pu faire à l'instant T où on respectait mon délai. À partir du moment où on décale d'une semaine, d'un mois, d'un trimestre, et bien ce laps de temps correspondaient à des belles choses qui devaient m'arriver. Ça peut être encore une fois financier ou autre chose. Et ces belles choses, je ne les ai pas. Et le temps est passé et potentiellement, je les ai perdues à jamais. Et souvent, ces gains-là sont sans commune mesure supérieurs à ce que j'avais injecté comme argent au départ. Les projets, on ne les fait pas à perte. Et donc, si je mets 100 pour gagner plus que 100, eh bien, à partir du moment où le délai passe, il se peut, ce n'est pas systématique, mais il se peut qu'en fait... il n'y a personne qui gagne. Donc, le client était protégé. Il se dit, moi, j'étais sous un engagement de résultat. Donc, si le fournisseur n'y est pas, eh bien, il doit remettre au pot. C'est pour sa pomme. Alors oui, les coûts directs vont être pour sa pomme. Mais le manque à gagner sera ad vitam aeternam perdu pour le client. Donc,
- Speaker #0
tout le monde perd.
- Speaker #1
Exactement. Et ça, c'est du côté engagement de résultat. Et du côté engagement de moyens, alors c'est un peu plus délicat. Encore une fois, je le redis, quand tout va bien, c'est le meilleur contrat du monde. là pour le coup le client a une sensation de maîtrise réel, je veux dire, c'est lui qui pilote les ressources, ce qui pose d'ailleurs d'autres problématiques d'un point de vue juridique, parce que le lien de subordination du coup n'est pas clair entre clients et fournisseurs et bon, ça tire un autre sujet et dans ce cadre-là Si on n'y prend pas garde, cette totale maîtrise peut se transformer en le client change d'avis tout le temps, et comme il a la main sur les ressources, il peut faire la girouette. Et cette girouette, si elle est poussée à l'extrême, et qu'on n'arrive pas à livrer suffisamment de valeur avant qu'on change d'avis, on se retrouve à changer tout le temps et à ne pas suffisamment livrer. Un jour, on se retourne dans les équipes, on se dit « mais quand est-ce que ça sera fini ? » Et malheureusement, les équipes parfois n'ont pas ce niveau de prédictivité. Elles sont incapables de dire « qu'est-ce que j'aurais porté le date ? » ou quand est-ce que toute cette chose-là sera prête.
- Speaker #0
Et il manque les engagements qu'on avait dans leur contrat.
- Speaker #1
Exactement. On n'a plus du tout les engagements, ce qui est le principe même. Engagement moyen, je n'ai quasiment aucun engagement sur le contenu. Engagement de résultat, je n'ai que des engagements fermes et ce qui jamais en dépasse, soi-disant, c'est pour la pomme du fournisseur. Et là où ça devient, on pourrait dire, on peut avoir l'impression que c'est gagnant-perdant. C'est-à-dire qu'après tout, si le client fait la girouette et que ça lui cause tort, On pourrait dire tant pis pour lui, mais nous, en tout cas, en tant que fournisseur, on a placé une ressource, on est rémunéré pour ça. OK. Là où ça devient plus délicat, c'est qu'on peut être attaqué sur le devoir de conseil. Vous auriez pu me conseiller. Et on peut aussi ternir notre image. C'est-à-dire, la mission devait durer six mois, elle a duré trois ans, et au bout, le client n'est toujours pas content, il n'a pas de visibilité. Alors, on pourrait se cacher en disant, oui, mais le client change d'avis tout le temps, il ne laisse pas les équipes, il ne leur laisse pas le temps de livrer. Pourquoi pas ? Mais où est notre devoir de conseil ?
- Speaker #0
De toute façon, ce qui va engager la réputation et la pérennité d'un prestataire et de la société d'un prestataire, c'est cette capacité de repeat business, de la capacité à avoir des clients satisfaits qui veulent ce prestataire pour d'autres projets ou parlent de ce prestataire à d'autres, etc. Et c'est ça qui fait la pérennité à long terme. Donc du coup, avoir une vision court-termiste sur la satisfaction du client, Je ne suis pas convaincu que ça marche.
- Speaker #1
C'est pour ça que si on revient sur la question initiale...
- Speaker #0
Je suis convaincu que ça ne marche pas, mais enfin...
- Speaker #1
C'est un risque fort, parce que bien sûr, c'est jamais absolu. En tout cas, si on revient sur la question initiale de quel est le problème qu'on essaie de résoudre, c'est qu'entre ces deux extrêmes de contrats dits traditionnels, que sont l'engagement de moyens et l'engagement de résultats, on peut trouver un ou plusieurs types de contrats agiles ou ce qu'on appelle des clauses agiles qu'on peut mélanger entre elles. Ce qui permet d'avoir un bon niveau de flexibilité, comme ce qu'on essaie d'avoir dans l'engagement de moyens, mais quand même d'avoir au moins en partie une forme d'engagement, le B.A.B. étant budget et délai, alors que le périmètre peut changer de nature et c'est là où les différents types de contrats peuvent moduler cette partie, voire l'enlever complètement et mettre autre chose à la place.
- Speaker #0
On va rentrer dans le sujet, mais en préalable comme ça... C'est dingue qu'on doive se battre sur des éléments comme ça parce que la base de l'agilité, c'est un peu ça. Nous allons revenir au podcast dans quelques secondes, mais j'ai une question pour vous. Est-ce que vous êtes capable de mesurer la performance de vos projets IT ? Si la réponse est non, vous perdez sûrement déjà du temps et de l'argent. Ce podcast vous est présenté par Exfabrica, une ESN qui aide les directions métiers et IT à exiger du ROI dans leurs projets. Chez Exfabrica, nous traitons deux problèmes majeurs, le manque de performance et le manque d'engagement sur vos projets de développement. trop souvent synonyme de retard et de dépassement de budget. Comment ? En mobilisant une équipe de développement qui s'engage sur le résultat et la performance et en appliquant une méthode éprouvée pour tous vos projets de développement, modernisation et architecture, expérience développeur ou encore cadrage projet. Vous pouvez dès maintenant prendre rendez-vous en suivant le premier lien en description et retrouvez-moi à la fin de cet épisode pour en savoir plus sur notre offre. Allez, on y retourne. C'est dingue qu'on doive se battre sur des éléments comme ça parce que la base de l'agilité c'est un peu ça quoi.
- Speaker #1
Oui, clairement. L'agilité, en fait, parfois j'observe qu'il y a une inversion de cause à effet. C'est-à-dire que parfois j'entends, à cause de l'agilité, le projet, on n'arrive pas à livrer ce qu'on voulait, ou on n'a pas de visibilité sur quand est-ce qu'on va finir.
- Speaker #0
C'était le plan initial.
- Speaker #1
Exact, c'était le fameux plan initial. En réalité, ça c'est une inversion de cause à effet, parce que ce n'est pas parce que le projet est agile qu'il est du coup flou, incertain, etc. C'est le contraire. C'est parce que projet est flou, un certain complexe subjectif. Parce que le monde est comme ça. Exactement, parce qu'on fait appel, c'est pour ça qu'on fait appel aux approches agiles, pour essayer d'adresser cette difficulté. Par contre, là où certains marquent à point quand ils critiquent l'agilité, en fait, ce qu'ils critiquent, ce n'est pas l'agilité en tant que telle, c'est comment est-ce qu'on l'implémente. Et là, pour le coup, je reconnais que sur le terrain, il peut y avoir un risque fort et je ne juge personne là-dessus, on peut tomber à pieds joints dans ce problème sans y prendre garde, c'est qu'on finit par mettre en place Merci. des approches agiles, des techniques, des méthodes, des rôles, etc. En ayant perdu de vue que ce qu'on essayait de tacler, c'est un sujet exploratoire qu'on essaye de rendre moins exploratoire, c'est-à-dire tester, découvrir, s'adapter, dérisquer et peut-être... rendre un peu plus connu, maîtrisé, quelque chose qui au départ était très peu connu, maîtrisé. Et ça, je pense que malheureusement, il y a beaucoup de contextes qui le perdent de vue, que ce soit côté client ou fournisseur, les deux peuvent arriver. Et les contrats agiles, justement, sont là pour donner un cadre. Alors attention, là aussi, il faut faire attention à une inversion. Quand les entreprises s'intéressent, qu'elles soient clients ou fournisseurs, quand elles s'intéressent aux contrats agiles, j'entends parfois le discours ou l'espoir de dire parce qu'on va prendre un contrat agile, alors ça va nous aider à être plus agiles. Et moi, ce que j'ai observé sur le terrain, c'est le contraire. C'est parce qu'une équipe va grandir avec ses approches agiles et va commencer à challenger le système, à le pousser un peu dans ses rôles franchement. Un jour, elle va planter du doigt le mode de contrat. Elle va dire, ce contrat n'est plus suffisant pour nous permettre d'aller chercher les grands bénéfices de l'agilité. Et c'est seulement dans ce cadre-là que je conseille de passer à un contrat agile, pas avant. Parce que sinon, qu'est-ce qu'on risque d'avoir ? On risque d'avoir un contrat qui, en théorie, nous donne un cadre pour être agile, mais si les équipes, si le fournisseur n'est pas suffisamment mature sur les approches agiles, il va à la fois...
- Speaker #0
Et si c'est inverse ? Si le fournisseur a cette maturité, cette habitude de mettre en place des contrats agiles, est-ce qu'il peut embarquer le client avec ?
- Speaker #1
Alors, est-ce que c'est facile ? Non. Oui,
- Speaker #0
rien n'est jamais facile.
- Speaker #1
Par contre, si une équipe a grandi et devient de plus en plus mature en agilité, ça va donner deux choses. Moi, j'ai bien dit que les approches agiles... C'est à la fois des détecteurs de problèmes, des thermomètres. Donc, ce n'est pas des médicaments, ce n'est pas des solutions, mais ça permet de révéler les bons problèmes. Et la deuxième chose, c'est des machines à séduction. C'est-à-dire qu'à un moment donné, quand on goûte du sucre, on devient addict, c'est une drogue. Eh bien, la JT, c'est un peu pareil. Si vraiment j'adresse mes différentes parties prenantes, mes utilisateurs, mon client payeur, le responsable juridique qui a aussi son mot à dire, même s'il n'est pas directement dans le projet. Bref, j'ai différents acteurs autour, les membres de l'équipe aussi, les partenaires. Eh bien, à un moment donné, si vraiment j'adresse mes différents interlocuteurs, alors à un moment donné, chacun y trouve son compte, chacun trouve des morceaux de valeur ajoutée pour ce qui lui est propre, et va être demandeur, va en vouloir plus, va vouloir mieux, va vouloir plus vite, etc. Et c'est dans ce cadre-là que les équipes agiles vont dire, eh bien, mon détecteur à problème a montré qu'aujourd'hui,
- Speaker #0
on plafonnait à cause des contraintes contractuelles.
- Speaker #1
C'est-à-dire, un contrat, ça nous protège et ça nous contraint. C'est les deux en même temps, comme un feu rouge. Ça nous protège, ça nous contraint. Et à un moment donné, ça nous contraint plus que ça nous protège. Et là, on va dire, on a besoin d'aller au-delà. Et tout le monde va vouloir y aller. En tout cas, il y a de grandes chances parce que chacun voit maintenant ce qu'il peut aller chercher de mieux au-delà du contrat habituel. Pour autant, facile à dire, pas facile à faire.
- Speaker #0
Oui, énormément.
- Speaker #2
Et du coup, qu'est-ce qui change dans la relation entre le prestataire et le client ? Dans le fait de mettre en place ces nouveaux contrats ou comme les contrats agiles, par exemple ?
- Speaker #1
Alors... Il y a des modalités techniques du genre, il faut influer les juridiques de chaque côté, etc. Mais je vais passer outre, pour l'instant, ces modalités techniques, parce qu'en réalité, pour moi, le changement le plus important, il est côté fournisseur. Et je vais mettre les pieds dans le plat, parce que potentiellement, ça peut changer son modèle économique. En tout cas, ça peut donner l'impression qu'il devra le faire, parce que ce n'est pas obligatoire. Typiquement, pour moi, un projet agile réussi, c'est un projet qui a peut-être découvert, testé et délivré une meilleure... va leur ajouter que ce qu'on aurait pu imaginer au départ dans un délai plus court que ce qu'on aurait imaginé. Donc, je vais dire autrement, par rapport à un contrat traditionnel où on s'engage sur six mois, par exemple, potentiellement, un contrat agile va permettre aux deux parties d'y mettre fin avec toute la satisfaction du monde des différentes parties plus tôt que les six mois. Est-ce que notre modèle économique, en tant que fournisseur, est content avec ça ? Et c'est là où je dis que je pose les pieds dans le plan de stake-up. On revient sur vision court terme, vision long terme. Exactement. Tant qu'on n'a pas eu cette discussion, Alors à un moment donné, il y aura quelqu'un, notamment côté fournisseur, qui va dire, écoute, ça on pourra toujours leur dire plus tard, terminez déjà ce contrat, non mais il faut se dire les choses. En réalité non, moi j'ai découvert ça en fait, je ne l'ai pas lu, je l'ai vécu et c'est après que je l'ai compris. Un DSI un jour m'a donné deux ans pour transférer un tas de choses que je faisais en tant que responsable opérationnel, pour le transférer à ses équipes internes. J'ai mis 18 mois à le faire, il était super content, les équipes étaient super contentes. et j'étais super content. Et du coup, ma mission s'est terminée plus tôt que prévu. Et quand j'en ai parlé autour de moi, j'ai vu à quel point cette notion-là faisait tiquer. Et bien sûr, je n'ai pas cherché plus loin. J'ai bien vu qu'un modèle économique basé sur un TGM où on se dit qu'il y a une mission pour deux ans, finir au bout de 18 mois, ce n'est pas idée de se dire que c'est une victoire pour tout le monde. Et ça, je l'ai recollé à quelque chose que j'avais déjà connu, mais plus sur l'opérationnel. C'est que, par exemple, le rôle de Scrum Master est un rôle qui en théorie selon moi visent à s'aborder c'est-à-dire qu'un des critères de succès c'est au début l'équipe sait pas faire je lui dis comment faire je suis un peu directif ensuite elle sait faire mais c'est pas fluide j'aide à fluidifier je suis plus facilitateur. Et un jour, L'équipe est autonome, elle n'a plus besoin de moi. Elle peut me rappeler pour aller piquer là où elle ne regarde plus, là où ça fait mal. Ok, pourquoi pas ? Etiquette coach agile. En tout cas, c'est comme ça que je l'appelais à une époque. Aujourd'hui, les mots sont un peu plus confus. Mais j'ai découvert sur le tas que mon rôle de Scrum Master que j'avais à une époque, c'était de peut-être me rendre obsolète. Et ça, ce n'est pas inné. J'ai redécouvert ça ensuite avec le modèle économique des ESN et des bureaux de conseil, enfin de tout un tas d'entreprises. qui sont fournisseurs d'autres entreprises et dont le modèle économique est souvent basé autour du TGM, c'est-à-dire le TJ le plus élevé et avec des gens placés le plus longtemps possible. Et donc, ça, c'est le point le plus dur.
- Speaker #0
Tu affiches une certaine typologie de projet où il y a une vraie fin. C'est-à-dire que tu peux arriver dans une sorte de forme de fin. Sur des projets plus importants, quand tu attaques un projet une plafond client pour une grosse entreprise. Et en fait, c'est plutôt des grosses itérations, c'est des grosses versions que tu vas suivre dans le temps. Que ta première version, au lieu de la sortir au bout de 18 mois, tu la sors au bout de 12 mois. Au contraire, le client se re-engage derrière pour essayer de dire « Attends, du coup, on va pouvoir aller plus vite, plus vite que les concurrents, etc. On va sortir la V2 un peu plus vite, etc. » Enfin, voilà, je trouve qu'il y a toujours la façon de voir les choses et en fonction du projet, ça change complètement.
- Speaker #1
Absolument. Moi, ma grille de lecture là-dessus, c'est qu'il y a une différence entre le projet et le produit. Le produit, potentiellement, c'est infini. D'ailleurs, quand j'entends des entreprises dire « Nous, que ce soit en externe ou en interne, on va faire le Airbnb de… ou le BlablaCard de… ou on va être la plateforme qui permet de… » En fait, je leur dis « Mais quand vous faites ces équivalences, eux, ils ont fini quand ? » « Ah ben, ils n'ont pas fini, ils sont encore en cours. » Mais bien sûr, parce que là, on est en train de parler du produit. Alors que le projet, c'est peut-être de déjà sortir quelque chose, de mettre un premier pied dans la place. Un VP ou un VMA. Exactement, un premier but de valeur ajoutée qui va permettre de financer le suivant, puis le suivant. Et en réalité, on va se rendre compte que petit à petit, on va basculer d'un mode très séquencé avec des montées de versions, des lots, etc. pour peut-être un jour arriver à un flux continu parce qu'en réalité, le produit, il peut vivre.
- Speaker #0
Même s'il a quand même un cycle. Tu peux mettre en place tous les jours et avoir un cycle pour arriver à une certaine maturité au bout d'un certain temps. Et après, viser une autre... Et ces cycles peuvent s'enchaîner. Et au contraire, si tu as une capacité dans ton contrat d'aller plus vite, de vivre plus de valeur, et de dire, en fait, on s'était engagé pour... On avait visé, parce qu'initialement, quand tu fais des estimations, elles sont fausses, les principes des estimations. Si tu avais visé de faire ça en 12 mois, peut-être que tu arrives... plus vite à apporter la bonne valeur, arriver à sortir 95% de la valeur en 8 mois, 9 mois, et tant mieux. C'est génial. Et après, tu peux te concentrer sur des choses pour aller beaucoup plus loin.
- Speaker #1
Ça fait une connexion avec deux points que je trouve très importants, notamment vis-à-vis des équipes. Un, j'aime bien dire que les équipes, dans leur amélioration continue, devraient essayer d'accélérer leur fréquence, dit autrement, de réduire la durée de leur cycle, plus vite que la vitesse à laquelle leurs parties prenantes sont capables de l'encaisser. Par exemple, si un client dit, moi, je n'ai pas besoin que vous me livriez plus qu'une fois tous les mois ou trois mois. OK, on peut se caler dessus dans un premier temps, mais très vite, on va se dire, nous, on va prendre un coup d'avance et on va descendre à trois semaines, deux semaines, une semaine. Ce qui fait que le jour où le marché évolue ou le client évolue, ça peut être intéressant quand il dit, est-ce qu'on pourrait passer à deux ? Ah, mais nous, on fait déjà une. Et qu'en fait, on est toujours un coup d'avance sur l'accélération. Ça, ça tire ce premier point-là et ce n'est pas neutre. parce que combien de fois j'ai vu des équipes dire nous ça va en rétro, qu'est-ce que tu veux qu'on améliore non ça va bien Et je leur dis, tiens, et si on se challengeait pour livrer la même valeur, mais dans un délai plus court ? Attention, sans rogner sur l'humain, sans rogner sur la qualité, ce n'est pas le but, ce n'est pas faire la même chose plus vite. C'est trouver des astuces, des manières pour réduire les délais, mais encore une fois, en respectant l'humain et la qualité. Et ça, ça peut être une suite d'amélioration continue permanente, infinie. Et l'autre point que ça tire, c'est la notion de prédictivité. Alors attention, là aussi, je vais dire un propos qui souvent peut étonner. en tout cas je remarque sur le terrain qu'il n'est pas souvent connu, malheureusement, l'agilité permet de tacler, d'adresser les projets exploratoires, complexes, subjectifs, etc., expérientiels, etc. Eh bien, de mon point de vue, plus un sujet est exploratoire, plus le délai, c'est la partie la plus facile. Je le redis tranquillement, plus un sujet est exploratoire, plus le délai, c'est la partie facile. Pourquoi ? Parce qu'en fait, au lieu d'essayer d'estimer le délai, on va le contraindre. Je donne deux exemples. combien de temps il faut pour élever un enfant ? Il faut un an, six ans, dix-huit ans, trente ans, surtout si on est un mec, blague. En réalité, qu'est-ce qu'on fait ? On fixe. On dit, à trois ans, tu rentres en maternelle, à six ans, tu rentres en primaire, à dix-huit ans, tu peux passer le code, le permis, le machin, peut-être même avant avec la conduite accompagnée. Bref, on a fixé un délai alors qu'on ne sait encore rien de l'enfant. alors ça empêchera pas de juger, d'évaluer, de tester, bien sûr. Mais en tout cas, il y a un a priori qui est de dire voilà une date. Et des dates comme ça, on en a tout le long de l'année. La fête d'Amusik, c'est le 21 juin. Est-ce que d'ici là, j'aurai à répéter tous les morceaux que je veux ? Est-ce que mon bassiste ne va pas me lâcher ? Etc. Je ne sais pas. Pour autant, la date est fixe. Noël est fixe. Donc, fixer le délai, c'est en fait la partie la plus facile. On n'essaye pas de gérer un délai d'un projet expérimental. on le décrète, on le fixe. Et c'est même encore plus vieux en langue que ça. C'est qu'on fixe le délai global. et pour le sécuriser, on va le saucissonner en délai court.
- Speaker #0
Exactement.
- Speaker #1
C'est pour ça que les équipes agiles sont capables de dire, nous on vous livre toutes les semaines ou tous les mois, enfin à une certaine fréquence. Ah bon, et vous me livrez de quoi ? Mais pour l'instant, j'en sais rien. Déjà vous dire, réservez votre salle, vos billets de train, pour votre démo, pour votre livraison, pour votre installation. Réservez déjà les personnes qui vont être mobilisées pour installer. Je peux déjà vous dire qu'on aura quelque chose à leur ordre. Ne vous inquiétez pas, ça part en prod. Exactement. pour reprendre le titre. Ne vous inquiétez pas, on reprend le vendredi. et pour autant, je ne sais pas vous dire six mois à l'avance qu'est-ce qu'il y aura dans ce contenu-là. Donc ça, c'est contre-intuitif. Par contre, ça tire. Du coup, le sujet clé, pour moi, c'est la clé de voûte dans les approches agiles, c'est comment on découpe les sujets, non pas techniquement, mais par la valeur, de manière justement à tester, découvrir et délivrer la meilleure valeur ajoutée, mais dans des délais volontairement trop courts. Ça, pour moi, c'est le vrai sujet d'apprentissage de la JT. Les techniques, les rôles, les méthodes, c'est autre chose, mais vraiment la clé de voûte elle est là
- Speaker #2
Et du coup, quel est l'impact sur les équipes ? Justement, tu dis, on fixe des délais, on essaie de faire des choses dans un temps en partie. Comment est-ce que les équipes qui ne sont pas forcément habituées à ce genre de méthode, les mettent en place ?
- Speaker #1
Absolument. Le premier réflexe, bien sûr, si quelqu'un n'a pas été formé, n'a pas déjà pratiqué ça ailleurs, etc., le premier réflexe, c'est ça va nous mettre la pression. Mais c'est normal, je veux dire, dans notre croyance, dans notre hypothèse de raisonnement, c'est qu'on va faire la même chose avec les mêmes gens, mais comme le délai sera plus court, il faudra courir plus vite, il faudra prendre des raccourcis. Donc, en gros, l'humain va se dégrader en termes de rythme soutenable, etc. Et la qualité va en pâtir. C'est normal, c'est la première appréhension. Et le risque existe, donc il faut vraiment l'adresser. Maintenant, ce que j'ai trouvé, ce que j'ai découvert sur le terrain, c'est que dès que je questionne les équipes sur « et si on essayait de délivrer la même valeur ajoutée, mais dans un délai plus court ? » Je ne dis pas que c'est ce qu'on va faire, mais si on essayait de le faire. Est-ce qu'on améliorerait les mêmes choses qu'à l'habitude ? Et en fait, la réponse est souvent non. C'est-à-dire que quand je leur demande sur quoi vous voulez vous améliorer, souvent, elles me citent plein de choses, des livrables, des rôles et responsabilités, plein de sujets. Et quand je leur dis, tiens, on va essayer de raisonner, et si on livrait la même valeur dans un des plus courts, et d'un seul coup, ils pointent du doigt d'autres choses. Ils disent, ah mais cette opération-là, on ne la fait qu'une fois par livraison parce qu'elle nous coûte cher, si on doit l'itérer plus souvent, on va devoir la faire deux fois elle va nous coûter encore plus cher je dis bah tiens là il y a un sujet intéressant Exactement, il y a peut-être une opération manuelle ou à temps contraint. Comment on fait pour que ce temps contraint soit automatisé, raccourci ? Comment on peut jouer, par exemple, pour le faire la nuit ou entre midi et deux, de manière à ce qu'on réduise le délai, alors que l'humain va toujours très bien, que la qualité va toujours bien, etc. Donc, j'ai découvert sur le terrain que ça changeait le regard des choses. Par contre, je le redis, cette technique-là, comme d'autres, en agité, pour moi, ne sont que des prétextes à la discussion pour faire émerger les bons problèmes, c'est-à-dire un bon révélateur de problèmes. et donc si vraiment on est sérieux là-dessus ça veut dire que les problèmes vont émerger plus souvent et plus fort et bien sûr souvent les problèmes à terme vont être organisationnels en dehors de l'équipe donc ça va tirer d'autres sujets sur comment on embarque les autres, comment on dialogue avec les interfaces c'est-à-dire les autres équipes à mon pendant à Val, etc. Comment on négocie aussi avec le business, le marketing, la direction parce que peut-être ce qu'on est en train de découvrir c'est qu'il faut changer de cap, en tout cas potentiellement se poser la question, donc ça tire d'autres questions mais ça, ça vient dans un second temps Mais pour les embarquer, Au départ, il y a des appréhensions, il faut les entendre et les adresser, peut-être les dérisquer. Et après, j'ai remarqué que ça faisait changer les lieux d'amélioration.
- Speaker #0
Il y a des risques, donc forcément, s'il y a des risques, il faut les gérer, il faut les dérisquer. Exactement.
- Speaker #1
Ce n'est pas parce que c'est risqué qu'on ne le fait pas. Pour venir ici, j'ai traversé plusieurs fois la rue, traversé la route. On ne ferait plus jamais rien. Exactement, on ne ferait plus jamais rien. Donc, c'est risqué, c'est bien de l'identifier, c'est bien de mettre des contre-mesures en face. Exactement. Je ne traverse pas non plus les yeux bandés en courant sur l'autoroute, je fais gaffe. mais pour autant je le fais quand même c'est très intéressant d'y aller d'ailleurs c'est une petite astuce mais des fois on me dit comment t'embarques les résistants et quelqu'un l'a dit à la keynote je sais plus si c'est Benjamin qui a dit à un moment donné on fait avec ceux qui veulent et puis les autres on verra plus tard alors je vous donne une petite astuce parce que faire avec ceux qui veulent ça va, mais le on verra plus tard je vous donne une petite astuce qui permet déjà de les onboarder un peu c'est que quand les gens vous disent est-ce qu'on risque pas de... Ah mais ça... il risque d'y avoir telle chose, etc. Eh bien, c'est bien de valoriser ce qu'ils disent plutôt que d'essayer de l'argumenter. Parce qu'en faisant ça, sans se le dire, ils viennent d'avoir une super contribution sur la gestion des risques du projet. Donc c'est super intéressant quand quelqu'un dit par exemple, est-ce que ça risque pas de coûter du cher ? Merci pour ta remarque, c'est super important. On va regarder nous, qu'est-ce qu'on peut mettre comme action pour faire en sorte que ça ne fasse pas déraper le pire.
- Speaker #0
Alfred, si on veut en savoir plus sur ce sujet, est-ce que tu as des ressources à conseiller, des choses que les gens qui ont vu ce court échange avec toi peuvent aller creuser pour aller voir d'autres éléments ? Qu'est-ce que tu nous... Est-ce que tu peux nous flécher des ressources ?
- Speaker #1
Absolument. Alors effectivement, je dois reconnaître que moi-même, quand je me suis intéressé au sujet, j'ai trouvé très peu de ressources, on va dire centralisées, sur les notions de contrat agile. D'où d'ailleurs la conférence que j'avais faite à l'époque avec un des clients avec qui on avait beaucoup pratiqué différents types de contrats, donc en 2018 au BlendWeb. Voilà, maintenant en description de l'épisode. Voilà, pour tout le monde, n'hésitez pas à mettre le lien vers la vidéo. Et il y a aussi un lien vers un support, qui n'est pas le support de cette vidéo, mais qui est un autre support que j'utilise pour présenter les contrats agiles. Avec grand plaisir pour mettre en lien.
- Speaker #0
C'est génial.
- Speaker #1
Et en fait, je me sers de ça comme pointeur parce qu'en réalité, chacune des notions qui est à l'intérieur, que ce soit dans la vidéo ou dans la présentation, ça donne des pointeurs vers des billets de blog mais dont j'ai trouvé à l'époque en tout cas qu'ils étaient un petit peu essaimés à droite à gauche. Alors beaucoup dans la littérature anglophone mais j'ai trouvé que c'était pas centralisé. Par contre, si quelqu'un veut en savoir plus par exemple sur le contrat 50-50 ou sur le contrat stop ou encore, Et bien, il va taper ces mots-là en anglais sur les billets de blog, on va dire, avec le mot agile à coller. Et la personne va tomber sur les ressources associées. Mais c'est vrai que je n'ai pas trouvé de ressources, on va dire, académiques, formalisées. Je n'ai pas trouvé un bouquin directement qui formalise ça. En tout cas, pas sous cet angle-là. Pas sous cet angle, comment passer de contrats potentiellement perdants-perdants à des contrats potentiellement gagnants-gagnants. Donc aujourd'hui...
- Speaker #0
Sinon après il y a toutes les vidéos de toi sur
- Speaker #1
YouTube. Alors sur les vidéos, celle des contrats agiles, à ma connaissance il n'y en a qu'une. Grâce à votre podcast il y en aura peut-être une deuxième et plus récente, donc tant mieux.
- Speaker #0
Aujourd'hui ça sera filmé, ça sera aussi sur YouTube.
- Speaker #1
Et puis après ça peut être aussi l'occasion d'autres échanges directs en communauté. Je serais ravi par exemple au sein d'un meet-up agile. Comment on te contacte ? Le mieux, c'est LinkedIn, Mail, comme vous l'avez fait. C'est la base.
- Speaker #0
Ok, génial. Est-ce que tu as une ressource que tu aimerais partager ? Quelque chose qui t'inspire, que tu adores ?
- Speaker #1
Tu veux dire en dehors des contrats Agile, plus généralement ?
- Speaker #0
Plus généralement, oui.
- Speaker #1
Alors, comme j'ai cité, le découpage fin a une valeur ajoutée. Je me sens obligé de parler du Carpaccio d'éléphant, qui est assez connu quand même dans la communauté Agile. mais dont je retrouve malheureusement encore trop peu les traces. Le Carpaccio d'éléphant. Le Carpaccio d'éléphant.
- Speaker #0
Pour le coup, celui-là, je ne connais pas.
- Speaker #1
Eh bien, donc, je te recommande d'aller le voir. Alors, au départ, je crois que c'est Alistair Cockburn qui en avait fait un premier billet de blog il y a peut-être une vingtaine d'années. Ensuite, il a été beaucoup popularisé par Henrik Nyberg, puisqu'il est très connu dans la communauté et qu'il a fait des très belles choses et qu'il arrive à très bien les formaliser. Donc, il en a fait, lui aussi, un billet de blog. Et je crois que plein de gens de la communauté l'ont ensuite, soit expliquée, décrite, illustrée. Donc, on trouve maintenant des vidéos, des infographies, des billets de blog, tout un tas de matériel. Et pour moi, encore une fois, je reviens là-dessus, mais je n'aime pas citer qu'une seule technique ou qu'une seule pratique parce que ça fait un peu dogmatique, il faudrait en passer par là. Par contre, je reviens sur mon commentaire qui est de dire que si vraiment on est sérieux avec le fait que l'agilité permet de découvrir, tester, délivrer la meilleure valeur dans un cadre exploratoire, et de réussir petit à petit à reprendre la main sur ce sujet exploratoire pour le rendre un peu mieux connu, un peu mieux maîtrisé. Alors pour moi, la clé de voûte, une des clés de voûte, pour moi, il y en a deux, c'est les bonnes pratiques de qualité, ça c'est très technique, et il y a le découpe à cheval à valeur ajoutée, et les deux se combinent bien d'ailleurs. Et pour moi, une des pratiques phares pour découper finement, c'est le carpaccio des fangs. Donc si jamais quelqu'un ne connaît pas le carpaccio des fangs, ou en a entendu juste parler, peut-être que je connais le principe,
- Speaker #0
mais je ne connais pas le nom, Je vais y jeter un oeil. C'est génial.
- Speaker #1
Pour résumer très simplement, quand il y a plusieurs alternatives, on n'en prend qu'une à chaque fois. Genre, mon assurance, elle peut faire les urbains, les ruraux, et bien, je n'en prends qu'un, les urbains. Elle peut gérer les contrats multirisques ou responsabilités limitées ou je ne sais pas quoi, et bien, je n'en prends qu'un. Ça peut être les renouvellements. C'est fin de l'approche, il faut trancher. Exactement. Et ça, ce que Carpaccio, ce qu'il donne comme effet, c'est qu'il permet de finalement passer d'un mode où on se dit, je ne voyais pas comment découper finement, à, mais en fait, c'est trop fin.
- Speaker #0
Ah, génial.
- Speaker #1
Et du coup, ça devient une chance parce que c'est plus facile d'accepter pour la capacité au cœur.
- Speaker #0
Génial. Écoute, merci beaucoup.
- Speaker #1
Avec grand plaisir. Merci à vous.
- Speaker #0
Merci pour ton temps. Et puis, comme d'habitude, vous likez, vous partagez, vous abonnez à Newsletter et vous... Vous allez voir Alfred pour lui dire que l'échange était hyper cool et vous lui faites un feedback parce qu'il faut faire des feedbacks quand on aime bien les vidéos. Et puis, à très vite pour une autre vidéo dans Prends en Prod. Super. Merci Alfred. Merci à vous. Merci Marion.
- Speaker #1
Ciao.
- Speaker #0
Dans cet échange, Alfred nous a montré que le vrai problème n'est pas de travailler avec des prestataires, mais de rester enfermé dans des contrats qui créent mécaniquement du perdant-perdant. Si vous reconnaissez ces symptômes dans vos projets, des négociations tendues et permanentes sur chaque changement, Des retards qui s'accumulent, un périmètre livré mais pas à la valeur attendue pour les utilisateurs et pour l'entreprise, ou encore une mission qui s'éternise sans fin claire. Nous pouvons mettre en place une vraie collaboration gagnant-gagnant. Chez Exabrica, nous proposons une offre de delivery d'applications basées sur des contrats agiles. Que ce soit pour une application métier, une plateforme web de disponibilité, une app mobile ou des microservices, nous nous engageons sur les objectifs et la performance dans un cadre agile. Notre approche vous permet de bénéficier de tous les avantages qu'Alfred a détaillés. Réussir même avec des délais contraints et tenus, pilotage par la valeur, transparence sur les risques, livraison fréquente et surtout un vrai partenariat. What un objectif plutôt que prévu est une victoire pour tous. Prenez rendez-vous maintenant pour découvrir comment obtenir des engagements forts pour votre prochain projet de développement. Pour réserver votre créneau, cliquez sur le premier lien en description. Et n'oubliez pas, le monde se divise en deux catégories. Ce qui suivant part en prod.
