« Scrum », le mot ne vous dit peut-être rien. Et pourtant, c’est le nom d’une petite révolution dans la manière de travailler et de faire de la gestion de projets. Le Scrum définit un cadre méthodologique à la fois précis et souple pour la gestion de projets technologiques, innovants ou complexes. Ses objectifs : améliorer la productivité des équipes, favoriser le dialogue entre les parties prenantes et optimiser la réussite finale des projets.
En effet, et c’est tout particulièrement vrai dans le cadre de projets web, tous les professionnels seront d’accord pour faire ce constat : la gestion classique de projet, qui repose sur le fameux cahier des charges, ne convient pas, à cause de sa rigidité, du manque de dialogue entre les clients et les prestataires, et de l’effet tunnel. Les projets sont rarement livrés dans les délais et entraînent le plus souvent des dépassements de budgets. Pire encore, le résultat final est parfois loin des attentes initiales des clients. L’agilité du Scrum permet d’éviter tous ces écueils. Justement, qu’est-ce que le Scrum concrètement ? Comment fonctionne cette méthode utilisée par de plus en plus d’organisations (y compris le FBI !) ? Qu’est-ce qu’un sprint, un backlog, un user story, un Scrum Master, un Daily Scrum ? Et surtout : comment mettre en place facilement et rapidement ce cadre de travail au sein de votre entreprise ? quelles étapes suivre ? quels outils utiliser ? Dans cet article, inspiré du guide complet d’Andrew Littlefield, nous revenons sur tout ces points. Bonne lecture !
Qu’est-ce que le scrum et la gestion de projet « agile » ?
Définition
Le Scrum est LA méthode agile, celle dont on parle le plus, celle qui est la plus utilisée. Pour commencer, d’où vient ce nom bizarre : « Scrum » ? Le terme peut être traduit par « mêlée ». Ce qui pose d’emblée le décor. En fait, « Scrum » fait référence au rugby et à ses valeurs, comme l’esprit d’équipe. Et plus précisément au fait que, dans une mêlée, l’objectif est de faire circuler le ballon (le projet) en restant uni. Le Scrum, comme toutes les méthodes agiles, définit, plus qu’une méthode, un cadre méthodologique, un framework de gestion de projets. On pourrait même parler de paradigme, de culture. Avec le Scrum, c’est une toute nouvelle manière de travailler d’organiser le travail qui est en jeu. On pourrait presque parler de « philosophie », ou de « culture Scrum ». On le verra, le Scrum se caractérise par une définition des rôles nouvelles, par l’itération, par une organisation particulière des réunions, mais aussi par des règles du jeu bien définies.
Les méthodes agiles, dont le Scrum fait partie, sont clairement une réaction à la rigidité et aux lourdeurs d’exécution des méthodes traditionnelles de gestion de projet. L’éclosion de ces méthodes a pour genèse le constat simple que les méthodes classiques ne conviennent pas à la gestion de projets web, technologiques ou innovants. Le Scrum entend en finir avec le sempiternel cahier des charges et sa rigidité congénitale. En gros, pour faire très simple,la gestion de projet classique ressemble à ça :
- Le porteur de projet (le maître d’ouvrage) établit un cahier des charges de plusieurs pages (ou de plusieurs dizaines de pages), dans lequel tous les besoins sont définis et spécifiés.
- L’équipe en charge du développement (le maître d’oeuvre, ou prestataire) reçoit le cahier des charges et réalise le travail demandé.
Dans ce mode de fonctionnement classique, il y a deux problèmes majeurs. Premièrement, le manque de dialogue entre le maître d’oeuvre et le maître d’ouvrage, qui entraîne souvent un déphasage entre le besoin initialement exprimé par le client et le produit livré par le prestataire au moment de la recette. Evidemment, il y a des échanges, mais ceux-ci sont basés sur l’existence d’un cahier des charges qui déterminent le travail à réaliser de A à Z. Deuxième problème : le côté encore une fois très rigide, le manque de souplesse du cahier des charges, qui empêche, du fait de l’effet tunnel, les remises en questions et les évaluations en cours de route de la pertinence de telle fonctionnalité, de telle idée.
Dans le Scrum, il s’agit d’aller à l’encontre de cette façon de procéder, en partant du principe que tout prévoir et tout spécifier à l’avance, avant la phase de développement, est contre-productif. Le Scrum est basé sur des cycles de développement courts : le projet est découpé en blocs qui correspondent à des besoins (on parle d' »user story » en langage Scrum), et à chaque réalisation d’un bloc, une étape de validation intervient qui permet de recueillir des feedbacks, d’affiner ou de réajuster le besoin. Dans une approche Scrum, les changements et les bifurcations dans le projet sont autorisées, voire favorisées. Si des idées contenues dans le brief initial s’avèrent être de mauvaises idées, elles sont abandonnées. Dans la philosophie Scrum, l’idée centrale c’est qu’une bonne idée peut venir en cours de route, au fil des expérimentations et de l’avancée du projet. Le Scrum est une méthode essentiellement expérimentale et incrémentale.
On l’a dit, le Scrum fonctionne sur des cycles courts. Ce qui se traduit non seulement par une division du projet global en blocs et en besoins, mais aussi par une division du temps de travail. L’itération est une notion très importante dans le Scrum. L’idée est d’enchaîner des itérations d’une durée de 1 à 4 semaines, dont chacune correspond à la réalisation d’une partie du projet, à la mise au point d’une fonctionnalité, à la réponse à un besoin précis. Ces itérations sont aussi appelées « sprints ». « Itérations », « sprints » et « cycles courts » sont synonymes. Mais au fait, d’où vient le Scrum ?
L’histoire du scrum
Les méthodes dites « agiles » trouvent leur origine aux états-unis et au Japon et ont émergé dans les années 1970 – 1980, dans le sillage du toyotisme et du lean management. Les premières entreprises à appliquer ce nouveau paradigme de gestion de projet (ou de produit), ce sont des entreprises comme Toyota, Fuji et Honda. Mais les méthodes agiles telles qu’on les pratique aujourd’hui doivent surtout à Jeff Sutherland, un Américain cette fois, un ancien pilote de l’US Army reconverti dans l’informatique. 
Un autre événement important, qui concerne toutes les méthodes agiles, a lieu en 2001, avec la parution du Manifeste Agile, résultat d’une rencontre entre plusieurs figures éminentes du développement logiciel. C’est d’ailleurs à partir de cette date que le terme « méthode agile » entre dans le langage.
La répartition des rôles et le travail en équipes dans le Scrum
A la division du projet en besoins et à la division du temps s’adjoint une division des équipes qui reflète une organisation du travail tout sauf improvisée. Dans un projet Scrum, l’équipe est divisée en trois composantes (et seulement trois), qui remplissent chacune un rôle bien défini :
- Le Product Owner, qui est le représentant du client porteur du besoin. Il est complètement intégré dans la réalisation du projet. C’est le Product Owner qui porte la vision du produit à réaliser, spécifie les besoins et travaille main dans la main avec l’équipe de développement. C’est lui qui valide les fonctionnalités développées et plus généralement les différentes phases d’avancement. C’est lui qui réalise le backlog, c’est-à-dire la liste des fonctionnalités et caractéristiques attendues du produit final, et, dans cette liste, défini les priorités.
- L’équipe de développement, à laquelle revient la tâche de réaliser le produit en répondant aux besoins et aux attentes du Product Owner. Pour être fidèle à la logique Scrum, l’équipe se doit d’être pluridisciplinaire. Dans un projet web, elle comprend aussi bien des développeurs que des graphistes ou des analystes. Le terme de « développement » doit donc être pris au sens large. En fonction de la taille du projet, l’équipe de développement peut intégrer de 3-4 à 200 personnes.
- Le Scrum Master, qui joue le rôle de chef d’orchestre et de coach. Il veille au respect de la méthode Scrum et au bon déroulement du process, en appliquant une méthode de management « participative » (et non « directive »). La personne choisie pour être le Scrum Master est en général une personne qui est reconnue pour ses compétences en gestion et direction de projets.
Ces trois rôles vont être impliqués dans la réalisation du processus Scrum. Ce processus, on l’a dit, est divisé en périodes temporelles définies à l’avance (de 1 à 4 semaines), appelées Sprints. Dans chaque Sprint, les équipes travaillent sur la réalisation d’un besoin, d’une partie du projet (à partir du backlog). Tous les jours, une réunion est organisée, qui permet à chacun de faire état de son avancement et des problématiques rencontrées : c’est le Daily Scrum (ou « Daily Stand-Ups »). Chaque itération, chaque sprint s’achèvent par ce qu’on appelle une « rétrospective », qui est l’occasion de faire un bilan du travail accompli et de réfléchir à de possibles améliorations (dans l’optique du prochain sprint). Voyons maintenant comment mettre concrètement en place un Scrum.
Vous préparez une levée de fonds ? Découvrez notre article sur l’art du pitch en startup (avec 6 exemples de pitch & zoom sur le deck de la série A de FrontApp.
Mise en place d’un framework Scrum simple : les étapes à suivre
Vous en avez assez de gérer vos projets à l’ancienne. Vous voulez innover dans votre mode de gestion de projet, pour aller plus vite tout en étant plus productif et plus efficace ? Le problème avec la méthode Scrum, c’est qu’elle est très simple à comprendre, mais plus difficile à maîtriser. Mais ce n’est pas une raison de vous démotiver. Il y a un début à tout, et vous pouvez très rapidement mettre en place un framework Scrum pour un projet simple.
Voici les principales étapes à suivre pour commencer à travailler suivant une méthodologie / optique Scrum :
- Téléchargez le guide officiel de la méthode Scrum, proposé par Jeff Sutherland et Ken Schwaber et disponible ici. Prenez le temps de le lire, dans les transports, pendant la pause-déjeûner…Ce guide vous apprendra des tas de choses et vous donnera des tonnes de conseils sur la manière d’engager un processus de travail Scrum.
- Déterminez les rôles. Pour rappel, il faut un Product Owner, un Scrum Master et une équipe.
- Créez votre backlog. Le backlog, c’est le document sur lequel vous listez tous les besoins contenus dans le projet/produit. Vous devez aussi classer les besoins par ordre d’importance, prioriser. Gardez à l’esprit que votre backlog est forcément incomplet. De nouveaux besoins apparaîtront à mesure du déroulement du projet. A chaque fois qu’un nouveau besoin se fait jour, rajoutez-le dans le backlog. C’est le Product Owner qui est responsable du backlog, de la définition des besoins à leur priorisation.
- Sélectionnez un besoin à partir de votre backlog. Il constituera l’objet de travail de votre premier sprint. Rappelons que chaque sprint, y compris le premier, est limité dans le temps. Vous devez donc aussi déterminer la longueur de votre sprint : une semaine, deux semaines, trois semaines, un mois (maximum). Cela dépend de la complexité des tâches, des besoins. Toute l’équipe doit déterminer, pour chaque sprint, les tâches qui seront réalisées et leur partage au sein des membres.
- Il est maintenant temps de commencer à travailler sur votre premier sprint. Chaque membre de l’équipe travaille sur la tâche qui lui a été confiée. Chaque jour, vous organisez une réunion (Daily Scrum) pour faire le point sur ce qui a été fait la veille et sur ce qui va être fait aujourd’hui. Les réunions quotidiennes, qui ne doivent pas durer plus de 15 – 20 minutes, sont aussi l’occasion de partager sur les éventuels problèmes ou points de blocage rencontrés la veille.
- A la fin du premier sprint, tous les membres de l’équipe doivent présenter leur travail fini et en faire un bilan. C’est la réunion de « rétrospective ». Cette réunion doit aussi être l’occasion de faire un point sur l’état de réalisation du projet et de discuter des possibles idées d’amélioration.
- C’est parti pour un nouveau sprint !
Les outils pour gérer un projet Scrum : l’exemple de Trello
La transparence est un des principes essentiels du Scrum. Chaque membre de l’équipe doit être au courant de ce que les autres font, des tâches qu’ils réalisent, des objectifs qu’ils poursuivent et de leur niveau d’avancement. La transparence est la base du travail en équipe. C’est la raison pour laquelle il est très important d’utiliser des outils qui permettent de rendre facilement visible ce que les autres font. Un de ces outils est le Scrum Board. Il permet d’organiser le backlog, de voir les objectifs accomplis et surtout l’avancement des tâches en cours (To Do ==> In Progress ==> Done). Le Board peut être réalisé avec un tableau et des stickers. Mais vous pouvez aussi utiliser des logiciels de collaboration professionnelle comme Trello, qui ont l’avantage de permettre une visualisation très claire du workflow. Nous avons déjà eu l’occasion de parler de Trello dans un article intitulé « Organiser la rédaction de vos articles comme un pro avec Trello« . Trello permet de créer des planches, organisées en « cartes » et en colonnes. Les cartes, qui correspondent à des tâches, peuvent être déplacées d’une colonne à l’autre à mesure de leur avancement. Sur ces cartes, il est possible de partager des commentaires, des fichiers, etc. Libre à vous d’organiser votre board Trello (ou vos boards) comme vous l’entendez.
Voici un exemple d’organisation des colonnes d’une planche Trello, dans une optique Scrum (exemple de Andrew Littlefield) :
- Colonne « Ressources », qui contient toutes les tâches récurrentes. Cela permet d’éviter d’avoir à recréer une carte à chaque fois que la tâche est renouvelée (au contraire, il vous suffit de la déplacer dans les autres colonnes lorsque la tâche est en cours, avant de la replacer dans la colonne Ressources).
- Colonne « Backlog », qui contient la liste des tâches sur lesquelles l’équipe doit travailler.
- Colonne « To Do », qui contient les cartes des tâches à accomplir pendant le sprint en cours.
- Colonne « Doing » : lorsque le membre de l’équipe en charge d’une tâche commence à travailler dessus, il déplace la carte correspondante de la colonne « To Do » à « Doing ».
- Colonne « QC », pour « Quality Check ». Lorsque la personne en charge d’une tâche l’a terminée, il déplace la carte correspondante de la colonne « Doing » à la colonne « QC ». Le Scrum Master et le Product Owner peuvent vérifier que le résultat des tâches accomplies. Remarque : dans le cadre de l’organisation d’un process de rédaction d’articles, c’est la colonne « Relecture » qui joue le rôle de la colonne QC.
- Colonne « Done ». Après avoir vérifié que la tâche avait bien été accomplie, la carte correspondante passe de QC à Done. Sa mise en oeuvre peut être planifiée (par exemple, s’il s’agit d’une fonctionnalité, il est possible de planifier le jour de son intégration au produit).
- Colonne « Blocked ». Une carte de tâche est déplacée dans la colonne « Blocked » lorsqu’un problème surgit en cours de réalisation. La box de commentaire intégrée dans la carte permet à celui qui a identifié le problème d’en faire part aux autres.
Trello est un outil très efficace et très pertinent dans le cadre d’un projet Scrum mais également avec Kanban. Les planches (boards) Trello peuvent être partagés entre tous les membres de l’équipe, ce qui permet à chacun d’avoir une vue globale de l’avancée du sprint et du travail des autres. La possibilité d’ajouter des commentaires sur les planches, de créer des checklists ou de mettre en place un calendrier permettent d’avoir encore plus de détails sur la réalisation des différentes tâches. Trello peut par ailleurs être intégré à Slack, un autre outil de gestion de projet génial. Pour conclure sur cette partie, disons que pour mener à bien une gestion de projet « agile », il vous faut des outils eux-mêmes « agiles ». Ces outils, ils existent et sont gratuits, pourquoi ne pas les utiliser ?
Vous ne connaissez pas (encore) Slack ? Si c’est le cas, nous vous invitons chaudement à le découvrir en lisant notre article sur le phénomène Slack (croissance, usages et avis).
Conclusion sur les méthodes agiles et le Scrum
Le concept le plus important dans les méthodes agiles (il y a beaucoup de concepts importants, il faut bien l’avouer !), et dans le Scrum en particulier, c’est celui d’itération. C’est l’organisation du travail et des objectifs en cycles courts qui donne toute sa puissance au Scrum et permet d’améliorer la productivité et la qualité du produit final. Chaque sprint s’attache à la réalisation d’un besoin précis, d’une partie du projet global. Si vous développez une application mobile, un besoin correspond en général à une fonctionnalité. Il est très important d’avoir à l’esprit la chose suivante : le travail délivré à la fin de chaque sprint doit être opérationnel pour le client. Le Scrum implique des livraisons itératives au client, à la fin de chaque cycle. Il faut être en mesure d’évaluer le travail à la fin du sprint, pendant la réunion de « rétrospective ». Si le besoin est une fonctionnalité, elle doit pouvoir être testée tout de suite. Il existe des formations sur la gestion de projet qui intègrent ces concepts.
Dans le cas contraire, il est très difficile de dégager des pistes d’amélioration. L’effet tunnel ressurgit et on retombe dans les défauts de la méthode classique (basée sur le cahier des charges). D’où le deuxième concept important du Scrum : l’idée d’amélioration continue, via les feedbacks inter et intra-sprints. D’ailleurs, l’amélioration continue ne concerne pas uniquement le produit et ses fonctionnalités. Le process de Scrum peut lui aussi faire l’objet d’adaptations en cours de route – si par exemple on s’aperçoit que la répartition des tâches à l’intérieur de l’équipe de développement est déficiente. Par contre, il faut trouver le juste milieu entre la recherche de souplesse optimale la nécessité d’une organisation rigoureuse du travail.
Bien appliquée, les méthodes agiles et le Scrum en particulier permettent de gagner beaucoup de temps en améliorant la productivité des équipes. A vous de jouer !
Voici quelques ressources pour aller plus loin dans la compréhension du Scrum (et la manière de le mettre en place concrètement) :
- Scrum : The Art of Doing Twice the Work in Half the Time. Ce livre, rédigé par Jeff Sutherland, explique tout ce qu’il faut savoir sur le Scrum, de manière ludique et avec plein d’anecdotes concrètes.
- The Scrum Guide. Rédigé par Jeff Sutherland et Ken Schwaber, ce guide vous donnera les bases pour commencer avec le Scrum.
- The Scrum Primer (en français). Un petit guide d’une vingtaine de pages qui aborde l’essentiel pour comprendre la logique et le fonctionnement du Scrum.
- Agile Vs Kanban: What’s the Difference? Un petit guide pratique qui explique les différences entre la méthode Agile et la méthodologie Kaban