Dans cet article, nous proposons de comparer les deux grandes familles de méthodes de gestion de projet : les méthodes traditionnelles et les méthodes agiles. Il ne s’agit pas de discréditer l’une ou l’autre mais de comprendre les finalités et les différences qu’elles présentent. Tout d’abord, définissons-les.
La méthode traditionnelle est la méthode décrite dans le PMBoK. Elle suit le cycle de vie standard d’un projet. Elle présente les caractéristiques suivantes :
- approche séquentielle, logique et prédictive,
- s’adapte bien aux projets avec des objectifs clairement identifiés,
- le projet tout entier est défini et planifié dès le début,
- permet une estimation précise du budget, des délais et des ressources nécessaires au projet,
- facile à mettre en oeuvre et structurée.
Les méthodes agiles regroupent différents modes de réalisation de projet, par exemple Extreme Programming (XP), Emertxe, Fast Prototyping, etc. Le point commun principal est la volonté d’accélérer le développement et la réalisation des projets. Leurs propriétés sont les suivantes :
- Des modules fonctionnels
- Des itérations courtes
- Des contraintes définies tout au long du projet
Pour certains, gérer des projets en mode traditionnel consiste à gérer les écarts. Cela s’explique par le fait qu’en mode traditionnel, on compare les valeurs obtenues à celles prévues dans le plan du projet. L’objectif consiste alors à minimiser l’écart valeur planifiée VS. valeur acquise. Par ailleurs, la donnée d’entrée principale du processus « diriger et gérer le travail » du PMBoK est le plan de management du projet. En outre, lorsque quelque chose n’est pas « en accord » avec ce plan, on le considère comme un changement. Ainsi, il s’agit d’exécuter le projet en suivant au mieux la feuille de route (le plan de projet) défini. Cela passe par l’analyse de la valeur acquise (VA) et les indices de performance (IPD pour les délais ou temps et IPC pour les coûts).
Pour d’autres, « la réunionite » est également un cliché de la gestion de projet en mode traditionnel. Les réunions sont nécessaires pour suivre le projet et gérer les interfaces. En mode traditionnel, elles apparaissent comme une activité récurrente qui peut faire avancer rapidement le projet lorsqu’elles sont bien menées. C’est également, pour l’équipe projet un moyen efficace permettant de prendre des décisions collectives et d’échanger sur les différents aspects du projet en confrontant les opinions. En mode traditionnel, les réunions de suivi de projet se déroulent généralement sur un rythme hebdomadaire.
Aujourd’hui, avec des projets de plus en plus complexes et incertains, il peut être difficile voire impossible de tout prévoir avant de débuter l’exécution du projet. Les méthodes agiles permettent donc de mieux répondre aux attentes des gestionnaires de projet concernés par ces problématiques. En revanche, pour des projets plus « prévisibles » (comme la construction d’une maison par exemple), la gestion en mode traditionnel répond parfaitement au besoin. Ainsi, malgré le gain de popularité des méthodes agiles, la méthode traditionnelle continue à être pertinente et grandement utilisée au sein des entreprises.
Malheureusement, pour de nombreuses organisations, la mise en place de la gestion traditionnelle s’est avérée particulièrement lourde avec de nombreux documents administratifs à remplir plutôt qu’une écoute active auprès des parties prenantes, sur le terrain. Effectivement, des organisations souhaitant suivre par exemple les bonnes pratiques proposées par le PMI ont décidé d’implémenter la totalité des recommandations du PMBoK dans leurs structures. Or, ce que le PMI prône réellement, c’est la compréhension de ce manuel et de ses processus et non l’implémentation systématique de l’ensemble des bonnes pratiques. Pour le PMI, il s’agit finalement uniquement d’identifier et d’appliquer les bonnes pratiques qui intéressent l’entreprise dans le PMBoK et non d’alourdir les procédures administratives avec des processus inutiles. La mauvaise interprétation des recommandations du PMI a ainsi conduit des organisations à décourager leurs ressources à l’utilisation de la méthode traditionnelle. L’entreprise doit donc adapter la gestion de son projet au contexte, aux enjeux et aux risques.
Les gestionnaires de projet qui choisissent le mode agile plutôt que le mode traditionnel le font généralement parce que le projet présente un niveau élevé d’incertitude. Les intérêts principaux des méthodes agiles sont :
- d’améliorer la qualité,
- de maximiser la valeur créée,
- d’améliorer le « time to market »,
- d’améliorer l’engagement des équipes et la satisfaction client,
- de réduire les risques ,
- de renforcer la capacité d’adaptation,
- de donner de la visibilité sur l’utilisation du budget et des ressources,
- de promouvoir l’amélioration continue.
Présentation du framework SCRUM
Voyons maintenant quelques notions de vocabulaire propre au mode agile et plus particulièrement à SCRUM :
- Product Backlog : il s’agit de la liste des tâches à effectuer pour aboutir à un produit ou à une version du produit ;
- Product Owner : c’est celui qui représente l’utilisateur du produit visé, c’est aussi le responsable du Product Backlog et une interface entre le client et l’équipe de développement ;
- Scrum (mêlée) : les réunions de suivi quotidiennes tenues généralement debout, d’environ quinze minutes ;
- Scrum Master : c’est le coach de l’équipe agile et du Product Owner et le garant du cadre méthodologique Scrum ;
- Sprint (Itération) : il s’agit d’une courte période (une à quatre semaines généralement) visant à rencontrer des objectifs précis ;
En gestion de projet agile, tout commence avec les « user stories » : l’équipe se rassemble et se met à la place du client pour imaginer les prérequis du projet. Elle se pose des questions telles que « Que veut le client ? », « Que peut-on peut imaginer comme scénarios / stories ? ». L’équipe imagine plusieurs scénarios, en sélectionne un et le propose au client. Une fois le scénario validé, l’équipe identifie les différents points par rapport aux valeurs pour chacune des activités au regard des prérequis identifiés. Ces points sont intégrés au Product Backlog qui rassemble les activités à réaliser.
Avant le premier sprint (et pour chacun d’entre eux), l’équipe cherche à connaître quels sont les items sur lesquels travailler pour le prochain sprint (on utilise alors des méthodes de planification comme le Poker Planning). Elle identifie ensuite l’effort qui est nécessaire pour ce sprint et une vélocité (elle est dans une nouvelle dynamique et a besoin de tester, sur un premier sprint au moins, si l’effort estimé est correcte).
En fin de sprint, l’équipe consulte le Product Backlog et compare les résultats produits avec ce qui était indiqué dans le backlog. Cela permet à l’équipe de se rendre compte de son avancement et ainsi de vérifier si les prévisions de planning sont bonnes ou doivent être réajustées. L’équipe est alors en mesure de donner un nombre de sprint total pour le projet.
Plus simplement, avec les approches agiles il s’agit de savoir « planifier juste assez, juste à temps ».
Le Poker Planning
Il s’agit de rassembler les membres de l’équipe avec un jeu de carte spécial basé sur la suite de Fibonacci. On identifie une valeur moyenne (généralement le 3 ou le 5).
Prenons un exemple :
L’animateur (ou chef de projet) propose une caractéristique à développer avec les explications associées et une estimation de la durée. Si la valeur moyenne est 5, les membres peuvent poser une carte 3 (ou inférieure) s’ils pensent que l’estimation est trop basse, 5 s’ils l’estiment correcte, ou 8 (ou supérieure) si la période semble trop courte.Après deux itérations, une majorité commence à se dégager. Parfois, une personne peut être en total désaccord avec le temps estimé. Un bon exemple serait un membre qui place une carte 1/2 pour une activité de deux semaines estimée à 10 jours avec une carte moyenne de 5. Cette personne est alors invitée à prendre la parole pour expliquer sa position sur le sujet. Souvent, elle propose une méthode que personne d’autre n’avait imaginé. Il peut donc y avoir un autre vote, compte tenu de la méthode mise en avant par le membre.Cette méthode a l’avantage de permettre aux personnes les plus timides de se faire entendre de la même manière que les autres, plus à l’aise à l’oral.
Quelques résultats
The Standish Group met en exergue des résultats concluants pour les projets gérés en mode agile. Effectivement, selon une étude réalisée entre 2002 et 2010 par ce même organisme, et considérant le succès d’un projet comme la rencontre des objectifs de qualité, de budget et des délais, l’étude montre que près de 14% des projets menés en mode traditionnel réussissent contre 42% en mode agile. Par ailleurs, ce ne sont pas moins de 29% des projets menés en mode traditionnel qui échouent contre « seulement » 9% en mode agile.
Conclusion
Malgré les nombreux atouts offerts par les méthodes agiles, il faut toutefois noter quelques inconvénients, tels que :
- Les indicateurs de performance classiques (valeur acquise) ne sont plus appropriés en mode agile,
- La gouvernance et la culture organisationnelle classique est un véritable défi à relever : cela demande plus de temps aux hauts dirigeants qui ne peuvent pas se contenter de déléguer l’agilité à leurs équipes,
- Les équipes de travail doivent être préparées à passer du mode traditionnel au mode agile (conduite du changement),
- Le fait que le contenu ne soit pas définitif constitue un autre risque.
Aussi, il convient de retenir que le PMI, au travers du PMBoK, propose un ensemble exhaustif de bonnes pratiques en matière de gestion de projet mais qu’il convient de n’implanter que les processus utiles à sa propre organisation. Si la méthode traditionnelle est adéquate pour gérer des projets prévisibles tels que la construction d’une maison, les projets complexes dont le développement est incertain auront avantage à privilégier les méthodes agiles. La méthode traditionnelle permet d’avoir une gestion de projet solide et efficace pour les projets prévisibles tandis que la seconde, plus souple concernant les exigences client, permet de gérer les projets complexes.
Également, rien n’empêche de mixer les deux méthodes pour créer un mode hybride prenant en compte les meilleurs pratiques de chacune des méthodes et qui peuvent aider à faire avancer le projet.
