Comment rendre plus « Agile » les entreprises qui réalisent leurs projets en mode Waterfall (en cascade)? La question est sur toutes les lèvres ces jours-ci. Beaucoup estiment d’ailleurs qu’il serait plus simple de résoudre la quadrature du cercle. Au mieux, l’idée est jugée peu réaliste. Au pire, et c’est le plus souvent le cas, on la considère comme une hérésie.
L’hypothèse sous-jacente, c’est que certains projets sont tout simplement impossibles à réaliser en suivant l’approche itérative préconisée par les méthodes Agiles, et que, par conséquent, certains projets Waterfall, impossibles à réaliser de manière itérative, ne profitent jamais des avantages d’Agile. Cependant, cette hypothèse découle peut-être d’une interprétation un peu trop littérale du sens d’Agile.
La notion d’Agilité repose sur 4 valeurs et 12 principes. Mais, pour être Agiles, faut-il absolument respecter ces valeurs et principes au pied de la lettre? Est-ce une proposition « tout ou rien »? Peut-on être Agile à, disons, 75 %? Peut-on l’être à seulement 33 %? Et, dans ce dernier cas, l’application de ces valeurs et principes procure-t-elle au moins certains avantages?
Faut-il choisir entre Waterfall et Agile?
Considérons un de ces principes, sans doute mon préféré, le principe no 5 : « Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés. »
Qui a dit que ce principe peut seulement être appliqué avec succès lorsqu’on réalise des projets de manière itérative? D’après votre expérience, qu’est-ce qui empêcherait une entreprise d’appliquer ce principe dans le cadre d’un véritable projet Waterfall?
Permettez-moi de faire une mise au point : trop souvent, nous entendons parler du contraste entre la méthode Waterfall et la méthode Agile, quand ce sont plutôt les méthodes Waterfall et « Itérative » que nous devrions comparer. Et si nous devons comparer la gestion de projet Agile à quelque chose, comparons-la plutôt à des méthodes de gestion de projet de type « commandement et contrôle », « de haut en bas », ou « prédictive ».
Ainsi, nous pourrions adopter aussi bien des approches Waterfall/Prédictives que des approches Itératives/Agiles, mais également combiner des approches Waterfall/Agiles, n’est-ce pas?
Revenons au principe no 5 : pourrait-on l’appliquer à l’équipe d’un projet Waterfall? Quelles en seraient les conséquences concrètes sur la définition des rôles et des responsabilités dans le cadre du projet? Plus précisément, quels seraient les effets concrets de l’application de ce principe sur la définition des rôles de nos planificateurs et de nos agents d’ordonnancement?
La distinction entre planificateurs et agents d’ordonnancement
Le flou qui entoure la distinction entre les planificateurs et les agents d’ordonnancement nuit parfois aux entreprises et aux projets. Comme nous aimons à le répéter souvent, les mots sont importants. Les planificateurs comme les agents d’ordonnancement sont au fait des exigences de rigueur et de discipline associées à l’ordonnancement de projet, au chemin critique, aux pratiques exemplaires en matière de structures de répartition du travail (SRT), etc. Habituellement, les deux maîtrisent également, à divers degrés, des outils d’ordonnancement de projet comme Microsoft Project ou Oracle Primavera P6. La différence entre les uns et les autres, c’est que les planificateurs ont une connaissance intime de la façon de réaliser le travail, puisque la plupart ont déjà acquis une expérience dans ce domaine plus tôt dans leur carrière ou dans une autre vie. En contrepartie, les agents de planning, souvent de récents diplômés dont l’expérience concrète du travail est limitée, possèdent une connaissance plus approfondie des technologies utilisées pour créer des échéanciers de projets et les mettre à jour.
Autrement dit, les planificateurs en savent nettement plus sur la pose de canalisations et l’érection de structures que sur la façon d’utiliser MS Project, tandis que les agents d’ordonnancement en savent un peu sur la pose de canalisations et l’érection de structures, mais en savent énormément sur MS Project.
Pour établir un plan, l’agent d’ordonnancement dépend donc de la contribution de l’équipe. Le planificateur, quant à lui, pourrait être tenté de créer un plan au nom de l’équipe. Et c’est là que l’on déroge à la philosophie Agile. En effet, les échéanciers établis par les planificateurs sont un peu moins susceptibles de bénéficier du principe Agile no 5, mais également du principe no 11 : « Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées » (pour appliquer ce principe aux projets Waterfall, on remplacera « architecture, spécifications et conceptions » par « plans et échéanciers »).
On pourrait ainsi arguer que pour être véritablement Agile dans le cadre d’un projet Waterfall, on doit se fier moins aux planificateurs de projets qu’aux agents d’ordonnancement.
Qu’en pensez-vous?