Scrum tient en moins de treize pages, et l’essentiel n’est pas dans les réunions

Votre équipe se réunit chaque matin un quart d’heure, debout. Elle découpe son travail en tranches de trois semaines. À la fin de chaque tranche, elle montre ce qu’elle a produit. Six mois après la formation, vous posez la seule question qui compte : est-ce que cela a changé quelque chose ?

La réponse honnête est souvent la même. Les réunions ont bien lieu. Les délais glissent comme avant, les mêmes sujets reviennent en comité de direction, et personne ne sait dire ce que la nouvelle organisation a apporté.

Ces trois habitudes portent un nom : Scrum. Le mot désigne un cadre de travail destiné aux projets dont on ne connaît pas la fin à l’avance. Un cadre, pas une méthode. Il fixe des rôles, un rythme et des rendez-vous. Il laisse à l’équipe le soin de trouver comment faire.

Ce qui reste quand la formation est loin

Ce qui survit à une formation, ce sont les gestes visibles. On retient le quart d’heure du matin, le tableau des tâches, le vocabulaire. On oublie ce qui rendait ces gestes utiles.

Le texte de référence le dit en une phrase : Scrum est « un cadre léger qui aide les gens, les équipes et les organisations à générer de la valeur par des solutions adaptatives aux problèmes complexes ». Léger et adaptatif. Il ne remplace donc ni la décision, ni le jugement.

Trois écrits font l’essentiel du travail. Tout le reste — le nom des réunions, l’outil de suivi, la façon de découper le travail — appartient à l’équipe. Deux entreprises peuvent pratiquer le même cadre sans se ressembler du tout.

Moins de treize pages, volontairement incomplètes

La version en vigueur du guide a été publiée en novembre 2020 par Ken Schwaber et Jeff Sutherland. Elle tient en moins de treize pages, précise le journal des révisions. Un document de cette taille se lit en une soirée.

La brièveté est un choix, et le texte l’assume. Le cadre est « volontairement incomplet » : il ne définit que ce qui est nécessaire pour fonctionner. Aucune technique d’estimation, aucun outil imposé, aucune recette de priorisation.

L’analogie tient : les règles du football définissent le terrain, le ballon et le but. Elles ne disent pas comment attaquer. Une équipe qui passe ses réunions à discuter du règlement ne marque pas de buts.

Le cadre s’inscrit dans un courant ancien. En janvier 1986, la Harvard Business Review publiait une étude de Hirotaka Takeuchi et Ikujiro Nonaka sur les entreprises capables de sortir un produit plus vite que les autres. Ces entreprises misaient sur la vitesse et la souplesse, pas sur le seul couple qualité-coût.

Trois engagements remplacent les listes de tâches

La version de 2020 a donné un statut à trois écrits que les versions précédentes mentionnaient sans leur faire de place. Le journal des révisions parle d’un « engagement » attaché à chacun des trois objets du cadre.

Le premier est l’objectif du produit. Il décrit ce que le produit doit devenir, à une échéance qui se compte en mois, et il sert d’engagement à la liste des besoins. Sans lui, cette liste devient un sac de demandes classées par urgence. C’est la différence entre une direction et un entassement.

Le deuxième est l’objectif du sprint, l’objectif unique de la tranche de travail en cours. Le guide le décrit comme un engagement des développeurs, qui laisse libres les moyens de l’atteindre. La différence avec une liste de tâches se voit le jour où une demande arrive en cours de route. Avec un objectif, la question devient simple : cette demande sert-elle l’objectif, oui ou non ?

Le troisième est la définition de « terminé ». C’est une description formelle de l’état d’un livrable qui satisfait aux exigences de qualité. Le guide est net : un travail qui n’y répond pas ne peut pas être livré.

Ce point mérite qu’on s’y arrête. Sans cette définition, « terminé » reste une opinion. Le module est fini quand le code est écrit, quand il est en production, ou quand un utilisateur l’a réellement utilisé ? Trois réponses, trois réalités, et un comité de direction qui ne parle pas de la même chose que ses équipes.

L’image du voyage résume les trois. L’objectif du produit est la destination. L’objectif du sprint est l’étape du jour. La définition de « terminé » est ce qui permet de dire, le soir, si l’on est arrivé.

Une durée fixe, et quelque chose d’utilisable au bout

Le guide définit le sprint comme un événement de durée fixe, d’un mois au maximum, et précise qu’un nouveau sprint commence dès la fin du précédent. Cette régularité n’est pas décorative.

Une durée constante rend les périodes comparables. Si la tranche dure trois semaines, puis cinq, puis deux, vous ne mesurez plus une progression : vous mesurez un changement de découpage. C’est la différence entre peser chaque semaine sur la même balance et changer de balance à chaque fois.

Chaque sprint doit produire un incrément, et cet incrément doit être utilisable. Le guide ajoute une phrase qui règle beaucoup de débats : la revue ne doit jamais être considérée comme un passage obligé avant de livrer. Autrement dit, rien n’interdit de mettre en production avant la fin du sprint.

Les durées des réunions sont des plafonds, pas des cibles. La planification est limitée à huit heures pour un sprint d’un mois, le point quotidien à quinze minutes, la revue à quatre heures. Le guide précise que, pour un sprint plus court, ces rencontres sont généralement plus courtes aussi. Une revue de quatre heures sur un sprint de deux semaines n’est pas plus sérieuse qu’une revue d’une heure.

La revue est un travail, pas une présentation

L’objectif de la revue est d’examiner le résultat du sprint et de décider des adaptations. L’équipe présente son travail aux personnes concernées, puis les participants examinent ensemble la suite, et la liste des besoins peut être modifiée sur place.

Le guide insiste : la revue est une séance de travail, et l’équipe doit éviter de la réduire à une présentation. Le test pratique tient en une question. Qui parle ? Si seuls les développeurs parlent, c’est une démonstration. Si les personnes qui commandent le produit et celles qui l’utilisent posent des questions et repartent avec des décisions, c’est une revue.

Le point quotidien obéit à la même logique. Quinze minutes, pour les développeurs, avec un but précis : examiner l’avancement vers l’objectif du sprint. Le guide laisse la forme libre. Ce qui compte est que la rencontre produise un plan pour la journée.

La version de 2020 a aussi supprimé la séparation entre l’équipe et une sous-équipe de développement. Le journal des révisions explique pourquoi : cette séparation produisait des comportements de type « nous et eux » entre le responsable produit et les développeurs. Il n’y a plus qu’une équipe, avec trois ensembles de responsabilités.

Ce que la version de 2020 a retiré

Trois questions rituelles du point quotidien ont disparu du texte : celles sur ce qui a été fait la veille, ce qui sera fait aujourd’hui, et les obstacles. Le journal des révisions assume le mouvement : la version 2020 visait à retirer ou adoucir le langage prescriptif, parce que le guide était devenu trop directif avec les années.

La même logique a fait passer l’équipe d’autonome dans l’organisation de son travail à autogérée. La nuance est réelle : l’équipe décide non seulement qui fait quoi et comment, mais aussi sur quoi elle travaille.

Conséquence directe pour un dirigeant : la plupart des disputes sur la bonne façon de tenir une réunion n’ont aucun fondement dans le texte. Assis ou debout, avec ou sans tableau, avec ou sans les trois questions : le guide ne tranche pas.

Ce qui reste vérifiable tient en trois questions. L’objectif du sprint est-il atteint ? Le résultat est-il utilisable ? La revue a-t-elle changé la liste des besoins ? Trois réponses concrètes, disponibles à la fin de chaque tranche.

Ce qu’il faut retenir

• Le guide de Scrum tient en moins de treize pages et se déclare volontairement incomplet : il ne dira jamais quoi construire.
• Trois écrits décident du reste : l’objectif du produit, l’objectif du sprint, et la définition de « terminé ».
• Sans définition de « terminé », l’avancement est une opinion. Écrivez-la, affichez-la, et refusez ce qui n’y répond pas.
• Un sprint dure un mois au maximum et se termine par quelque chose d’utilisable. Rien n’interdit de livrer avant la fin.
• Si la revue se tient sans les personnes qui décident, c’est une démonstration. Le test : la liste des besoins a-t-elle changé à la fin ?
• Les trois questions du point quotidien ont disparu du texte en 2020. Discuter du format est souvent le signe qu’on parle du cadre au lieu de le pratiquer.