Scrum
Livrez un incrément produit toutes les 2 semaines. Le cadre agile de Ken Schwaber et Jeff Sutherland pour structurer le développement par sprints itératifs.
Description
Scrum est un cadre de travail agile créé par Ken Schwaber et Jeff Sutherland en 1995, qui organise le développement produit en cycles courts appelés sprints (2 à 4 semaines), avec des rôles définis (Product Owner, Scrum Master, Developers), des événements structurés et un objectif clair : livrer un incrément de produit fonctionnel et potentiellement livrable à la fin de chaque sprint. Sa finalité : permettre aux équipes de livrer de la valeur de manière continue, prévisible et adaptable. Schwaber et Sutherland ont présenté Scrum pour la première fois à la conférence OOPSLA en 1995, s'inspirant de l'article "The New New Product Development Game" de Hirotaka Takeuchi et Ikujiro Nonaka (Harvard Business Review, 1986) qui comparait les équipes produit performantes à une mêlée de rugby. Le Scrum Guide, document de référence régulièrement mis à jour (dernière version : 2020), tient en 13 pages. Scrum fonctionne comme un moteur à quatre temps : le Sprint Planning définit le quoi et le comment, le Daily Scrum synchronise l'équipe en 15 minutes, la Sprint Review montre ce qui a été construit aux parties prenantes, et la Sprint Retrospective améliore le processus. Le Product Owner gère le Product Backlog (la liste ordonnée de tout ce que le produit pourrait contenir), le Scrum Master facilite le processus et élimine les obstacles, les Developers s'engagent sur un Sprint Goal et s'auto-organisent pour l'atteindre. Ce qui distingue Scrum des autres approches agiles, c'est la timebox non négociable du sprint : le scope peut changer, mais la durée reste fixe. Cette contrainte de temps force les décisions de priorisation que les équipes évitent quand le horizon est flou. Avec plus de 87% des équipes agiles utilisant Scrum ou un dérivé selon le State of Agile Report, c'est le framework agile le plus adopté au monde.
Objectifs
- Prioriser le travail
- Structurer le développement
- Améliorer la collaboration d'équipe
Utilisé par
- -Spotify (a utilisé Scrum comme base de son modèle d'organisation en squads, tribes et chapters)
- -Google (applique Scrum dans de nombreuses équipes produit, notamment pour le développement d'Android et de Google Cloud)
- -Airbnb (utilise Scrum pour structurer le développement de sa plateforme et synchroniser ses équipes produit distribuées)
Avantages
- Livraison prévisible et régulière. Le sprint de durée fixe crée un rythme que les parties prenantes apprennent à anticiper, ce qui réduit les "c'est prêt quand ?" de 80%.
- Feedback rapide et continu. Chaque Sprint Review expose l'incrément aux utilisateurs et stakeholders, ce qui corrige la trajectoire toutes les 2 semaines au lieu de tous les 6 mois.
- Cadre léger et documenté en 13 pages. Le Scrum Guide est le framework agile le plus concis et le plus accessible, applicable dès la première semaine.
- Adapté aux équipes de toute taille. Fonctionne pour une équipe de 5 personnes comme pour une organisation de 500 (via Scrum@Scale ou SAFe).
Limites
- Nécessite un Product Owner avec un vrai pouvoir de décision. Si le PO doit demander l'approbation d'un comité pour chaque priorisation, Scrum devient un goulot d'étranglement au lieu d'un accélérateur.
- Moins adapté aux équipes de maintenance ou de support. Les sprints de 2 semaines avec un scope fixe conviennent mal aux équipes qui gèrent du flux continu d'incidents. Kanban est souvent plus adapté.
- Risque de "Scrum mais...". Les équipes qui adoptent les cérémonies sans les principes (auto-organisation, engagement, transparence) pratiquent un théâtre agile qui génère frustration et désillusion.
- Le Sprint peut créer une pression artificielle. Si le Sprint Goal est systématiquement trop ambitieux, l'équipe accumule de la dette technique pour "finir à temps", ce qui détruit la qualité à moyen terme.
Comment appliquer Scrum
- 1
Constituer l'équipe Scrum
Une équipe Scrum se compose d'un Product Owner (responsable du quoi), d'un Scrum Master (responsable du comment) et de Developers (responsables de la réalisation). La taille idéale est de 5 à 9 personnes au total. Au-delà, la communication se dégrade. Le Product Owner est une seule personne, pas un comité. Si personne n'a le pouvoir de prioriser le backlog, Scrum ne fonctionnera pas. Output : équipe Scrum formée avec rôles assignés.
- 2
Créer et ordonner le Product Backlog
Le Product Owner crée une liste ordonnée de tout ce que le produit doit contenir : fonctionnalités, bugs, améliorations, dette technique. Chaque item doit être formulé en termes de valeur utilisateur. Les items en haut du backlog sont détaillés et prêts à être développés, ceux en bas sont des idées grossières. Le backlog n'est jamais figé, il évolue à chaque sprint. Output : Product Backlog initial ordonné par valeur.
- 3
Planifier le premier sprint (Sprint Planning)
L'équipe se réunit pour définir le Sprint Goal (l'objectif du sprint) et sélectionner les items du backlog à développer. La durée du Sprint Planning est proportionnelle à la durée du sprint : 4 heures max pour un sprint de 2 semaines. Les Developers décomposent chaque item en tâches et estiment si l'ensemble est réalisable dans le sprint. Output : Sprint Backlog avec Sprint Goal défini.
- 4
Exécuter le sprint avec les Daily Scrums
Pendant le sprint, les Developers travaillent sur les items du Sprint Backlog. Chaque jour, l'équipe se synchronise en 15 minutes (Daily Scrum) : qu'est-ce que j'ai fait, qu'est-ce que je vais faire, qu'est-ce qui me bloque ? Le Scrum Master élimine les obstacles. Aucun changement de scope n'est imposé pendant le sprint : si un item urgent apparaît, il entre dans le prochain sprint (sauf décision du Product Owner d'annuler le sprint en cours). Output : incrément de produit en cours de construction.
- 5
Présenter l'incrément en Sprint Review
À la fin du sprint, l'équipe présente l'incrément terminé aux parties prenantes. Ce n'est pas un PowerPoint, c'est une démo fonctionnelle. Les stakeholders donnent leur feedback, le Product Owner met à jour le backlog en conséquence. La Sprint Review est une inspection du produit, pas une validation. Output : feedback des parties prenantes intégré au backlog.
- 6
Améliorer le processus en Sprint Retrospective
Après la Review, l'équipe se retrouve entre elle pour inspecter son propre fonctionnement. Qu'est-ce qui a bien marché ? Qu'est-ce qui peut être amélioré ? L'équipe s'engage sur 1 à 3 améliorations concrètes pour le prochain sprint. Une retrospective sans action concrète est une perte de temps. Output : 1 à 3 améliorations du processus engagées.
- 7
Itérer sprint après sprint
Chaque sprint recommence le cycle : Planning, Daily Scrums, Review, Retrospective. Le Product Owner affine continuellement le backlog (refinement) pour que les 2 à 3 prochains sprints aient des items suffisamment détaillés. Le rythme fixe du sprint crée une cadence prévisible que les stakeholders apprennent à respecter. Output : livraison continue d'incréments à chaque sprint.
- 8
Mesurer et ajuster la vélocité
Après 3 à 5 sprints, l'équipe a une vélocité stable (nombre de points ou d'items livrés par sprint). Cette vélocité permet de projeter des dates de livraison réalistes et de calibrer les engagements futurs. Ne comparez jamais la vélocité entre équipes : elle est propre à chaque équipe et n'a de sens qu'en interne. Output : vélocité mesurée et utilisée pour la planification.