Scrum (litt. : « mélée », comme au rugby) est probablement une des méthodes agiles la plus connue. Ses termes ont largement quitté les équipes informatiques : sprint, backlog, Product Owner, daily meeting… Pourtant, cette diffusion a aussi produit une étrange situation. Beaucoup d’organisations pratiquent les rituels de Scrum sans toujours comprendre le problème qu’ils cherchent à résoudre. Derrière les réunions et les tableaux de tâches se trouve pourtant une idée assez simple : lorsqu’un projet comporte beaucoup d’incertitudes, mieux vaut avancer par cycles courts, produire quelque chose de concret, observer ce qui se passe et adapter la suite.
Il suffit d’assister à quelques réunions de projet pour constater à quel point le vocabulaire de l’agilité s’est diffusé. On ne réalise plus une première phase de projet, mais un « sprint ». La liste des choses à faire devient un « backlog ». Une réunion rapide du matin prend le nom de « daily ». Un chef de projet se retrouve parfois rebaptisé Product Owner et le tableau blanc se couvre de post-it. Tout cela peut parfaitement fonctionner. Mais on peut également conserver l’intégralité de ces signes extérieurs et continuer à gérer le projet exactement comme auparavant.
- Dans cet article
- I. Scrum est un cadre, pas une méthode complète de gestion de projet
- II. Pourquoi l’agilité est apparue
- III. Le cœur de Scrum : rendre l’apprentissage régulier
- IV. Les principales dérives de Scrum
- V. Scrum est intéressant lorsque l’on ne sait pas encore exactement comment réussir
- VI. Références
- VII. Ressources
C’est sans doute la principale difficulté lorsqu’on cherche à comprendre Scrum. Scrum n’est pas d’abord un ensemble de cérémonies. Il repose sur une autre manière de traiter l’incertitude. Et c’est aussi ce qui permet de comprendre dans quelles situations il peut être utile, et dans lesquelles il l’est beaucoup moins.
Scrum est un cadre, pas une méthode complète de gestion de projet
Commençons par une précision de vocabulaire. On parle couramment de « méthode Scrum », y compris dans cet article, mais ses créateurs préfèrent le terme de framework, que l’on traduit généralement par « cadre de travail ». La nuance est importante car Scrum ne dit pas comment réaliser une étude de marché, programmer une application, concevoir une pièce mécanique, calculer un budget ou interroger des utilisateurs. Il ne fournit pas non plus un processus détaillé décrivant toutes les étapes d’un projet.
Le Guide Scrum officiel tient aujourd’hui en une douzaine de pages. Sa version actuelle, publiée en novembre 2020 par Ken Schwaber et Jeff Sutherland, définit essentiellement une équipe, quelques responsabilités, cinq événements et trois artefacts. Le reste dépend du métier et du contexte. Ce dépouillement est volontaire. Scrum cherche à fournir juste assez de structure pour permettre à une équipe de progresser dans un environnement complexe sans prétendre prescrire à l’avance la meilleure manière de faire.
Cette idée a des racines plus anciennes que le développement logiciel. En 1986, Hirotaka Takeuchi et Ikujiro Nonaka publient dans la Harvard Business Review un article devenu célèbre, The New New Product Development Game. En étudiant le développement de nouveaux produits dans plusieurs entreprises japonaises et américaines, ils opposent à l’approche séquentielle traditionnelle une organisation plus souple dans laquelle une équipe pluridisciplinaire progresse collectivement, comme une équipe de rugby se déplaçant ensemble sur le terrain. C’est cette image de la mêlée, scrum en anglais, qui donnera plus tard son nom au cadre développé notamment par Jeff Sutherland et Ken Schwaber.
Le point essentiel n’était donc déjà pas de faire davantage de réunions. Il était de remplacer une succession rigide d’étapes par un processus dans lequel conception, réalisation, apprentissage et décision peuvent davantage se chevaucher.
Pourquoi l’agilité est apparue
Scrum appartient à la famille plus large des approches agiles. Il ne faut donc pas confondre les deux. En 2001, dix-sept praticiens du développement logiciel formalisent dans le Manifeste Agile quatre préférences :
- les individus et leurs interactions plutôt que les processus et les outils,
- un produit fonctionnel plutôt qu’une documentation exhaustive,
- la collaboration avec le client plutôt que la seule négociation contractuelle,
- et l’adaptation au changement plutôt que le suivi rigide d’un plan.
Le texte précise bien qu’il existe de la valeur dans les éléments de droite, mais qu’il faut privilégier ceux de gauche. Cette dernière précision est souvent oubliée.
Être agile ne signifie pas ne plus planifier, ne plus documenter ou ne plus respecter de processus. Cela signifie accepter qu’un plan établi à partir d’informations incomplètes devra probablement évoluer lorsque de nouvelles informations apparaîtront. Cette question est particulièrement importante dans les projets innovants. Lorsque l’on développe quelque chose qui n’existe pas encore, certaines connaissances ne peuvent être obtenues qu’en avançant. Un prototype révèle un problème technique. Un premier utilisateur comprend mal une fonctionnalité que toute l’équipe jugeait évidente. Un essai invalide une hypothèse. Une solution techniquement élégante s’avère trop coûteuse. Une approche classique cherche principalement à réduire l’écart entre le plan et la réalisation. Une approche agile cherche également à améliorer le plan grâce à ce que la réalisation nous apprend.
C’est une différence beaucoup plus profonde qu’un changement de vocabulaire. Une étude de Pedro Serrador et Jeffrey Pinto publiée en 2015 dans l’International Journal of Project Management permet d’ailleurs d’éviter une opposition trop caricaturale. Sur un échantillon de 1 002 projets, les auteurs observent une association positive entre le recours aux approches agiles et le succès des projets, notamment en matière de satisfaction des parties prenantes. Mais ils constatent également que les formes hybrides, combinant pratiques agiles et planification plus traditionnelle, sont très fréquentes. L’intérêt de ce résultat est de rappeler qu’il ne s’agit pas nécessairement de choisir une religion méthodologique : la question est de déterminer quel degré d’adaptation le projet nécessite.
Le cœur de Scrum : rendre l’apprentissage régulier
Le Scrum Guide présente Scrum comme une approche fondée sur l’empirisme : les décisions doivent être prises à partir de ce que l’on observe réellement plutôt qu’à partir de ce que l’on imaginait plusieurs mois auparavant. Pour que cela fonctionne, Scrum repose sur trois piliers : la transparence, l’inspection et l’adaptation.
- La transparence consiste à rendre la situation suffisamment visible. Quel est l’objectif ? Que reste-t-il à faire ? Qu’est-ce qui est réellement terminé ? Quels problèmes rencontrons-nous ?
- L’inspection consiste à regarder régulièrement le résultat obtenu et la manière dont l’équipe travaille.
- L’adaptation consiste enfin à modifier ce qui doit l’être lorsque l’écart observé le justifie.
Voilà pourquoi Scrum fonctionne par sprints, c’est-à-dire par périodes fixes d’un mois maximum, souvent deux ou trois semaines en pratique. Chaque sprint constitue une boucle complète : choisir un objectif, travailler, produire quelque chose d’utilisable, examiner le résultat puis améliorer la manière de travailler.
Le sprint n’est donc pas seulement une manière commode de découper un projet de douze mois en vingt-six morceaux de deux semaines. Si chaque sprint exécute simplement une fraction d’un plan entièrement défini au départ, l’organisation reste fondamentalement séquentielle. L’intérêt apparaît lorsque chaque boucle permet réellement d’apprendre et, si nécessaire, de modifier la suivante.
Une équipe Scrum n’est pas une équipe projet classique rebaptisée
Le Scrum Guide distingue trois responsabilités au sein d’une même Scrum Team : le Product Owner, le Scrum Master et les Developers. Depuis la révision de 2020, le guide insiste sur le fait qu’il s’agit d’une seule équipe, sans sous-équipe ni hiérarchie interne, généralement composée de dix personnes ou moins. Elle doit posséder collectivement les compétences nécessaires pour créer de la valeur et être capable de gérer elle-même son travail.
- Le Product Owner est responsable de la maximisation de la valeur du produit. Il formule notamment le Product Goal et ordonne le Product Backlog. Cela implique des arbitrages : parmi toutes les choses intéressantes que l’on pourrait réaliser, lesquelles comptent réellement maintenant ?
- Le Scrum Master est souvent mal compris. Ce n’est ni le secrétaire des réunions ni nécessairement un chef de projet. Sa responsabilité porte sur l’efficacité de Scrum : aider l’équipe à comprendre le cadre, supprimer certains obstacles organisationnels, améliorer les interactions et accompagner également l’organisation lorsqu’elle empêche l’équipe de fonctionner correctement.
- Les Developers, enfin, sont les personnes qui produisent concrètement l’incrément. Le terme ne désigne pas nécessairement des développeurs informatiques. La version 2020 du Scrum Guide a justement cherché à rendre Scrum moins dépendant du vocabulaire logiciel. Dans un autre contexte, il peut s’agir d’ingénieurs, de designers, d’analystes, de chercheurs ou d’autres professionnels contribuant directement au résultat.
Un des changements les plus délicats est que l’équipe doit être autogérée. Cela ne signifie pas qu’elle fait ce qu’elle veut : le Product Owner donne une direction et ordonne les priorités et l’organisation fixe également des contraintes, mais l’équipe décide elle-même comment transformer ces objectifs en résultat.
Ce passage d’une organisation centrée sur l’attribution individuelle du travail à une responsabilité réellement collective est loin d’être automatique. Une étude de Nils Brede Moe, Torgeir Dingsøyr et Tore Dybå, fondée sur neuf mois d’observation d’une équipe Scrum, montre précisément les difficultés de cette transformation. Des compétences trop spécialisées, une division rigide du travail, des problèmes de coordination ou une orientation insuffisamment collective peuvent empêcher l’autogestion de fonctionner. Les auteurs soulignent également l’importance de la confiance et d’une représentation partagée du travail à accomplir.
On peut donc installer Scrum en quelques jours mais construire une équipe Scrum qui applique et comprend l’esprit de la méthode prend souvent beaucoup plus de temps.
Le backlog : décider aussi de ce que l’on ne fera pas
L’objet le plus visible de Scrum est probablement le Product Backlog. On le présente parfois comme une gigantesque liste de tâches mais ce n’est pas ça du tout. Le Product Backlog représente plutôt l’état actuel de ce que l’équipe pense devoir améliorer dans le produit. Il évolue continuellement. Certains éléments deviennent prioritaires, d’autres perdent leur intérêt, de nouvelles idées apparaissent et les éléments proches de leur réalisation sont progressivement précisés.
Depuis 2020, le Scrum Guide associe explicitement ce backlog à un Product Goal, c’est-à-dire un état futur du produit vers lequel l’équipe cherche à progresser. Cette évolution est intéressante parce qu’elle corrige un travers très courant : accumuler des demandes sans véritable direction. Un backlog de 600 éléments n’est pas une stratégie produit. Il peut même devenir le cimetière très organisé de plusieurs années d’idées que personne n’ose supprimer.
Le travail du Product Owner consiste donc autant à renoncer qu’à ajouter. Si tout est prioritaire, rien ne l’est réellement.
Le sprint organise une boucle complète
Chaque sprint contient quatre événements particuliers, auxquels s’ajoute le sprint lui-même.
- Le Sprint Planning ouvre le cycle. L’équipe détermine pourquoi le sprint est utile, ce qu’elle pense pouvoir réaliser et comment elle va commencer à s’organiser. Le résultat est un Sprint Goal et un Sprint Backlog. Comme nous l’avons vu dans l’article consacré spécifiquement au Sprint Planning, il s’agit d’une prévision et d’un plan adaptable, pas d’un contrat gravé dans le marbre.
- Le Daily Scrum est une réunion quotidienne de quinze minutes destinée aux Developers. Son but n’est pas de rendre compte au manager de ce que chacun a fait la veille. Il sert à inspecter la progression vers le Sprint Goal et à adapter le plan de travail. La différence peut sembler légère, mais elle change complètement la nature de la réunion.
- La Sprint Review, organisée vers la fin du sprint, confronte le résultat aux parties prenantes et à l’évolution du contexte. Ce n’est pas seulement une démonstration où l’équipe présente fièrement ce qu’elle a terminé. Elle doit aider à décider de ce qu’il convient de faire ensuite.
- La Sprint Retrospective porte sur une autre question : comment mieux travailler ? L’équipe examine ses interactions, ses processus, ses outils, ses problèmes de qualité ou d’organisation et choisit des améliorations.
On retrouve donc toujours la même mécanique. On agit, on observe, on apprend, on adapte. Cette logique est d’ailleurs très proche de l’un des principes du Manifeste Agile : à intervalles réguliers, l’équipe réfléchit à la manière de devenir plus efficace, puis adapte son comportement.
À la fin d’un sprint, quelque chose doit réellement exister
Scrum ajoute une contrainte fondamentale : chaque sprint doit produire au moins un Increment utilisable. C’est probablement l’un de ses principes les plus intéressants pour des projets d’innovation. L’incrément n’a pas nécessairement besoin d’être commercialisé ou livré immédiatement au client. Mais il doit atteindre un état suffisamment abouti pour pouvoir être utilisé. Le Scrum Guide associe à cet incrément une Definition of Done, c’est-à-dire une compréhension explicite et partagée de ce que signifie réellement « terminé ».
Sans cette exigence, les projets accumulent facilement les fameux travaux « presque terminés ». La conception est faite à 90 %. Le développement aussi. Les essais ont commencé. La documentation sera finalisée plus tard. Individuellement, toutes les tâches semblent bien avancées mais collectivement, rien ne peut encore être utilisé. Scrum préfère moins de travail réellement terminé à beaucoup de travail partiellement avancé. Cette idée rejoint très directement la logique de l’innovation : un objet imparfait mais observable apprend davantage qu’un projet parfait uniquement décrit dans un fichier PowerPoint.
Scrum ne signifie pas travailler plus vite
Le mot sprint entretient une ambiguïté malheureuse. Il suggère l’accélération, alors que Scrum insiste au contraire sur un rythme soutenable. Le bénéfice attendu vient moins de la vitesse d’exécution que de la réduction de certaines formes de gaspillage : développer longtemps quelque chose dont personne ne veut, détecter tard une hypothèse erronée, conserver des priorités devenues obsolètes ou découvrir à la fin du projet que différentes parties ne fonctionnent pas ensemble.
La revue systématique de Tore Dybå et Torgeir Dingsøyr (cf. supra) sur les études empiriques de l’agilité rappelait déjà que les bénéfices observés dépendaient fortement des dimensions humaines et organisationnelles. Les approches agiles ne sont pas simplement des techniques de planification : elles déplacent une partie de la coordination vers les équipes et augmentent l’importance de la communication, de la collaboration et des compétences collectives.
L’agilité peut donc parfaitement ralentir certains gestes locaux tout en améliorant le système dans son ensemble. Une discussion avec l’utilisateur prend du temps. Une rétrospective aussi. Tester plusieurs hypothèses semble moins efficace que d’en choisir immédiatement une. Mais ces activités peuvent éviter plusieurs mois consacrés à une mauvaise direction.
Les principales dérives de Scrum
- La première consiste à transformer Scrum en bureaucratie agile. Les équipes consacrent progressivement une part considérable de leur temps à administrer leur outil de suivi, comme Jira, à estimer des points, préparer des cérémonies et mettre à jour des tableaux. Le processus censé rendre le travail visible finit par devenir le travail.
- La deuxième consiste à conserver une organisation très hiérarchique derrière le vocabulaire Scrum. Le Product Owner décide de tout, le Scrum Master contrôle les délais et les Developers reçoivent leurs tickets. L’autonomie disparaît, mais les cérémonies restent.
- La troisième consiste à confondre adaptation et absence de direction. Une équipe agile a besoin d’objectifs particulièrement clairs puisque le chemin pour les atteindre n’est pas totalement défini à l’avance.
- La quatrième consiste à utiliser Scrum pour des activités qui n’en ont pas besoin. Si un processus est parfaitement connu, répétitif et stable, introduire des sprints, des reviews et des rétrospectives n’apporte pas nécessairement grand-chose. Une bonne méthode dépend toujours de la nature du problème.
Enfin, certaines organisations veulent les bénéfices de Scrum sans accepter ce qu’ils supposent : donner réellement de l’autonomie à une équipe, permettre de modifier certaines décisions, rendre les problèmes visibles et accepter qu’une hypothèse initiale puisse être abandonnée.
Scrum est intéressant lorsque l’on ne sait pas encore exactement comment réussir
Scrum a été créé dans le développement logiciel, mais le Scrum Guide ne fait désormais pratiquement plus référence à ce domaine. Le cadre peut donc être utilisé ailleurs, notamment pour du développement produit, de l’innovation, certains travaux de conception ou des projets dans lesquels les besoins et les solutions se construisent progressivement. Il faut toutefois résister à la tentation de transformer cette possibilité en principe universel.
Construire un pont, conduire une campagne réglementaire, développer un procédé industriel, organiser un événement ou explorer un nouveau service ne présentent pas le même niveau d’incertitude. Certaines parties peuvent nécessiter une planification détaillée très en amont, tandis que d’autres gagnent à être traitées de manière itérative.
L’intérêt de Scrum dépend donc moins de la nature du projet que du degré d’incertitude auquel l’équipe doit faire face. Lorsque les objectifs peuvent être précisément définis à l’avance, que les étapes sont bien connues et que les principales difficultés relèvent surtout de l’exécution, une organisation séquentielle ou fortement planifiée peut rester parfaitement pertinente. Scrum devient plus intéressant lorsque le projet oblige au contraire à apprendre en cours de route : préciser progressivement le besoin, tester des hypothèses, découvrir des contraintes techniques ou intégrer des retours susceptibles de modifier les priorités. Dans ce cas, les cycles courts n’ont pas pour fonction d’accélérer artificiellement le travail, mais de créer des moments réguliers où l’équipe peut confronter ses hypothèses à la réalité et réorienter la suite du projet.
Références
Ressources
- le Guide Scrum en français
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.