Agile ou Prédictive : une méthode hybride ?

Peut-être, comme moi, vous vous intéressez à la gestion de projet Agile. Que ce soit par pression sociale (bah oui tout le monde n’a que ce mot à la bouche dans les entreprises… Soyons plus agiles, si tu n’as pas atteint tes objectifs c’est sûrement parce que tu manques d’agilité, vous auriez encore un peu de cet agile pour parfumer mon café…) ou par curiosité, vous êtes tombés sur ce post !

Mon objectif ici est de vous présenter un Framework que j’expérience depuis quelques temps.

CONTEXTE :

La première fois que j’ai entendu parler de gestion de projet Agile j’ai trouvé le vocabulaire séduisant. Il résumait très bien ce que je reprochais aux méthodes classiques de la gestion Prédictive ; trop figé, pas assez réactives faces aux changements, faces aux problèmes, peu évolutives… J’ai donc commencé à me renseigner mais je suis vite arrivé à un blocage, la gestion de projet agile fonctionne très bien pour des projets dont le scope est mal défini au départ et qui se défini au fur et à mesure des itérations du projet. Je gère principalement des projets dont l’objectif est très bien défini au départ et qui est peu sujet à évolution.

J’ai donc dans un premier temps mis de côté cette nouvelle méthodologie et approfondi mes connaissances dans les techniques Prédictive.

Et puis un jour, en regardant mon WBS… Tient donc… Ne serait-ce pas un « Backlog » d’actions ? Je me suis donc repenché sur les méthodes de gestion de projet agile et notamment la méthode « SCRUM ». Et finalement même si mon scope global est peu sujet à variation, tout au long de la vie de mes projets je rencontre des problématiques obligeant à ajuster mon planning et mes ressources en actualisant l’initiation du projet.

Je vous propose donc ce Framework qui combine les deux approches. On garde les Process Groups décrits dans le PMBoK (INITATING / PLANNING / EXECUTING / MONITORING & CONTROLLING / CLOSING) en les arrangeant un peu différemment.



1. INITIATING
Ici pas de différences, les principaux livrables sont
- le Project Charter
- l’indentification des Stakeholders.

2. INITIAL PLANNING
Etant donné qu’on dispose de l’entièreté du scope, on peut réaliser un planning initial prenant en compte des hypothèses documentées. On associe à chaque Work Package et/ou Deliverable :
- Un temps
- Un budget
- Un scope
- Des risques
- Des hypothèses
- Une matrice de responsabilités
- Les relations entre Work Package et/ou Deliverable
- Les critères d'acceptation

Afin que chaque Work Package puisse être traité comme un petit projet de manière indépendant.

Le principal livrable :
- WBS documenté

3. SCRUM : PLANNING / EXECUTING / MONITORING / CONTROLLING



Chaque Work Package est traité comme une entité du Backlog. L’avancement du projet est donc suivi par l’avancement des itérations du projet. Contrairement aux méthodes agiles, ici des Work Package sans relations peuvent être réalisés simultanément.

Chaque Work Package possède sa propre équipe qui le réalise selon le principe du Sprint, il faut donc essayer de respecter un temps de réalisation inférieur au mois par Work Package. La responsabilité de la réalisation de chaque Work Package incombe à la personne identifiée comme Accountable.

Le chef de projet participe avec au contrôle de la réalisation de chaque Work Package et les valide le cas échéant.