La méthode Agile s’est répandue dans tous les discours. Toutes les DSI des entreprises se sont mises à cette méthode, SCRUM en tête. Et certaines le font vraiment. Il n’y a plus de proposition d’une ESN qui ne soit pas Agile. C’est vrai que la promesse est belle. Rompre avec les projets informatiques. Mais attention à ne pas demander l’impossible ! Voici quelques éclairages pour éviter les faux semblants de l’Agilité.

Agile : votre entreprise est-elle prête ? « 3 tue l’amour »

Piège Agile #1 : votre DSI fait deux versions (ou mises en production) par an

En quoi est-ce un problème ? L’Agile est une méthode qui vise à avoir des cycles de mises en production très rapprochées. En fait, les développeurs livrent à chaque fin de cycle (appelé sprint). Ces sprints portent leur nom car ils sont courts : en moyenne, 6 semaines. Comment dès lors répondre à ce principe de livraison rapide, avec deux fenêtres de tirs par an, et que la prochaine est dans plus de 5 mois ? Ce n’est pas possible !

Deux possibilités : 1 / adapter pour votre projet les dates de livraison avec la DSI ; 2/ renoncer à l’agile pour éviter la déconvenue.

Piège Agile #2 : vos Achats ne veulent faire que des forfaits

C’est vrai que c’est très bien de se mettre d’accord sur tout à l’avance. C’est le but du forfait : un contrat très précis, avec une obligation de résultat et des indicateurs de résultat. Le problème est justement que l’Agile permet d’abord d’explorer, avec une équipe conjointe métier et SI très resserrée, les possibles. Et l’Agile et d’abord une méthode qui met en place des moyens permettant d’approcher différemment le résultat à atteindre : au lieu d’attendre d’avoir tout prévu, l’Agile crée une équipe qui remet en cause les priorités sur des cycles courts. L’équipe fait évoluer les besoins face aux résultats obtenus. Comment demander à un prestataire d’adapter en permanence ses livrables avec des objectifs déjà contractualisés ?

Trois possibilités : 1/ adapter le mode de contractualisation avec les Achats sur ce projet ; 2/ faire un contrat cadre de type vivier, et adapter les commandes au fur et à mesure ; 3/ renoncer à l’Agile.

Piège Agile #3 : le Product Owner n’a pas les clés du métier

Imaginons un Product Owner (PO) qui n’est en fait pas propriétaire du produit face à l’équipe projet. Cela a l’air absurde et pourtant…

La fiche de mission du PO indique qu’il devra faire valider les besoins du métier auprès de sa direction et de ses collègues. La méthode SCRUM pose que le PO représente le métier et prend les décisions en cycle rapide. Il répond aux questions des développeurs, débloque les situations et arbitre. Si le PO doit faire valider chaque décision à des instances ou à d’autres utilisateurs, cela l’obligera à remettre les personnes dans le bain, présenter les enjeux, les conséquences… pour espérer obtenir un consensus. A chaque fois, des délais. Et après quelques questions, l’équipe perdra de sa vélocité. Comment alors la faire avancer sans subir l’inertie du collectif ?

Trois possibilités : 1/ adapter la fiche de poste pour donner le pouvoir au PO de mener sa mission de PO ; 2/ remonter d’un cran dans la hiérarchie si besoin ; 3/ renoncer tout de suite à l’Agile.

L’Agile est une méthode avec beaucoup de promesses et de souplesse. Toutefois, comme toute méthode, elle ne doit pas devenir un dogme. L’informatique a quand même livré des projets (certains grands) avant l’Agile.

Votre contexte d’entreprise est tout aussi important que le sujet du projet pour évaluer l’opportunité de l’utilisation de l’Agile.

Pour aller plus loin : « Cycle en V ou Scrum : que-choisir ? », « Méthodes Agiles – quelles leçons tirer de leur utilisation ? », « Les développements agiles sont-ils plus rapides ? », « Méthodes Agiles – Qu’est ce qu’un PO Proxy ? »