Passer de la théorie Scrum à la pratique est le moment où la plupart des équipes hésitent. Le cadre de travail agile le plus répandu au monde tient en 15 pages (le Scrum Guide 2020), mais il ne dit presque rien sur la marche à suivre concrète pour démarrer. Voici ce qui se passe quand on décide de lancer Scrum sur un premier projet, jour après jour.
Jour 1: constituer l’équipe et attribuer les rôles
Scrum repose sur trois rôles distincts au sein d’une équipe qui compte idéalement entre 3 et 9 membres. Le Product Owner porte la vision du produit et décide de ce que l’équipe va construire, dans quel ordre. Le Scrum Master veille au respect du cadre Scrum et aide l’équipe à lever les obstacles qui ralentissent son travail. Les développeurs (ou membres de l’équipe, dans un contexte non-IT) réalisent concrètement le travail pendant chaque sprint, c’est-à-dire chaque cycle de travail itératif.
La première décision structurante est de ne pas cumuler les rôles de Product Owner et de Scrum Master sur la même personne. Le Product Owner pousse naturellement vers plus de contenu dans chaque sprint, tandis que le Scrum Master protège la capacité réelle de l’équipe. Confier ces deux responsabilités à une seule personne crée un conflit d’intérêts qui se manifeste dès les premières semaines, quand les arbitrages deviennent nécessaires.
Si vous êtes chef de projet et que vous lancez Scrum dans votre équipe, le rôle de Scrum Master est souvent le plus naturel pour vous au départ. Cherchez un Product Owner du côté métier, quelqu’un qui comprend les priorités utilisateur et qui a l’autorité de dire non à certaines demandes.
Jour 2: construire un backlog minimal et définir le “Done”
Le Product Backlog est la liste ordonnée de tout ce que l’équipe pourrait faire pour atteindre son objectif. L’erreur la plus fréquente des équipes débutantes consiste à vouloir rédiger un backlog exhaustif avant de commencer quoi que ce soit. Cette recherche de complétude est un piège: elle retarde le premier sprint de plusieurs semaines et donne une fausse impression de maîtrise.
En pratique, il suffit de disposer de suffisamment d’éléments pour remplir un sprint, soit une quinzaine d’items classés par priorité. Ces items prennent généralement la forme de user stories, des descriptions courtes d’un besoin utilisateur. Le critère INVEST (Indépendante, Négociable, Valuable, Estimable, Small, Testable) permet de vérifier qu’une story est correctement formulée: si elle est trop grosse pour tenir dans un sprint, il faut la découper.
En parallèle, l’équipe doit s’accorder sur sa Definition of Done (DoD), la liste des critères qui permettent d’affirmer qu’un élément de travail est réellement terminé. Sans cette définition partagée, chaque membre de l’équipe applique ses propres standards et le mot “terminé” perd tout sens. Pour un premier sprint, une DoD simple suffit: l’important est qu’elle existe et que tout le monde la connaisse.
Jour 3: planifier et lancer le premier sprint
La Sprint Planning, la réunion de planification du sprint, se déroule en deux temps. L’équipe commence par définir le Sprint Goal, l’objectif concret du sprint, puis sélectionne dans le backlog les items qui contribuent à cet objectif. Ensuite, les membres décomposent ces items en tâches opérationnelles pour construire le Sprint Backlog, le plan de travail du sprint.
Pour un premier sprint, la durée recommandée est de deux semaines. Les sprints courts créent des cycles d’apprentissage rapides, ce qui est essentiel quand l’équipe découvre le cadre. Un sprint de quatre semaines laisse trop de temps avant le premier feedback et repousse les ajustements nécessaires.
La notion de Sprint 0: un anti-pattern fréquent
Certaines équipes instaurent un “Sprint 0”, une itération préparatoire dédiée à la mise en place de l’environnement de travail, sans livrer de valeur. Cette pratique, souvent qualifiée d’anti-pattern par la communauté Scrum, pose un problème de principe: elle installe l’idée qu’un sprint peut exister sans produire d’incrément utilisable. Un à deux jours de préparation avant le premier sprint suffisent largement, à condition de résister à la tentation de tout anticiper.
Les rituels qui donnent son rythme au sprint
Quatre événements structurent chaque sprint. Le Daily Scrum (ou mêlée quotidienne) réunit l’équipe 15 minutes par jour pour synchroniser le travail en cours et signaler les blocages. La Sprint Review, en fin de sprint, est le moment où l’équipe présente l’incrément (le résultat concret du sprint) aux parties prenantes (stakeholders) et recueille leur feedback. La Sprint Retrospective, qui suit immédiatement la review, porte non pas sur le produit mais sur le fonctionnement de l’équipe: ce qui a bien marché, ce qui doit changer.
À ces événements prescrits s’ajoute en pratique le Backlog Refinement, une session régulière (souvent hebdomadaire) où l’équipe passe en revue les items qui pourraient entrer dans les prochains sprints. Le Scrum Guide n’impose ni la fréquence ni le format de cet affinage, mais la quasi-totalité des équipes expérimentées y consacrent entre 5 et 10% de leur capacité par sprint. Sans ce travail de préparation, la Sprint Planning devient un exercice chaotique où l’équipe découvre des items mal définis ou mal dimensionnés au moment où elle doit s’engager dessus.
Les pièges de la première itération
Deux erreurs reviennent systématiquement dans les premiers sprints. La première consiste à ajouter du travail en cours de sprint sous la pression d’une demande urgente. Toute nouvelle demande doit rejoindre le backlog et attendre le prochain sprint, sauf exception validée collectivement par l’équipe. Accepter des interruptions constantes vide le sprint de sa raison d’être.
La seconde erreur est de sauter la rétrospective au motif que l’équipe manque de temps. C’est précisément quand l’équipe est sous pression que la rétrospective est la plus utile, car c’est elle qui permet d’identifier les causes de cette pression et d’y remédier dès le sprint suivant. Une équipe qui ne fait pas de rétrospective pratique Scrum de nom, mais répète les mêmes erreurs d’un sprint à l’autre. Comme le recommande scrum.org, mieux vaut démarrer avec une seule équipe sur un seul projet et s’engager à respecter le cadre pendant au moins trois ou quatre sprints avant de juger des résultats.