Description de la méthode SCRUM à travers deux
expériences en entreprise
Gérard Memmi
LTCI, Telecom Paris, Institut Polytechnique de Paris
Résumé : Deux expériences conduites dans deux jeunes pousses américaines servent de base pour décrire et discuter sur la
méthode scrum. Le contexte de jeune pousse rend encore plus critique l’importance des questions relatives à l’affectation de
ressources limitées et au respect rigoureux des délais. Après avoir introduit le manifeste Agile, le processus scrum est décrit.
Les concepts désormais classiques de backlogs accompagnés des autres artefacts de la méthode Scrum sont intégrés à des
artefacts de développement produit plus traditionnels afin de passer à l'échelle. Le concept de sprint est légèrement modifi é
pour mieux s’adapter à un environnement où les ressources sont rares. La gestion des livraisons produit est ensuite discutée
en particulier celles correspondant à des versions majeures et critiques du produit. Ces dernières impliquent d’organiser et de
coordonner plusieurs équipes scrum. Cet aspect de la méthode, tout du moins pour les deux expériences considérées, est
essentiel. Un ensemble de questions fondamentales doivent être résolues pour que la méthode scrum soit adoptées par les
équipes de développement et réussisse à passer à l’échelle. Ce rapport se termine par plusieurs recommandations pour
améliorer la productivité du développement produit dans un contexte similaire à nos deux jeunes pousses.
Mots clés : Manifeste Agile, méthode scrum, backlog, sprint, jeune pousse, génie logiciel
Abstract: Two experiments conducted in two American seedlings serve as a basis for describing and discussing the
scrum method. The context of a start-up makes the importance of issues related to the allocation of limited resources and
strict adherence to deadlines even more critical. After introducing the Agile Manifesto, the scrum process is described. The
now classic concepts of backlogs along with the other artifacts of the Scrum method are integrated with more traditional
product development artifacts in order to scale up. The concept of sprint is slightly modified to better adapt to an
environment where resources are scarce. The management of product deliveries is then discussed, in particular those
corresponding to major and critical product versions. The latter involve organizing and coordinating several scrum teams.
This aspect of the method, at least for the two experiments considered, is essential. A set of fundamental issues must be
resolved for the scrum method to be adopted by the development teams and succeed to scale up. This report concludes with
several recommendations to improve the productivity of product development in a context similar to our two start-ups.
Keywords: Agile Manifesto, Scrum method, Backlog, Sprint, Start-up, Software Engineering
Note : Une version préliminaire de ces notes beaucoup moins détaillée a été publiée dans [Memmi 11]. Ces
notes contiennent de nombreux ajouts, plus un état de l’art plus complet et mis à jour.
1. INTRODUCTION
La méthode de développement logiciel appelée scrum (qui signifie mêlée en termes de rugby) est ici décrite à
travers deux retours d’expériences dans le cadre de deux jeunes pousses ayant un écosystème différent. Nous
étudions la réalisation d’un produit nécessitant une équipe de taille trop importante pour être contenue dans un
seul processus scrum ; il est d’usage d’avoir recours à la notion de « scrum de scrums ». Outre qu’elle introduit
un niveau de hiérarchie contraire aux principes de la méthode Agile, et sans prétendre introduire de principes
méthodologiques vraiment nouveaux, il nous est vite apparu qu’il nous fallait modifier cette notion de scrum de
scrums, en particulier du fait que nos projets se développaient au sein de jeunes pousses, une première fois dans
une jeune pousse n’ayant pas encore de base client développée, une seconde fois dans une jeune pousse ayant
déjà de nombreux utilisateurs. Nous tenterons d’expliquer comment ce passage à l’échelle en termes de force de
développement fut réussi.
Le mot « scrum » est évocateur : la mêlée, en rugby, est le moment où une partie de l’équipe a un objectif
commun et va se rassembler, s’auto-organiser, se souder et rapidement décider d’un plan d’actions prenant en
compte divers éléments de la rencontre. C’est un effort intense pendant un temps assez court qui est demandé à
chaque fois que l’arbitre le décidera durant la rencontre. Le taux de succès de prise de balle à la mêlée est
considéré comme essentiel pour remporter la partie. Cette notion d’équipe où chacun a une fonction précise, où
chacun doit savoir s’adapter rapidement aux évènements est au cœur de la méthode Scrum. On commence à
comprendre dès lors quelques principes fondamentaux de la méthode à savoir d’établir de petites équipes très
1
soudées, dans un effort court et bien défini, concentrées sur un objectif précis et circonscrit. Au bout de cette
période, il sera impératif de livrer un code fonctionnel de qualité dont les clients perçoivent la valeur. Avant de
décrire plus en détails les aspects essentiels de la méthode, donnons quelques éléments du contexte dans lequel
nos deux projets ont été développés.
2. DEUX EXPÉRIENCES UTILISANT LA MÉTHODE SCRUM
La méthode scrum est décrite en exploitant deux exemples où elle a été déployée et utilisée dans les années
2000. Ces deux expériences ont été menées au sein deux jeunes pousses (ou start-ups). Le fait même qu’il
s’agisse de jeunes pousses n’est pas anodin : dans toute jeune pousse les ressources sont rares et chères ; les
processus de remontée d’information atteignent fréquemment le président directeur général ; chaque erreur est
vite visible dans la mesure où elle peut avoir un impact important sur l’entreprise. Chaque nouvelle opportunité
d’affaire peut secouer l’entreprise entière en quelques jours et peut potentiellement imposer de changer les plans
de développement produit de façon considérable et parfois brutale.
La première entreprise développait un produit de CAO (un environnement de tests de très grands circuits
électroniques intégrés (ASIC)); il s’agissait donc de développer des algorithmes originaux, de concevoir des
outils de compilation et stockage de données hautement complexes. Autre élément important : la jeune pousse
partait d’une table rase sans aucun client préalable. Deux conséquences immédiates : pas de pression de la part
d’une base de clients (cependant bien sûr, une forte pression sur l’emploi du Conseil d’Administration composé
en partie des financiers de la jeune pousse) à livrer le produit et des cas d’usage validés seulement lors de trop
rares réunions avec des clients potentiels et très discutés (voire trop simplifiés) en interne par l’équipe de
développement.
La seconde entreprise se trouvait dans une situation très différente. Elle développait un produit dans le domaine
de la santé (traitement collaboratif du dossier médical). Sa base de clients et d’utilisateurs était importante au
moment où la décision fut prise d’appliquer la méthode scrum. Les besoins en développement étaient donc
exprimés de manière beaucoup plus fiable et précise que dans le premier cas. La pression des clients était très
importante quant à la livraison du produit dans les délais impartis. Les utilisateurs exigeaient une interface très
soignée et très proche de leur habitudes ce qui était en fort contraste avec la première expérience où le produit
développé était destiné à des ingénieurs intéressés par une interface programmable. L’équipe de tests prenait
plusieurs jours pour tester manuellement toutes les possibilités offerte par l’interface sur des scénarios définis
avec précision. Des rapports de défauts pouvaient arriver avec plusieurs jours de délai ce qui n’était pas sans
poser des problèmes importants d’intégration et de convergence de livraison produit. Autre différence notable :
la première expérience se situait dans le cadre d’un développement d’un produit nouveau dont les fonctions et
contours étaient à définir alors que pour la seconde expérience le produit était déjà défini et il s’agissait de le
faire évoluer et de passer à l’échelle afin de satisfaire une base d’utilisateurs plus vaste et plus variée [Memmi
09].
Les sections suivantes décrivent la méthode scrum telle qu’elle a été rédigée dans [Schwaber… 02] ou
[Schwaber 04] en soulignant de nombreux points très positifs mais également telle qu’elle a été interprétée,
intégrée aux méthodes et aux données existantes des deux jeunes pousses et surtout adaptée pour tenir compte de
l’organisation et de la culture de chaque entreprise ainsi que de la situation et de la nature particulières de chaque
produit. Ce mode d’introduction d’une méthode de travail est complètement consistant avec le principe
d’adaptabilité exprimé dans le Guide Scrum [Sutherland…17] ainsi que dans la méthode Agile décrite dans la
section suivante. Nous nous attacherons à analyser et expliquer les éléments de la méthode qui nous ont paru les
plus intéressants.
3. MANIFESTE de la MÉTHODE AGILE et NOTIONS de BASE de la
MÉTHODE SCRUM
La méthode Scrum a été décrite pour la première fois dans [Takeuchi…86] où les auteurs mettent l’accent sur la
vitesse d’exécution et l’agilité avec l’intention d’augmenter de façon significative la productivité d’équipes de
développement de produits industriels. De manière similaire, Ken Schwaber, qui a adapté la méthode au
développement logiciel vers les années 90-96, fait état de gains de productivité de plusieurs ordres de grandeur
[Schwaber… 02]. D’autres méthodes agiles respectant le manifeste Agile [Agile 01] sont souvent rapprochées de
la méthode scrum : la programmation extrême [XP…99] ou encore les méthodes DSDM (Dynamic System
Development Method) [DSDM…95] [DSDM…14], SAFe [Safe 17] [Safe 19], FDD (Feature-driven
Development) [Palmer…02], ou Kanban [Anderson…16] pour n’en citer que quelques-unes.
2
3.1. Manifeste de la méthode Agile
Le manifeste de la méthode Agile [Agile 01] énoncée dans ses douze principes dans la Figure 1: le Manifeste
Agile tiré de [Agile 01] ci-dessous a été signé en février 2001 par 17 professionnels de la programmation dont K.
Schwaber, J. Sutherland et M. Beedle qui sont les principaux auteurs de la méthode Scrum ([Schwaber… 02] et
[Schwaber…17]). La méthode Agile est aujourd’hui très répandue et repose sur quelques idées simples telles
l’attention et le dialogue constant avec le client ou l’utilisateur. Ce dialogue permet à la fois de mieux
comprendre et de suivre au plus près l’évolution du besoin client. Elle ouvre la porte à l’acceptation de
changements pouvant être tardif durant le développement du produit ce qui se démarque nettement des méthodes
plus classiques comprenant une spécification qui une fois figée sera suivie d’un développement puis de tests
telles que le cycle de vie du logiciel en V ou en cascade. Deux autres points importants du manifeste de la
méthode Agile sont d’une part l’intention de délivrer régulièrement de fréquentes versions incrémentales du
produit et d’autre part la volonté forte de maintenir et constamment améliorer les performances de l’équipe de
développement à travers des revues et des retours d’expérience permettant également d’adapter les différents
outils de production et processus aux besoins d’évolution du produit.
Énoncé des douze principes de la méthode Agile
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s
competitive advantage.
3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
4 Business people and developers must work together daily throughout the project.
5 Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6 The most efficient and effective method of conveying information to and within a development team is face-
to-face conversation.
7 Working software is the primary measure of progress.
8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9 Continuous attention to technical excellence and good design enhances agility.
10 Simplicity—the art of maximizing the amount of work not done—is essential.
11 The best architectures, requirements, and designs emerge from self-organizing teams.
12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
Figure 1: le Manifeste Agile tiré de [Agile 01]
Dans ce qui suit, nous ferons parfois référence à l’un ou l’autre de ces principes au moment de son application.
3.2. Composants principaux du processus scrum
La méthode scrum opère sur un ensemble de composants que l’on peut séparer en trois (comme pour de très
nombreuses méthodes au demeurant) : les artefacts, les étapes principales du processus, les différents rôles que
les participants remplissent.
1. Les artéfacts :
le « backlog produit » contient les diverses fonctions et caractéristiques non fonctionnelles qu’il est désirable de
développer. Ces fonctions peuvent être décrites dans des « story cards » qui peuvent être disposées sur un
tableau de type kanban afin d’obtenir une vue synthétique du statut des travaux en cours. Le « backlog de
sprint » est un sous-ensemble du backlog produit. Le tableur de charge de travail (graphique d’avancement ou
burndown chart) est utile afin de mesurer la charge de travail restant à effectuer, de surveiller et constater la
convergence du sprint.
2. Les étapes du processus :
le « sprint » est le niveau d’organisation le plus petit ayant pour but le développement d’un quantum du livrable ;
la réalisation de livraison produit (ou version produit) (release en anglais). Les réunions journalières (daily