Scrum,
sans le jargon.

Scrum est le cadre agile le plus utilisé au monde, et le plus souvent mal appliqué. Trois rôles, cinq événements, trois artefacts : c'est tout. La difficulté n'est pas de le comprendre, elle est de ne pas le vider de son sens.

Ce que Scrum est, et n'est pas

Scrum est un cadre de travail léger pour développer des produits complexes, structuré autour de cycles courts et de durée fixe appelés sprints. Il met en œuvre les principes agiles avec un minimum de règles obligatoires.

Scrum n'est pas une méthodologie de gestion de projet, pas un outil, et pas un processus de développement logiciel complet. Il ne vous dit rien sur la façon d'écrire du code, de tester ou de déployer. Il vous dit comment décider quoi faire ensuite, et comment vérifier que vous vous trompez le moins possible.

Les 3 rôles

Le Product Owner

Une seule personne, jamais un comité. Elle est responsable de la valeur du produit : elle possède le backlog, en fixe l'ordre, et tranche quand deux parties prenantes veulent des choses contradictoires. Sans autorité réelle de décision, le rôle devient un poste de transmission — et le projet ralentit à chaque arbitrage.

Les développeurs

L'équipe qui construit. Trois à neuf personnes, avec toutes les compétences nécessaires pour livrer un incrément utilisable : conception, code, test, déploiement. Elle est auto-organisée — elle décide comment faire le travail, pas quoi faire en premier.

Le Scrum Master

Le rôle le plus mal compris. Ce n'est ni un chef de projet, ni un chef d'équipe, ni un secrétaire de réunion. Sa fonction est de faire fonctionner le cadre : lever les obstacles, protéger l'équipe des interruptions, et rendre visibles les dysfonctionnements que tout le monde préfère ignorer. Un bon Scrum Master rend son propre rôle de moins en moins nécessaire.

Les 5 événements

• Le sprint lui-même : un cycle de durée fixe, une à quatre semaines. Sa durée ne change pas d'un sprint à l'autre. À la fin, il existe un incrément potentiellement livrable.
• La planification de sprint : l'équipe choisit ce qu'elle prend dans le backlog et formule l'objectif du sprint. Durée typique : deux heures par semaine de sprint.
• La mêlée quotidienne : quinze minutes, debout, pour l'équipe et non pour un chef. La question utile n'est pas « qu'as-tu fait hier ? » mais « qu'est-ce qui nous empêche d'atteindre l'objectif du sprint ? ».
• La revue de sprint : on montre l'incrément qui fonctionne aux parties prenantes et on récolte du retour. Pas de diapositives, pas de captures d'écran : le logiciel qui tourne.
• La rétrospective : l'équipe examine sa propre façon de travailler et choisit une amélioration concrète pour le sprint suivant.

Les 3 artefacts

• Le product backlog : la liste ordonnée de tout ce qui pourrait être fait. Vivant, jamais complet, affiné en continu.
• Le sprint backlog : ce que l'équipe s'engage à faire pendant le sprint, plus son plan pour y arriver.
• L'incrément : la somme de tout ce qui est terminé, dans l'état où on pourrait le mettre en production.

La définition de « fini » : la règle qui sauve les projets

C'est l'élément le plus souvent négligé et le plus rentable. La definition of done est le critère explicite, partagé, qui décide si une tâche est terminée. Une définition sérieuse ressemble à ceci :

• Le code est revu par un pair et fusionné.
• Les tests automatisés couvrent le comportement et passent en intégration continue.
• Aucun nouveau code smell bloquant n'est introduit.
• La documentation utilisateur ou technique est à jour.
• La fonctionnalité est déployée en préproduction et validée par le Product Owner.

Sans ce critère, « fini » veut dire ce que chacun veut bien y mettre. Le travail non fait ne disparaît pas : il devient de la dette technique, et il revient plus cher.

Scrum ou Kanban ?

Scrum protège la concentration avec un périmètre gelé pendant le sprint : c'est ce qui le rend adapté au développement de produit, où la priorité principale tient plusieurs semaines. Kanban accepte le flux continu et limite le travail en cours : c'est ce qui le rend adapté au support, à la maintenance et aux équipes plateforme, où un incident ne demande pas la permission d'arriver.

Beaucoup d'équipes matures font du Scrum avec des limites de travail en cours empruntées à Kanban. C'est un bon compromis, et personne ne viendra vous retirer votre certificat.

Les signes que votre Scrum est vide

1. Le périmètre du sprint change en cours de route, toutes les semaines.
2. La mêlée quotidienne dure quarante minutes et sert à rapporter au gestionnaire.
3. La revue de sprint se fait sur des diapositives parce que rien n'est déployable.
4. Les actions de rétrospective ne sont jamais mises dans le backlog, donc jamais faites.
5. Le Product Owner doit demander l'autorisation à trois personnes avant de trancher.
6. La vélocité est affichée à côté du nom des équipes et comparée en réunion de direction.

Questions fréquentes

Quels sont les 3 rôles de Scrum ?

Le Product Owner, responsable de la valeur du produit et de l'ordre du backlog ; les développeurs, l'équipe qui conçoit, code, teste et livre l'incrément ; et le Scrum Master, qui fait fonctionner le cadre et lève les obstacles.

Quelle est la différence entre Scrum et agile ?

Agile est un ensemble de valeurs et de principes. Scrum est un cadre concret qui les applique avec des rôles, des événements et des artefacts définis. Scrum est agile, mais l'agilité ne se limite pas à Scrum.

Combien de temps doit durer une mêlée quotidienne ?

Quinze minutes maximum, quelle que soit la taille de l'équipe. C'est un point de synchronisation entre développeurs pour lever les blocages, pas un rapport de statut à un gestionnaire.

Qu'est-ce que la definition of done en Scrum ?

C'est le critère explicite et partagé qui décide qu'un élément est terminé : code revu, tests automatisés au vert, documentation à jour, fonctionnalité déployée et validée. Sans elle, chaque personne applique sa propre barre et la dette technique s'accumule.

À lire ensuite

• Agile : c'est quoi, vraiment ?
• Story points et estimation
• La rétrospective agile
• Dette technique : la mesurer et la rembourser

Parlons de votre projet

Nos ingénieurs s'intègrent dans votre équipe, travaillent avec vos rituels et transfèrent les compétences avant de partir. Parlez-nous de votre équipe.