Scrum : Une gestion de projet agile – moderne et flexible

Aujourd’hui, lorsque des équipes com­men­cent un projet, elles ne se lancent pas tête baissée dans le travail. Les commandes les plus im­por­tantes, en par­ti­cu­lier, re­quiè­rent une gestion de projet et de produit efficace. La méthode agile Scrum est ac­tuel­le­ment la pratique la plus courante dans de nom­breuses en­tre­prises. Cette approche met l’accent sur des méthodes de travail flexibles, un dé­ve­lop­pe­ment in­cré­men­tal et des pro­cé­dures trans­pa­rentes. Dans le contexte de la gestion de projet agile Scrum, on rencontre de plus en plus fré­quem­ment le terme « Scrum ». Conçu ini­tia­le­ment pour le dé­ve­lop­pe­ment logiciel, ce modèle est aujourd’hui également apprécié dans de nombreux autres secteurs. Dans cet article, nous vous ex­pli­quons ce que recouvre exac­te­ment ce mot à la mode.

Même si la forme qu’on lui connaît ac­tuel­le­ment date de 1995, l’histoire de Scrum remonte aux années 1980. En 1980, Ken Schwaber et Jeff Su­ther­land, qui avaient d’ores et déjà utilisé des modèles si­mi­laires in­di­vi­duel­le­ment dans leurs en­tre­prises, ont publié un papier commun. Cet article avait pour objectif d’augmenter la pro­duc­ti­vité du travail tout en in­tro­dui­sant un minimum de règles sus­cep­tibles de la limiter.

Pour y parvenir, Scrum établit un cadre de travail (framework) uti­li­sable dans dif­fé­rentes si­tua­tions. L’objectif est d’améliorer con­ti­nuel­le­ment notre façon de tra­vail­ler ainsi que le produit. Pour ce faire, le framework comporte des rôles, des évé­ne­ments, des artefacts et des règles définis. Ces limites doivent permettre aux équipes Scrum d’atteindre des résultats aussi efficaces que possible afin de fournir au client un produit d’une meilleure qualité. Le client – ou le donneur d’ordre – et l’uti­li­sa­teur occupent donc une place es­sen­tielle dans Scrum puisque le dé­ve­lop­pe­ment est axé sur leurs exigences.

Lorsqu’on applique l’approche Scrum, deux termes clés jouent un rôle récurrent :

• itératif : Avec Scrum, le produit est en constante évolution. Le travail décrit donc un cercle qui va de la pla­ni­fi­ca­tion à l’éva­lua­tion en passant par le dé­ve­lop­pe­ment et la phase de test avant de revenir à la phase de pla­ni­fi­ca­tion. Scrum ne porte donc pas uni­que­ment sur la pro­duc­tion initiale, mais aussi sur les dé­ve­lop­pe­ments ul­té­rieurs.
• in­cré­men­tal : Scrum est basé sur l’idée qu’un produit est le résultat d’une suc­ces­sion d’étapes qui re­pré­sen­tent des objectifs in­ter­mé­diaires. La méthode Scrum se démarque ainsi de l’approche visant à atteindre un seul objectif majeur en fin de dé­ve­lop­pe­ment. Les grands projets sont divisés en projets de moindre envergure pour permettre une plus grande flexi­bi­lité.

En combinant les approches itérative et in­cré­men­tale, on obtient un processus pro­gres­sif et durable dans le cadre du dé­ve­lop­pe­ment. D’une part, le processus est alors nettement plus trans­pa­rent puisqu’il prévoit des contrôles fréquents du travail (résultant de l’approche par petites étapes suc­ces­sives) et d’autre part, il permet d’améliorer la qualité du produit puisque sa fonc­tion­na­lité est contrôlée en continu.

À l’origine, Scrum vient du dé­ve­lop­pe­ment logiciel agile. On utilise la méthode agile Scrum pour améliorer en per­ma­nence le travail effectué sur les pro­grammes. Mais Scrum est également utilisé avec succès pour d’autres produits – par exemple dans la fa­bri­ca­tion de matériel in­for­ma­tique. Chaque projet Scrum ne s’achève toutefois pas né­ces­sai­re­ment avec un produit au sens propre du terme : les avantages de Scrum peuvent également se révéler bé­né­fiques pour un projet axé sur les résultats. Ce modèle est par exemple utilisé pour organiser des équipes marketing ou des organes d’ad­mi­nis­tra­tion ainsi que pour le dé­ve­lop­pe­ment de pres­ta­tions de service.

Scrum est toujours basé sur de petites équipes, « petit » étant ici un terme relatif : ce modèle flexible est en effet moins adapté à de grands groupes de travail, mais il est souvent possible de diviser ces derniers en équipes de moindre envergure. Scrum est également idéal pour mettre en relation des équipes. Ce modèle accorde en effet une place pré­pon­dé­rante au travail d’équipe dont les dif­fé­rents membres doivent se compléter par des aptitudes diverses.

Scrum n’est pas considéré comme une méthode fixe ou une approche de travail concrète, mais plutôt comme un simple cadre de travail qui offre aux équipes des repères fixes pour leur travail. Ce cadre comporte des rôles, des évé­ne­ments et des artefacts dé­ter­mi­nés.

Une équipe Scrum comporte trois rôles fixes : l’équipe de dé­ve­lop­pe­ment, le Product Owner et le Scrum Master. L’équipe regroupe les dé­ve­lop­peurs du produit à pro­pre­ment parler. Le groupe est composé de telle sorte qu’il peut s’auto-organiser afin de dé­ter­mi­ner comment accomplir un objectif convenu. Par ailleurs, les équipes Scrum ne disposent pas de hié­rar­chie. Chaque col­la­bo­ra­teur a bien sûr son propre domaine de res­pon­sa­bi­lité, mais au final, l’équipe rend compte du produit de façon commune.

La taille de l’équipe n’est pas clai­re­ment définie : elle doit être composée de façon à pouvoir agir ra­pi­de­ment et avec flexi­bi­lité tout en restant per­for­mante, c’est-à-dire être ni trop grande ni trop petite. K. Schwaber et J. Su­ther­land proposent de composer des équipes de 3 à 9 membres.

Dans une équipe Scrum, le Product Owner est res­pon­sable de la qualité du produit et du travail et assume donc une fonction de contrôle. Le Product Owner organise le Backlog Produit, une liste qui définit les exigences du projet (de plus amples in­for­ma­tions sur le Backlog Produit sont dis­po­nibles au point Artefacts Scrum.) Il a également pour tâche d’organiser les objectifs selon un ordre pertinent et de les do­cu­men­ter de façon com­pré­hen­sible. Le Product Owner est un rôle directif : même si les équipes dé­fi­nis­sent per­son­nel­le­ment la façon dont elles en­vi­sa­gent d’atteindre les objectifs formulés dans le Backlog, la dé­ter­mi­na­tion des objectifs est la res­pon­sa­bi­lité du Product Owner. Et il ne saurait être remis en question : pour atteindre une pro­duc­ti­vité maximale, l’équipe doit pouvoir se reposer sur les décisions du Product Owner. Cependant, on ne peut pas con­si­dé­rer le Product Owner comme un cadre de direction : le Product Owner et son équipe ont des tâches dis­tinctes et font référence dans ces domaines. Tout comme l’équipe n’a pas son mot à dire sur le Backlog, le Product Owner ne se mêle pas du processus de dé­ve­lop­pe­ment.

Le Scrum Master fait office de médiateur entre les deux autres rôles. Les Scrum Masters ont pour res­pon­sa­bi­lité d’intégrer et de mettre en œuvre Scrum dans le processus de travail. Par con­sé­quent, ce rôle est également res­pon­sable de l’or­ga­ni­sa­tion des évé­ne­ments Scrum : il fixe les réunions et en assure la mo­dé­ra­tion. Le Scrum Master se tient également prêt à assister l’équipe et le Product Owner, mais n’in­ter­vient jamais dans le processus de dé­ve­lop­pe­ment à pro­pre­ment parler. Sa fonction consiste uni­que­ment à sim­pli­fier les processus de travail pour les col­la­bo­ra­teurs par­ti­ci­pants à la pro­duc­tion et ainsi, à augmenter la pro­duc­ti­vité et la créa­ti­vité.

En tant qu’in­ter­lo­cu­teur, le Scrum Master veille à la bonne com­pré­hen­sion des processus par les parties prenantes : il donne des conseils pour la création des Backlogs ou l’or­ga­ni­sa­tion de l’équipe et, de façon générale, essaie d’éliminer les obstacles. Le Scrum Master in­ter­vient donc notamment en tant que coach. Ce rôle implique de par­fai­te­ment connaître Scrum, raison pour laquelle une cer­ti­fi­ca­tion en tant que Scrum Master est proposée. Il existe aujourd’hui plusieurs or­ga­nismes de cer­ti­fi­ca­tions proposant des for­ma­tions cor­res­pon­dantes. La Scrum Alliance et Scrum.org ont été fondées par Ken Schwaber et proposent les cer­ti­fi­cats Certified Scrum Master ou Pro­fes­sio­nal Scrum Master.

Un processus de travail organisé selon le principe de Scrum fait in­ter­ve­nir des évé­ne­ments ré­cur­rents. Puisque Scrum est un processus itératif, le travail est accompli dans des cycles ré­pé­ti­tifs : chaque événement est répété à chaque nouveau cycle. Grâce à la fréquence de ces évé­ne­ments, les réunions imprévues ne sont que rarement ou ab­so­lu­ment pas né­ces­saires. Tous les évé­ne­ments sont par ailleurs limités dans le temps.

On appelle ce cycle un Sprint. Il décrit la période d’une phase de dé­ve­lop­pe­ment. À la fin d’un Sprint, l’équipe de dé­ve­lop­pe­ment livre un incrément produit fini. Cela signifie que le dé­ve­lop­pe­ment doit avoir donné naissance à un produit po­ten­tiel­le­ment livrable. Chaque Sprint a ainsi une mission concrète que l’on marque comme « terminée » à la fin du cycle. La limite tem­po­relle d’un Sprint est définie au préalable, mais ne devrait pas dépasser 30 jours. Pour dé­ter­mi­ner cette limite, il doit être tenu compte des facteurs suivants : un Sprint ne peut être ni prolongé ni raccourci et les futurs Sprints du projet devront avoir la même longueur.

Les Sprints sont dé­li­bé­ré­ment courts afin de formuler les objectifs de façon aussi simple que possible. Cette courte durée permet également d’assurer une vé­ri­fi­ca­tion du dé­ve­lop­pe­ment au minimum une fois par mois. Dans des cas ex­cep­tion­nels, le Product Owner (et uni­que­ment lui) peut annuler un Sprint. Une telle an­nu­la­tion est par exemple possible lorsqu’il n’est plus né­ces­saire d’atteindre l’objectif, car l’en­tre­prise a fixé un nouvel objectif entre-temps. En principe, les Sprints ne doivent pas être annulés, car cette an­nu­la­tion diminue fortement la pro­duc­ti­vité.

Un Sprint commence avec la Pla­ni­fi­ca­tion du Sprint (Sprint Planning) : tous les rôles de l’équipe Scrum par­ti­ci­pent à cet événement. Les parties prenantes discutent d’un incrément produit en attente pendant une réunion d’une durée maximale de huit heures : ils dé­ter­mi­nent ce que doit contenir cet incrément et comment ils sou­hai­tent atteindre ce résultat. Le Backlog Produit sert de point de départ à la pla­ni­fi­ca­tion. L’équipe de dé­ve­lop­peurs et le Product Owner s’entendent sur les objectifs pouvant être atteints au cours du mois à venir. L’équipe de dé­ve­lop­peurs discute ensuite de la façon dont les tâches doivent être réalisées. À la fin de la réunion, les dé­ve­lop­peurs doivent pouvoir s’en­tre­te­nir de leur plan avec le Product Owner et le Scrum Master.

Une Mêlée quo­ti­dienne (Daily Scrum) doit avoir lieu chaque jour d’un Sprint – toujours au même moment et au même endroit afin d’éco­no­mi­ser sur les frais d’or­ga­ni­sa­tion. Dans le cadre de cette réunion de 15 minutes, l’équipe de dé­ve­lop­peurs fait le tour des tâches à réaliser dans la journée et de ce qui a été effectué la veille. Les dé­ve­lop­peurs évaluent également l’avancée globale du projet : Où en est-on dans le trai­te­ment des entrées du Backlog ? Ce re­cou­pe­ment quotidien permet de garantir que toutes les parties prenantes gardent un œil sur l’objectif ce qui, à terme, augmente également la pro­duc­ti­vité.

Le Scrum Master veille à la tenue de cette mêlée quo­ti­dienne, mais son contenu est décidé par les dé­ve­lop­peurs. Ils dé­ter­mi­nent quels seront les thèmes abordés. Le Scrum Master n’in­ter­vient pas tant que le contenu de cette réunion porte sur l’ac­com­plis­se­ment de l’objectif du Sprint et qu’elle ne dépasse pas 15 minutes. Il veille également à ce que les autres personnes assistant à la mêlée quo­ti­dienne ne per­turbent pas les dé­ve­lop­peurs dans leur travail.

Une revue de Sprint (Sprint Review) est effectuée à la fin de chaque Sprint : elle consiste à vérifier l’incrément produit. Les résultats sont analysés con­join­te­ment avec des personnes ne faisant pas partie de l’équipe Scrum, mais ayant un intérêt con­si­dé­rable au produit, par exemple les pro­prié­taires de l’en­tre­prise ou les clients (regroupés sous le terme Sta­ke­hol­der dans Scrum). Cette revue aborde le processus de travail en tant que tel, revient sur les problèmes ren­con­trés lors du dé­ve­lop­pe­ment et comporte un échange sur les défis à relever. Elle a également une influence sur la suite de la pla­ni­fi­ca­tion, car le Product Owner utilise cette op­por­tu­nité pour aborder les progrès du Backlog. Les con­clu­sions du Sprint impactent les pro­nos­tics pour les futures pres­ta­tions.

La situation cor­res­pon­dante du marché a également une influence sur le Backlog : pour les projets à long terme, en par­ti­cu­lier, certaines priorités peuvent être reportées au fil du temps et les budgets peuvent être modifiés. Ces sujets sont également pris en compte dans la revue de Sprint et viendront modifier la stratégie future. En cas de Sprint d’un mois, la revue ne doit pas durer plus de quatre heures.

La revue du Sprint est suivie par un autre examen : la ré­tros­pec­tive de Sprint (Sprint Re­tros­pec­tive). Au cours d’une réunion de trois heures au maximum, l’ensemble de l’équipe Scrum (c’est-à-dire l’équipe de dé­ve­lop­peurs, le Product Owner et le Scrum Master, mais pas les Sta­ke­hol­ders) se réunit pour apporter un feed-back. Si la revue se concentre prin­ci­pa­le­ment sur le produit et l’avancée du projet, la ré­tros­pec­tive s’intéresse ma­jo­ri­tai­re­ment au travail en équipe. L’objectif de ce second examen est d’améliorer le travail collectif et de résoudre les problèmes internes. Dès qu’un Sprint est achevé, le suivant lui succède en com­men­çant par la phase de pla­ni­fi­ca­tion du Sprint.

Les objets appelés artefacts jouent un rôle essentiel dans Scrum. Parmi les artefacts, on trouve d’une part le Backlog Produit et le Backlog Sprint, et d’autre part, l’incrément achevé.

La trans­pa­rence est un facteur crucial dans Scrum. Toutes les parties prenantes doivent pouvoir accéder aussi fa­ci­le­ment que possible et à tout moment à l’ensemble des in­for­ma­tions. C’est pourquoi il convient de formuler les artefacts Scrum de façon simple et com­pré­hen­sible lors de leur con­cep­tion. Dans le cas du Backlog Produit, cette res­pon­sa­bi­lité incombe au Product Owner : le Backlog est une liste ordonnée de tous les éléments décisifs pour le produit. En font notamment partie, les fonc­tion­na­li­tés du produit, mais aussi les cor­rec­tions d’erreurs ou les amé­lio­ra­tions.

Le travail sur le Backlog Produit est effectué en continu : cette liste est tenue de façon dynamique – de nouveaux éléments peuvent être intégrés à tout moment et font en sorte que les entrées puissent être plus clai­re­ment dif­fé­ren­ciées, de nouvelles tâches s’y ajoutent et le clas­se­ment est ajusté. Au départ, le Product Owner est souvent assisté du Scrum Master lors de la création. En raison de leur ex­pé­rience, les Scrum Masters savent comment formuler le document afin de sa­tis­faire aux exigences de trans­pa­rence et d’ef­fi­ca­cité. Les entrées doivent gé­né­ra­le­ment être alignées sur les exigences du client. Outre une des­crip­tion des ca­rac­té­ris­tiques demandées, ce document comporte également une note sur la charge de travail ainsi qu’une entrée con­cer­nant les niveaux de priorité.

En plus du Backlog Produit, il existe également un Backlog Sprint qui est généré à partir du premier document. Le Backlog Sprint regroupe toutes les entrées du Backlog Produit sé­lec­tion­nées pour la pla­ni­fi­ca­tion du Sprint à venir. Ce Backlog présente ainsi toutes les étapes jusqu’à l’objectif du Sprint cor­res­pon­dant. Pendant la mêlée quo­ti­dienne, l’avancée est évaluée sur la base du Backlog Sprint. Cette liste peut également être ac­tua­li­sée en cours de Sprint afin de cor­res­pondre aux exigences et aux défis de l’équipe. C’est la raison pour laquelle la res­pon­sa­bi­lité de procéder aux mo­di­fi­ca­tions dans le Backlog Sprint incombe également aux dé­ve­lop­peurs. Ni le Product Owner ni le Scrum Master ne peuvent modifier cette liste.

À la fin d’un Sprint, l’équipe de dé­ve­lop­peurs présente l’incrément, c’est-à-dire le résultat de la phase de dé­ve­lop­pe­ment. Un incrément doit contenir toutes les entrées du Backlog Sprint ainsi que tous les in­cré­ments des Sprints pré­cé­dents. Un incrément doit pouvoir être livré tel quel, tout du moins en théorie. Il doit être prêt à l’emploi, même s’il n’est pas ef­fec­ti­ve­ment prévu de le livrer. L’équipe présente l’incrément dans la revue de Sprint où le Product Owner et les Sta­ke­hol­ders pourront en évaluer le résultat.

Que ce soit par com­pa­rai­son avec d’autres méthodes agiles ou avec des méthodes de gestion plus tra­di­tion­nelles, Scrum offre certains avantages. Ils résident prin­ci­pa­le­ment dans l’approche pro­gres­sive et dans les quelques règles limitant l’équipe Scrum :

• Com­mu­ni­ca­tion : Une bonne gestion de projet peut uni­que­ment fonc­tion­ner si tous les membres de l’équipe sont au même niveau. Scrum accorde une grande im­por­tance au fait que les col­la­bo­ra­teurs com­mu­ni­quent beaucoup entre eux. C’est pourquoi les évé­ne­ments Scrum ont un rythme re­la­ti­ve­ment élevé. La réunion quo­ti­dienne en début de journée veille à ce qu’aucun dé­ve­lop­peur n’avance plus vite que les autres alors que la ré­tros­pec­tive finale permet d’aborder les problèmes au sein de l’équipe.
• Flexi­bi­lité : Dans Scrum, on utilise des Sprints re­la­ti­ve­ment courts. Étant donné qu’un mois sépare au maximum deux réunions de pla­ni­fi­ca­tion, il est également possible de modifier le projet à court terme et de l’adapter à de nouvelles exigences.
• Trans­pa­rence : La com­mu­ni­ca­tion constante entre tous les membres de l’équipe de même que la con­cep­tion des artefacts Scrum ga­ran­tis­sent un haut niveau de trans­pa­rence. Les Backlogs sont formulés de telle sorte que chaque par­ti­ci­pant s’y retrouve fa­ci­le­ment et trouve les in­for­ma­tions né­ces­saires con­cer­nant le projet.
• Contrôle de la qualité : Le principe itératif de Scrum assure un contrôle constant du produit. Aussi bien les cor­rec­tions des erreurs que les amé­lio­ra­tions sont intégrées au Backlog Produit. L’équipe de dé­ve­lop­peurs présente d’autre part un incrément fini dans le cadre de la revue de Sprint. Le Product Owner et les Sta­ke­hol­ders ont ainsi la pos­si­bi­lité de s’assurer de la qualité. En cas d’erreur lors du dé­ve­lop­pe­ment, cela permet de réagir nettement plus ra­pi­de­ment par rapport à une méthode où l’erreur serait uni­que­ment constatée en fin de projet.
• Créa­ti­vité : Scrum est basé sur l’auto-or­ga­ni­sa­tion de l'équipe. Plutôt que d’obtenir la manière de procéder d’un supérieur, les dé­ve­lop­peurs s’attellent à leurs tâches avec leurs propres idées. De plus, comme le framework de Scrum est ouvert et dispose de peu de règles con­trai­re­ment à d’autres méthodes, les dif­fé­rents membres de l’équipe peuvent apporter librement leurs idées.
• Ef­fi­ca­cité : Par com­pa­rai­son avec une gestion de projet classique, Scrum nécessite une do­cu­men­ta­tion nettement moins im­por­tante. L’accent est mis sur la fonc­tion­na­lité du produit plutôt que sur une do­cu­men­ta­tion sans faille qui coûterait du temps et des res­sources. L’équipe peut plei­ne­ment se con­cen­trer sur le travail de dé­ve­lop­pe­ment lors du Sprint et le réaliser comme elle l’entend.

Malgré des avantages in­dé­niables, Scrum ne convient pas à toutes les en­tre­prises. Les in­con­vé­nients suivants ex­pli­quent pourquoi Scrum n’est pas une solution idéale pour certaines en­tre­prises :

• Une absence de vue d’ensemble : Ce qui constitue un énorme avantage pour une équipe ne l’est pas né­ces­sai­re­ment pour une autre : le fait de planifier par très petites étapes peut empêcher d’avoir une vue globale sur le projet.
• Une com­mu­ni­ca­tion la­bo­rieuse : Les évé­ne­ments Scrum sont prévus à un rythme régulier. Mais pour certaines équipes et certains projets, ce volume de com­mu­ni­ca­tion con­si­dé­rable peut s’avérer inutile. Dans de tels cas, les mêlées quo­ti­diennes sont plutôt un frein à la pro­duc­ti­vité. On passe alors davantage de temps à organiser et à com­mu­ni­quer qu’à tra­vail­ler vé­ri­ta­ble­ment sur le produit.
• In­cer­ti­tude en matière de pla­ni­fi­ca­tion et de res­pon­sa­bi­lité : Scrum prévoit que les équipes s’auto-or­ga­ni­sent. Cela peut se révéler très avan­ta­geux, mais dans certains domaines et secteurs, une hié­rar­chie ho­ri­zon­tale de ce type peut également entraîner une in­cer­ti­tude dans la pla­ni­fi­ca­tion et en matière de res­pon­sa­bi­lité.
• Im­pos­si­bi­lité d’in­té­gra­tion : Dans certaines struc­tures d’en­tre­prises, l’in­té­gra­tion de Scrum né­ces­si­te­rait des ajus­te­ments majeurs. Dans de tels cas, il convient alors de se demander si Scrum apporte un réel gain d’ef­fi­ca­cité.

Il vous revient donc de juger si Scrum convient également à votre en­tre­prise et d’estimer si des hié­rar­chies ho­ri­zon­tales et une com­mu­ni­ca­tion régulière dans les équipes Scrum ap­por­te­raient un gain de pro­duc­ti­vité à votre en­tre­prise et une plus grande qualité de travail et de produit.