Définition
Scrum est un cadre de travail (framework) au sein duquel les acteurs
peuvent aborder des problèmes complexes et adaptatifs, en livrant de
manière efficace et créative des produits de la plus grande valeur
possible. Trois qualités le caractérisent : léger, simple à comprendre,
difficile à maîtriser.
Il ne s'agit pas d'une méthode figée mais d'un cadre : Scrum n'est pas en
soi un processus, une technique ou une méthode définitive. C'est plutôt
un cadre de travail dans lequel vous pouvez utiliser différents processus et
techniques. L'article du blog résume bien l'esprit : le framework aide « les
personnes, les équipes et les organisations à générer de la valeur grâce à
des solutions adaptatives pour des problèmes complexes ».
Concept fondamental : l'empirisme
Scrum repose sur la théorie du contrôle empirique de processus.
L'empirisme affirme que la connaissance provient de l'expérience et la
prise de décisions est basée sur des faits connus.
Ce concept s'appuie sur 3 piliers :
Transparence : un langage et des standards communs partagés
par tous
Inspection : vérification fréquente des artefacts et de l'avancement
Adaptation : ajustement rapide dès qu'un écart est détecté
Et sur 5 valeurs : engagement, courage, focus, ouverture, respect.
À cela s'ajoutent 3 composantes concrètes : les rôles (Product Owner,
Équipe de développement, Scrum Master), les artefacts (Product
Backlog, Sprint Backlog, Incrément) et les 4 événements (Sprint
Planning, Daily Scrum, Sprint Review, Rétrospective), le tout organisé
autour du Sprint (cycle de 1 mois maximum).
Avantages
Adaptabilité : le Backlog Sprint peut être renégocié en cours de
route selon ce que l'équipe apprend, ce qui permet de réagir vite
aux changements de marché ou de besoins
Livraisons fréquentes : chaque Sprint produit un incrément
potentiellement publiable, donc de la valeur livrée régulièrement
plutôt qu'en fin de projet
Transparence forte : tout le monde partage la même vision de
l'avancement (Backlog, Definition of Done commune)
Équipe auto-organisée : personne, pas même le Scrum Master,
ne dicte à l'équipe comment transformer le Backlog en incrément —
cela favorise l'engagement et la créativité
Réduction du risque : le risque est plafonné à la durée d'un Sprint
(max 1 mois), et un Sprint peut être annulé si son objectif devient
obsolète
Amélioration continue intégrée via la Rétrospective à chaque
Sprint
Inconvénients
Exigeant en discipline : simple à comprendre, mais difficile à
maîtriser — les rôles, règles et événements sont indivisibles ; en
retirer une partie signifie ne plus faire du « vrai » Scrum
Charge de réunions perçue comme chronophage par certaines
équipes (Planning, Daily, Review, Rétro à chaque Sprint)
Nécessite une équipe pluridisciplinaire stable : taille optimale
entre 3 et 9 développeurs — trop petite, elle manque de
compétences ; trop grande, elle génère une coordination excessive
Dépend fortement du Product Owner : un PO peu disponible ou
peu légitime dans l'organisation fragilise tout le cadre
Peu adapté aux contextes où les exigences sont figées dès le
départ (type cahier des charges fermé) ou aux organisations très
hiérarchiques peu prêtes à l'auto-organisation
Scrum ne dit pas comment faire techniquement : il ne fournit
pas de pratiques d'ingénierie (tests, architecture...), il faut les
combiner avec d'autres méthodes (XP, Kanban, etc.)
Outils physiques couramment utilisés
Bien que le Guide Scrum lui-même ne prescrive aucun outil précis (il reste
volontairement silencieux sur les « tactiques »), la pratique du terrain a
développé des outils physiques classiques :
Tableau Scrum / Kanban physique (souvent un tableau blanc)
avec colonnes "À faire / En cours / Fini", reflétant le Sprint Backlog
Post-it / étiquettes pour représenter chaque élément du Backlog
Produit ou tâche du Sprint Backlog, déplacés au fil de l'avancement
Cartes de Planning Poker pour l'estimation collective des
éléments du Backlog (souvent en suite de Fibonacci)
Burndown chart (papier ou affiché) pour visualiser le travail
restant durant le Sprint
Minuteur / sablier pour respecter les time-box (15 min pour le
Daily Scrum, etc.)
Product Backlog imprimé ou affiché, mis à jour visuellement par
le Product Owner
Story mapping sur mur ou tableau pour organiser les
fonctionnalités par parcours utilisateur