Utiliser l’agilité pour une ligne de métro: Fishbowl au IPMA Global Congress de Rotterdam

(Post égocentrique pour garder un souvenir de ce moment agile en groupe et garder à l'esprit cette approche applicable dans d'autres contextes. Pardon!)

Hier, le 1er octobre, j’ai eu la chance de participer au IPMA Global Congress de Rotterdam. En tant qu’agiliste, donner une conférence c’est bien, participer et partager avec ses pairs, c’est mieux encore.

Pendant les 3 jours de la conférence, un track spécial dédié pour l’Agilité a été mis en place par l’Agile Consortium (DSDM) sous l’impulsion d’Arie VanBennekum. Lors de la conclusion de tous les tracks (jeux, REX, méthodes), Arie avait prévu un Fishbowl sur un thème proposé par l’un des participants.

Le thème: « Comment construire une ligne de métro en mode agile? »

Devant un parterre d’une trentaine de personne, le chef de projet « Métro », nous explique que le sujet n’est pas une fiction et que cela le concerne directement. Comme l’agilité est un sujet important à ces yeux, il souhaite avoir l’avis de tous sur la faisabilité d’un projet d’infrastructure en mode agile. Super challenge!

Le chef de projet projète la vision ainsi que 7 points des conditions premières.

La discussion commence. La méthode traditionnellement utilisée dans ce type de projet est Prince2, nous analysons comment nous pourrions être agile et jusqu’où?

  • le démarrage et le cadrage peuvent être utilisés en mode agile (Scrum ou DSDM), sur ce point nous sommes d’accord.
  • le phasage qui engendre un grand risque devrait conserver les « quality gates » de Prince » avec des sprints intermédiaires.
  • la cloture pourrait être consolidée avec Prince2.

Une seconde contrainte est mise en avant: le projet est à budget fixe.

Cette contrainte est la raison principale sur le questionnement sur la faisabilité de l’agilité pour ce projet.

Tout le monde a joué le jeu et on s’est chatouillé un peu!

Comme je suis très joueur, j’ai sorti mon argument favori: en agilité, nous souhaitons maximiser la business value ce qui implique que la démarche est orientée produit et non budget!. Pour illustrer le propos, j’ai dessiné à quoi pourrait ressembler une feuille de route en mode scrum et quelle serait sa logique. ET, comme je n’ai pas été contredit, en fait il y a eu comme un blanc, je me permets de glisser ce dessin dans ce blog afin de souligner mon raisonnement.

Capture d'écran 2014-10-02 09.34.08

 

  • L’objectif du projet: relier la ville avec la plage par le métro

  • Stratégie:

    • au lieu de construire la ligne de métro ligne-gare-ligne-gare-ligne-gare (plusieurs gares intermédiaires entre les points bleu et vert)
    • pourquoi ne pas construire une ligne allant directement à la plage dans la 1e phase
    • avec le budget restant, nous pourrions construire des gares intermédiaires?
    • comme le budget risque d’être fortement amputé, nous pourrions faire participer les habitants des zones entre les points bleu et vert?
    • ceux-ci nous aideraient à déterminer les gares à construire, le type d’infrastructure souhaité (gares low-cost) etc…
    • l’implication des habitants se feraient avant le commencement des travaux pour:
      • impliquer les utilisateurs dès le début
      • ne pas avoir à gérer des problèmes de blocages ou de contestation car nous nous sommes mal pris (mettre devant le fait accompli)
      • créer du lien social et l’engagement des financiers (on parle d’impôts ici, utilisateurs=impôts=financiers)
      • et surtout, nous aurions de nouvelles idées auxquelles nous n’avions pas pensées au préalable

Il n’y pas eu de grincements de dents, mais un grand sourire et des yeux qui pétillent me faisant penser que cela vient de donner des idées au chef de projet. J’en était très heureux.

Le débat se recentre sur la partie management. J’en rajoute une couche: la gestion des fournisseurs.

Si, dans votre appel d’offre vous indiquez que le programme sera géré en mode agile, vous annoncez que la connaissance de l’agilité est un des critères d’acceptation de l’offre. De cette façon, la gestion du programme (projet) sera rythmé en fonction d’itérations de même longueur et des reviews en commun pour assurer l’alignement des travaux et réduire les déviations et le coût du délai (risque très important dans de tels projets).

Pas de silence, mais le début d’un débat dogmatique bon enfant.

En conclusion:

  • l’agilité est applicable dans de tels projets cependant:
  • il faut prendre en compte la phase de changement pour l’adoption de l’agilité (rappel que nous sommes dans un projet à coût fixe!): si 30% du budget est consommé par la mise en place de la méthode nous ne délivrions pas de valeur, ce qui n’est pas envisageable
  • cela est possible si la gouvernance et le chef de projet se sentent suffisamment à l’aise avec l’agilité

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s