Agile Scrum Quelle est la différence Capterra

La semaine dernière, je donnais une formation Scrum Master. Les participants avaient pour vocation de jouer, à plus ou moins brève échéance, le rôle de Scrum Master. Le premier matin, j’étais en train d’expliquer les six fondamentaux : émergence, priorité, auto-organisation, transparence, empirisme et rythme. Je les avais présentés comme les “fondamentaux de l’agilité”. C’est alors qu’un participant me demande de clarifier : Claude, est-ce que tu parles de Scrum ou d’agile ? quelle est la différence entre les deux ?

Ce n’est pas la première fois qu’on me pose une question à ce propos. Elle est le symptôme d’une méconnaissance d’une de ces notions, voire des deux. Cela se comprend pour des débutants. Mais ce n’est pas uniquement une question de débutants : même après plusieurs mois d’expérience, il arrive fréquemment qu’un praticien attribue à Scrum la notion de user story ou considère le planning poker comme en faisant partie. Pourtant, si ce sont bien des pratiques agiles, elles ne font pas partie de Scrum. On confond les pratiques qui forment le cadre Scrum avec celles qui peuvent être utilisées avec.

Le risque de confusion est renforcé par des articles, des discussions sur les réseaux sociaux, et aussi par des offres d’emploi, qui parlent de Scrum Agile —on trouve aussi Scrum/Agile— de façon bien peu claire.

Essayons d’éclaircir ce qui se cache derrière ces appellations.

Le sens des mots

Les deux termes viennent de mots qui sont dans le dictionnaire :

  • En anglais, scrum fait référence au rugby, c’est la mêlée en français.
  • En anglais comme en français, on trouve bien sûr l’adjectif agile.

Pour différencier du scrum en rugby, on écrit Scrum avec une majuscule pour évoquer ce truc agile, à savoir un cadre de développement de produit.

Agile étant un adjectif, on trouvera différentes écritures : agile avec un petit a, par exemple dans méthode agile, ou avec un grand A, comme dans Manifeste Agile.

Parfois l’adjectif devient un nom propre, car si on peut être agile, il ne serait pas très français de dire qu’on fait de l’Agile sans mettre un grand A. Savoir s’il faut écrire avec un petit a ou un grand A, ce n’est pas toujours facile.

Alors on peut passer au substantif avec agilité. Ou plutôt le terme Agilité, c’est ce que j’utilise, et de plus en plus, pour qualifier le mouvement de pensée dont une définition possible est la suivante :

L’Agilité est la capacité d’une organisation à fournir tôt et souvent des services procurant de la valeur, tout en s’adaptant à temps aux changements dans son environnement.

En bref, Scrum fait partie de ce mouvement, en est un des éléments. Un élément important, certes, mais qui est loin d’être le seul. On peut donc se réclamer de l’Agilité sans passer par Scrum. En revanche, pratiquer Scrum sans être Agile n’est pas recommandé…

Toutefois, approfondissons en commençant avec un peu d’histoire.

L’histoire : différences et convergences entre Scrum et Agile

Scrum précède Agile (1995–2001)

Scrum est apparu vers 1995, à une époque où on ne parlait pas encore d’Agile. Pourquoi cette référence au rugby ? Cela vient de chercheurs japonais qui avaient mis en évidence, pour développer des produits innovants et complexes, la préférence au travail collectif, où tout le monde pousse en même temps dans le même sens, comme dans une mêlée.

Les fondateurs de Scrum, Ken Schwaber et Jeff Sutherland, ont associé à cette idée centrale d’effort collectif la notion de développement itératif et incrémental qui émergeait alors dans le développement logiciel. Cela a donné le sprint, élément-clé de Scrum.

Scrum est resté marginal durant ces premières années. En France, on n’en parlait pas.

Scrum est une des méthodes agiles (2001–2006)

Le mot agile dans ce contexte vient du Manifeste Agile, qui date de 2001. 17 spécialistes du génie logiciel se sont réunis dans les Montagnes Rocheuses pour cette déclaration fondatrice. Parmi les participants, il y avait les 2 créateurs de Scrum.

Le Manifeste Agile avait l’ambition de défendre les processus légers par rapport aux processus lourds en vigueur à l’époque (et encore aujourd’hui,
on en voit revenir sous des formes camouflées).

Il repose sur 4 valeurs relatives et 12 principes.

La valeur qui est réellement en relation avec l’Agilité énonce la préférence à la réponse au changement plutôt qu’au suivi du plan. C’est ce besoin d’adaptation qui est souvent le déclencheur du passage à l’Agilité. Pouvoir prendre des décisions et survivre dans un monde de plus en plus incertain et complexe est effectivement une capacité attendue avec l’Agilité.

Une autre valeur est fondamentale, celle qui met en avant la primauté de l’aspect humain : les gens et les interactions sont plus importants que les processus et les outils. Elle définit, mine de rien, une rupture fondamentale avec les approches processus.

Le Manifeste ne donne pas d’indication sur la façon de faire —quelles pratiques utiliser, dans quel ordre— mais il a contribué à mettre sous une bannière agile unique des méthodes, comme Scrum, qui existaient déjà à l’époque. C’est ainsi que sont nées les méthodes agiles. Elles se sont diffusées tranquillement au début, puis plus largement, le mot agile ayant fonctionné comme attracteur efficace et Scrum comme catalyseur des expériences.

Scrum est la méthode agile la plus populaire (depuis 2006)

Parmi ces méthodes, beaucoup ont disparu au fil du temps. Scrum s’est imposé à partir de 2006. Cela fait maintenant une douzaine d’années que toutes les enquêtes montrent une utilisation très majoritaire de Scrum parmi les expériences qui se réclament des méthodes agiles.

Le vocabulaire reflète cette prédominance : sprint (pour itération) et backlog (pour liste des choses à faire) sont largement employés même par ceux qui ne se réclament pas explicitement de Scrum. Les rôles de Scrum Master et de Product Owner sont reconnus par à peu près tout le monde et on les retrouve largement dans les offres d’emploi.

Fin de l’histoire ? On pourrait se dire que Scrum et Agile, c’est pareil. Il n’y aurait pas vraiment de différence, Scrum étant le nom donné à la façon de mettre en place Agile.

Pas tout à fait.

La rançon du succès

Scrum est devenu prépondérant, mais le mouvement, l’Agilité, en prenant de la maturité, s’est ouvert et enrichi. Comme nous l’avons vu, le point de départ a été le Manifeste Agile, qui s’appliquait au développement de logiciel.

Évolutions polymorphes de l’Agilité

Depuis 2001 et en particulier ces dernières années, le mouvement s’est ouvert sur plusieurs axes :

  • Application vers d’autres domaines (pas uniquement le développement de logiciel),
  • Inclusion de nouveaux outils, comme les jeux pour apprendre, pour collaborer vers un résultat ou pour s’améliorer en tant qu’équipe,
  • Ajout de techniques, en amont de Scrum, pour définir le produit, comme le Lean Startup,
  • Coaching d’équipes ou de personnes,
  • Association avec des approches nouvelles de management (Management 3.0) et d’organisation (Entreprises libérées),
  • Émergence d’approches complémentaires à Scrum, comme par exemple Kanban apparu vers la fin des années 2000 et DevOps plus récemment.

Tout cela se voit dans les publications et les très nombreuses conférences sur l’Agilité qui ont lieu dans toute la France. Il y en a plusieurs dizaines dans toutes les villes de France et de Navarre. La plus importante est Agile Grenoble, qui réunit plus de 500 personnes et qui en est à sa 10e édition.

À travers les expérimentations de ces nouveaux outils et leur adoption, l’Agilité a impulsé une dynamique et continué sa diffusion. Cette ouverture a permis à l’Agilité de couvrir plus largement le cycle de vie des produits ou services, pendant que Scrum gardait son rôle central pour le développement. L’Agilité est devenue mainstream.

Agile a perdu de son sens

La métaphore a très bien fonctionné. Trop bien. On dit agile ou agilité à toute occasion, on l’entend même dans des pubs à la télé.

On confond agile et Agile, agilité et Agilité.

Le problème dans les entreprises, c’est quand Agilité est utilisé pour dire flexibilité, et c’est souvent une flexibilité imposée par le management, qui ignore les principes fondamentaux, comme l’auto-organisation.

Par exemple : “Vous êtes agiles, alors vous allez me faire cette tâche avant la fin du sprint.”

Cette phrase énoncée par un manager à une équipe Scrum révèle une mauvaise compréhension de l’Agilité. Ce manager abuse de son pouvoir pour imposer ce qu’il estime être une urgence.

Si l’adaptation au changement est bien favorisée, c’est à ceux qui font –donc à l’équipe– de décider de la prise en compte du changement. Le rôle de chef de projet qui décide est supprimé dans Scrum, au profit de l’auto-organisation.

D’autres phrases couramment entendues sont le reflet de la perte du sens dans l’emploi du mot agile :

“Nous sommes agiles, car nous utilisons

.”

Même si l’emploi d’un outil pour partager le backlog ou pour suivre le sprint est bien sûr possible, en particulier si l’équipe n’est pas co-localisée, ce n’est pas un argument décisif se définir Agile. La phrase suggère plutôt un risque, celui de faire passer l’outil avant la collaboration entre les personnes. Il est préférable d’apprendre d’abord à travailler ensemble et de définir seulement ensuite si un outil est nécessaire. Si c’est le cas, il ne faudra pas hésiter à comparer et tester pour trouver celui qui répond aux besoins de l’équipe. C’est à chaque équipe de faire son choix en tenant compte de son contexte.

“Ce n’est que du bon sens, finalement nous sommes déjà agiles.”

Certes on peut déceler du bon sens dans certaines pratiques (quoique la notion de bon sens est sujette à caution), mais cette phrase cache probablement une négation de l’effort nécessaire pour accéder aux premiers bénéfices de l’Agilité.

Idées reçues sur Scrum

Agilité, le mot a été récupéré, mais qu’en est-il avec Scrum, qui est moins sujet à confusion (son usage pour le rugby est le fait des anglophones) ?

La rançon du succès, c’est du Scrum qui n’en est pas vraiment.

Scrum ? mon scrotum ! c’est le titre provocateur d’une présentation que j’ai donnée dans plusieurs conférences, pour dénoncer les dérives dans l’utilisation de Scrum, et proposer des solutions.

La première raison de ces dérives, c’est l’ignorance. Parmi les nouveaux arrivants dans l’Agilité, beaucoup ne connaissent pas l’histoire, et certains ont une connaissance superficielle des fondamentaux du fait de l’absence de formation ou d’une formation insuffisante.

Voici des expressions qui dénotent de cette confusion avec Agile et de cette ignorance de Scrum :

“Pour ce projet, on passe en mode agile avec la méthodologie Scrum.”

Bullshit. Parler de mode agile et qualifier Scrum de méthodologie, ce sont de mauvais signes. En effet agile n’est pas un mode —ni une mode— parmi d’autres et Scrum n’est pas une méthodologie (à la limite une méthode, quoique ses fondateurs parlent plutôt de cadre).

De plus, le terme projet, qui implique un début, des étapes et leurs jalons, et une fin, ne convient pas.

Il n’est pas adapté à l’évolution des entreprises, notamment dans ce qu’on appelle les transformations numériques, où il s’agit de fournir régulièrement des services à valeur ajoutée.

Aux phases traditionnelles d’un workflow (conception, réalisation, test, …) se substitue la série des sprints, chacun déroulant en deux ou trois semaines toutes les activités nécessaires pour produire un résultat.

En fin de compte, Scrum vise à développer des produits ou des services, et a pour objectif de maximiser la valeur métier. Scrum n’est pas non plus une méthode qui dirait exactement comment faire. C’est un cadre dans lequel chacun ajoute des pratiques liées à son domaine.

“Scrum, c’est de la gestion de projet agile.”

Contresens. Parler de gestion de projet pousse à croire qu’on va planifier, puis allouer des ressources, puis contrôler. Ce n’est pas ça : une équipe Scrum n’est pas composée de ressources interchangeables. On ne mesure pas le temps passé et la productivité individuelle. Avec le sprint, la notion de boite de temps renverse le triptyque classique délai-coût périmètre.

“Scrum, c’est pour les équipes de développement.”

Inexactitude. Scrum s’appuie sur une équipe pluridisciplinaire capable de produire un résultat de valeur à la fin du sprint. Limiter Scrum à ceux qui développent ne permet pas de prendre en compte toute la chaîne de valeur. De plus, l’équipe Scrum n’est pas seule dans son environnement. Il convient de considérer tout l’écosystème en y incluant les parties prenantes, c’est-à-dire les personnes intéressées par ce que produit l’équipe.

Ce n’est pas l’objet de cet article de définir Scrum en détail. Il existe une référence, le Guide Scrum, et de nombreux ouvrages sur le sujet. Cependant, voici tout de même un bref résumé, tiré du premier chapitre de mon livre :

Scrum en bref

Avec Scrum, les gens travaillent en équipe.

Le rythme est donné par une série d’itérations (les sprints).

Toutes les choses à réaliser sont collectées dans une liste (le backlog).

Alimentée par cette liste priorisée, l’équipe travaille en flux continu, entrecoupé par la cadence régulière des événements du sprint :

  • Le premier événement, au début du sprint, consiste à se mettre d’accord sur un objectif, et à préparer le travail pour y arriver.
  • Le deuxième événement est un point quotidien de synchronisation, en équipe, pour converger vers l’atteinte de l’objectif.
  • À la fin du sprint, l’équipe présente le résultat qu’elle a obtenu pour solliciter du feedback, puis elle réfléchit à sa façon de travailler en vue de s’améliorer dans le sprint suivant.

Scrum pour démarrer en Agilité

Notre question de départ était : quelle est la différence entre Scrum et Agile ?

Nous avons indiqué que Scrum est un des éléments de l’Agilité, terme générique regroupant une large gamme d’outils, de techniques et de pratiques et portant des valeurs et des principes. Si ces derniers sont universels, la façon dont les premiers sont choisis et mis en oeuvre dépend complètement du contexte. C’est vrai si on considère l’Agilité, mais Scrum aussi est toujours adapté au contexte, imposant juste quelques pratiques.

Pour finir, essayons de voir si vous avez besoin de l’Agilité et de Scrum.

L’Agilité est nécessaire chaque fois que vos plans sont contrariés par des événements inattendus ou des réactions imprévues de vos utilisateurs. Je n’ai pas rencontré de situations où ce n’était pas le cas, mais je vous laisse vous positionner.

Pour obtenir les bénéfices attendus de l’Agilité, il faut un peu d’efforts et du temps. En effet, le premier bénéfice apparaît quand l’équipe réussit à produire un résultat, ce qui permet d’obtenir du feedback et ainsi d’améliorer le produit.

Cela demande un changement dans la culture de l’équipe, qui doit se concentrer vers ce résultat, dans une durée courte, afin que ces boucles d’amélioration soient fréquentes. Selon la culture des organisations, il faudra faire plus ou moins d’efforts. Celles qui sont le moins engluées dans des hiérarchies empilées et des processus rigides y arriveront plus facilement, c’est pourquoi les transformations sont plus rapides dans les

PME.

Bon, vous êtes décidé à passer à l’Agilité et vous souhaitez obtenir ces premiers bénéfices au bout de quelques mois ? Scrum a une place reconnue dans ce mouvement, qui a fait ses preuves depuis des années. On constate en effet que :

  • Le sprint, avec ses événements, favorise le changement de culture vers plus de collaboration.
  • Le cadre simple aide bien les membres de l’équipe à se focaliser vers le résultat.

C’est pourquoi, pour démarrer en Agilité et espérer en obtenir les premiers bénéfices, l’option Scrum représente souvent le choix le plus approprié.

Et en quoi les logiciels de gestion de projet aident à appliquer Scrum en entreprise ?

Comme on vient de le voir avec toutes ces idées reçues sur Scrum, les équipes en entreprises seront peut-être tentées d’investir dans un logiciel de gestion de projet et choisiront le premier outil à la mode ou bien alors le plus reconnu. Là encore, attention, c’est contraire à l’esprit des méthodes agiles qui font passer les personnes et les interactions avant les processus et les outils. Il ne faut pas hésiter à comparer, à comprendre les besoins de l’équipe lors de toutes les étapes du projet et à tester plusieurs logiciels de gestion Agile/Scrum.


À propos de l’auteur

Capterra Scrum Agile Claude Aubry

Claude Aubry est l’un des spécialistes français de Scrum. Il a écrit de nombreux articles et livres, dont le dernier en date est SCRUM, édition 5 aux Éditions Dunod dans la collection InfoPro. Vous pouvez le suivre sur twitter : @claudeaubry et sur son blog  Scrum, agilité & rock’n roll