Scrum : Une gestion de projet agile – moderne et flexible

Aujourd’hui, lorsque des équipes commencent un projet, elles ne se lancent pas tête baissée dans le travail. Les commandes les plus importantes, en particulier, requièrent une gestion de projet et de produit efficace. La méthode agile Scrum est actuellement la pratique la plus courante dans de nombreuses entreprises. Cette approche met l’accent sur des méthodes de travail flexibles, un développement incrémental et des procédures transparentes. Dans le contexte de la gestion de projet agile Scrum, on rencontre de plus en plus fréquemment le terme « Scrum ». Conçu initialement pour le développement logiciel, ce modèle est aujourd’hui également apprécié dans de nombreux autres secteurs. Dans cet article, nous vous expliquons ce que recouvre exactement ce mot à la mode.

Même si la forme qu’on lui connaît actuellement date de 1995, l’histoire de Scrum remonte aux années 1980. En 1980, Ken Schwaber et Jeff Sutherland, qui avaient d’ores et déjà utilisé des modèles similaires individuellement dans leurs entreprises, ont publié un papier commun. Cet article avait pour objectif d’augmenter la productivité du travail tout en introduisant un minimum de règles susceptibles de la limiter.

Pour y parvenir, Scrum établit un cadre de travail (framework) utilisable dans différentes situations. L’objectif est d’améliorer continuellement notre façon de travailler ainsi que le produit. Pour ce faire, le framework comporte des rôles, des événements, 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’utilisateur occupent donc une place essentielle dans Scrum puisque le développement 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 planification à l’évaluation en passant par le développement et la phase de test avant de revenir à la phase de planification. Scrum ne porte donc pas uniquement sur la production initiale, mais aussi sur les développements ultérieurs.
• incrémental : Scrum est basé sur l’idée qu’un produit est le résultat d’une succession d’étapes qui représentent des objectifs intermédiaires. La méthode Scrum se démarque ainsi de l’approche visant à atteindre un seul objectif majeur en fin de développement. Les grands projets sont divisés en projets de moindre envergure pour permettre une plus grande flexibilité.

En combinant les approches itérative et incrémentale, on obtient un processus progressif et durable dans le cadre du développement. D’une part, le processus est alors nettement plus transparent puisqu’il prévoit des contrôles fréquents du travail (résultant de l’approche par petites étapes successives) et d’autre part, il permet d’améliorer la qualité du produit puisque sa fonctionnalité est contrôlée en continu.

À l’origine, Scrum vient du développement logiciel agile. On utilise la méthode agile Scrum pour améliorer en permanence le travail effectué sur les programmes. Mais Scrum est également utilisé avec succès pour d’autres produits – par exemple dans la fabrication de matériel informatique. Chaque projet Scrum ne s’achève toutefois pas nécessairement 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’administration ainsi que pour le développement de prestations 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épondérante au travail d’équipe dont les diffé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énements et des artefacts déterminés.

Une équipe Scrum comporte trois rôles fixes : l’équipe de développement, le Product Owner et le Scrum Master. L’équipe regroupe les développeurs du produit à proprement parler. Le groupe est composé de telle sorte qu’il peut s’auto-organiser afin de déterminer comment accomplir un objectif convenu. Par ailleurs, les équipes Scrum ne disposent pas de hiérarchie. Chaque collaborateur a bien sûr son propre domaine de responsabilité, mais au final, l’équipe rend compte du produit de façon commune.

La taille de l’équipe n’est pas clairement définie : elle doit être composée de façon à pouvoir agir rapidement et avec flexibilité tout en restant performante, c’est-à-dire être ni trop grande ni trop petite. K. Schwaber et J. Sutherland proposent de composer des équipes de 3 à 9 membres.

Dans une équipe Scrum, le Product Owner est responsable 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 informations sur le Backlog Produit sont disponibles au point Artefacts Scrum.) Il a également pour tâche d’organiser les objectifs selon un ordre pertinent et de les documenter de façon compréhensible. Le Product Owner est un rôle directif : même si les équipes définissent personnellement la façon dont elles envisagent d’atteindre les objectifs formulés dans le Backlog, la détermination des objectifs est la responsabilité du Product Owner. Et il ne saurait être remis en question : pour atteindre une productivité maximale, l’équipe doit pouvoir se reposer sur les décisions du Product Owner. Cependant, on ne peut pas considérer le Product Owner comme un cadre de direction : le Product Owner et son équipe ont des tâches distinctes 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éveloppement.

Le Scrum Master fait office de médiateur entre les deux autres rôles. Les Scrum Masters ont pour responsabilité d’intégrer et de mettre en œuvre Scrum dans le processus de travail. Par conséquent, ce rôle est également responsable de l’organisation des événements Scrum : il fixe les réunions et en assure la modération. Le Scrum Master se tient également prêt à assister l’équipe et le Product Owner, mais n’intervient jamais dans le processus de développement à proprement parler. Sa fonction consiste uniquement à simplifier les processus de travail pour les collaborateurs participants à la production et ainsi, à augmenter la productivité et la créativité.

En tant qu’interlocuteur, le Scrum Master veille à la bonne compréhension des processus par les parties prenantes : il donne des conseils pour la création des Backlogs ou l’organisation de l’équipe et, de façon générale, essaie d’éliminer les obstacles. Le Scrum Master intervient donc notamment en tant que coach. Ce rôle implique de parfaitement connaître Scrum, raison pour laquelle une certification en tant que Scrum Master est proposée. Il existe aujourd’hui plusieurs organismes de certifications proposant des formations correspondantes. La Scrum Alliance et Scrum.org ont été fondées par Ken Schwaber et proposent les certificats Certified Scrum Master ou Professional Scrum Master.

Un processus de travail organisé selon le principe de Scrum fait intervenir des événements récurrents. Puisque Scrum est un processus itératif, le travail est accompli dans des cycles répétitifs : chaque événement est répété à chaque nouveau cycle. Grâce à la fréquence de ces événements, les réunions imprévues ne sont que rarement ou absolument pas nécessaires. Tous les événements 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éveloppement. À la fin d’un Sprint, l’équipe de développement livre un incrément produit fini. Cela signifie que le développement doit avoir donné naissance à un produit potentiellement livrable. Chaque Sprint a ainsi une mission concrète que l’on marque comme « terminée » à la fin du cycle. La limite temporelle d’un Sprint est définie au préalable, mais ne devrait pas dépasser 30 jours. Pour déterminer 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élibé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érification du développement au minimum une fois par mois. Dans des cas exceptionnels, le Product Owner (et uniquement lui) peut annuler un Sprint. Une telle annulation est par exemple possible lorsqu’il n’est plus nécessaire d’atteindre l’objectif, car l’entreprise a fixé un nouvel objectif entre-temps. En principe, les Sprints ne doivent pas être annulés, car cette annulation diminue fortement la productivité.

Un Sprint commence avec la Planification du Sprint (Sprint Planning) : tous les rôles de l’équipe Scrum participent à 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éterminent ce que doit contenir cet incrément et comment ils souhaitent atteindre ce résultat. Le Backlog Produit sert de point de départ à la planification. L’équipe de développeurs et le Product Owner s’entendent sur les objectifs pouvant être atteints au cours du mois à venir. L’équipe de développeurs discute ensuite de la façon dont les tâches doivent être réalisées. À la fin de la réunion, les développeurs doivent pouvoir s’entretenir de leur plan avec le Product Owner et le Scrum Master.

Une Mêlée quotidienne (Daily Scrum) doit avoir lieu chaque jour d’un Sprint – toujours au même moment et au même endroit afin d’économiser sur les frais d’organisation. Dans le cadre de cette réunion de 15 minutes, l’équipe de développeurs fait le tour des tâches à réaliser dans la journée et de ce qui a été effectué la veille. Les développeurs évaluent également l’avancée globale du projet : Où en est-on dans le traitement des entrées du Backlog ? Ce recoupement quotidien permet de garantir que toutes les parties prenantes gardent un œil sur l’objectif ce qui, à terme, augmente également la productivité.

Le Scrum Master veille à la tenue de cette mêlée quotidienne, mais son contenu est décidé par les développeurs. Ils déterminent quels seront les thèmes abordés. Le Scrum Master n’intervient pas tant que le contenu de cette réunion porte sur l’accomplissement 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 quotidienne ne perturbent pas les développeurs 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 conjointement avec des personnes ne faisant pas partie de l’équipe Scrum, mais ayant un intérêt considérable au produit, par exemple les propriétaires de l’entreprise ou les clients (regroupés sous le terme Stakeholder dans Scrum). Cette revue aborde le processus de travail en tant que tel, revient sur les problèmes rencontrés lors du développement et comporte un échange sur les défis à relever. Elle a également une influence sur la suite de la planification, car le Product Owner utilise cette opportunité pour aborder les progrès du Backlog. Les conclusions du Sprint impactent les pronostics pour les futures prestations.

La situation correspondante du marché a également une influence sur le Backlog : pour les projets à long terme, en particulier, 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étrospective de Sprint (Sprint Retrospective). Au cours d’une réunion de trois heures au maximum, l’ensemble de l’équipe Scrum (c’est-à-dire l’équipe de développeurs, le Product Owner et le Scrum Master, mais pas les Stakeholders) se réunit pour apporter un feed-back. Si la revue se concentre principalement sur le produit et l’avancée du projet, la rétrospective s’intéresse majoritairement 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 commençant par la phase de planification 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 transparence est un facteur crucial dans Scrum. Toutes les parties prenantes doivent pouvoir accéder aussi facilement que possible et à tout moment à l’ensemble des informations. C’est pourquoi il convient de formuler les artefacts Scrum de façon simple et compréhensible lors de leur conception. Dans le cas du Backlog Produit, cette responsabilité 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 fonctionnalités du produit, mais aussi les corrections d’erreurs ou les améliorations.

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 clairement différenciées, de nouvelles tâches s’y ajoutent et le classement est ajusté. Au départ, le Product Owner est souvent assisté du Scrum Master lors de la création. En raison de leur expérience, les Scrum Masters savent comment formuler le document afin de satisfaire aux exigences de transparence et d’efficacité. Les entrées doivent généralement être alignées sur les exigences du client. Outre une description des caractéristiques demandées, ce document comporte également une note sur la charge de travail ainsi qu’une entrée concernant 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électionnées pour la planification du Sprint à venir. Ce Backlog présente ainsi toutes les étapes jusqu’à l’objectif du Sprint correspondant. Pendant la mêlée quotidienne, l’avancée est évaluée sur la base du Backlog Sprint. Cette liste peut également être actualisée en cours de Sprint afin de correspondre aux exigences et aux défis de l’équipe. C’est la raison pour laquelle la responsabilité de procéder aux modifications dans le Backlog Sprint incombe également aux développeurs. Ni le Product Owner ni le Scrum Master ne peuvent modifier cette liste.

À la fin d’un Sprint, l’équipe de développeurs présente l’incrément, c’est-à-dire le résultat de la phase de développement. Un incrément doit contenir toutes les entrées du Backlog Sprint ainsi que tous les incré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 effectivement prévu de le livrer. L’équipe présente l’incrément dans la revue de Sprint où le Product Owner et les Stakeholders pourront en évaluer le résultat.

Que ce soit par comparaison avec d’autres méthodes agiles ou avec des méthodes de gestion plus traditionnelles, Scrum offre certains avantages. Ils résident principalement dans l’approche progressive et dans les quelques règles limitant l’équipe Scrum :

• Communication : Une bonne gestion de projet peut uniquement fonctionner si tous les membres de l’équipe sont au même niveau. Scrum accorde une grande importance au fait que les collaborateurs communiquent beaucoup entre eux. C’est pourquoi les événements Scrum ont un rythme relativement élevé. La réunion quotidienne en début de journée veille à ce qu’aucun développeur n’avance plus vite que les autres alors que la rétrospective finale permet d’aborder les problèmes au sein de l’équipe.
• Flexibilité : Dans Scrum, on utilise des Sprints relativement courts. Étant donné qu’un mois sépare au maximum deux réunions de planification, il est également possible de modifier le projet à court terme et de l’adapter à de nouvelles exigences.
• Transparence : La communication constante entre tous les membres de l’équipe de même que la conception des artefacts Scrum garantissent un haut niveau de transparence. Les Backlogs sont formulés de telle sorte que chaque participant s’y retrouve facilement et trouve les informations nécessaires concernant le projet.
• Contrôle de la qualité : Le principe itératif de Scrum assure un contrôle constant du produit. Aussi bien les corrections des erreurs que les améliorations sont intégrées au Backlog Produit. L’équipe de développeurs présente d’autre part un incrément fini dans le cadre de la revue de Sprint. Le Product Owner et les Stakeholders ont ainsi la possibilité de s’assurer de la qualité. En cas d’erreur lors du développement, cela permet de réagir nettement plus rapidement par rapport à une méthode où l’erreur serait uniquement constatée en fin de projet.
• Créativité : Scrum est basé sur l’auto-organisation de l'équipe. Plutôt que d’obtenir la manière de procéder d’un supérieur, les développeurs 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 contrairement à d’autres méthodes, les différents membres de l’équipe peuvent apporter librement leurs idées.
• Efficacité : Par comparaison avec une gestion de projet classique, Scrum nécessite une documentation nettement moins importante. L’accent est mis sur la fonctionnalité du produit plutôt que sur une documentation sans faille qui coûterait du temps et des ressources. L’équipe peut pleinement se concentrer sur le travail de développement lors du Sprint et le réaliser comme elle l’entend.

Malgré des avantages indéniables, Scrum ne convient pas à toutes les entreprises. Les inconvénients suivants expliquent pourquoi Scrum n’est pas une solution idéale pour certaines entreprises :

• Une absence de vue d’ensemble : Ce qui constitue un énorme avantage pour une équipe ne l’est pas nécessairement pour une autre : le fait de planifier par très petites étapes peut empêcher d’avoir une vue globale sur le projet.
• Une communication laborieuse : Les événements Scrum sont prévus à un rythme régulier. Mais pour certaines équipes et certains projets, ce volume de communication considérable peut s’avérer inutile. Dans de tels cas, les mêlées quotidiennes sont plutôt un frein à la productivité. On passe alors davantage de temps à organiser et à communiquer qu’à travailler véritablement sur le produit.
• Incertitude en matière de planification et de responsabilité : Scrum prévoit que les équipes s’auto-organisent. Cela peut se révéler très avantageux, mais dans certains domaines et secteurs, une hiérarchie horizontale de ce type peut également entraîner une incertitude dans la planification et en matière de responsabilité.
• Impossibilité d’intégration : Dans certaines structures d’entreprises, l’intégration de Scrum nécessiterait des ajustements majeurs. Dans de tels cas, il convient alors de se demander si Scrum apporte un réel gain d’efficacité.

Il vous revient donc de juger si Scrum convient également à votre entreprise et d’estimer si des hiérarchies horizontales et une communication régulière dans les équipes Scrum apporteraient un gain de productivité à votre entreprise et une plus grande qualité de travail et de produit.