Un cadre né du refus de la planification rigide
La gestion de projet classique repose sur une promesse implicite: si le plan est suffisamment détaillé, l’exécution suivra. On définit le périmètre, on estime les coûts, on trace un diagramme de Gantt et le projet se déroule selon la séquence prévue. Cette approche, souvent appelée waterfall ou cycle en cascade, a fait ses preuves pour les projets dont les exigences sont stables et bien comprises dès le départ, comme la construction d’un pont ou l’installation d’une chaîne de production.
Mais pour les projets où les besoins évoluent au fil du temps, où les parties prenantes (stakeholders) précisent leurs attentes à mesure qu’elles voient les premiers résultats, cette logique séquentielle atteint ses limites. C’est dans ce contexte que Scrum propose une alternative. L’agile est une philosophie, pas une méthode: elle regroupe un ensemble de principes formalisés en 2001 par le Manifeste Agile, qui privilégie les individus et les interactions, la collaboration avec le client et la réponse au changement. Scrum est l’un des cadres de travail, ou frameworks, qui mettent cette philosophie en pratique, aux côtés de Kanban ou de SAFe.
Né au milieu des années 1990 sous l’impulsion de Jeff Sutherland et Ken Schwaber, Scrum structure le travail autour de trois ruptures fondamentales avec l’approche classique.
Le périmètre devient variable
La première rupture concerne le traitement du périmètre. En approche traditionnelle, le périmètre est fixe: on définit exactement ce qui sera livré, et le budget ainsi que le calendrier s’ajustent. Scrum inverse cette logique: le temps est fixé grâce au sprint, une itération de durée constante, généralement deux semaines, qui ne dépasse jamais un mois. Le budget est stable puisque l’équipe reste la même d’un sprint à l’autre. C’est le périmètre qui varie: à chaque sprint, l’équipe choisit les éléments les plus prioritaires du Product Backlog, la liste ordonnée de tout ce qui reste à réaliser sur le produit.
Pour un chef de projet formé aux méthodes prédictives, cette inversion est souvent déroutante. Accepter que le contenu final du produit ne soit pas entièrement défini au démarrage ressemble à un aveu de faiblesse. En réalité, c’est une décision pragmatique: les exigences recueillies en début de projet sont rarement exhaustives, et planifier dans le détail un périmètre incomplet conduit souvent à replanifier en cours de route, ce qui génère exactement l’instabilité que le plan initial était censé prévenir.
Des rôles redistribués
La deuxième rupture porte sur les rôles. En gestion de projet classique, le chef de projet concentre la planification, le suivi et la prise de décision. Scrum distribue ces responsabilités entre trois rôles complémentaires. Le Product Owner, qui représente les utilisateurs et les parties prenantes, décide de ce qui entre dans le produit et priorise le travail. Le Scrum Master facilite l’application du cadre, lève les obstacles et protège l’équipe des perturbations extérieures, sans pour autant jouer le rôle de supérieur hiérarchique. Les développeurs, terme qui désigne tout membre de l’équipe contribuant à la création du produit et pas uniquement des informaticiens, sont auto-organisés: ils décident eux-mêmes comment accomplir le travail pendant le sprint.
Ce partage des responsabilités est plus qu’un ajustement organisationnel. Il modifie la posture du chef de projet, qui passe du contrôle direct à la facilitation. Dans certaines organisations, le chef de projet traditionnel évolue vers le rôle de Scrum Master; dans d’autres, il devient Product Owner. La transition n’est jamais neutre, car elle implique de renoncer à une partie du contrôle sur le quotidien de l’équipe.
Une cadence qui crée du feedback
La troisième rupture concerne le rythme. Un projet en cascade progresse vers une livraison unique en fin de parcours. Scrum impose une cadence régulière: chaque sprint produit un incrément, un résultat tangible et potentiellement utilisable. Quatre événements structurent ce cycle. Le Sprint Planning ouvre le sprint en définissant l’objectif et les éléments à réaliser. La mêlée quotidienne, ou Daily Scrum, synchronise l’équipe chaque jour en quinze minutes. La Sprint Review présente les résultats aux parties prenantes pour recueillir du feedback. La Sprint Retrospective permet à l’équipe d’améliorer ses propres pratiques.
Cette cadence régulière crée un mécanisme de feedback qui n’existe pas dans l’approche séquentielle. Les parties prenantes voient le produit se construire toutes les deux semaines, peuvent réagir et réorienter les priorités. L’équipe identifie ses dysfonctionnements à chaque rétrospective au lieu de les accumuler jusqu’au bilan de fin de projet. L’information circule plus vite, ce qui permet des corrections de trajectoire plus fréquentes et moins coûteuses.
Le vrai défi est culturel
Le Guide Scrum, document de référence rédigé par Schwaber et Sutherland et librement accessible sur scrumguides.org, tient en une vingtaine de pages. Les règles du cadre sont volontairement simples: trois rôles, trois artefacts (Product Backlog, Sprint Backlog et incrément), cinq événements. Le défi n’est pas intellectuel, il est culturel: Scrum exige de faire confiance à l’équipe pour s’organiser, d’accepter l’incertitude sur le périmètre final et de mesurer la progression par la valeur livrée plutôt que par le respect d’un plan.
Pour un praticien habitué aux méthodes classiques, la question n’est pas de savoir si Scrum est objectivement meilleur que le waterfall, car chaque approche a son domaine de pertinence. La question pertinente est de savoir si le projet présente un degré d’incertitude qui justifie une approche itérative: plus les exigences sont susceptibles de changer et plus le feedback des utilisateurs est déterminant, plus Scrum devient un cadre pertinent pour organiser le travail.