Scrum : comment fonctionne ce framework agile

Qu'est-ce que Scrum ?

Scrum est un framework agile de gestion de projet dans lequel une équipe livre un produit par itérations courtes appelées sprints, généralement de deux semaines. À la fin de chaque sprint, l'équipe produit un incrément utilisable. Le cadre fixe trois accountabilities (responsabilités), cinq événements et trois artefacts ; les choix techniques restent à l'équipe.

Le mot vient du rugby, où le « scrum » désigne la mêlée, un groupe soudé qui avance ensemble vers un but. La méthode revendique l'image. Au lieu de tout planifier au départ et de livrer à la fin, Scrum découpe le projet en petits cycles et fait avancer une équipe pluridisciplinaire sprint après sprint, en corrigeant le tir à chaque fois.

Un point de vocabulaire : Scrum est un framework, c'est-à-dire un cadre léger, et non une méthode figée. Sa source primaire est le Scrum Guide (Schwaber & Sutherland, version 2020), le court document de référence qui fixe la définition officielle du cadre et son vocabulaire. Il dit qui fait quoi et à quel rythme, mais pas comment coder, tester ou concevoir. C'est ce qui explique son succès : il s'adapte à des contextes très différents. Scrum est aujourd'hui le cadre agile le plus répandu dans le développement logiciel, et il est l'une des déclinaisons concrètes de la méthode agile.

Les trois accountabilities (responsabilités) de Scrum

Le Scrum Guide 2020 ne parle plus de rôles mais de trois accountabilities (responsabilités) : le Product Owner, qui porte la vision du produit et priorise le travail ; le Scrum Master, qui fait vivre la méthode et lève les obstacles ; et les Developers (les développeurs), qui conçoivent et construisent l'incrément. Ensemble, ces trois responsabilités forment l'équipe Scrum, sans hiérarchie interne.

Une nuance importante : dans Scrum, personne ne « commande » au sens classique. Il n'y a pas de chef de projet qui distribue les tâches. La responsabilité est répartie entre trois accountabilities complémentaires, le terme que le Scrum Guide 2020 emploie à la place de « rôles ».

Le product owner

Le product owner (propriétaire du produit) est le porteur de la valeur. C'est lui qui sait ce que le produit doit accomplir et pour qui. Il alimente et priorise le product backlog, tranche les arbitrages et décide de ce qui compte le plus. Il représente les intérêts des utilisateurs et de l'entreprise. S'il fait ce travail à moitié, l'équipe construit vite, mais pas forcément la bonne chose.

Le scrum master

Le scrum master fait vivre la méthode et facilite le travail de l'équipe. Il organise les événements, aide l'équipe à mieux travailler ensemble et surtout lève les obstacles qui la ralentissent. Le mot « master » trompe : il ne commande pas, il sert. Il n'assigne pas les tâches, ne fixe pas les priorités du produit, n'évalue pas les personnes ; son autorité est morale, jamais hiérarchique. Son service s'exerce sur trois fronts :

• Auprès des Developers. Il veille à ce que les événements restent utiles, protège l'équipe des sollicitations extérieures et des changements de cap en cours de sprint, et l'aide à gagner en autonomie jusqu'à avoir de moins en moins besoin de lui.
• Auprès du product owner. Il aide le product owner à tenir un backlog clair et à préparer les affinages, sans jamais empiéter sur ses décisions de contenu.
• Auprès de l'organisation. Il aide les autres services à travailler avec l'équipe sans casser son rythme.

Sur un projet confié à un prestataire, regardez la liste des obstacles qu'il tient. Un accès manquant, un validateur injoignable, une décision qui traîne : ceux-là se trouvent souvent de votre côté. Le scrum master peut les rendre visibles, les lever vous revient.

Ne le prenez pas non plus pour votre chef de projet. Le chef de projet planifie, assigne les tâches et répond des délais et de l'enveloppe ; le scrum master aide une équipe à s'organiser elle-même. Le présenter comme « le chef de projet agile » est une confusion fréquente, et elle laisse sans titulaire la question « tiendra-t-on la date et l'enveloppe ? ». Quelqu'un doit la porter, côté maîtrise d'ouvrage comme côté prestataire, et ce n'est pas lui.

Deux points à vérifier quand une proposition mentionne ce rôle. Le cumul avec le product owner est déconseillé : l'un pousse pour livrer plus de valeur quand l'autre protège le rythme et la santé de l'équipe. Et l'intensité doit suivre la maturité. Une équipe qui découvre Scrum a besoin d'un scrum master présent et dédié ; une équipe rodée peut le partager avec une autre équipe, ou confier le rôle à l'un de ses membres dont la charge de développement est allégée d'autant. Un scrum master de nom, sans temps ni mandat réel, ne sert à rien.

Les Developers (développeurs)

Les Developers (le terme du Scrum Guide 2020 pour l'ancienne équipe de développement) regroupent les personnes qui construisent le produit : développeurs, mais aussi designers, testeurs ou tout profil nécessaire. Le groupe est pluridisciplinaire et auto-géré : il décide lui-même comment atteindre l'objectif du sprint. Petit par nature (le Scrum Guide recommande une équipe Scrum de dix personnes ou moins), il est responsable collectivement de la qualité de l'incrément livré.

Les cinq événements Scrum

Scrum s'articule autour de cinq événements cadencés : le sprint lui-même, qui contient tous les autres ; le sprint planning, qui l'ouvre ; le daily scrum (mêlée quotidienne), un point court chaque jour ; la sprint review, où l'équipe présente l'incrément ; et la rétrospective, où elle améliore sa façon de travailler. Ces rituels donnent au projet son rythme régulier.

Ces événements ne sont pas de la bureaucratie. Chacun répond à une question précise : que fait-on ce sprint, où en est-on aujourd'hui, qu'a-t-on produit, comment progresser.

• Le sprint : l'itération elle-même, d'une à quatre semaines, à durée fixe. C'est l'événement qui contient les quatre autres.
• Le sprint planning : la planification qui ouvre le sprint, où l'équipe choisit ce qu'elle s'engage à livrer et se donne un objectif de sprint clair.
• Le daily scrum (mêlée quotidienne) : un point de quinze minutes, chaque jour, debout de préférence. L'équipe s'y synchronise : ce qui avance, ce qui bloque, ce qui est prévu ensuite. C'est une coordination entre pairs, pas un compte rendu au chef.
• La sprint review (revue de sprint) : à la fin du sprint, l'équipe montre l'incrément aux parties prenantes et recueille leurs retours. C'est le moment de la confrontation au réel, où l'on ajuste la suite en fonction de ce qui a été vu.
• La rétrospective : juste après la revue, l'équipe examine sa propre façon de travailler et décide d'une ou deux améliorations concrètes pour le sprint suivant. C'est le moteur d'amélioration continue de Scrum, et le rituel que l'on sacrifie le plus souvent à tort.

Les artefacts de Scrum

Scrum s'appuie sur trois artefacts, c'est-à-dire trois documents ou livrables qui rendent le travail visible : le product backlog, la liste priorisée de tout ce qui reste à faire ; le sprint backlog, ce que l'équipe s'engage à faire pendant le sprint en cours ; et l'incrément, la version fonctionnelle du produit livrée à la fin du sprint.

Un artefact, dans Scrum, sert à donner de la transparence. Il permet à tout le monde de voir où en est le travail et ce qui reste à accomplir, sans avoir à demander.

Le product backlog n'est jamais figé : il s'affine à mesure que l'on apprend. Le sprint backlog se remplit au moment de la planification. L'incrément, lui, doit répondre à une exigence claire, la « définition de terminé » (definition of done), qui fixe ce que signifie vraiment « fini » pour éviter le faux achèvement.

Comment se déroule un sprint, de bout en bout

Un sprint se déroule en quatre temps : la planification, où l'équipe choisit ce qu'elle va livrer ; le développement quotidien, rythmé par la mêlée ; la revue, où elle présente l'incrément ; et la rétrospective, où elle améliore sa méthode. Le sprint suivant repart aussitôt, sur ce qui a été appris.

Le fil d'un sprint de deux semaines, tel que je le vois tourner sur le terrain :

1. Planification. L'équipe et le product owner examinent le haut du product backlog, choisissent ce qui entre dans le sprint et formulent un objectif de sprint. Ce qui est retenu devient le sprint backlog.
2. Exécution. Pendant deux semaines, l'équipe construit. Chaque matin, la mêlée quotidienne synchronise tout le monde et fait remonter les blocages. Le scrum master s'occupe de les lever.
3. Revue. En fin de sprint, l'équipe présente l'incrément aux parties prenantes. Les retours nourrissent la suite du backlog. C'est ici que se joue l'adaptation.
4. Rétrospective. L'équipe fait le point sur sa manière de travailler et choisit une amélioration à tester au sprint suivant.

Au fil des sprints, l'équipe mesure sa vélocité, c'est-à-dire la quantité de travail qu'elle achève en moyenne par sprint. Cette donnée l'aide à s'engager sur un volume réaliste, sans se surcharger. C'est un repère interne de planification, pas une note de performance à comparer entre équipes.

Un objectif de sprint qui décrit une valeur, pas des tâches

L'objectif de sprint (sprint goal) se formule au sprint planning. Un bon objectif décrit une valeur livrée, pas une liste de tâches : « permettre à un utilisateur de finaliser sa commande » plutôt que « coder l'écran de paiement ». Formulé ainsi, il se relit sans connaître le code, et c'est ce que je demande à lire en premier quand je pilote pour le client. Il sert ensuite de boussole : quand un imprévu surgit en cours de route, l'équipe sait ce qu'elle doit protéger et ce qu'elle peut laisser de côté. Sans lui, elle empile des tâches et finit le sprint sans savoir si elle a réussi, faute de critère de réussite.

Une durée fixe : ce qui n'est pas fini repart dans le backlog

La durée d'un sprint ne bouge pas, le périmètre oui. Ce qui n'est pas terminé à la date prévue ne prolonge pas le sprint et ne compte pas dans sa vélocité : il retourne au product backlog, où le product owner le repriorise, et ne repart au sprint suivant que s'il reste la chose la plus utile à faire. Cette discipline protège le rythme, garde la vélocité mesurable et évite les sprints qui débordent en silence. Elle suppose une définition de terminé nette : sans elle, un incrément déclaré fini n'est pas vraiment utilisable, et une dette invisible s'accumule jusqu'à ressortir plus tard.

Scrum ou Kanban : choisir selon la nature du travail

Scrum convient quand le travail se planifie par lots et se livre par itérations, comme le développement d'un produit. Kanban convient mieux au flux continu, quand les demandes arrivent en permanence, comme la maintenance ou le support. Le choix dépend de la nature du travail, pas d'une préférence de principe, et beaucoup d'équipes combinent les deux.

Kanban est l'autre grand cadre agile. Là où Scrum cadence le travail en sprints avec des rôles définis, Kanban se concentre sur la visualisation du flux et la limitation du travail en cours, sans itérations imposées. Ni l'un ni l'autre n'est « meilleur » : ils répondent à des rythmes de travail différents. Un projet neuf avec une feuille de route se prête bien à Scrum ; une équipe qui absorbe un flot continu de tickets se sentira à l'étroit dans des sprints et sera plus à l'aise en Kanban. Le cadre compte moins que l'intention agile qui le sous-tend, comme je l'explique dans ma comparaison entre agile et cycle en V.

Scrum et ses limites en pratique

Scrum donne d'excellents résultats quand l'équipe a un vrai product owner disponible, une direction qui accepte l'incertitude et la discipline de tenir ses rituels. Il échoue quand on l'applique comme un rituel vide : des sprints sans objectif clair, un backlog mal tenu ou une rétrospective sacrifiée transforment le cadre en théâtre.

Ce que j'observe le plus souvent, c'est un Scrum « de façade ». On garde les rituels et le vocabulaire, mais on a perdu l'intention. Quelques symptômes reviennent sans cesse :

• Un product owner absent ou sans pouvoir de décision, qui ne peut pas prioriser vraiment. L'équipe avance à vide.
• Des sprints qu'on rallonge pour « finir », ce qui casse le rythme et la mesure de la vélocité.
• Une rétrospective expédiée ou supprimée, donc aucune amélioration réelle d'un sprint à l'autre.
• Une direction qui exige un planning figé à douze mois tout en réclamant de l'agilité. Les deux ne tiennent pas ensemble.
• Un sprint backlog chargé au-delà du réaliste, parce qu'on promet trop pour faire plaisir. La qualité baisse, le stress monte, et le report au sprint suivant devient une habitude.
• Des priorités changées en plein sprint par une direction ou un client pressé. L'engagement et la mesure ne veulent alors plus rien dire : une fois le sprint lancé, je le protège, y compris contre les demandes de dernière minute, qui attendent le planning suivant.

Scrum n'est pas une baguette magique, et surtout pas une religion. C'est un cadre qui rend service quand on comprend pourquoi chaque pièce existe. Sur mes projets, je pilote en Scrum quand le contexte s'y prête, en gardant ce qui a du sens et en assumant d'adapter le reste. La compétence utile est de savoir quand s'écarter du cadre, pas de le réciter.