Scrum tient en une vingtaine de pages : le Scrum Guide, écrit par Ken Schwaber et Jeff Sutherland, dont la dernière version date de novembre 2020. C'est volontairement peu. Scrum ne dit presque rien de la façon de faire le travail ; il installe un rythme, des responsabilités et des rendez-vous qui obligent l'équipe à regarder ce qui se passe vraiment.
Agile ou Scrum : la différence en deux phrases
L'agilité est une intention : avancer par petits pas, regarder le résultat avec les personnes concernées, et changer de cap quand la réalité le demande. Scrum est un cadre précis pour tenir cette intention, avec des règles du jeu écrites.
La confusion entre les deux coûte cher. Une organisation qui « passe à l'agile » en installant Scrum croit souvent que les rituels suffisent. Or Scrum ne fait que créer des occasions de voir ; ce que l'équipe a le droit de décider après avoir vu, Scrum ne peut pas le décréter. Voir l'agilité, c'est quoi ? et Scrum ou Kanban pour les autres façons d'être agile.
| Agilité | Scrum | |
|---|---|---|
| Nature | Valeurs et principes (manifeste de 2001) | Cadre de travail défini par le Scrum Guide |
| Ce qu'il prescrit | Rien de précis : une direction | 3 responsabilités, 5 événements, 3 artefacts |
| Alternatives | Kanban, XP, Lean et d'autres | Une option parmi elles |
| Échec typique | Le mot sans le changement | Les rituels sans les décisions |
Les trois piliers : transparence, inspection, adaptation
Scrum repose sur l'empirisme : on décide à partir de ce qu'on observe, pas de ce qu'on avait prévu. Trois conditions rendent cela possible. Elles sont enchaînées, et retirer l'une fait tomber les deux autres.
On pourrait croire qu'il suffit de s'adapter. Mais on ne peut s'adapter qu'à ce qu'on a examiné, et on ne peut examiner que ce qui est visible. D'où l'ordre : transparence, puis inspection, puis adaptation.
- Sans transparence, l'inspection porte sur une fiction. On revoit un tableau qui ne reflète pas la réalité, et les décisions qui en sortent reposent sur du vent. C'est le cas le plus fréquent, et le plus difficile à admettre, parce que rendre visible ce qui va mal suppose qu'on ne soit pas sanctionné pour l'avoir dit.
- Sans inspection, l'adaptation devient réactive et tardive. On corrige quand le problème est devenu visible de l'extérieur, c'est-à-dire trop tard et à un coût élevé.
- Sans adaptation, tout le reste est du décor. On rend visible, on regarde, on ne change rien. C'est la définition exacte du théâtre agile.
Pour savoir où en est une équipe, trois questions suffisent. Ce qui va mal est-il visible sans avoir à le demander ? Regarde-t-on à date fixe, même quand tout va bien ? La dernière rétrospective a-t-elle produit un changement observable ? Trois oui : l'empirisme fonctionne. Un non quelque part indique précisément où travailler.
L'équipe Scrum : une seule équipe, trois responsabilités
Scrum ne définit pas trois équipes, ni deux équipes et un chef. Il définit une seule équipe portant trois responsabilités distinctes. Cette nuance décide de tout le reste.
- Le Product Owner maximise la valeur du produit. Concrètement, c'est lui qui décide de l'ordre du backlog.
- Le Scrum Master est responsable de l'efficacité de l'équipe : il aide à installer Scrum, lève ce qui bloque, travaille avec le Product Owner et avec l'organisation.
- Les développeurs sont toutes les personnes qui construisent l'incrément, quel que soit leur métier : développement, design, test, rédaction, analyse.
Dans beaucoup d'organisations, le Product Owner est rattaché au métier et les développeurs à la DSI. Chacun a sa hiérarchie, ses objectifs et ses réunions. Le résultat est prévisible : on négocie au lieu de construire. Une équipe unique partage un objectif de sprint, une définition de fini et une responsabilité collective sur le résultat.
Ce que l'auto-organisation veut dire, et ne veut pas dire
L'équipe décide comment elle réalise le travail : la répartition, l'ordre technique, les pratiques, l'organisation interne du sprint. Elle ne décide pas seule quoi construire (cela relève du Product Owner), ni de sa propre composition, ni de son budget. L'auto-organisation est un périmètre d'autonomie précis, pas une absence de cadre.
C'est la source du malentendu le plus fréquent avec les managers, qui entendent parfois « plus personne ne décide » là où il faut lire : l'autorité sur le comment passe à ceux qui font.
Combien de personnes ?
Le Scrum Guide indique une équipe de 10 personnes ou moins en général : assez petite pour rester agile, assez grande pour produire un incrément utile. La raison est mécanique : le nombre de canaux de communication croît beaucoup plus vite que le nombre de personnes. La pluridisciplinarité compte encore davantage. Une équipe qui doit attendre une autre équipe pour livrer n'est pas autonome, et son rythme dépend de délais qu'elle ne maîtrise pas.
Le cycle d'un sprint
Le sprint est une durée fixe d'un mois au maximum, le plus souvent deux semaines. Il contient tous les autres événements :
- Sprint planning : l'équipe choisit un objectif de sprint et le travail qui permet de l'atteindre.
- Daily scrum : quinze minutes chaque jour pour se synchroniser vers l'objectif et ajuster le plan.
- Sprint review : l'équipe montre ce qu'elle a produit aux parties prenantes et ajuste le backlog avec elles.
- Rétrospective : l'équipe regarde sa façon de travailler et décide ce qu'elle change.
Trois artefacts rendent le travail visible, chacun avec un engagement : le backlog produit et son objectif de produit, le backlog de sprint et son objectif de sprint, l'incrément et sa définition de fini. Le détail des durées et des dérives est sur la page les événements Scrum.
Ce qui coince le plus souvent
Prenez une équipe qui a tout installé en trois semaines : les rôles, les sprints de deux semaines, l'outil, le tableau. Six mois plus tard, le périmètre et la date sont toujours fixés par un comité, le Product Owner transmet les décisions, et la rétrospective ressort les mêmes irritants. Scrum est en place ; rien de ce qu'il rend visible ne peut être changé.
Les blocages récurrents ne viennent presque jamais des règles de Scrum elles-mêmes. Ils viennent de ce qui l'entoure :
- un Product Owner sans mandat, qui ne peut ni dire non ni changer l'ordre ;
- un financement par projet à périmètre et date fixés d'avance, qui ne laisse rien à arbitrer ;
- une vélocité devenue objectif, comparée entre équipes, donc gonflée ;
- des dépendances à d'autres équipes qui empêchent de livrer quoi que ce soit de fini en un sprint.
Si vous reconnaissez votre équipe, le test agilité de façade aide à localiser le rituel qui tourne à vide. Et pour pratiquer Scrum de bout en bout avant d'en apprendre le vocabulaire, le parcours Agilité et Scrum consacre une journée entière au cadre.
Sources
- Ken Schwaber et Jeff Sutherland, The Scrum Guide, novembre 2020 : piliers, responsabilités, événements, artefacts et engagements, taille de l'équipe.
- Manifeste pour le développement agile de logiciels, 2001.
Sources vérifiées le 9 novembre 2026.