Un cadre agile qui n’a pas oublié le chef de projet
Quand on parle d’agilité en gestion de projet, Scrum domine la conversation. Pourtant, Scrum a été conçu pour une équipe unique travaillant sur un produit, et il n’attribue aucun rôle au chef de projet. Pour les organisations qui gèrent des projets multi-équipes avec des contraintes de gouvernance, ce modèle atteint vite ses limites.
AgilePM propose une alternative structurée. Fondé sur DSDM (Dynamic Systems Development Method), une méthode agile créée en 1994 à partir du RAD (Rapid Application Development), ce cadre couvre l’intégralité du cycle de vie d’un projet, de l’étude de faisabilité jusqu’à la réalisation des bénéfices. DSDM est détenu par l’Agile Business Consortium, une association à but non lucratif, et les certifications sont accréditées par APMG International, organisme indépendant d’examen.
La différence fondamentale avec Scrum tient en une phrase: DSDM a été conçu dès l’origine pour fonctionner dans un environnement projet complet, avec des rôles de gouvernance, un chef de projet identifié et une gestion explicite des parties prenantes.
Huit principes comme socle
Le cadre repose sur huit principes reconduits sans modification dans la version 3: se concentrer sur le besoin métier, livrer dans les délais, collaborer, ne jamais compromettre la qualité, construire de façon incrémentale sur des fondations solides, développer de façon itérative, communiquer en continu et démontrer la maîtrise.
Ces principes ne sont pas décoratifs: le premier, “se concentrer sur le besoin métier”, conditionne toutes les décisions de priorisation. Dans un projet AgilePM, chaque fonctionnalité est évaluée non pas selon sa complexité technique mais selon la valeur qu’elle apporte à l’organisation. Concrètement, si un composant techniquement élégant ne répond pas à un besoin métier identifié, il ne sera pas développé, quelle que soit l’envie de l’équipe technique.
Le deuxième principe, “livrer dans les délais”, implique que c’est le périmètre qui s’ajuste quand les contraintes de temps sont fixes, pas le planning. Cette inversion par rapport à l’approche prédictive classique est au coeur du fonctionnement de DSDM. En pratique, cela signifie qu’une équipe qui constate en milieu de timebox qu’elle ne pourra pas tout livrer doit immédiatement revoir les priorités avec les parties prenantes plutôt que de demander un délai supplémentaire.
Le quatrième principe, “ne jamais compromettre la qualité”, se matérialise par la définition préalable de critères de qualité mesurables avant chaque timebox. L’équipe s’accorde sur ce qui constitue un travail “terminé” avec le niveau de qualité attendu, et ce seuil ne peut pas être abaissé pour respecter un délai. Si le temps manque, c’est la quantité de fonctionnalités livrées qui diminue, jamais leur niveau de finition.
Un cycle de vie en six phases
Le cycle de vie DSDM comprend six phases: pré-projet, faisabilité, fondations, développement évolutif, déploiement et réalisation. Les trois premières permettent de cadrer le projet avant d’engager des ressources significatives. La phase de fondations est particulièrement intéressante: elle pose l’architecture de solution, les rôles, les standards de qualité et le plan de livraison, sans basculer dans un tunnel de spécifications exhaustives.
Le développement évolutif s’organise en timeboxes, c’est-à-dire des périodes de durée fixe (généralement deux à quatre semaines) pendant lesquelles un ensemble de travail défini doit être accompli. Chaque timebox produit un incrément testable qui peut être évalué par les parties prenantes. La phase de déploiement gère la mise en production, et la phase de réalisation vérifie que les bénéfices attendus sont effectivement atteints.
Priorisation MoSCoW et gouvernance
La technique MoSCoW est l’outil de priorisation central de DSDM. Chaque exigence est classée en quatre catégories: Must have (indispensable pour la livraison), Should have (important mais contournable à court terme), Could have (souhaitable si le temps le permet) et Won’t have (exclu de cette itération). Cette catégorisation permet de protéger les délais: si une timebox prend du retard, ce sont les exigences Could have et Should have qui sont différées, jamais les Must have.
En pratique, cette technique exige une discipline réelle de la part des parties prenantes. La tentation de tout classer en Must have existe dans chaque projet, et c’est le rôle du chef de projet AgilePM de maintenir une répartition réaliste, typiquement pas plus de 60% du périmètre en Must have.
Ce que la version 3 change concrètement
La version 3 d’AgilePM, publiée en 2024, marque une évolution significative. Le cadre intègre désormais Scrum au niveau de l’équipe de développement: on retrouve les termes de Solution Backlog, Sprint Backlog, Product Owner et Scrum Master. Un nouveau rôle d’Agile Coach/Mentor apparait pour accompagner la maturité des équipes.
L’accent se déplace de la production de livrables (output) vers l’atteinte de résultats métier (outcome), ce qui aligne AgilePM avec les évolutions récentes de la gestion de projet dans son ensemble. Le guide de référence passe de 245 à 206 pages, non par appauvrissement mais par une meilleure intégration des concepts. Henny Portman propose une analyse détaillée des différences entre les deux versions pour ceux qui souhaitent approfondir.
Deux niveaux de certification
La certification AgilePM se décline en deux niveaux. Le Foundation évalue la compréhension du cadre via 50 questions à choix multiples en 40 minutes, livre fermé. Le Practitioner teste la capacité à appliquer DSDM dans des scénarios réalistes: 4 questions détaillées en 150 minutes, livre ouvert. Le Practitioner requiert d’avoir obtenu le Foundation au préalable et reste valide cinq ans, avec une re-certification possible entre la troisième et la cinquième année.
Le positionnement de cette certification mérite d’être compris: elle n’entre pas en concurrence directe avec Scrum Master ou PMP. AgilePM cible spécifiquement les professionnels qui pilotent des projets agiles à l’échelle d’une organisation, pas seulement au sein d’une équipe de développement. En Suisse, la certification reste moins visible que HERMES ou IPMA, mais elle gagne en pertinence dans les secteurs réglementés (finance, administration, santé) où la gouvernance projet ne peut pas être optionnelle.
Un complément, pas un remplacement
AgilePM a été conçu pour coexister avec d’autres cadres. PRINCE2 peut fournir la structure de gouvernance globale pendant que DSDM gère la livraison agile. Scrum peut fonctionner au niveau de chaque équipe tandis qu’AgilePM coordonne l’ensemble du projet. Cette compatibilité n’est pas un accident: elle reflète la réalité des organisations qui ne peuvent pas adopter un cadre unique pour tous leurs besoins.
Pour un chef de projet habitué aux approches prédictives qui souhaite intégrer l’agilité sans abandonner la gouvernance projet, AgilePM offre un pont structuré entre les deux mondes. Le cadre ne demande pas de choisir entre contrôle et adaptabilité: il propose de combiner les deux selon les contraintes réelles du projet.