Méthodes et pratiques

Scrum en bref

Scrum est le cadre de travail agile le plus répandu, au point que beaucoup le confondent avec l'agilité elle-même. Sa définition officielle tient pourtant en un texte de moins de quinze pages, le Guide Scrum de Ken Schwaber et Jeff Sutherland. Cet article en résume l'essentiel : une théorie, trois responsabilités, cinq événements et trois artefacts. Le détail est traité dans le corpus Scrum du site.

Deux semaines dans une équipe

Un réseau de centres de santé veut permettre à ses patients de prendre rendez-vous en ligne. Sept personnes y travaillent. Cinq d'entre elles fabriquent le service : deux programmeuses, un testeur, une designer et un administrateur de bases de données. Samira est responsable du produit, et Yann aide l'équipe à bien travailler ensemble.

Le lundi matin, l'équipe prépare les deux semaines à venir. Samira présente ce qui compte le plus à ses yeux : les patients doivent pouvoir annuler un rendez-vous sans téléphoner, car les secrétariats sont saturés d'appels. L'équipe en fait l'objectif de la période, choisit dans la liste des demandes celles qui y contribuent et prévoit comment les réaliser. Chaque matin, les cinq développeurs se retrouvent un quart d'heure devant leur tableau pour ajuster le plan de la journée.

Le deuxième vendredi, ils montrent l'annulation en ligne, qui fonctionne réellement, à deux secrétaires et au directeur d'un centre. L'une des secrétaires réagit aussitôt : « Il faut un délai minimal, sinon des patients annuleront dix minutes avant la consultation. » Samira ajoute cette demande à sa liste. L'après-midi, l'équipe examine sa propre façon de travailler et décide d'un changement pour la période suivante.

Cette scène contient les principaux éléments de Scrum. La période de deux semaines est un Sprint, Samira est la Product Owner, Yann est le Scrum Master, et chacune des quatre réunions porte un nom que l'on verra plus bas.

D'où vient Scrum

Le mot vient du rugby, où il désigne la mêlée. En 1986, Hirotaka Takeuchi et Ikujiro Nonaka publient dans la Harvard Business Review un article intitulé « The New New Product Development Game ». Ils y décrivent des entreprises qui conçoivent leurs nouveaux produits avec de petites équipes pluridisciplinaires et autonomes. Les membres de ces équipes avancent ensemble en se passant le ballon, au lieu de se transmettre le travail de service en service comme dans une course de relais.

Au début des années 1990, Jeff Sutherland s'inspire de cet article pour organiser une équipe de développement chez Easel Corporation, avec John Scumniotales et Jeff McKenna. Ken Schwaber expérimente à la même époque des idées voisines dans sa propre société. Les deux hommes présentent Scrum à la conférence OOPSLA en 1995, et ils signent six ans plus tard le Manifeste agile, de même que Mike Beedle, qui pratique lui aussi Scrum. Le cadre est donc antérieur au Manifeste, qu'il a contribué à inspirer.

Le Guide Scrum, publié pour la première fois en 2010 et révisé plusieurs fois depuis, est la définition de référence ; l'édition en vigueur date de novembre 2020. Les enquêtes annuelles sur les pratiques agiles, comme le State of Agile Report, placent régulièrement Scrum en tête des cadres utilisés. Ces enquêtes sont déclaratives et publiées par un éditeur de logiciels, mais le constat n'est guère contesté.

La théorie : apprendre de ce que l'on observe

Le Guide présente Scrum comme un cadre de travail léger, destiné à produire de la valeur face à des problèmes complexes, c'est-à-dire des problèmes où l'on ne peut pas tout prévoir. Il repose sur l'empirisme : la connaissance vient de l'expérience, et les décisions se prennent d'après ce que l'on observe. Le Guide y associe la pensée Lean, qui cherche à réduire le gaspillage et à se concentrer sur l'essentiel.

Trois piliers en découlent. La transparence veut que le travail et son état réel soient visibles de ceux qui le font comme de ceux qui le reçoivent. L'inspection consiste à examiner souvent les résultats et la progression. L'adaptation consiste à corriger le plan ou la façon de travailler dès que l'inspection révèle un écart. Chaque événement de Scrum est une occasion d'inspecter et d'adapter.

Le Guide ajoute cinq valeurs que l'équipe est censée faire vivre : l'engagement, la concentration (« focus »), l'ouverture, le respect et le courage. Il précise enfin que le cadre est volontairement incomplet. Il fixe quelques règles et laisse à chaque équipe le choix de ses techniques.

Le cadre : une équipe, cinq événements et trois artefacts

Une équipe et trois responsabilités

L'unité de base est la Scrum Team, une petite équipe qui compte en général dix personnes au plus, sans sous-équipe ni hiérarchie interne. Elle est pluridisciplinaire, ce qui veut dire qu'elle réunit toutes les compétences nécessaires pour produire un résultat utilisable, et elle s'organise elle-même. Depuis 2020, le Guide parle de trois « responsabilités » plutôt que de rôles.

• Le Product Owner répond de la valeur du produit. Il tient et ordonne le Product Backlog, la liste de tout ce qui reste à faire. C'est une personne et non un comité : ceux qui veulent changer les priorités doivent le convaincre.
• Les développeurs (Developers) sont tous ceux qui fabriquent le produit, quel que soit leur métier. Ils décident comment faire le travail, établissent le plan du Sprint et répondent de la qualité.
• Le Scrum Master veille à ce que Scrum soit compris et bien pratiqué. Il aide l'équipe et l'organisation, fait lever les obstacles et s'assure que les événements ont lieu et restent utiles. Il n'est ni chef de projet ni supérieur hiérarchique.

Cinq événements

Le Sprint contient tous les autres événements. Sa durée est fixe, d'un mois au plus, et un nouveau Sprint commence dès que le précédent s'achève. Les durées maximales ci-dessous valent pour un Sprint d'un mois ; elles sont en général plus courtes quand le Sprint est plus court.

On reproche souvent à Scrum de multiplier les réunions, et le calcul mérite d'être fait. Pour un Sprint de deux semaines, beaucoup d'équipes divisent par deux les durées maximales, sans que le Guide l'impose : 4 heures de Sprint Planning, 2 heures de Sprint Review et 1 heure 30 de rétrospective. S'y ajoutent dix Daily Scrums de 15 minutes, soit 2 heures 30. Le total est de 10 heures sur les 70 heures d'une quinzaine à 35 heures par semaine, soit environ 14 % du temps. C'est un plafond, que les équipes rodées n'atteignent pas. Le Guide précise par ailleurs que ces événements servent à réduire le besoin d'autres réunions, et non à s'y ajouter.

Trois artefacts et leurs engagements

Un artefact est un objet qui rend le travail visible. Scrum en définit trois, et l'édition 2020 associe à chacun un « engagement » qui lui donne son sens.

• Le Product Backlog est la liste ordonnée de tout ce qui pourrait améliorer le produit. Son engagement est l'objectif de produit (Product Goal), l'état futur du produit que l'équipe vise à long terme.
• Le Sprint Backlog réunit l'objectif du Sprint (Sprint Goal), les éléments choisis pour ce Sprint et le plan pour les réaliser. Il appartient aux développeurs, qui le mettent à jour au fil des jours.
• L'incrément (Increment) est le résultat utilisable produit pendant le Sprint, qui s'ajoute à tous les précédents. Son engagement est la Definition of Done, la définition commune de ce que « terminé » veut dire. Un travail qui n'y satisfait pas ne peut pas être présenté comme fini.

Dans l'exemple des centres de santé, l'objectif de produit pourrait être que la moitié des rendez-vous se prennent sans appel téléphonique. L'objectif du Sprint est l'annulation en ligne. La Definition of Done exige par exemple que chaque fonction soit essayée sur téléphone et relue par un second développeur avant d'être montrée.

Ce que Scrum ne dit pas

Beaucoup de pratiques que l'on croit obligatoires ne figurent pas dans le Guide. Il ne parle ni de user stories, ni de points d'estimation, ni de vélocité, ni de graphique d'avancement. Ces techniques viennent d'ailleurs, et les équipes sont libres de les utiliser ou non. Les trois questions rituelles du Daily Scrum, sur ce que chacun a fait la veille, ce qu'il fera aujourd'hui et ce qui le bloque, ont disparu de l'édition 2020.

Le Guide ne prescrit pas non plus de pratique technique. Martin Fowler a décrit en 2009, sous le nom de « Flaccid Scrum », le sort des équipes qui adoptent Scrum sans se soucier de la qualité interne de leur logiciel : elles avancent vite pendant un temps, puis chaque changement devient plus coûteux que le précédent. C'est pourquoi beaucoup d'équipes associent Scrum aux pratiques techniques d'Extreme Programming.

Scrum ne se confond pas davantage avec l'agilité. Le Manifeste ne nomme aucune méthode, et l'on peut suivre ses valeurs sans Sprint ni Scrum Master, comme le fait par exemple la méthode Kanban.

Limites et pièges

Les rites sans l'esprit. Scrum est simple à décrire et difficile à pratiquer. Une organisation peut installer les cinq événements en une semaine sans rien changer à sa manière de décider. Ron Jeffries, signataire du Manifeste, a appelé « Dark Scrum » en 2016 la version dévoyée qui en résulte : le Daily Scrum devient un compte rendu au chef, le Sprint Planning une liste de tâches imposées, et chaque fin de Sprint une échéance de plus. L'article Être agile ou faire de l'agile revient sur ces dérives.

Un vocabulaire trompeur. Le mot « sprint » suggère une course à fond, alors que le Manifeste demande un rythme que l'on puisse tenir indéfiniment. Une équipe qui finit chaque Sprint épuisée fait fausse route.

Des responsabilités vidées de leur contenu. Un Product Owner qui doit faire valider chaque priorité par un comité ne peut pas jouer son rôle. Il en va de même d'un Scrum Master à qui l'on demande de suivre l'avancement et de rendre des comptes, comme un chef de projet rebaptisé.

Un marché de la certification. Deux organismes principaux, la Scrum Alliance et Scrum.org, délivrent des certificats. Le plus connu, le Certified ScrumMaster de la Scrum Alliance, s'obtient après seize heures de formation, souvent données en deux jours, et un questionnaire à choix multiples. Un certificat atteste qu'on a suivi un cours, pas qu'on sait accompagner une équipe.

Des promesses plus grandes que les preuves. Le livre de Jeff Sutherland paru en 2014 promet dans son titre de faire deux fois plus de travail en deux fois moins de temps. Cette formule est un argument de vente. Les travaux disponibles sont surtout des études de cas et des enquêtes déclaratives, qui ne permettent pas de chiffrer un gain. L'article Que valent les preuves ? fait le point, et le corpus Scrum y consacre aussi un article critique.

Des contextes mal adaptés. Scrum suppose que le travail peut être préparé pour quelques semaines et découpé en résultats utilisables. Une équipe de support, dont les demandes arrivent sans prévenir et doivent être traitées dans l'heure, se trouvera mieux d'un fonctionnement en flux.