Méthodes Agiles – 3 pièges à éviter

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.

Calendrier

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.

Cadenas contractuel

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.

Clés avec maison

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 ? »

Louis-Alexandre Louvet

Depuis 2000 dans le conseil, Louis-Alexandre s'est spécialisé dans les problématiques d'innovation et de lancement de nouvelles offres s'appuyant sur les technologies, notamment au travers de la conception de stratégie et de schéma directeur SI. Il accompagne également le cadrage et le pilotage de grands programmes de transformation faisant levier sur le SI. Il développe les études sur l'impact et la valeur des technologies pour différents secteurs, notamment le secteur immobilier, fédérations professionnelles, associations. Louis Alexandre a accompagné le cours Essec / Centrale Paris / Strate Collège, création d'un produit innovant pendant 2 ans. En tant que citoyen passionné par la transformation des usages, Louis-Alexandre est également membre du bureau de Démocratie Ouverte, association qui conçoit, développe et teste de nouveaux modèles de gouvernance citoyenne. Il a rejoint ISlean consulting en novembre 2012.


Louis-Alexandre Louvet

Depuis 2000 dans le conseil, Louis-Alexandre s'est spécialisé dans les problématiques d'innovation et de lancement de nouvelles offres s'appuyant sur les technologies, notamment au travers de la conception de stratégie et de schéma directeur SI. Il accompagne également le cadrage et le pilotage de grands programmes de transformation faisant levier sur le SI. Il développe les études sur l'impact et la valeur des technologies pour différents secteurs, notamment le secteur immobilier, fédérations professionnelles, associations. Louis Alexandre a accompagné le cours Essec / Centrale Paris / Strate Collège, création d'un produit innovant pendant 2 ans. En tant que citoyen passionné par la transformation des usages, Louis-Alexandre est également membre du bureau de Démocratie Ouverte, association qui conçoit, développe et teste de nouveaux modèles de gouvernance citoyenne. Il a rejoint ISlean consulting en novembre 2012.

Leave A Comment