Quand un chef de projet habitué aux méthodes prédictives (PRINCE2, HERMES, cycle en V) rejoint un environnement Scrum, le premier obstacle n’est pas technique: c’est linguistique. Sprint, Product Owner, Definition of Done, les termes se multiplient sans que leur correspondance avec les concepts classiques soit évidente. Certains ressemblent à des notions familières mais recouvrent des réalités différentes, ce qui crée des malentendus plus pernicieux qu’une ignorance franche.
Ce lexique raisonné ne vise pas à former des Scrum Masters. Il s’adresse aux praticiens qui collaborent avec des équipes Scrum et qui ont besoin de comprendre ce que ces mots signifient vraiment, pas seulement dans leur définition officielle, mais dans leur logique sous-jacente.
L’empirisme comme point de départ
Avant d’entrer dans le vocabulaire, un concept mérite d’être posé: l’empirisme. Le Guide Scrum de Ken Schwaber et Jeff Sutherland définit Scrum comme un cadre fondé sur l’empirisme, c’est-à-dire sur l’idée que les décisions doivent reposer sur l’observation et l’expérience plutôt que sur un plan détaillé établi en amont. Ce principe repose sur trois piliers: la transparence (l’information est visible par tous), l’inspection (on examine régulièrement le travail accompli) et l’adaptation (on ajuste le cap en fonction de ce qu’on observe).
Pour un chef de projet classique, ce changement de paradigme est fondamental: en gestion prédictive, la qualité du plan détermine la qualité du projet, alors qu’en Scrum, c’est la capacité à observer et ajuster qui prime, et le vocabulaire reflète cette philosophie.
Trois rôles, zéro chef de projet
Le cadre Scrum ne prévoit pas de rôle de chef de projet. Il définit trois responsabilités distinctes au sein de ce qu’il appelle la Scrum Team (l’équipe Scrum).
Le Product Owner (propriétaire du produit) est responsable de maximiser la valeur du produit. Il gère le Product Backlog (la liste ordonnée de tout le travail à réaliser), priorise les éléments et s’assure que l’équipe travaille sur ce qui apporte le plus de valeur. Il est souvent confondu avec un chef de projet, mais sa responsabilité porte sur le “quoi” (que construire et dans quel ordre), jamais sur le “comment” ni sur la gestion de l’équipe.
Le Scrum Master n’est ni un manager ni un coordinateur. Le Guide Scrum le décrit comme un facilitateur au service de l’équipe: il veille à ce que le cadre Scrum soit compris et appliqué, élimine les obstacles qui freinent l’équipe et protège l’espace de travail contre les interférences extérieures. Un chef de projet classique qui assisterait à un Daily Scrum en prenant des notes pour son reporting hiérarchique incarne exactement ce que le Scrum Master est censé empêcher.
Les Developers (développeurs) désignent dans le glossaire officiel Scrum tous les membres de l’équipe qui contribuent à créer l’incrément, quel que soit leur métier. Un designer, un testeur ou un analyste métier qui travaille dans une équipe Scrum est un Developer au sens du cadre. Cette terminologie prête à confusion hors du contexte informatique, mais le terme désigne une fonction (créer l’incrément), pas une compétence technique.
Trois artefacts, trois engagements
Scrum structure le travail autour de trois artefacts, chacun associé à un engagement qui lui donne son sens.
Le Product Backlog est la liste unique et ordonnée de tout ce qui pourrait être fait pour améliorer le produit. Son engagement est le Product Goal (objectif produit), une cible à moyen terme qui oriente les priorités. Pour un chef de projet classique, le Product Backlog ressemble à un registre des exigences, à la différence qu’il évolue en permanence et qu’il n’est jamais considéré comme complet.
Le Sprint Backlog est le sous-ensemble du Product Backlog que l’équipe sélectionne pour un sprint donné, accompagné d’un plan pour le réaliser. Son engagement est le Sprint Goal (objectif de sprint), un objectif cohérent qui donne un sens au travail du cycle. L’équipe s’engage sur cet objectif, pas sur une liste figée de tâches.
L’Increment (incrément) est le résultat concret et utilisable produit à chaque sprint. Il doit satisfaire la Definition of Done (définition de “terminé”), un ensemble de critères de qualité que l’équipe a formalisé. La Definition of Done joue un rôle comparable à des critères d’acceptation en gestion classique, mais elle s’applique à tout le travail de l’équipe de manière uniforme plutôt qu’exigence par exigence.
Cinq événements structurés par le temps
Le concept de timebox (boite de temps) est central en Scrum: chaque événement a une durée maximale fixe et non négociable. Le chef de projet habitué aux réunions qui s’étirent découvre ici un cadre strict.
Le Sprint est le conteneur de tous les autres événements, un cycle de travail de une à quatre semaines pendant lequel l’équipe produit un incrément. Un sprint ne se prolonge pas et ne se raccourcit pas en cours de route.
Le Sprint Planning (planification de sprint) ouvre chaque cycle: l’équipe sélectionne les éléments du Product Backlog et définit le Sprint Goal. Le Daily Scrum (mêlée quotidienne) est un point de synchronisation de quinze minutes réservé aux Developers pour coordonner leur travail, pas un rapport d’avancement au management. La Sprint Review (revue de sprint) ferme le cycle en présentant l’incrément aux parties prenantes et en recueillant leur retour pour adapter le Product Backlog. La Sprint Retrospective (rétrospective) permet à l’équipe d’examiner son propre fonctionnement et d’identifier des améliorations pour le prochain sprint.
La confusion la plus fréquente concerne la Sprint Review et la Sprint Retrospective: la première porte sur le produit (qu’avons-nous construit?), la seconde sur le processus (comment avons-nous travaillé?). Un chef de projet classique pourrait assimiler la Review à une réunion de validation de livrable et la Retrospective à un retour d’expérience de fin de phase, mais ces événements interviennent à chaque sprint, pas en fin de projet.
Un vocabulaire intentionnel
Ce qui distingue le lexique Scrum d’un simple jargon professionnel, c’est que chaque terme encode une contrainte de conception du cadre. L’absence de rôle de chef de projet n’est pas un oubli mais une redistribution délibérée des responsabilités entre trois fonctions complémentaires, et la timebox de quinze minutes du Daily Scrum traduit la conviction que la synchronisation quotidienne fonctionne mieux quand elle est brève et ciblée. Pour le chef de projet qui découvre cet univers, saisir l’intention derrière les mots permet de passer de la traduction terme à terme à une compréhension du système dans son ensemble.