Fondements

Scrum en bref : origines et cadre

Scrum est né d'une observation faite au Japon dans les années 1980, il a pris forme dans une équipe de logiciel en 1993 et il tient aujourd'hui dans un guide gratuit d'une quinzaine de pages. Cet article retrace cette histoire, puis présente le cadre tel que le définit l'édition 2020 du Guide Scrum : une équipe, trois responsabilités, cinq événements et trois artefacts.

Une mêlée plutôt qu'une course de relais

Pensez à une course de relais. Le premier coureur fait son tour de piste, transmet le témoin et s'arrête, puis le suivant prend la suite. Beaucoup d'organisations conçoivent leurs produits de cette façon : le marketing rédige un cahier des charges et le remet au bureau d'études, qui transmet des plans à la fabrication, qui livre enfin le produit aux vendeurs. Chaque service fait sa part, et personne ne suit le produit du début à la fin.

Au début de l'année 1986, deux chercheurs japonais, Hirotaka Takeuchi et Ikujiro Nonaka, publient dans la Harvard Business Review un article intitulé « The New New Product Development Game ». Ils y étudient des entreprises qui ont conçu des produits nouveaux plus vite que leurs concurrents, par exemple Fuji-Xerox pour un copieur, Canon pour un appareil photo et Honda pour une petite voiture, la City. Dans ces entreprises, une équipe qui réunit plusieurs métiers avance ensemble du début à la fin, et les phases du projet se chevauchent au lieu de se succéder. Les auteurs comparent cette manière de faire au rugby, où l'équipe remonte le terrain en se passant le ballon, et ils emploient le mot scrum, qui désigne la mêlée.

Leur article décrit six caractéristiques de ces équipes : une instabilité voulue par la direction, qui fixe un objectif très ambitieux, des équipes de projet auto-organisées, des phases de développement qui se chevauchent, un apprentissage qui traverse les métiers et les niveaux, un contrôle discret et la transmission de ce qui a été appris au reste de l'entreprise. Takeuchi et Nonaka parlent de produits industriels comme les copieurs, les appareils photo et les voitures. Leur article ne traite pas du développement de logiciel, et le mot « scrum » n'y désigne pas encore un cadre de travail.

De l'article au cadre

En 1993, Jeff Sutherland travaille chez Easel Corporation, un éditeur de logiciels américain. Avec Jeff McKenna et John Scumniotales, il organise une équipe selon les idées de Takeuchi et Nonaka et reprend le mot « scrum ». À la même époque, Ken Schwaber expérimente une approche voisine dans sa propre société, avec Mike Smith et Chris Martin. Schwaber et Sutherland présentent ensemble Scrum pour la première fois en 1995, à la conférence OOPSLA, qui se tient cette année-là à Austin, au Texas. Le Guide Scrum rappelle ces débuts dans ses remerciements.

En février 2001, Schwaber, Sutherland et Mike Beedle font partie des dix-sept signataires du Manifeste agile. La même année, Schwaber et Beedle publient Agile Software Development with Scrum, le premier livre consacré à Scrum. La première version du Guide Scrum date de 2010. Ses deux auteurs l'ont révisée en 2011, 2013, 2016, 2017 et 2020. Le texte est gratuit et publié sous licence Creative Commons (CC BY-SA 4.0). Il sert de définition officielle, et c'est à lui qu'il faut revenir quand deux personnes ne sont pas d'accord sur ce que Scrum demande.

Scrum a d'autres sources que l'article de 1986. Les auteurs de A Scrum Book (2019), dont Sutherland fait partie, le rattachent au système de production de Toyota, et Sutherland a souvent cité les travaux de James Coplien sur les organisations parmi ce qui a nourri le premier Scrum. L'article sur les patterns de Scrum revient sur cette filiation.

Ce que dit le Guide Scrum 2020

Le Guide définit Scrum comme un cadre de travail léger, qui aide des personnes, des équipes et des organisations à produire de la valeur en apportant des solutions adaptatives à des problèmes complexes. Un problème est complexe, en ce sens, quand on ne peut pas en connaître la solution à l'avance et qu'il faut essayer pour apprendre. La conception d'un nouveau produit ou d'un nouveau service en est un bon exemple.

Le cadre repose sur l'empirisme, c'est-à-dire sur l'idée que la connaissance vient de l'expérience et que les décisions se prennent d'après ce que l'on observe. Il s'appuie sur trois « piliers », la transparence, l'inspection et l'adaptation, que détaille l'article sur l'empirisme. Il demande aussi à ceux qui l'appliquent de faire vivre cinq valeurs : l'engagement, le focus, l'ouverture, le respect et le courage. Le Guide précise que Scrum est volontairement incomplet : il fixe le minimum nécessaire et laisse chaque équipe choisir ses techniques.

Une équipe et trois responsabilités

L'unité de base est la Scrum Team, une petite équipe, en général de dix personnes au plus, sans sous-équipe ni hiérarchie interne. Elle réunit toutes les compétences nécessaires pour produire quelque chose d'utile à chaque cycle, et elle décide elle-même qui fait quoi, quand et comment. Le Guide y distingue trois responsabilités.

• Le Product Owner répond de la valeur du produit. Il tient à jour la liste ordonnée de ce qu'il reste à faire. Le Guide insiste sur le fait qu'il s'agit d'une personne et non d'un comité.
• Les Developers (développeurs) sont ceux qui fabriquent le produit, quel que soit leur métier. Le mot ne désigne pas seulement des programmeurs.
• Le Scrum Master répond de la bonne compréhension de Scrum et de l'efficacité de l'équipe. Il l'aide à améliorer ses pratiques et fait en sorte que les obstacles qu'elle rencontre soient levés.

Cinq événements

Le travail est découpé en Sprints, des périodes de durée fixe, d'un mois au plus, qui se suivent sans interruption. Chaque Sprint contient quatre autres événements. Les durées du tableau sont les maximums prévus pour un Sprint d'un mois. Elles sont en général plus courtes quand le Sprint est plus court, sauf pour le Daily Scrum, qui dure toujours quinze minutes.

Trois artefacts et leurs engagements

Un artefact est un objet qui rend le travail visible. Depuis 2020, chacun est associé à un « engagement », c'est-à-dire à un repère par rapport auquel on peut mesurer l'avancement.

Ce que l'édition 2020 a changé

Si vous lisez des livres ou des articles antérieurs à 2020, vous y trouverez un vocabulaire un peu différent. L'édition 2020 a raccourci le texte et retiré les termes propres à l'informatique. Elle parle de « Developers » là où les éditions précédentes parlaient d'une « Development Team », afin qu'il n'y ait plus d'équipe dans l'équipe. Elle introduit le Product Goal et rattache un engagement à chaque artefact. Elle dit l'équipe « autogérée » (self-managing) plutôt qu'« auto-organisée » (self-organizing). Elle ajoute au Sprint Planning la question du « pourquoi », et elle retire les trois questions proposées jusque-là pour le Daily Scrum.

Ces différences comptent pour la lecture de ce site. A Scrum Book, sur lequel il s'appuie, a paru en 2019 : il parle de « Development Team », écrit « ScrumMaster » en un seul mot et compte trois « rôles » là où le Guide de 2020 parle de responsabilités. Les articles signalent ces écarts chaque fois qu'ils ont une conséquence pratique.

Ce que le Guide ne dit pas

Beaucoup de pratiques que l'on associe à Scrum ne figurent pas dans le Guide. Les user stories (récits utilisateur), les points d'estimation, la vélocité et le tableau à colonnes n'y sont pas mentionnés, et les graphiques d'avancement n'y sont cités qu'à titre d'exemple. Ce sont des techniques complémentaires, souvent utiles, mais une équipe peut appliquer Scrum sans elles.

Le Guide dit lui-même que la description de ces pratiques dépasse son objet, parce qu'elles dépendent du contexte, et il renvoie à d'autres sources. A Scrum Book est l'une d'elles. Ses auteurs comparent le Guide au livret de règles des échecs : il faut le connaître, mais sa lecture ne suffit pas à bien jouer. Leurs patterns décrivent ce que les règles ne disent pas, c'est-à-dire le problème que chaque élément de Scrum cherche à résoudre et la manière dont des équipes s'y sont prises.

Limites et pièges

Scrum est conçu pour un travail complexe, dont on découvre la solution en avançant. Pour un travail répétitif et bien connu, comme le traitement de dossiers tous semblables, des cycles avec objectif et revue apportent peu, et d'autres approches conviennent mieux (voir le corpus Lean).

Le Guide affirme que le cadre est « immuable » et qu'une application partielle n'est pas Scrum. Cette fermeté protège la définition, mais elle encourage aussi une lecture scolaire, où l'on vérifie la présence des cinq événements sans se demander s'ils servent à quelque chose. L'article sur l'esprit du jeu est consacré à ce risque.

Il faut enfin distinguer l'histoire et les preuves. Le récit des origines est surtout fait par les fondateurs eux-mêmes. Les gains de productivité spectaculaires parfois annoncés, notamment par Jeff Sutherland, ne sont pas établis par des études indépendantes. L'article Critiques et état des preuves fait le point sur ce que l'on sait.